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
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 $
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
> 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.
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
> 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
Thanks,
Alek Storm
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
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