--- TSa <[EMAIL PROTECTED]> wrote: > > First, when a role is applied to a class at runtime, a instance of > > that class in another scope may specifically *not* want that role. > > Is there a way of restricting a role to a particular lexical scope > > short of applying that role to instances instead of classes? > > I think you'll need an intermediate class that you use to apply your > role. Classes are open and that implies the possibility to merge > further roles into them. But this applies for all users of the class. > How this works when there are already instances I don't know.
Ah, that makes sense. > > Second, how can I remove roles from classes? > > Is that a wise thing to do? Roles are not assigned and removed > as a regular operation. What is your use case? I don't think I have a clear use case here because the examples that come to mind all involve adding and then quickly removing the extra behaviors when I'm done with them. That's going to be fraught with bugs. The "intermediate class" solves the problem but it instantly suggests that we have a new "design pattern" we have to remember. Basically, if I can't lexically scope the additional behavior a role offers, I potentially need to remove the role or use the "intermediate class" pattern. I suppose one could look at this as "separation of concerns". If I have an MVC framework, instances of objects in the M, V, or C portions might want to exhibit different behaviors, depending upon what I'm doing with them, but I don't necessarily want those behaviors to bleed over to the other layers of my application. Whether or not this is a clean way of looking at the problem, I don't know. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
