----- Original Message ---- > From: Dermot <[email protected]>
> Why wouldn't you, as you write, use the the fastest access methods > available? Surely you'd want to develop habits that will a) provide > better performance and b) as mentioned below avoid the thorny > side-effects of req->params(). This isn't a matter of premature > optimisation but simply establishing good practise. This is a very common trap that many developers (even experienced ones) get caught up in. Let's make *everything* faster and our app is faster. A month of optimisation could easily result in no benefits because what developers think is slow rarely matches what *is* slow unless the developers have carefully profiled their application. The problem, as has been pointed out, is that ENCAPSULATION is so terribly, terribly important -- and almost always more important that micro-optimisation -- that throwing away the known, constant benefits of encapsulation for unknown, occasional benefits of micro-optimisation would be a very, very bad idea for the community in general. It might be OK for you, but it's not OK for me. Without encapsulation, it's much harder to trust the correctness of my app. In other words: give me a slower, but correct application over a faster, but unreliable one any day of the week. Of course, if you can think of a way of dramatically improving the performance of the accessors without violating encapsulation, I'm sure patches would be gratefully received. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
