note BrowserUk <blockquote><i>Class::XSAccessor is freakishly fast. Given that a sub call still has to happen, you wouldn't expect it to eliminate that much overhead.</i></blockquote> <p>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. <p>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 &#91;sic&#93; 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. <p>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. <p>My first attempts were based upon the optimisations done for the callback subroutines in [mod://List::Util]<c>::reduce()</c> 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, <blockquote><i>It does do one slightly scary thing though...</i></blockquote> <p>That is an unfortunate side effect; but one I could live with -- subject to clear documentation -- if I had the need for it. <blockquote><i>PS: there is Class::XSAccessor::Array as part of the same distribution.</i></blockquote> <p>Cool. I shall investigate. <p>For the most part, I do not feel the need for the use of getters and setters in classes. <p>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. <p>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. <p>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. <P>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. <p>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. <p>But when they do crop up, I shall now go looking for [mod://Class::XSAccessor] to fulfill them :) <div class="pmsig"><div class="pmsig-171588"> <hr /> <font size=1 > <div>With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'</div> <div>Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.</div> <div>"Science is about questioning the status quo. Questioning authority". </div> <div>In the absence of evidence, opinion is indistinguishable from prejudice. </div> </font> </div></div> 1011175 1013170