On Mon, Jul 18, 2005 at 05:34:01PM -0400, Sam Tregar wrote:
> >
> > I'm also more interested in number 1 than number 2. Do you mean "get
> > behind" as in: "go forth and prepare a patch ye feature requester"
>
> I guess I mean if there was a module on CPAN that did this I might use
> it. I'm not presently inclined to include it in the core module, if
> only because it's obviously something that would be easy to do in a
> sub-class.
I've learned by following the developments of modules such as
WWW::Mechanize and CGI::Application and Data::Page that subclass'ing
isn't always a good solution. The problem arises when two people have
good ideas for sub-classes and each release their own. As long as you
just need one feature, it's OK. If you want both, it seems like an
awkward situation if not impossible situation. What if two sub-classes
both overrode param() with an interesting and non-overlapping features?
In the current CGI::Application scheme, we solve this with mix-ins and
hooks for callbacks at various points. H::T seems rather mature already,
and I'm not suggesting making these kind of extensions to it. This seems
like a case where modifying the core strikes me as reasonable.
> > Wouldn't the method call support be sort of like coderef support that is
> > already there?
>
> Yes, although I'd wager that the percentage of anonymous subs that
> have side-effects is much lower than the percentage of methods that
> have side-effects. I realize that either one could but methods just
> seem more likely to encourage this abuse.
I would say "encourage", but it doesn't actively try to prevent it
either. My take is that these kind of quality issue that should be in
hands of the programmer to deal with, and not of H::T's concern. Much
like if they use H::T in combination with many global variables or bad
indentation.
> Although, if you want to get to the heart of the matter, code-ref
> variables were not my idea. I added them in response to a majority of
> the users declaring their interest. Sometimes I do that...
>
> > It seems like it might even be implemented like that: as as callback
> > which gets the method name passed in as a parameter.
>
> Yes, I think that would be the easiest way. HTML::Template::Expr
> exploits code-ref variables to offer function calls, so why not
> methods too?
Are you suggesting that the method technique may make sense to add to
HTML::Template::Expr ?
Personally, I'm a purist and haven't yet used ::Expr for a project.
The syntax would be a little different, but I think in a key way. Here's
how ::Expr uses functions:
<TMPL_IF expr="defined(foo)">
The template system has to know what 'defined' means here to parse it.
I'm suggesting:
<TMPL_IF foo.is_defined>
As now, we just need to check to see if we have "foo" to use, and
quickly check to see to if it's a object or a complex data structure to
see what to do with the bit after the dot.
Mark
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Html-template-users mailing list
Html-template-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/html-template-users
