HaloO,
On Thursday, 22. October 2009 20:58:15 I wrote:
> The class Dogwood however might be written as
>
> class Dogwood does Dog[Dogwood:] does Wood[Dogwood:]
> {
> method Dog {...}
> method Wood {...}
> method bark {...}
> }
On #perl there was the question if any type could be put
into the brackets, e.g. 'class C does B[A:]'. But this is
a semantic error like using a role in an is clause or a
class in a does clause. However I see this as a weakness
of my proposal. So we could actually use 'class Dogwood
does Dog:self does Wood:self' as alternative. This is
hopefully closer to the point.
> where the explicit invocant type prevents the creation of the
> subclass relations between Dogwood and Dog and Wood. So in an
> environment which requests plain Dog a Dogwood instance is only
> applicable after the call of the coercion routine which could
> setup things so that Dog::bark is dispatched to. Environments
> that want Dogwood::bark need to explicitly coerce Dogwood instances
> to Dog[Dogwood:] which actually is a no-op. But then other non-Dogwood
> Dog doers are excluded unless they have a Dogwood coercion routine.
> Or they use the Dogwood class directly.
While pondering the consequences of my proposal it occurred to me
that the use of a juxtaposed type Dog Wood should not mean Dog[Dog:]
Wood[Wood:]. That is each with its role as invocant, because this
would force an ambiguous type conversion on Dogwood. So I change the
proposal such that a juxtaposition means Dog[::T:] Wood[T] which
nicely gives the Dogwood implementation of bark as requested by the
two roles.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
