On 3/15/2010 12:41 PM, Felipe Gasper (cPanel) wrote:
> ----------
> SET test_hash = {
> 'keys' => 'foo',
> 'bar' => 'baz',
> };
>
> GET test_hash.keys();
> ----------
>
> ...what I get back is “foo” rather than an array reference.
>
> The .items() hash vmethod allows me to specify that I want an item
> rather than a vmethod; how can I specify that I want it the other way,
> getting a vmethod rather than an item?
Hmm. It seems like the stash should be checking hashes for a vmethod first
instead of the existence of the hash key. This appears to be a 'bug', since
there is no way to get at the vmethod as you say. (Although, it's definitely
arguable that you'd want to always try to get the key instead.) However, I'm
not sure the order could be changed there without possibly breaking code out in
the wild.
Some possible ideas:
*) Allow a symbol sequence that will let Stash::dotop know that we're dealing
with a vmethod. Something like two underscores at the beginning.
(test_hash.__keys()). This would need to change the $PRIVATE regexp in the
Stash module to allow two underscores.
*) pass information that parenths were used and we want to call a routine.
Then we could check and see if the key is a routine or not and if it's not, we
could look for a vmethod.
*) You can hack a different keys vmethod named something like 'mykeys', which
won't exist in the hash. This would be very simple since you just have to
point at the old one.
*) We could add another hash vmethod that is more unique that allows us to call
a vmethod directly. ie: test_hash.__vmethod('keys'). Again $PRIVATE would have
to change for this.
Maybe someone has a better idea or knows something I don't here, though. I
didn't spend a ton of time thinking on this, so there may be a better way to
fix this problem.
-- Josh Rosenbaum
_______________________________________________
templates mailing list
[email protected]
http://mail.template-toolkit.org/mailman/listinfo/templates
