Author: allison
Date: Wed Apr 4 19:05:53 2007
New Revision: 17985
Modified:
trunk/docs/pdds/draft/pdd15_objects.pod
Log:
[pdd]: Some reorganization on the Objects PDD, a basic addition of super and
next, to be revised on further input from HLL implementers.
Modified: trunk/docs/pdds/draft/pdd15_objects.pod
==============================================================================
--- trunk/docs/pdds/draft/pdd15_objects.pod (original)
+++ trunk/docs/pdds/draft/pdd15_objects.pod Wed Apr 4 19:05:53 2007
@@ -138,14 +138,14 @@
specific vtable methods used to perform those objecty things, and the
supporting code provided by the interpreter engine to do the heavy lifting.
-Please note that Parrot, in general, does I<not> restrict operations on objects
-and classes. If a language has restrictions on what can be done with them, the
-language is responsible for making sure that disallowed things do not happen.
-For example, Parrot permits multiple inheritance, and will not stop code that
-adds a new parent to an existing class. If a language doesn't allow for
-multiple inheritance it must not emit code which would add multiple parents to
-a class. (Parrot may, at some point, allow imposition of runtime restrictions
-on a class, but currently it doesn't.)
+Parrot, in general, doesn't restrict operations on objects and classes. If a
+language has restrictions on what can be done with them, the language is
+responsible for making sure that disallowed things do not happen. For example,
+Parrot permits multiple inheritance, and will not stop code that adds a new
+parent to an existing class. If a language doesn't allow for multiple
+inheritance it must not emit code which would add multiple parents to a class.
+(Parrot may, at some point, allow imposition of runtime restrictions on a
+class, but currently it doesn't.)
=head2 Class PMC API
@@ -255,7 +255,43 @@
Class PMCs also have the "I am a class" flag set on them.
-=head2 Class Vtable Entries
+=head3 Classes, Namespaces, and the Class Registry
+
+Extending an existing class that has been instantiated creates a new
+class object that replaces the old class object in the Namespace.
+However, the old class object must be kept, as the old objects still
+point to it and do their method resolution and attribute lookup through
+that class object.
+
+If a class hasn't been instantiated, adding a method or attribute only
+modifies the existing class object instead of creating a new class
+object. Extending a class that has been instantiated only causes the
+creation of a new class object the first time it's extended. After
+that, methods and attributes added to it will only modify the existing
+class object until it is instantiated again.
+
+The Namespace always points to the most current incarnation of the
+class. All the class objects that belong to a particular namespace store
+a pointer to that Namespace object. They keep that pointer even if the
+Namespace object no longer stores a pointer to them.
+
+Since any given class name may have multiple corresponding class
+objects, the class registry has a much diminished role in this
+implementation. Its only responsibility is maintaining a mapping of
+unique IDs to class objects throughout the system. It can't be used for
+looking up classes by name, because it's possible to have multiple
+classes with the same name in the same namespace. The class registry may
+need to have names removed (since it doesn't care about names anymore).
+Low-level PMC types will also need entries in the namespace hierarchy.
+We may eventually be able to eliminate the registry of class IDs
+altogether.
+
+A class can be garbage collected when it has no instantiatated objects
+and no Namespace object referencing it (to mark it as live). When a
+class is garbage collected, it should remove itself from the registry.
+
+
+=head3 Class Vtable Entries
To make this work all Classes need the following vtable entries.
@@ -263,7 +299,8 @@
=item new()
-Instantiate a new object from the class.
+Instantiate a new object from the class. Set the instantiated flag on the
+class.
=item clone()
@@ -476,42 +513,6 @@
=back
-=head3 Classes, Namespaces, and the Class Registry
-
-
-Extending an existing class that has been instantiated creates a new
-class object that replaces the old class object in the Namespace.
-However, the old class object must be kept, as the old objects still
-point to it and do their method resolution and attribute lookup through
-that class object.
-
-If a class hasn't been instantiated, adding a method or attribute only
-modifies the existing class object instead of creating a new class
-object. Extending a class that has been instantiated only causes the
-creation of a new class object the first time it's extended. After
-that, methods and attributes added to it will only modify the existing
-class object until it is instantiated again.
-
-The Namespace always points to the most current incarnation of the
-class. All the class objects that belong to a particular namespace store
-a pointer to that Namespace object. They keep that pointer even if the
-Namespace object no longer stores a pointer to them.
-
-Since any given class name may have multiple corresponding class
-objects, the class registry has a much diminished role in this
-implementation. Its only responsibility is maintaining a mapping of
-unique IDs to class objects throughout the system. It can't be used for
-looking up classes by name, because it's possible to have multiple
-classes with the same name in the same namespace. The class registry may
-need to have names removed (since it doesn't care about names anymore).
-Low-level PMC types will also need entries in the namespace hierarchy.
-We may eventually be able to eliminate the registry of class IDs
-altogether.
-
-A class can be garbage collected when it has no instantiatated objects
-and no Namespace object referencing it (to mark it as live). When a
-class is garbage collected, it should remove itself from the registry.
-
=head2 Object PMC API
C<Object> PMCs are the actual objects, and hold all the per-object
@@ -658,7 +659,7 @@
=back
-=head2 Role Vtable Entries
+=head3 Role Vtable Entries
All Roles need the following vtable entries.
@@ -874,6 +875,7 @@
=item callmethodcc
+ callmethodcc
callmethodcc $S1
Make a method call, automatically generating a return continuation. If a
@@ -881,6 +883,26 @@
put it in the method slot. If a method name isn't provided then we
assume that things are already properly set up.
+=item callmethodsupercc
+
+ callmethodsupercc $S1
+
+Make a method call, automatically generating a return continuation. A variant
+of C<callmethodcc> that skips over the current class when searching for the
+method, and only looks in the parent classes. PIR may provide some syntactic
+sugar for this.
+
+=item callmethodnextcc
+
+ callmethodnextcc $S1
+
+Make a method call, automatically generating a return continuation. A variant
+of C<callmethodcc> that picks up an existing C<find_method> search where it
+left off for the current call. {{ Note: this depends on find_method being
+resumable, and on the context of a particular method including a pointer to the
+find_method call that found it. Neither may be feasible. }} PIR may provide
+some syntactic sugar for this.
+
=item newclass
$P1 = newclass $S2
@@ -1208,12 +1230,6 @@
Dog bark := method("yap" print) # It has a method 'bark'
Dog bark # call the method 'bark', printing 'yap'
-=head1 QUESTIONS
-
-Should we have a super or next opcode?
-
-{{ Shouldn't that be a super or next method call instead? }}
-
=head2 Translation
The following list a set of languages, then within each language what the
