At 07:55 PM 12/6/00 +0000, Simon Cozens wrote:
>Oh boy, it's OO syntax nargery time again. *sigh*.
>
>On Wed, Dec 06, 2000 at 10:51:14AM -0800, Nathan Wiger wrote:
> > @array->length
> > %hash->keys
> >
> > Simply keeping @arrays and %hashes as buckets for SV's wouldn't let you
> > do this.
>
>I don't think that's true. At all.
Definitely not.
> > An "SV" would really just be an AV with
> > one value. HV's would remain separate since there's more to them (direct
> > access, etc) than just multiple values. Again, just something worth
> > tossing around.
>
>I'm in favour of the exact opposite: an AV is "just" an SV-alike vtable
>with array methods instead of scalar methods and a pointer to some
>storage, (probably an array of SVs) and likewise an HV. That would allow
>(array->length)() which seems to be what you want above.
Currently the only difference between accessing an AV's member's value, an
HV's member's value, or an SV's value is an extra argument to the vtable call.
print $foo[0];
is
foo->get_string[UTF_8](ARRAY, 0);
while
print $foo
is
foo->get_string[UTF_8](SCALAR);
There doesn't seem to be any reason to split array/hash access into
separate fetch and convert vtable calls. Bleah. (And the only reason for
the first arg in there is because you can't do varargs with 0 args in C)
> > I think it would be cool
>
>Good for you. This is internals design; perl6-language is over there --->
>and the "ph33r mY |<ewl dr3am 5inta><" phase is supposed to be over now
>anyway.
I think we can skip that, though.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
