Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Roles and Mix-ins?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
David Storrs  
View profile  
 More options Jan 5 2004, 11:49 am
Newsgroups: perl.perl6.language
From: dsto...@dstorrs.com (David Storrs)
Date: Mon, 5 Jan 2004 08:46:08 -0800
Local: Mon, Jan 5 2004 11:46 am
Subject: Re: Roles and Mix-ins?

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


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.