Edwin, good that we agree. I have some questions for you:
Edwin Steiner wrote:
> Branden wrote:
> > but would certainly make the program die, what could be avoided if SV*,
AV*,
> > HV* and so on are different of each other, and casts are not required
among
> > them, as is done today in Perl 5,
>
> Different pointer types also make coding harder when there is no
> need to make a difference between object types. (When you just pass
> something on, for example.)
>
I actually see it as strong typing, which I believe is good on the
low-level. When there would be no need to make a difference between
scalar/array/hash/filehandle/regex? If you're passing something on, at least
in the Perl language, you can't call mysub($a), mysub(@a), mysub(%a), and
expect them all to be in the same variable, so I don't see why this should
be done in the low level. In contrast to it, you can call mysub(\$a),
mysub(\@a) and mysub(\%a) and have them all in one scalar, but this could
also be done with the DEREF of the scalar vtable. Of course in C you can
always pass SV*,AV*,HV*,... as void*, and have all vtables have a special
`type' entry (possibly the first one in the vtable), to make the cast back
to SV*,AV*,HV*,... possible.
> > and the other thing is that creating a
> > vtable for another type would break all existing types. Example: suppose
we
> > want compiled regexes (qr/^xyz$/) to have its own vtable so that we
could
> > inspect them and the regex-engine would interact with them by a clear
> > interface. If we don't make it at first, adding them later would
probably
> > break scalars, arrays, hashes, and so on.
>
> I get your point. But considering what Dan said about *not exporting
vtables*
> I wonder how many data types will directly rely on vtable layout. I would
> think all data types implemented outside the core will use an additional
> level of indirection (tie-like callbacks?). So maybe there will only be
> a hand full of 'very internal' data types depending on the vtables.
I actually don't see the need for having a `tie'-like interface. To me, at
least, vtables are much more clear to deal with than a `tie'-like interface.
Of course, we don't want to PMC->vtable[ADD][UTF_32](DEST, PMC1, PMC2);
ourselves, but we could actually have a SV_ADD_UTF32(DEST, PMC1, PMC2) macro
that would expand to that, and so on. Here the macros really buy us
something... Having them implemented directly over the vtables, we won't
have version-portability problems, and won't have to write that ugly piece
of code either.
> > Actually this is safer, because if SV* never really
> > contains an AV*, as happens in Perl5, you would never get a sv_vtable
from
> > an array, which would cause the crash you are talking about...
>
> Right. I was talking about the case of only a single pointer type (PMC).
> Both PMC and (SV*,AV*,...) have their pros and cons. Another advantage of
> (SV*,AV*,...) is that the vtables would be smaller.
> Dan favors the PMC single pointer according to his posts and I have the
> *slightest* feeling that he knows a lot more about perl guts than me :-)
Well, Dan, please tell us what you think about it... I also think I know
much less of the guts than you.
Thanks,
- Branden
