Re: Modifiers and variables

William McKee wrote:

>On Mon, Aug 16, 2004 at 09:42:48AM +0100, Jean-Michel Hiver wrote:
>  
>
>>How do you mean? When you write a modifier, you have access to the raw 
>>string that comes after the modifier. What you do with that string is up 
>>to you.
>>    
>>
>
>Exactly, which is where the problem lies. If each modifier author is
>writing custom code to break up the string, there is no consistency in
>Petal's modifiers.
>
I see. Well, I wouldn't adding a base class (i.e. Petal::Plugin) which 
would be the recommended method to implement new modifiers, and then 
cabling existing modifiers onto Petal::Plugin.

I don't really see the advantage of /enforcing/ this syntax though. What 
happens when you DO want your own syntax? At the moment the string: 
modifier is quite important to me as I use it in conjunction with a 
translation service (if there is one).

In other words, I am confused and I'm not sure :-)

>I'm not sure that I follow what you mean by an abstract modifier. Would
>my custom modifier inherit from that? If so, this is essentially what
>Petal::Utils is doing now.
>
Looks like it's time to go steal some code from there...

>I was hoping to have a standard method for
>extracting the arguments from the string but migrating the Plugin
>modifier architecture from Petal::Utils into Petal would be great (I
>know Steve would be all for this).
>
But surely the abstract class then becomes the standard method. Except 
that if you don't want to use the standard method, well, you don't have 
to. Does it make sense?

>That's what I was wondering. Since we're out on a limb, I guess we can
>make up anything we want. I'm going to add the proposed functionality to
>Petal::Utils::fetch_arg. Perhaps it can eventually be merged into Petal.
>
Well, " string: " is also implemented by ZPT. They also implement 
python: but I think it's a mistake so I made a conscious decision NOT to 
implement 'perl:', although it would be trivial.