Clear questions and runnable code
get the best and fastest answer
Re^18: The Most Essential Perl Development Tools Today (negative)by BrowserUk (Pope)
|on Jan 14, 2013 at 12:42 UTC||Need Help??|
Class::XSAccessor is freakishly fast. Given that a sub call still has to happen, you wouldn't expect it to eliminate that much overhead.
Indeed. (As you may remember) I dismissed the idea that writing accessors in XS would yield much benefit, which just points up my own stupidity.
Given that I have often lamanted the cost of Perl's subroutine calls, I should have been open to the idea that there was scope [sic] for skipping some of the belt&braces stuff required for the general case -- to cater for ties and the like -- provided one is prepared to live with the need for additional restrictions and caveats. And provided you are sufficiently conversant with the nitty gritty of perl's internals.
In my defense, I've tried a couple of times to optimise the calling mechanism required by a few of my XS/Inline C subs by omitting unnecessary ENTER/LEAVE/PUTBACK et. al. calls; but I've nearly always come up wanting.
My first attempts were based upon the optimisations done for the callback subroutines in List::Util::reduce() which are measurably more effective than using the boilerplate conventions outlined in perlcall. But it took the authors/maintainers of that module many releases to fix all the bugs and memory leaks that optimisation introduced; and my attempts to replicate their effort fell short for want of a clear understanding of the purpose of all of the macros involved,
It does do one slightly scary thing though...
That is an unfortunate side effect; but one I could live with -- subject to clear documentation -- if I had the need for it.
PS: there is Class::XSAccessor::Array as part of the same distribution.
Cool. I shall investigate.
For the most part, I do not feel the need for the use of getters and setters in classes.
I generally believe that nothing external to the class should be given the ability to access the classes attributes directly. All changes to attributes should happen as a result of asking the object to do something to itself.
And I don't see the real-world benefit in the use of accessors internally to the class. The theory goes that if you avoid direct access to your attributes, you can -- if the need arises -- change the internal structure or representation of the class without re-writing all the methods.
Which is a fine & dandy theoretical nice-to-have, but in 20+ years of writing OO code, I've never seen a single situation where the internal structure changed in such a trivial way that it didn't require the methods to also be re-written anyway.
And in the world of dynamic, interpreted languages -- where the lack of macro abilities and compile-time analysis and optimisations mean that such nice-to-haves exact a considerable runtime cost; I'd rather dispense with the small possibility of some future saving of effort; for the real, measurable and ongoing runtime saving that I get by having my methods access their attributes directly.
In short, I rarely find the need for accessors. There are occasional C++ 'friend' type subclass requirements, but they are far too rare in the real world to consider catering for them in the general case.
But when they do crop up, I shall now go looking for Class::XSAccessor to fulfill them :)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.