Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Readonly PMCs and types

4 views
Skip to first unread message

Leopold Toetsch

unread,
Jun 16, 2006, 7:45:21 AM6/16/06
to perl6-i...@perl.org, Chip Salzenberg
Recently on IRC:

@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

Klaas-Jan Stol

unread,
Jun 16, 2006, 11:29:36 AM6/16/06
to Leopold Toetsch, perl6-i...@perl.org, Chip Salzenberg
Leopold Toetsch wrote:

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

Chromatic

unread,
Jun 16, 2006, 1:27:06 PM6/16/06
to perl6-i...@perl.org, Klaas-Jan Stol, Leopold Toetsch, Chip Salzenberg
On Friday 16 June 2006 08:29, Klaas-Jan Stol wrote:

> 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

Larry Wall

unread,
Jun 16, 2006, 1:39:44 PM6/16/06
to perl6-i...@perl.org
On Fri, Jun 16, 2006 at 10:27:06AM -0700, chromatic wrote:

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

Leopold Toetsch

unread,
Jun 16, 2006, 2:37:00 PM6/16/06
to Klaas-Jan Stol, perl6-i...@perl.org, Chip Salzenberg

On Jun 16, 2006, at 17:29, Klaas-Jan Stol wrote:

> 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

0 new messages