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