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 [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
