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

[perl #41619] [PATCH] add add_attr, rem_attr, and rem_attr_str vtable methods

5 views
Skip to first unread message

Alek Storm

unread,
Feb 25, 2007, 11:12:32 PM2/25/07
to bugs-bi...@rt.perl.org
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #41619]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41619 >


This patch adds the add_attr, rem_attr, and rem_attr_str vtable
methods. These will come in handy for Ruby's metaclasses or
Smalltalk's class objects. The only PMC currently affected by this is
ParrotClass, and the rem_attr and rem_attr_str methods are still
unimplemented.

Files affected:
src/ops/object.ops
src/pmc/parrotclass.pmc
vtable.tbl

Thanks,
Alek Storm

add_attr.patch

James E Keenan

unread,
Feb 26, 2007, 10:12:38 PM2/26/07
to perl6-i...@perl.org, bugs-bi...@rt.perl.org

FWIW, I applied this patch in the buildtools branch and ran 'make
buildtools_tests'. Everything passed.

[bt] 518 $ patch -p0 < add_attr.patch
patching file src/ops/object.ops
patching file src/pmc/parrotclass.pmc
patching file vtable.tbl
[bt] 519 $ make buildtools_tests
/usr/local/bin/perl t/harness t/tools/pmc2cutils/00-qualify.t
t/tools/pmc2cutils/01-pmc2cutils.t t/tools/pmc2cutils/02-find_file.t
t/tools/pmc2cutils/03-dump_vtable.t t/tools/pmc2cutils/04-dump_pmc.t
t/tools/pmc2cutils/05-gen_c.t t/tools/pmc2cutils/06-print_tree.t
t/tools/pmc2cutils/07-open_file.t t/tools/ops2pmutils/00-qualify.t
t/tools/ops2pmutils/01-ops2pmutils.t t/tools/ops2pmutils/02-usage.t
t/tools/ops2pmutils/03-new.t t/tools/ops2pmutils/04-prepare_ops.t
t/tools/ops2pmutils/05-renum_op_map_file.t
t/tools/ops2pmutils/06-load_op_map_files.t
t/tools/ops2pmutils/07-no_ops_skip.t t/tools/ops2pmutils/08-sort_ops.t
t/tools/ops2pmutils/09-prepare_real_ops.t
t/tools/ops2pmutils/10-print_module.t t/tools/ops2pmutils/11-print_h.t
t/tools/ops2cutils/01-new.t t/tools/ops2cutils/02-usage.t
t/tools/ops2cutils/03-print_c_header_file.t
t/tools/ops2cutils/04-print_c_source_top.t
t/tools/ops2cutils/05-print_c_source_bottom.t
t/tools/ops2cutils/06-dynamic.t t/tools/ops2cutils/07-make_incdir.t
t/tools/ops2cutils/08-nolines.t t/tools/ops2cutils/09-dynamic_nolines.t
t/tools/pmc2cutils/00-qualify..................ok

t/tools/pmc2cutils/01-pmc2cutils...............ok

t/tools/pmc2cutils/02-find_file................ok

t/tools/pmc2cutils/03-dump_vtable..............ok

t/tools/pmc2cutils/04-dump_pmc.................ok

t/tools/pmc2cutils/05-gen_c....................ok

t/tools/pmc2cutils/06-print_tree...............ok

t/tools/pmc2cutils/07-open_file................ok

t/tools/ops2pmutils/00-qualify.................ok

t/tools/ops2pmutils/01-ops2pmutils.............ok

t/tools/ops2pmutils/02-usage...................ok

t/tools/ops2pmutils/03-new.....................ok

t/tools/ops2pmutils/04-prepare_ops.............ok

t/tools/ops2pmutils/05-renum_op_map_file.......ok

t/tools/ops2pmutils/06-load_op_map_files.......ok

t/tools/ops2pmutils/07-no_ops_skip.............ok

t/tools/ops2pmutils/08-sort_ops................ok

t/tools/ops2pmutils/09-prepare_real_ops........ok

t/tools/ops2pmutils/10-print_module............ok

t/tools/ops2pmutils/11-print_h.................ok

t/tools/ops2cutils/01-new......................ok

t/tools/ops2cutils/02-usage....................ok

t/tools/ops2cutils/03-print_c_header_file......ok

t/tools/ops2cutils/04-print_c_source_top.......ok

t/tools/ops2cutils/05-print_c_source_bottom....ok

t/tools/ops2cutils/06-dynamic..................ok

t/tools/ops2cutils/07-make_incdir..............ok

t/tools/ops2cutils/08-nolines..................ok

t/tools/ops2cutils/09-dynamic_nolines..........ok

All tests successful.
Files=29, Tests=1023, 65 wallclock secs (43.84 cusr + 7.41 csys = 51.25
CPU)
[bt] 520 $

Allison Randal

unread,
Mar 2, 2007, 6:31:38 PM3/2/07
to perl6-i...@perl.org
Alek Storm (via RT) wrote:
>
> This patch adds the add_attr, rem_attr, and rem_attr_str vtable
> methods. These will come in handy for Ruby's metaclasses or
> Smalltalk's class objects. The only PMC currently affected by this is
> ParrotClass, and the rem_attr and rem_attr_str methods are still
> unimplemented.

It's more of a design question than a code question. Why make add_attr,
rem_attr, and rem_attr_str vtable methods rather than simply methods on
the Class class (the metaclass)? They only affect ParrotClass, which
means we're defining vtable entries for functionality that will be used
by one PMC type.

Allison

Alek Storm

unread,
Mar 4, 2007, 1:40:01 PM3/4/07
to Allison Randal, perl6-i...@perl.org
For the same reason we have set_attr, set_attr_str, get_attr, and
get_attr_str, even though they're only used by ParrotObject - it allows for
multiple, concurrent object systems. This goal is mentioned in PDD 15, in
"What The Bytecode Sees". Why tie programmers into the default way of doing
things? In Smalltalk, objects and classes work very differently, to the
point where I have a wrapper object around every class. It would be a whole
lot easier if I could define my own class implementation.

Joshua Isom

unread,
Mar 4, 2007, 4:42:10 PM3/4/07
to Alek Storm, perl6-internals List
On Mar 4, 2007, at 12:40 PM, Alek Storm wrote:

> For the same reason we have set_attr, set_attr_str, get_attr, and
> get_attr_str, even though they're only used by ParrotObject - it
> allows for
> multiple, concurrent object systems. This goal is mentioned in PDD
> 15, in
> "What The Bytecode Sees". Why tie programmers into the default way of
> doing
> things? In Smalltalk, objects and classes work very differently, to
> the
> point where I have a wrapper object around every class. It would be a
> whole
> lot easier if I could define my own class implementation.

But part of the point of parrot is dynamic language interoperability.
Will perl6 and tcl be able to use that new class implementation without
a problem, and could you use perl6 and tcl classes and objects? This
of course assumes the language gets the added functionality to import
stuff across HLL's. There are times where different languages make
coding different aspects of a large program easier, so people might
want to use, say, perl for the string comparison, tcl for the gui, and
java for communicating over the network with a binary protocol. It's
just a rough example, but nevertheless, that is the potential of
parrot, without using weird embedding stuff.

Alek Storm

unread,
Mar 4, 2007, 10:13:16 PM3/4/07
to Joshua Isom, perl6-internals List
The same questions are solved for all PMCs - the vtable provides an
abstracted interface that everyone can use seamlessly. Because tcl
and Java use the same interface (opcodes), there's no problem. I
honestly cannot see a difference between these and any other vtable
method. The fact that Perl strings work differently than Python
strings is cited as one of the reasons why Parrot is so useful for
interoperating between languages, and the object system is a logical
addition to this.

In fact, these vtable methods *encourage* the use of many languages in
a single application. For example, without these methods, programmers
have to be aware of the semantics of the Smalltalk object system and
use extra code when dealing with Smalltalk objects, breaking
abstraction. With them, however, interoperability is complete, and
the Smalltalk object semantics are still satisfied.

Thanks,
Alek Storm

Chromatic

unread,
Mar 4, 2007, 10:24:28 PM3/4/07
to perl6-i...@perl.org, Alek Storm, Joshua Isom
On Sunday 04 March 2007 19:13, Alek Storm wrote:

> In fact, these vtable methods *encourage* the use of many languages in
> a single application. For example, without these methods, programmers
> have to be aware of the semantics of the Smalltalk object system and
> use extra code when dealing with Smalltalk objects, breaking
> abstraction. With them, however, interoperability is complete, and
> the Smalltalk object semantics are still satisfied.

Are you intending to use these to store instance attributes? I thought the
point of these was to store annotations on PMCs--something very different
from member variables.

Perhaps the discussion would be clearer if you were to sketch out the specific
behavior you would like to enable in the HLL.

-- c

Alek Storm

unread,
Mar 4, 2007, 10:39:52 PM3/4/07
to chromatic, perl6-i...@perl.org, Joshua Isom
Hmm, no, these deal with normal object attributes. I believe you're
thinking of properties. I'll put together some sketch code with what
I already have and post that.

Thanks,
Alek Storm

Alek Storm

unread,
Mar 12, 2007, 8:39:38 AM3/12/07
to perl6-i...@perl.org, Joshua Isom
I'm still working on my use case, but it appears the new MetaClass PMC
(src/pmc/metaclass.pmc) could use this vtable method as well; currently it
only has an add_attribute PMETHOD.

James Keenan via RT

unread,
Mar 16, 2008, 12:20:57 PM3/16/08
to perl6-i...@perl.org
On Mon Mar 12 05:40:14 2007, alek....@gmail.com wrote:
> I'm still working on my use case, but it appears the new MetaClass PMC
> (src/pmc/metaclass.pmc) could use this vtable method as well; currently it
> only has an add_attribute PMETHOD.
>

Alek, Are you still planning work on this patch? (No activity in thread
for > 1 year.) Could you give us an update on the issues at hand?

Thank you very much.
kid51

Patrick R. Michaud via RT

unread,
May 17, 2008, 6:12:58 PM5/17/08
to perl6-i...@perl.org

No activity on this ticket since Mar 2007. Beyond that, I suspect it's
been made obsolete by the pdd15oo changes from November 2007. I vote to
close it.

Pm

0 new messages