Sam Tregar <[EMAIL PROTECTED]> writes: > On 22 Apr 2002, Gregory Stark wrote: > > > a) If param() were change to instead of looping through all of the keys of the > > argument to instead loop through all of the required template parameters > > and check for them in the hash. This would allow me to implement a FETCH > > method that does the necessary logic and database work to fetch just the > > pieces that are actually needed in the template. This means the object > > wouldn't have to know in advance everything that the template needs and > > prepare all of it. > > Which would be slow, both in the tied() case and in the average case of > calling param() with some fraction of the total available parameter names.
Nobody's saying users would have to use the feature. Just that HTML::Template ought to not go out of its way to break it. If you're concerned about speed it still makes sense to reverse the loop logic like I describe. Consider the case where the template only uses a few fields out of a model that has hundreds. > > b) If param() were to accept an object for TMPL_LOOPs. It could call the > > iterator operator <$object> to retrieve the parameters for each element of > > the loop. This means I wouldn't have to fetch all of the elements at the > > start and put them in a prebuilt array, This would allow more general > > iterators to be used instead of just arrays. > > Which would also be slow since each loop through would require the > equivalent of a subroutine call. Sorry, I'm just far too interested in > being faster than the competition... You could, of course, sub-class > HTML::Template and build a param wrapper that does what you want. Again, just because it supported it doesn't mean anyone is forced to use it. You could keep passing an arrayref as a supported option too. There are plenty of cases where it might be much faster to work this way, consider the case of a database query that will return hundreds or thousands of records. By processing them as they arrive you're effectively pipelining with the network and the database latency instead of buffering the entire array in memory. -- Gregory Stark Ideas And Associates T +1 514 940 2891 x111 H +1 514 486 9705 C +1 514 945 3796 F +1 209 828 3730 http://www.ideasandassociates.com [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
