Andy Wardley <[EMAIL PROTECTED]> writes:
> > b) Do we risk name clashes with blessed objects. For example, does
> > my number class that has it's own "commify" operator risk having
> > that overridden by the virtual method?
>
> No, object methods always win.
That's good.
> But, namespace collision can be a problem.
>
> In fact, one of the gnarliest problems I/we really need to solve for v3
> is a reliable and easy way to:
>
> * specify at startup which virtual methods should be enabled/disabled
>
> * add new virtual methods, remove or hide existing ones on the fly,
> even from within templates (if the right "let the meddle" flag is
> set)
>
> * define some syntax or convention to indicate when you really want
> a virtual method, and when you really don't.
>
> That last point is the hard one. I got burnt by this when I added the
> 'size' virtual method to hashes (and then promptly took it away again).
>
> I hade some code which said:
>
> <font[% IF font.size %] size="[% font.size %]"[% END %]...etc...>
>
> and suddenly, in the many cases where font.size had previously been
> undefined, it now magically returned a value and messed up all my
> output.
>
> So, being able to disable the 'size' hash virtual method, either
> for all templates, a single template, or within a lexical block,
> is one solution, but a bit clumsy.
I think it's good that the you in the template doesn't have to know
how the values are stored.
You shouldn't have to think about details about the implementation for
an object then you want to retrieve a value.
The creator of an object, on the other hand, should declare it's
properties.
I think that you may have to make a distinction between false, undef
and none-esisting properties of a hash.
In the case of font above, the size property should have been declared
even if it's undefined.
But I also think that "size" is a bad property, since it's not saying
the size of what. Maby it should be called "number_of_properties".
That would give it a meaning both for objects and hashes. Or manby
"number_of_values", that also would work for lists.
> Some syntax solutions I've considered include:
>
> * using a tt_ prefix to say "I really, really want the TT virtual
> method", e.g. [% hash.tt_size %]
That's look like a namespace specification and could be generalised.
Let it say [% hash.tt:size %]
> * using {key} or maybe 'key' to say "I really want the hash key, or
> object method, no TT magic, thank you very much", e.g.
> [% hash.{size} %] or [% hash{size} %] or [% hash.'size' %]
> The first two are starting to look a bit Perlish, the second
> doesn't seem obvious enough to me as to what it's doing. And
> they're both confusing when it comes to object methods.
Bad, bad, bad.
If anything, they should mean the same thing.
> * forget about it, and have people do [% hash.item('size') %] when
> they really want a hash item, but that's not very helpful, and
> leads to problems as I discovered.
Having such a method for retrieving properties is sometimes helpful.
It makes the code more easy to read then the key is the result of an
expression.
What is the problem?
> * make all virtual methods UPPER CASE. Doesn't solve the problem
> but may avoid conflicts if you warn people that UPPER CASE keys
> might clash with reserver words, e.g. [% hash.SIZE %] vs
> [% hash.size %]. Maybe too much shouting. My little fingers
> already hurt from the shift key.
That would be symetric with other TT keywords. Add an upper case
alias for the virual methods as an alternative and make it optional to
disable lowercase methodnames.
> * use a separator other than '.', e.g. [% hash!size %] or
> [% hash:size %] or [% hash(size) %] or something else.
I think there could be other uses for those.
> Another partial solution is to expose the stash virtual methods
> themselves. This will, I think, be the preferred approach to
> call a virtual method, when you really, really want to call a
> virtual method:
>
> [% tt.hash.size(myhash) %]
That's good.
--
/ Jonas - http://jonas.liljegren.org/myself/en/index.html
