[Petal] Modifiers and variables

[Steve Purkis]

On Aug 18, 2004, at 13:57, Jean-Michel Hiver wrote:

> 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 say, what a brilliant idea! :-)

> I don't really see the advantage of /enforcing/ this syntax though.

Well, maybe don't enforce it, but *strongly recommend* it.
The advantage is a consistent API for people writing Petal modifiers so 
the wheel isn't re-invented 100 times.  As William points out, that's 
essentially what we've tried to do with the Petal::Utils::Base class, 
but really this is Petal's area of responsibility.


>  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).

I think the most important thing to stress is the fact that there needs 
to be a standard set of methods to parse modifier args, *and* a base 
class for plugins.  I think you already mentioned this, but: That's not 
to say that you can't do your own parsing, just that it's not the 
default way of doing things.

I quite like Fergal's idea about pre-parsing args if 
$module->can("new_process")... means less repetitive work for plugin 
writers.  Sure you'd run into problems when you do your own parsing 
(the "if: .. then: ... else: ..." modifier is implemented as only 1 
modifier, for example, but would prolly be pre-parsed as 3).  But you'd 
get around that by having a plain old "process" method.  Cool.
(One thing -- 'new_process' could be better named.  Maybe 
'process_with_preprocessed_args', or 'process_with_args' ?)

And if you did do your own parsing, ideally you'd be using the parsing 
methods.  For example, Petal::Utils::Base has this little helper:

	# my ($arg1, $other_args) = $self->split_first_arg( $args );
	sub split_first_arg {
	    my $class = shift;
	    my $args  = shift;
	    # don't use split(/\s/,...) as we might kill an expression that way
	    return ($args =~ /\A(.+?)\s+(.*)\z/);
	}

Ok, so it's horribly named, but it's these kind of parsing methods that 
would be quite helpful.  William's was talking about adding a 
"fetch_arg" (by Warren Smith), and I'm sure there are plenty of other 
useful things that Petal prolly does already.  It would be a matter of 
refactoring Petal's parsing engine to present these in an API.

Finally, it certainly wouldn't be bad to keep existing model for 
backwards compat... you could always throw 'deprecated' warnings.


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

Well, I'm sure that'll clear things up (*ahem* ;-)

Right, back to lurking for me.

-Steve