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

[svn:parrot-pdd] r17907 - trunk/docs/pdds/draft

0 views
Skip to first unread message

all...@cvs.perl.org

unread,
Mar 31, 2007, 3:09:20 PM3/31/07
to perl6-i...@perl.org
Author: allison
Date: Sat Mar 31 12:09:18 2007
New Revision: 17907

Modified:
trunk/docs/pdds/draft/pdd15_objects.pod

Log:
[pdd]: Integrating some questions and comments on the Objects PDD.


Modified: trunk/docs/pdds/draft/pdd15_objects.pod
==============================================================================
--- trunk/docs/pdds/draft/pdd15_objects.pod (original)
+++ trunk/docs/pdds/draft/pdd15_objects.pod Sat Mar 31 12:09:18 2007
@@ -282,7 +282,13 @@

Adds a single attribute to the class. It takes a simple string name and,
optionally, a simple string value for type. {{ Conjectural: Actually, the
-simple string value alone won't cut it. We need to take a key there too? }}
+simple string value alone won't cut it. We need to take a key there too?
+Answer: No, just the string name of the type. Types are not classes, they just
+perform a C<does> operation.}}
+
+If the class has already been instantiated, adding a new attribute triggers the
+creation of a new class, replacing the old class. See L<Classes, Namespaces,
+and the Class Registry>.

=item add_method

@@ -568,6 +574,14 @@

Create a new class, named Sz, which has Py as its immediate parent.

+=item get_class
+
+ $P1 = get_class $S2
+ $P1 = get_class $P2
+
+Retrieve a class object for the class identified by the string name in $S2, or
+by the PMC key in $P2.
+
=item addparent Px, Py

Add class Py to the end of the list of immediate parents of class Px. Adds any
@@ -605,13 +619,6 @@
To make this work all PMCs must have the following vtable entries. They may,
for non-objects, throw an exception.

-The catalog metadata for objects is considered to be attributes on the class,
-so to get the offset for a class for an object, you fetch the object's class
-then look up the offset attribute from it. (The class attributes are detailed
-later) This is safe in general, since the only code reasonably querying a
-class' attribute list is the class code itself, and if a class doesn't know
-whether it's a Class-style class or not you've got bigger problems.
-
=over 4

=item find_method(string *)
@@ -685,30 +692,36 @@

{{ Conjectural:

-When a role is added to a class, we try to compose it right away, and flag up
-any conflicts that are detected. A conflict occurs if two roles try to supply
-a method of the same name (but see the note on multi-methods below). High
-level languaes will provide varying facilities to deal with this, and Parrot
-provides the primitives to implement them.
+When a role is added to a class, we try to compose it right away, and throw an
+exception on any conflicts that are detected. A conflict occurs if two roles
+try to supply a method of the same name (but see the note on multi-methods
+below). High level languaes will provide varying facilities to deal with this,
+and Parrot provides the primitives to implement them.
+
+When declaring a class, you can optionally supply an array of method names that
+will be supplied by the composed class because of a conflict in the roles. This
+is done using the named parameter C<resolve>. This feature supports composition
+conflict resolution in languages such as Perl 6.

When adding a role to a class, you can optionally supply an array of method
-names from the role to exclude from the composition process. This is done
-using the named parameter C<without>. It is not an error to list a method name
-in this array that the role does not have. This makes it possible to implement
-languages that provide for explicit exclusions on a role-by-role basis as well
-as Perl 6, which can supply an array of all method names in the class (since
-writing a method in the class resolves any conflicts between methods of the
-same name from roles, and automatically overrides it).
-
-The second primitive is aliasing. When adding a role to a class, the optional
-C<alias> named parameter can be supplied, with a value of a hash of strings to
-strings. The key of this hash is a method name in the role, and the value is
-the name we should give it when we compose it in to the class. This will allow
-Parrot to support languages that allow resolution of conflicts in this form.
-
-It is fine to use both C<without> and C<alias> with a single role. However,
-placing a method name in the exclude list and also aliasing it has undefined
-behaviour.
+names from the role to exclude from the composition process. This is done using
+the named parameter C<exclude>. It is not an error to list a method name in
+this array that the role does not have. This makes it possible to implement
+languages that provide for explicit exclusions on a role-by-role basis.
+
+When adding a role to a class, you can optionally specify that specific methods
+are to be aliased to different names within the class. This is done with the
+optional C<alias> named parameter. The parameter takes hash of strings, where
+the key is a method name in the role, and the value is the name it will have in
+to the class. (This is also sometimes used for conflict resolution.)
+
+If you C<alias> a method, it won't automatically C<exclude> the original name
+from the role. You can also explicitly C<exclude> the method name, if you want
+a proper renaming of the method. A C<resolve> at the class level will
+automatically C<exclude> all methods of that name from any role composed into
+the class. You can C<alias> the method if you want to call it from the composed
+class. (You might use this if you want the resolving method to be able to call
+either of the conflicting methods from two composed roles.)

If a method in a role is a MultiSub PMC and there is either no method of that
name yet OR what is in the method slot with that name is also a MultiSub PMC,
@@ -743,7 +756,7 @@

Adding the attributes C<a> and C<b> to the new class C<Foo>:

- newclass $P0, "Foo"
+ $P0 = newclass "Foo"
addattribute $P0, "a" # This is offset 0 + classoffset
addattribute $P0, "b" # This is offset 1 + classoffset

@@ -753,8 +766,8 @@

.local pmc FooClass
.local pmc MyObject
- find_class FooClass, "Foo"
- new MyObject, FooClass
+ FooClass = get_class "Foo"
+ MyObject = new FooClass

=head2 Calling a method on an object

@@ -855,6 +868,11 @@
Called when the object is destroyed. This method is only called if the PMC is
marked as having an active finalizer.

+=item clone
+
+Create an (anonymous) clone of the class. Unset the instantiated flag on the
+new class.
+
=item getprop

=item setprop
@@ -875,8 +893,6 @@

=item name

-=item clone
-
=item find_method

=item get_integer

Jonathan Worthington

unread,
Mar 31, 2007, 4:23:08 PM3/31/07
to perl6-i...@perl.org
all...@cvs.perl.org wrote:
> Adds a single attribute to the class. It takes a simple string name and, optionally, a simple string value for type. {{ Conjectural: Actually, the
> -simple string value alone won't cut it. We need to take a key there too? }}
> +simple string value alone won't cut it. We need to take a key there too?
> +Answer: No, just the string name of the type. Types are not classes, they just
> +perform a C<does> operation.}}
>
But names of types need to also be specifiable as keys for full
flexibility? Since they may be in any namespace, not just the current one.

> +When declaring a class, you can optionally supply an array of method names that
> +will be supplied by the composed class because of a conflict in the roles.

Should that read "...supplied by the class because...."?

> This
> +is done using the named parameter C<resolve>. This feature supports composition
> +conflict resolution in languages such as Perl 6.
>

You can already do this, by passing the same list to "exclude" for each
role. That doesn't seem to great a hardship to me - I just wanted to
make sure it was clear that this feature was just sugar, not adding
anything new? Note that to implement this the class has the keep the
resolve list around too, making classes a little bigger in memory (not
much I know, it's just an "is it worth it" question).

> - newclass $P0, "Foo"
> + $P0 = newclass "Foo"
> addattribute $P0, "a" # This is offset 0 + classoffset
> addattribute $P0, "b" # This is offset 1 + classoffset
>

Guess the talk of offsets need to go away, that's ye olde object model.

Thanks,

Jonathan

Allison Randal

unread,
Mar 31, 2007, 5:31:57 PM3/31/07
to Jonathan Worthington, perl6-i...@perl.org
Jonathan Worthington wrote:
>
> But names of types need to also be specifiable as keys for full
> flexibility? Since they may be in any namespace, not just the current one.

Fair enough. But I'll be very clear that using a key to specify a type
is *not* the same thing as using a key to specify a namespace. We only
use keys to provide a language-agnostic way of combining pieces of the
type name. And it's only a convention that the default type name of a
class happens to correspond to the namespace hierarchy for the class.
The type for a class in the namespace [ 'My'; 'Lengthy'; 'Hierarchy';
'Thing' ] may be just Thing.

>> +When declaring a class, you can optionally supply an array of method
>> names that
>> +will be supplied by the composed class because of a conflict in the
>> roles.
> Should that read "...supplied by the class because...."?

Because it sounds like "a class" and "the composed class" are different
things? I'll add "composed" earlier so it's clear that we're talking
about the same thing in both cases.

"When declaring a composed class, you can optionally supply an array of
method names that will be supplied by the class because of a conflict in
its roles."

>>> This
>> +is done using the named parameter C<resolve>. This feature supports
>> composition
>> +conflict resolution in languages such as Perl 6.
>>
> You can already do this, by passing the same list to "exclude" for each
> role. That doesn't seem to great a hardship to me - I just wanted to
> make sure it was clear that this feature was just sugar, not adding
> anything new? Note that to implement this the class has the keep the
> resolve list around too, making classes a little bigger in memory (not
> much I know, it's just an "is it worth it" question).

The difference is that marking them on the class applies to all roles,
not just a particular individual role. It also makes it possible to
check whether the class actually implemented the specified method, and
gives you introspective capabilities into method composition conflicts
resolved by the class. In general, C<resolve> is the preferred strategy
for conflict resolution, and we only provide the per-role C<exclude> as
a tool for languages that allow individual method exclusion. (I nearly
removed the C<exclude> feature entirely, but decided it was useful
outside of conflict resolution.)

> Guess the talk of offsets need to go away, that's ye olde object model.

Deleted. (Consistency pass coming up after I finish responding to
questions.)

Allison

0 new messages