@woggle> leo: So, for read-only PMC variants, I'm presuming that it's okay
to have the read-only
variants have their own type number and type name (like was
done for ConstSArray)...
My 2 c:
A distinct type number would cause e.g. different MMD behavior and I'm not
sure, if we want to duplicate MMD function code. Letting r/o types subclass
the r/w types would change relative distances and also looks suboptimal.
But I don't know yet, how to do it right.
leo
Wouldn't it be an idea to have a property 'is_read_only' or something
like that? Then, when attempting to do a write action on a r/o PMC, an
exception is thrown. It would seem to me that this is a typical case for
using a property.
The disadvantage of course of this approach is that for every
write-operation, this check would have to be done, although this is done
in fast C code, it *is* yet another check to be done.
My 2c,
klaas-jan
> Wouldn't it be an idea to have a property 'is_read_only' or something
> like that? Then, when attempting to do a write action on a r/o PMC, an
> exception is thrown. It would seem to me that this is a typical case for
> using a property.
>
> The disadvantage of course of this approach is that for every
> write-operation, this check would have to be done, although this is done
> in fast C code, it *is* yet another check to be done.
If I understand this correctly, it's heading in the direction of how Perl 5
works. Swapping the vtable pointer seems, to me, to be both cleaner and
probably faster.
-- c
Yes, and we can change the vtable pointer without changing the type. The
type is primarily distinguishing an interface (or set of interfaces), and
an object is presumably allowed to change how it responds to that interface,
as long as it doesn't violate The Contract.
Larry
> Wouldn't it be an idea to have a property 'is_read_only' or something
> like that? Then, when attempting to do a write action on a r/o PMC, an
> exception is thrown. It would seem to me that this is a typical case
> for using a property.
A "Parrot property" is handled by a full-fledged hash and by far too
heavy to serve the information of a single bit 'r/o'. "Perl6
properties" will be (according to docs) implemented by (possibly
singleton) classes.
For the subject, just swapping vtables is enough, which doesn't impose
any runtime overhead to check for r/o-ness. We will still need some
infrastructure and thoughts, how to manage additional vtables per type.
leo