Re: Named rules and basic OO support landed.

[Leopold Toetsch]

Autrijus Tang <autr...@autrijus.org> wrote:

> class Point {
> has $.x;
> has $.y;

The progress pugs makes is really impressive.

[ ... ]

> Pugs's Parrot codegen backend needs to be updated

Object attribute access, yeah. IMHO Parrot's current implementation is
wrong.

0) class construction # a bit shortened for this example

.local pmc cl, o, x, y # decls for example
cl = newclass "Point"
addattribute cl, "x" # "$x" what does Python then?
addattribute cl, "y" # "$y" what does Python then?
o = new "Point" # make instance - __init not shown

1) indexed access

$I0 = classoffset o, "Point"
x = getattribute o, $I0 # 1st attribute at ofs + 0
$I1 = $I0 + 1
y = getattribute o, $I1 # 2nd attribute at ofs + 1

The offset is cached in the bytecode, you could keep it over the whole
program life-time. If the class layout ever changes, things would break
horribly. The compiler needs intimate knowledge of the attribute order
and it's usable for an array-ish object layout only.

2) named access

x = getattribute o, "Point\0x"

This needs a full qualified attribute name "Class" ~ NUL ~ "Attribute".
That's unusable for at least Python and probably more HLLs as the
compiler has to know in which class the attribute was defined.

We should just have:

x = getattribute o, "x"

and the set equivalent:

setattribute o, "x", x

Comments welcome,
leo

[Autrijus Tang]

On Wed, May 11, 2005 at 09:19:50AM +0200, Leopold Toetsch wrote:
> 2) named access
>
> x = getattribute o, "Point\0x"
>
> This needs a full qualified attribute name "Class" ~ NUL ~ "Attribute".
> That's unusable for at least Python and probably more HLLs as the
> compiler has to know in which class the attribute was defined.

Yes. I've encountered this during my PGE::Hs hacking:

.const string PGE_SUB_POS = "PGE::Match\x0@:capt"
.const string PGE_SUB_NAMED = "PGE::Match\x0%:capt"

I had no idea why the class name has to be fully qualified
for attributes, whilst methods can be simply invoked.

Pugs would have no easy way to figure out, at runtime,
which attribute to dispatch to, as Perl 6 allows adding
new attribute slots by eval'ing "class Foo { has $.x }"
blocks, so attributes previously resolved as belong to a
superclass may need to be redispatched.

> We should just have:
> x = getattribute o, "x"
> and the set equivalent:
> setattribute o, "x", x

It'd definitely be better if the VM can keep track of
this; otherwise I'd need to marshall the whole attribute
table and do a lookup each time by hand, which would be
slow (and non-interoperable) indeed.

Thanks,
/Autrijus/

[Patrick R. Michaud]

On Wed, May 11, 2005 at 09:19:50AM +0200, Leopold Toetsch wrote:

> We should just have:
> x = getattribute o, "x"
> and the set equivalent:
> setattribute o, "x", x

I would much prefer this. I don't have much problem with
grabbing and using the offsets, but at the moment they're
really only useful as a speed optimization when accessing
more than a couple of attributes, and then only for the
duration of a subroutine. For accessing a single attribute,

x = getattribute o, "MyClass\x0$.x"

or (better)

x = getattribute o, "x"

is far superior.

Pm