Austin Hastings wrote: > Jonathan Lang wrote: > > The danger isn't really in the ability to suppress a method from a > > given role or parent; the danger comes from the ability to suppress a > > method from _every_ role or parent. A safe alternative to this would > > be to define a class method which then turns around and explicitly > > calls the inherited or role method that you really wanted; the > > drawback here is the poor Huffman encoding involved: writing a method > > is considerably more bulky than saying "exclude ..." or "rename ...". > > You can resolve this dilemma in two ways (not mutually exclusive): > > forbid the latter options, or come up with a more succinct way of > > handling the former option. > > I don't think this is a disadvantage. > > Consider that ROLES already require some similar feature: When two roles > have methods that conflict, there is a requirement to suppress or rename > one or both methods.
Actually, no; roles don't _need_ "suppress" or "rename" options to disambiguate a conflict: the priority chain of "class methods, then role methods, then inherited methods" provides all the tools that are _required_ to remove ambiguities: you merely override the conflicting role methods with a class method - which may explicitly call the preferred inherited or role method, do its own thing, or both. This technique covers every benefit that exclusions and aliases provide with the sole exception of the ability to make a given method name unavailable. Its only other potential fault vs. suppress and rename is poor Huffman encoding. > Consider also that suppression across the board would be a valid > Aspect-Oriented operation. For example, adding or replacing a C<debug> > method. But suppressing the same debug method for use in finished > products might be advantageous, especially if it resulted in a smaller > compiled executable. > > To me, the "forget" or "discard" or "dispose" or "delete" (gasp) keyword > or operation has a valid place, even if it's not a frequently used > place. I guess the question is: Could we successfully implement this in > 6.1 as a module? It's been suggested that something like this could be handled by hacking the DISPATCH method of a class so that it throws an exception whenever that method gets called. This doesn't really _remove_ the method in question, but it does render it unavailable (implicitly, at least). ===== Jonathan "Dataweaver" Lang __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
