Re: [SMARTY-DEV] Re: [SMARTY] modifier_string_format in 2.5.0-RC1

func_get_args() was not available when Smarty was first written. Also, args cannot be passed by reference this way. On Thu, 2003-03-06 at 16:04, messju mohr wrote: > On Thu, Mar 06, 2003 at 03:55:47PM -0600, Monte Ohrt wrote: > > Hmm, I'm not the originating author of the modifier structure, but I'll > > take a guess :-) Function attributes have name/value pairs so an > > associative array makes sense, and order is not an issue. OTOH, modifier > > parameters are only values so their order is important. I suppose they > > could have been passed as an enumerated array of values, that way the > > second parameter can be the smarty object much the same as functions > > are. But then your modifier would need to know what each value of > > $params[0], $params[1], etc. are for without an intuitive name. > > one can use func_get_args() to write modifiers with a variable number > arguments, so there is no need to break bc for this. > > but having &$smarty available in modifiers would be worth it for me... :) > > > > > Monte > > > > > > > Ok, I see the difference and how it works now, though I can't say that > > > it is the most intuitive implementation. Usually the modifier modifies > > > the string it is attached to, not the other way around. For people like > > > myself who want it the other way, and for the sake of backwards > > > compatibility, one can simply register the modifier in the code as I > > > have done. > > > > > > As an idea for being able to attach what is basically a dynamic amount > > > of arguments to a modifier, why don't you make modifiers work the way > > > function plugins do: pass a $params variable that is an array of all the > > > arguments? That seems to be somewhat logical and at the same time > > > backwards compatible with existing templates, even though all modifier > > > plugins will have to be rewritten. > > > > > > ~Paul -- Monte Ohrt <monte@ispi.net>