Re: Re: [Mason-checkins] CVS: mason/dist/lib/HTML/Mason/Resolver File.pm,1.86,1.87

>>* Fix up the plugin architecture; change calling convention from a hash
>>  to a list of ordered arguments, for performance
> 
> 
> I object to this pretty strongly.  I don't mind switching internal
> interfaces, but this is intended for public consumption.  If it's an array
> (and a long one at that), adding new elements will be a big pain.
> 

Adding new elements would be easy as long as you add them to the end of 
the list. Plugin hooks don't have to grab everything from @_.

I acknowledge your point, and originally supported passing a hashref or 
hash. That was before I took a close look at performance. IMO it's 
critical to streamline $m->comp, to bring component calls as close as 
possible to subroutines without sacrificing user features. Creating a 
hash for both start and end plugins, then copying that hash twice when 
you call each plugin hook, is unnecessarily wasteful.

I could be convinced to change it back to a hashref and reusing the 
hashref for both the start and end hook (with more info available to the 
end hook). But passing/copying the full hash sacrifices performance for 
no other reason than we've always passed hashes in the past.

Though I actually think the plugin code reads better when everything is 
passed in @_, e.g. $comp and $args instead of $context->{comp} and 
$context->{args}.

Jon



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl