Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 01:20 PM 12/7/00 +0000, David Mitchell wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > print $foo[0];
> > > is
> > > foo->get_string[UTF_8](ARRAY, 0);
> > > while
> > > print $foo
> > > is
> > > foo->get_string[UTF_8](SCALAR);
> >
> >Just to clarify:
> >
> >does the get_string method in an AV's vtable do an indexing lookup,
> >grab the relevant SV pointer, then call that SV's get_string() method,
> >and forward the return value? ie
> >
> >char * AV_get_string_utf8(AV *av, int index) {
> > SV* sv = av->whatever[index];
> > return sv->get_string[UTF_8](sv);
> >}
> >
> >What advantage(s) does this buy?
>
> It means that array and hash elements don't have to be scalars, and
> that the scalar fetch/store opcodes don't need to check array and
> hash types.
>
>
> One of the memory use wins that Chip talked about with Topaz was
> having specialized array and hash types--string, integer, and float
> arrays were the big ones. If you do this (and lots of folks do)
>
>
> my @foo;
> @foo = <SOME_HUGE_FILE>;
>
> then having @foo be a specialized array that only holds strings
> (requiring a declaration, of course) is a memory win. Those array
> elements don't have to be pointers to scalars--they can be pointers
> to strings, tossing all the unneeded scalar bits. And while scalars
> might be slightly slimmer in p6, there's still non-string bits that
> we can toss, along with possibly a level of indirection in there.
> (The array could hold all the string info and not even have to hold
> pointers to each string's info)
Excuse me if I'm stating the obvious here, but presumably as soon as
you start doing something like $total += $array[$index_of_a_number]
then $array[$index_of_a_number] will acquire an SV like decoration,
but doing
$array[$some_index] = $not_a_string_and_has_no_stringify_overload
could be made to throw an exception.
Or would one need to explicitly copy something from the array into an
SV type variable before getting SV magic.
--
Piers
