Re: [Templates] Solve overloaded object problem w/ namespace handler?

[prev] [thread] [next] [Date index for 2004/09/03]

Tom,

> I don't at the moment, but I can very much see myself having a related 
> problem - I have a blessed hashref that overloads the list dereferencing 
> operator. This is a slightly harder problem, of course - it's easy to 
> say 'object.fred' should be a hash dereference, harder to say 'object.4' 
> should be a list dereference. Elegant solution, anyone?

That's very similar to my object, actually.

Well, in the patch-to-Template::Stash corner, I see two possible ways to 
attack the problem:

1) In addition to the check to see if it's a hash, add a check to see if 
the hash-deref operator has been overloaded.

2) _Instead_ of checking to see if it's a hash, just eval an attempt to 
deref it as a hash.

Now, I haven't had a chance to write any code, much less profile it or 
anything fancy like that, but if #2 is feasible (i.e., if there aren't 
some performance penalties or hidden gotchas that any of the gurus 
around here could point out), then I think that might solve your problem 
too, in that, if deref'ing it as a hash fails, you can just move on and 
try to deref it as an array too.  This is all assuming I understand 
what's going on in Template::Stash (specifically, 
Template::Stash::_dotop) sufficiently, which may very well not be the case.

OTOH, if the proper solution is writing a namespace handler, then I 
suppose you could do it any way you like (including something as simple 
as checking to see if your arg is /^\d+$/), but we'll have to wait for 
someone a bit more knowledgeable on that score to chime in on how 
exactly the namespace handlers work.

Or, of course, perhaps there's another solution altogether.  But that 
exhausts my poor brain for today. :-)


		-- Buddy

_______________________________________________
templates mailing list
templates@xxxxxxxxxxxxxxxx.xxx
http://lists.template-toolkit.org/mailman/listinfo/templates