Re: [SMARTY-DEV] Re: [SMARTY] modifier_string_format in 2.5.0-RC1
| From: | messju mohr | Date: | Thu, 06 Mar 2003 22:21:20 +0000 |
| Subject: | Re: [SMARTY-DEV] Re: [SMARTY] modifier_string_format in 2.5.0-RC1 | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.smarty.dev |
| Request: | Send a blank email to php-smarty-dev+get-909@lists.php.net to get a copy of this message | ||
On Thu, Mar 06, 2003 at 04:12:33PM -0600, Monte Ohrt wrote:
> func_get_args() was not available when Smarty was first written. Also,
> args cannot be passed by reference this way.
hmm, i never needed to pass args by reference to a modifier AFAIR.
and func_get_args() is available in every version of php that supports
a reasonable up-to-date version of smarty.
> 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