On Tue, Nov 15, 2005 at 12:32:38PM -0600, Patrick R. Michaud wrote:
: On Tue, Nov 15, 2005 at 10:26:05AM -0800, jerry gay wrote:
: > > Thus, while PGE::Match currently defines a C<__get_pmc_keyed_int>
: > > method, it's doesn't yet define a C<__get_string_keyed_int> method.
: > > So, a statement like
: > >
: > > .local string res
: > > .local pmc match
: > > res = match[0]
: > >
: > > is defaulting to using the inherited op from the Hash class, and
: > > since there's not an entry at the 0 key in the hash (as opposed to
: > > the array) you get the null PMC.
: > >
: > it seems to me it could inherit from Array as well, but it may not be
: > a precise fit.
:
: Worse, I think the two might interact in strange and undesirous
: ways.
Inheritance is wrong here anyway. We need some kind of basic Tree node
object that *does* Hash, Array, and Item, but isn't any of them.
Think about how you'd want to represent XML, for instance:
~$obj name of tag, probably
+$obj number of elements?
+$obj[] number of elements?
+$obj{} number of attributes?
$obj[] ordered child elements
$obj{} unordered attributes
But the scalar values don't match up with how Match objects work, so it
would likely have to be:
~$obj representation of entire <tag>...</tag>.
+$obj +~$obj (0 with warning?)
Another approach would be to say that we make Hash smart enough to
behave like an array or a scalar in context, and then we write
~%obj name of tag, probably
+%obj number of attributes?
+%obj[] number of elements?
%obj[] elements
%obj{} attributes
But then hashes should have to store scalars and arrays as "hidden"
keys, and we still have an inconsistent scalar interface. Plus it
smacks of pseudo-hashery.
Yet another approach is to reinvent typeglobish objects (but without
confusing them with symbol table entries.) But we've stolen the *
sigil since then. And it might be more readable to simply be able
to declare highlanderish variables such that
my Node $obj;
my @obj ::= $obj[];
my %obj ::= $obj{};
And otherwise we just stick with $ sigil and semantics. Basically,
match objects are ordinary objects that merely *contain* other types,
while providing Str, Int, Num, Array and Hash roles.
Of course, we could give syntactic relief in just the declaration
on the order of
my ?obj; # the '?' is negotiable, of course
that implies the creation of a highlander variable. Outside the
declaration you'd only be able to use one of the real sigils.
Interestingly, though, that kind of implies that ^obj as an rvalue
would give the type of $obj in that scope.
One interesting question is, if you said
my ?obj := %random_hash;
whether it would try to emulate the $ and @ views or merely fail, or
something in between, like returning null lists and undefined values.
Presumably &obj would likely fail unless ?obj contained a code object
of some sort. It would make sense to allow tests for "exists &obj"
and such.
And then maybe we'd be talking about the ?/ variable rather than the
$/ variable. And we'd get @/ and %/, FWIW. Of course, none of this
highlander stuff buys you anything as soon as you go down a level in
the tree (unless you realias the child nodes). To my mind the main
benefit of declaring something like ?obj rather than $obj is that
you are documenting the expected polymorphism, and only secondarily
that you're claiming all the local "obj" namespaces.
[Followups to p6l.]
Larry
