Leopold Toetsch:
# The property 'constant', 'ro' or whatever can only be some kind of
# communication: the HLL is telling the PMC to be read only. We could
now
# have in each set-like vtable:
# # if (we_have_props && !is_bool(prop("ro")) // pseudo code
# set_the_value ...
# else
# throw_exception
# # or we have a different class, that have in the set-like vtable
slots
# just the exception. No penalty for rw classes.
I'm starting to wonder if we shouldn't copy the vtable at construction time. That way, we can have our read-only set_* behaviors without requiring a second class:
void init(...) { SELF->vtable=copy(this_class's_vtable); if(is_bool(prop("ro")) { SELF->vtable->set_int=&Parrot_pmc_ro_set_int;
This would work for properties known at constrution time. But it doesn't much help, if at runtime the "ro" property is set. This scheme would work e.g. for tie, where a new variable (ref) is returned, with different vtable pieces allocated and copied in. Allocating new vtables at runtime for the same object instance would need some book-keeping (vtable already allocated, which entries...). And the more that constant objects are used internally, I think its better to create these at compile time.
This would also allow for other class-specific vtable customization. After all, I doubt ro will be the *only* property that's much more efficiently implemented as a modified vtable...
Yep. That's right, your scheme matches somehow my tied sample code, I posted long times ago.
A generalization of my compile time classes variations for runtime modifications is for sure necessary - somewhen. But for now (and as long Dan's specs for vtable chenges are hidden) I don't want to go further.
leo
