All classes imply the existence of a role of the same name.
-- c
Please justify that.
--John
As a 'Joe Blow' type programmer trying to follow this thread, I went
back to the "traits" paper
<http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-012.pdf> and read
John's Polymorphism paper.
From the traits paper and some of what I have picked up, I think we have:
An object is an instance of a class. A class is composed of roles
(traits) + state + glue. Roles can be composed of other roles, but not
from classes.
Hence conceptually the programming sequence is a) make roles; b) make
classes; c) make objects. (This makes roles more 'fundamental/granular'
than classes.)
So:
- if u want an object direct from a role, perl6 automatically completes
the sequence by making an anonymous class for you
- if u want to add a role to an existing object, perl wraps the object
into a class, adds the role, reinstantiates the object.
Is my understanding correct?
I'm not sure, but am I right in thinking that a role can have objects
from other classes?
It seems to me that the jargon of 'inheritance' normally applied to a
relation between objects and classes is misplaced in perl6. It is rather
classes 'inherit' roles (like animals inherit genes from parents).
Objects emerge as exact copies of each other from a class (template),
only becoming individuals when their 'state' is changed. This is more
like asexual reproduction. Sexual reproduction requires that individuals
come from two predecessors and genes are not all passed on.
"inheritance" therefore implies a loss of information (not all genes
from both parents are expressed) and the complete individuality of
nearly each child.
In trying to understand the idea of types, am I correct in understanding
that perl6 is seeking to define the 'type' of an object by something
other than the name of its class?
If this is true, then from the equation class=roles+state+glue we see
that the type of the class could be defined in terms of 'role' and
'state'. If we assume that 'glue' is not involved in type, then objects
born from different classes may have the same type if their 'roles' and
'state' are the same (but not the content of the state), or they can be
made into the same type by having wrappers to emulate said roles and state.
If this is true, then anything that is not 'roles' or 'state' is 'glue',
which should be ignored by the type system. If the programmer wants
things currently defined in his/her class as 'glue' to be a part of the
type, then it should be factored out into a 'role'.
As for input and return values, couldnt these simply be considered
aspects of 'state'? Return is a sort of accessor that gives the end
value of a process, while input variables change the state of the object
at the start of a process.
Is this too simplistic?
However, I find myself completely lost when it comes to 'super-',
'generic', and 'duck' typing.
What extra capacities do these concepts give a programmer that cannot be
obtained from the roles/class/object hierarchy?
Regards,
Richard Hainsworth
