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.]


Reply via email to