On Thu, Jan 30, 2003 at 09:11:10AM -0800, Damian Conway wrote:
> >What was the reason again which Larry rejected unifying the syntax for
> >array
> >and hash indexing?
>
> Because some things have both, and do different things with each.
> And because some built-in redundancy is useful for error checking,
> especially on complex nested data structures.
>
>
> >As Piers said, we know whether $a is an array or hash reference when we do:
> >
> >print $a->{foo};
>
> No we don't. Especially if $a is $0 (i.e. the result of a pattern match).
> See Exegesis 5 for details.
>
>
> >Someone correct me when I go astray...
>
> See above. ;-)
>
>
> Damian
I like very much that a reference can point to an object that has
scalar, array and hash natures at once. With the current (non unified
syntax), we can very elegantly munge any kind of attributed tree: XML,
parsing tree...
In the case of XML. if the node is a leaf, the referenced entity would
be a regular scalar. Otherwise, it would be the multifacetted object
of type (say) TagNd; the scalar would be the tag name, the hash would contain the
key/attribute pairs, the array would contain the sons if any.
Example: suppose that $t is the root node of such a tree obtained by parsing:
<a b="c">
<d>e</d>
f
</a>
print $t{a} ; # prints "c"
print $t[0][1]; # prints "f"
This tree (simplified) deparsing would be done like that:
sub deparseNd($n) {
return $$n if ref($n) ne 'TagNd'; # returns text of leaf node
return "<$$n" ~
(join '', map { qq|$_="$n{$_} "| } keys %$n) ~
">" ~
(join '', deparseNd $_ for @$n) ~ # should I protect for the
# possible autoinstanciation of
# of the sons array @$n (when no son?)
"</$$n>
}
print deparseNd($t);
Does it make any sense?
Someone correct me where I go astray... :)
Probably there is a more elegant way to concatenate all the chunks.
BTW: Can I write "for $t" instead of "for @$t", same for "keys $t"?
Will Perl6 smart enough to autodereference when needed?
--
stef
