List of problems and proposed solutions for objects:
Class namespace is global
At present it's not possible for a HLL to define a classname that
has already been used by another HLL. (Example: PGE/Perl 6 cannot
define a class named 'Closure' because Parrot already has one.)
PMC vtable entries don't work in subclasses (or subsubclasses)
Currently things are handled by deleg_pmc.pmc and default.pmc .
Unfortunately, it appears that the vtable entries in default.pmc
take place before delegation to a superclass. Pm proposes that this
be switched somehow -- i.e., inheritance should be preferred over
default vtable entries.
PMC methods aren't inherited by ParrotObject pmcs
If a METHOD is defined in a *.pmc file, that METHOD is not
automatically inherited by PIR-based subclasses.
This isn't true --leo (s. the get_as_base test in t/pmc/object-meths.t)
I've entered an example in RT, also available at http://nopaste.snit.ch:8001/8680 .
I should clarify -- the problem isn't that the method isn't inherited, but rather
that it won't work unless it's been specifically coded to work by a PIR-based subclass.
(See http://rt.perl.org/rt3/Public/Bug/Display.html?id=39329 )
getattribute/setattribute efficiency
Dan used to often remark that sequences like the following were "very slow":
$P0 = getattribute obj, "foo"
$P1 = getattribute obj, "bar"
$P2 = getattribute obj, "baz"
Instead, Dan suggested always using classoffset to obtain attributes:
$I0 = classoffset obj, "FooClass"
$P0 = getattribute obj, $I0 # which attr is this?
inc $I0
$P0 = getattribute obj, $I0 # and that?
inc $I0
$P0 = getattribute obj, $I0
Unfortunately, this doesn't seem to be very practical in many respects.
Can we at least get a declaration from the designers about the
appropriate style to use for object attributes? I much prefer the former
to the latter, and if it's a question of efficiency we should make the
former more efficient somehow.
The latter takes 2 opcodes, which is per se suboptimal, The former is much more readable, just one opcode and optimizable and never subject of any caching effects of the offset - e.g. what happens, if the getattribute has some nasty side-effects like adding new attributes.
Oh well, and classoffset does of course not work for Hash-like or other objects.
See also similar topic for pmc