[Petal] Accessor methods in path statements? - Comments please!

[Jean-Michel Hiver]

> Greetings, All!
> 
> After spending some time examining the internals of VAR.pm, I began to play
> around with the idea of allowing a single method argument to be declared
> directly in the path statement.  While this may seem rather upsetting at
> first, this is based on the following logic:
> 
> Why should the argument to an accessor method be treated any differently
> than a hash key or an array index?

That's a very interesting idea! To be honest when I wrote Petal I
hesitated in making the system so modular for performance reasons. But
now I'm glad to see people hacking around them!


> For example, imagine an application framework where the template is
> populated with a single application object.
> 
> $template->process($app);
> 
> In a contrived case, I could specify the path
> 
> <? petal:var name="app/forms/userinfo/fields/username/value" ?>
> 
> which maps to the method call:
> 
> $app->forms('userinfo')->fields('username')->value().

Yeah... But then it's a bit endless really... I mean, what if you wanted
to pass TWO arguments to a method call?

How about the following

  object/method=somestring=*somevalue/othermethod

Which would be equivalent to

  $object->method ('somestring', $hash->FETCH ('somevalue'))->othermethod();

Then there would be no possible confusion...


> Aside from this, the XVAR module has a few features that I think belong in
> the production version of VAR.pm.  I have wrapped the method calls in eval{}
> blocks, and changed the handling of autoloaded methods so that if AUTOLOAD
> fails with an 'Undefined subroutine' value in $@, the $next argument will
> still be tested as a possible hash key or array index.

One eval per method call... this might slow things down considerably
(need benchmarks !!!). Plus there is no guarantee that the AUTOLOAD will
die with "undefined subroutine" string (even if it's good practice...)

Maybe wrapping in one BIG eval would be an idea. Rather than dying, if
an expression fail, an appropriate value could be returned, i.e.

<?petal:var="really/silly/path"?>

Would produce:

[ Petal Runtime Error: unable to evaluate 'really/silly/path' ]



> Again, I stress that XVAR.pm is an experimental module that demonstrates
> alternate path semantics and possible improvements to the object handling
> code in VAR.pm.  It is intended for educational and entertainment purposes
> only!

Yes this is cool, I'll take a look at your code. Happy Petal Hacking!
Cheers,

-- 
IT'S TIME FOR A DIFFERENT KIND OF WEB
================================================================
  Jean-Michel Hiver - Software Director
  jhiver@mkdoc.com
  +44 (0)114 255 8097
================================================================
                                      VISIT HTTP://WWW.MKDOC.COM