Re: class interface of roles
TSa wrote:
I'm not familiar with the next METHOD syntax.
It's simple: if a multi method says "next METHOD;" then execution of
the current method gets aborted, and the next MMD candidate is tried;
it uses the same parameters that the current method used, and it
returns its value to the current method's caller. In effect, "next
METHOD" is an aspect of MMD that allows an individual method to say
"I'm not the right guy for this job", and to punt to whoever's next in
line. If not for the possibility of side effects that occur before
the punt, one could pretend that the current method was never tried in
the first place.
I see that quite different: roles are the primary carrier of type
information! Dispatch depends on a partial ordering of roles. I
think all roles will form a type lattice that is available at
runtime for type checks.
True: the relationships between various roles and classes ("who does
what?") is needed for runtime type checking. However, the _contents_
of the roles are only important for composing classes and for the
occasional runtime introspection of a role. If roles are never
composed or inspected at runtime, the only details about them that
need to be kept are "who does what?" - and if all type-checking takes
place at compile-time, not even this is needed.
But now we're getting dangerously close to perl6internals territory...
--
Jonathan "Dataweaver" Lang
[OT] Unicode fonts (was: Re: Hash composers and code blocks)
Mark J. Reed: > Aaron Sherman: >> Proposal: A sigil followed by [...] is always a composer for that type. >> >> %[...] - Hash. Unicode: ?...? >> @[...] - Array. Unicode: [...] >> ? - Seq. Unicode: ?...? >> &[...] - Code. Unicode: ?...? >> |[...] - Capture. Identical to \(...). Unicode: ?...? >> $[...] - Scalar. Identical to item(value). Unicode: ?...? >> #[...] - A comment. Just seeing if you're paying attention ;) > > Are those supposed to be question marks up there (meaning "up for > discussion"), or did something go awry in the email encoding (possibly > on my end)? It took me a while to find a font that displays them: Code2000. http://en.wikipedia.org/wiki/Code2000 (shareware) See also: http://en.wikipedia.org/wiki/Free_software_Unicode_fonts http://en.wikipedia.org/wiki/Unicode_typefaces http://www.alanwood.net/unicode/fonts_windows.html -- Affijn, Ruud "Gewoon is een tijger."
Re: class interface of roles
HaloO,
Stevan Little wrote:
On 10/2/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
This notion of exclusionary roles is an interesting one, though. I'd
like to hear about what kinds of situations would find this notion
useful; but for the moment, I'll take your word that such situations
exist and go from there.
Well to be honest, I haven't found a real-world usage for it yet (at
least in my travels so far), but the Fortress example was this:
trait OrganicMolecule extends Molecule
excludes { InorganicMolecule }
end
trait InorganicMolecule extends Molecule end
Wouldn't that be written in Perl6 the other way around?
role OrganicMolecule {...}
role InorganicMolecule {...}
role Molecule does OrganicMolecule ^ InorganicMolecule {...}
Which is a nice usage of the xor role combinator.
And from that I could see that given a large enough set of roles you
would surely create roles which conflicted with one another on a
conceptual level rather then on a methods/attribute (i.e. - more
concrete) level.
I don't abide to that. If roles are conceptually modelling the same
entity their vocabulary should conflict also. Well unless some
differing coding conventions accidentally produce non-conflicting
roles. The whole point of type systems relies on the fact that
concrete conflicts indicate conceptual ones!
Regards,
--
Re: class interface of roles
HaloO, Stevan Little wrote: As for how the example in the OP might work, I would suspect that "super" would not be what we are looking for here, but instead a variant of "next METHOD". I'm not familiar with the next METHOD syntax. How does one get the return value from it and how are parameters passed? Would the respective line in the equal method then read: return next METHOD($p) and self.x == $p.x and self.y == $p.y; I think that a super keyword might be nice syntactic sugar for this. > However, even with that an ordering of some > kind is implied The only ordering I see is that the class is "up" from the role's perspective. When more then one role is combined and all require the presence of an equal method I think the roles can be combined in any order and the super refers to the class combined so far. IOW, at any given time in the composition process there is a current version of the class' method. The final outcome is a method WALK or however this is called in composition order. Conceptually this is method combination: seen from outside the class has just one type correct method equal. Theoretical background can be found in http://www.jot.fm/issues/issue_2004_01/column4 I suppose this is again where the different concepts of classes are roles can get very sticky. I have always look at roles, once composed into the class, as no longer needing to exist. In fact, if it weren't for the idea of runtime role compostion and runtime role introspection, I would say that roles themselves could be garbage collected at the end of the compile time cycle. I see that quite different: roles are the primary carrier of type information! Dispatch depends on a partial ordering of roles. I think all roles will form a type lattice that is available at runtime for type checks. With parametric roles there will be dynamic instanciations as needed. Regards, --
