Here are a few comments on RFC35 (base format for perl variables).
[ NB - I've only just joined this list, and although I've rummaged
through the archives, I may have missed bits which make my comments
obsolete/absurd etc... :-) ]
1. void *variable_data;
I would suggest having a slightly larger payload area than just
space for a single pointer. At the least have the ability to store
a standard number (ie double), or possibly even the xpv_pv/xpv_cur/xpv_len
of a standard string. This way, most scalars could avoid the necessity
of a separate alloc and extra level of indirection and cleanup.
Other variable types whose payload doesnt fit in that area could
still have a pointer to private data as usual, but could also use the
remainder of the payload area for private data also (especially for
some commonly accessed stuff such as length etc).
The penalty for this would be that SVs holding only ints would waste
a few bytes.
2. "Op functions have intimate knowledge of the internals and unrestricted
access"
In this context, is an "op function" a function in the vtable, or
are we refering to pp_foo functions? If the latter, surely they shouldnt
have access to SV internals?
3. The vtable needn't only include function pointers. For example,
it could include a set of class-wide RO flags as well, which could be
accessed directly rather than via a function call for efficiency.
(Can't think of any needed flags off the top of my head, but if say
*vtable[0] was reserved for this, it might come in handy later.)
4. The vtable should have a few spare slots at the end, which external
implementers of data types are obliged to fill with pointers to noop
and/or croak functions. Then when a later release of Perl adds new
functions to the API, these slots can be reassigned, and XSUBS compiled
under the previous versions will continue to work, or will at least die
gracefully.
I presume there will be a set of standard noop/carp functions which
implentors can stuff their vtables with for the unneeded bits?
5. Is the intention to handle upgrades automatically via vtable calls?
For example the [gs]et_string method for a numeric-only SV would
be responsible for uprading the SV and setting its vtable pointer to
point to the string-SV vtable, etc.
6. Will magicalness now be handled by having a separate vtable for
each type of magicalness?
7. Will there be only one vtable API, or a separate one for scalars, arrays,
hashes etc?
I can see some advantages of having a single one covering all types.
For example, one possible pseudo-hash implementation would have both
arrayish and hashish methods. Or a HTML parser module might want to
treat a HTML document both as a straight scalar string and a hash of the
parsed DOM for that object (presuambly with pointers to the var from both
scalar and hash entries in one or more globs).
Presumably for standard arrays etc, the scalar functions would do what
you would expect of an array evaluated in a scalar context, eg
get_int/float would return the length of the array, set_string would
croak, etc etc. Or should they all just croak, and there be an
array-specific method for getting array length?
8. Slowness of function call overhead.
I did a very quick and crude test (650Mhz Athalon running Linux, perl 5.005_03)
and got the following numbers.
250ns: Perl program: time to do $i++
45ns: standalone C program: time to do the pair
i = (sv->vtable[OFFSET_GETVAL])(sv);
(sv->vtable[OFFSET_SETVAL])(sv,i);
where the 2 entries in vtable point to simple functions that
get or set an integer in the payload of the sv.
This at least gives a preliminary indication that the overhead of
a couple of method calls isnt huge compared with the overall cost of
performing a simple perl op.
* Dave Mitchell, Operations Manager,
* Fretwell-Downing Facilities Ltd, UK. [EMAIL PROTECTED]
* Tel: +44 114 281 6113. The usual disclaimers....
*
* Standards (n). Battle insignia or tribal totems
