On Jun 12, 2006, at 9:17 AM, Andy_Wardley via RT wrote:
Show quoted text> <URL:
http://rt.cpan.org/Ticket/Display.html?id=19827 >
>
> The hash.list vmethod has not changed from 2.14 to 2.15. It always
> has
> returned a decomposed version of the hash, as documented in
> Template::Manual::VMethods.
>
> What has changed in 2.15 is that we now have full support for calling
> hash virtual methods on objects composed from hashes. In 2.14 calling
> .list on a hash object resulted in the *scalar* .list virtual method
> being called incorrectly. This, as documented returns the single item
> in a list: [$obj]
>
> So it's more correct to say that TT was broken in 2.14 and has now
> been
> fixed in 2.15.
Right, but it's highly debatable whether the expected and most useful
behavior is to always invoke the hash vmethods on objects composed
from hashes. As it is now, there is apparently *no* way in 2.15 to
uniformly handle the results of a method that returns zero or more
objects. I had been using .list in order to make sure the object was
always an array. As far as I'm concerned they are just objects; I
don't need to know, or care, that they are hashes, as I access the
objects only via their methods. The 2.15 behavior is quite
unintuitive. The whole point of objects is that they are objects! I
haven't checked to see if obj.foo first tries $obj->foo or $obj->
{foo}, but if $obj is blessed it should certainly be the former.
I'm not really sure how this should be resolved, as I can see certain
restricted situations when you would not want a distinction between
blessed and unblessed hashes, but in any case I don't think the 2.15
behavior should just be imposed by fiat, leaving no easy way to do
what seems a perfectly logical thing to want to do, and which used to
work fine.
Dave
