On Sat, Dec 13, 2003 at 11:12:31AM -0800, Larry Wall wrote:
> On Sat, Dec 13, 2003 at 04:57:17AM -0700, Luke Palmer wrote:
> : For one, one role's methods don't silently override another's. Instead,
> : you get, er, role conflict and you have to disambiguate yourself.
How do you disambiguate?
> : For
> : two, you can attach new roles to an object at runtime (I don't know if
> : you can do this with mixins, actually).
>
> Yes, you can. The mixin creates a new singleton class every time
> you do it, derived from the previous class. My current thinking is
> that run-time roles work a little differently. You get a singleton
> class for the object the first time you apply a property, so that each
> object's properties remain distinct. However, subsequent properties
> re-use the existing singleton class, and do the same role-conflict
> checks at run time that "does" would do in the class definition
> at compile time. Furthermore, the singleton class is not really
> derived from the original class, but just presents a different view
> of the same class, so that, from the viewpoint of the object, every
> role has the same standing, and run-time roles aren't privileged
> above compile-time roles, as they would be if the singleton class
> were really derived from the original class. In a sense, the object
> thinks it's recomposing the original class, but it's slightly wrong.
After reading this several times, I _think_ I understand. Let me
check: imagine that the original class is a text buffer going from
0-99. We have two roles (A and B), each of length 100. Objects of
various types can then see different segments of the buffer (i.e.,
different methods/properties/whatever), as follows:
Type Can see
---- -------
Class 1-100
A 101-199
B 200-299
Class+A 1-100,101-199
Class+B 1-100,200-299
Class+A+B 1-100,101-199,200-299
Is that right?
Dave
