On Mon, Apr 15, 2002 at 07:24:13PM -0700, Larry Wall wrote:
> So the main reason that objects can function as hashes is so that the
> user can poke an object into an interface expecting a hash and have it
> "make sense", to the extent that the object is willing to be viewed like
> that.
AKA the uniform access principle.
This was something that I was very keen to exploit in the Template Toolkit
where foo.bar is interpreted as "Do(t) The Right Thing" to access the
'bar' part of 'foo', be it the 'bar' key in the 'foo' hash or the 'bar'
method of the 'foo' object. The result is, of course, that you can use
a hash of static data one day (great for mocking up web pages for example)
and later upgrade it to an object which fetches/generates data on demand
(e.g. from a database) when you put your pages into production.
Alas, I also designed a flaw into the system by introducing "virtual
methods" that TT automatically applies onto various data types, equivalent
to various Perl functions, e.g. somehash.keys or somelist.size. As
convenient as this is, the problem lies in the fact that you can't
differentiate somehash.keys between the Perl equivalents of C<keys %$hash>
or C<$hash->{keys}>.
So my thought for version 3 of TT is to introduce somehash.{keys} as
a syntax to mean "only the 'keys' key/method of the 'foo' hash/object
but *NOT* the 'keys' virtual method" and to leave somehash.keys resolving
to the virtual method as it currently does.
Am I right in thinking that this would then be (roughly) consistent with
the Perl 6 syntax?
e.g.
TT3 Perl 6 Perl 5 (hash) Perl 5 (obj)
--------------------------------------------------------
foo.keys $foo.keys keys %$foo $foo->keys()
foo.{keys} $foo.{keys} $foo->{keys} $foo->keys()
Hang on, now I'm a little confused - I thought that hashes were supposed
to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
But then that would then violate the uniform access principle because
hash/key access has a different syntax from object/method?
Have I missed a vital clue?
A
