Dan Sugalski wrote:
> At 05:30 PM 8/31/00 -0400, Ken Fox wrote:
> > before_get_value
> > after_get_value
> > before_set_value
> > after_set_value
> >
> >There ought to be specializations of get_value and set_value
> >that call these hooks if they're defined -- no sense in making the
> >normal case slow.
>
> You could override the vtable function in that case, I think.
It'd be nice if there were standard functions for this in the core.
I don't want every type author to write debugger code (which is
probably what the before_* and after_* methods will be most useful
for.)
> >We also need GC functions:
> > children -- nested SV *s (for live object traversals)
>
> I'm not sure. Maybe.
How else are you going to discover the internal SV references in an
object? I don't want to have a conservative GC.
> > move -- move object to new memory location
>
> Don't think this is needed. The base SV structures won't move, I think, and
> we should be able to move the variable's contents (hanging off the sv_any
> analog) at will.
Different types may cache internal pointers instead of offsets. Those
pointers might need to change if an object is moved. (I agree that SVs
should not move.)
> > resize_granted -- object's resize request was granted
>
> I don't think this is needed--the guts of the set functions would handle
> this as needed.
An object might be smart enough to either compress itself or take
advantage of adjacent space becoming available. This method would let
the GC and the object discuss allocations.
> >Is is_same an identify function? Or does it check the type?
>
> Identity. If two SVs pointed to the identical same data, this'd return true.
Shouldn't the sv_any pointers be the same then?
> >What purpose do the logical_* functions serve? Shouldn't there just be
> >one is_true function that the logical_* ops call?
>
> In case one wants to overload
>
> @foo || @bar
>
> to do a piecewise logical or of the two arrays.
I don't like the idea of using the ops vtbl for syntax overloading. For
one thing there aren't individual ops for every syntax, so the vtbl alone
isn't sufficient. Secondly, I think vtbl ops should have very consistent
semantics to allow the optimizer some room to re-arrange things. Short
circuiting should not be customizable by each type for example.
- Ken
