From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Grover Newsgroups: gmane.lisp.guile.user Subject: Re: Delegation in goops? Date: Sun, 19 Feb 2006 10:24:48 -0500 Message-ID: <43F88DC0.3040706@mail.msen.com> References: <43ECD742.8040808@mail.msen.com> <87psluku2x.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1140380892 13009 80.91.229.2 (19 Feb 2006 20:28:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Feb 2006 20:28:12 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Feb 19 21:28:10 2006 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FAvA7-00076m-VJ for guile-user@m.gmane.org; Sun, 19 Feb 2006 21:28:08 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FAv8i-0001tW-Rb for guile-user@m.gmane.org; Sun, 19 Feb 2006 15:26:41 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FAqbX-00058h-62 for guile-user@gnu.org; Sun, 19 Feb 2006 10:36:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FAqSi-0002q0-TW for guile-user@gnu.org; Sun, 19 Feb 2006 10:27:03 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FAqOT-00020m-V3 for guile-user@gnu.org; Sun, 19 Feb 2006 10:22:38 -0500 Original-Received: from [148.59.80.48] (helo=ww8.msen.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FAqUJ-0003qO-A8 for guile-user@gnu.org; Sun, 19 Feb 2006 10:28:39 -0500 X-Sent-To: Original-Received: from [192.168.1.220] (pool-151-196-178-13.balt.east.verizon.net [151.196.178.13]) (authenticated bits=0) by ww8.msen.com (8.13.4/8.13.4) with ESMTP id k1JFMZgt034510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 19 Feb 2006 10:22:36 -0500 (EST) (envelope-from awgrover@mail.msen.com) User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en Original-To: guile-user@gnu.org In-Reply-To: <87psluku2x.fsf@ossau.uklinux.net> Received-SPF: Pass (sender authenticated); receiver=(null); client-ip=151.196.178.13; envelope-from= Received-SPF: Pass (sender authenticated); receiver=(null); client-ip=151.196.178.13; helo=[192.168.1.220] X-Milter: Spamilter (Reciever: ww8.msen.com; Sender-ip: 151.196.178.13; Sender-helo: [192.168.1.220]; ) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:5165 Archived-At: Neil Jerram wrote: > Alan Grover writes: > > >>Does anybody have a solution to implement delegation in goops? >> >>I have an object that implements the full behavior of interest. Say it's >>an employee object. >> >>For whatever perverse reason, which I assure you is reasonable, I want >>to wrap the employee in another object. And, for the most part, it will >>act just like the employee, except in a few places. Let's say I want to >>have the employee masquerade as the CEO. The wrapper would implement a >>few methods like "title", "salary", etc. And, specifically, the wrapper >>doesn't need to know what all the other methods are, or what might be >>added later. >> >>Seems like a job for delegation. > > Sounds like a job for inheritance to me. But I'm sure you must have > thought of that and rejected it already, so can you explain why? That > will probably throw some more light on your objective and thinking. Assume that an instantiated "employee" already exists in the system (maybe via a third-party interface), so I can't just sub-class it. Assume that I want to delegate in two different ways. >>So, I looked at the goops MOP. >> >> ... >> >>"no-applicable-method" assumes that you will throw an exception. It does >>not let you substitute a method of your choosing. Specifically, it's >>result is discarded, and it appears to be approximately in the same >>place as "compute-applicable-methods" .... > > > But if you could customize no-applicable-method to return a just in > time method, you can equally well define your fallback method using > define-method, can't you? (Using to ensure that it matches all > possible arg types.) That is also one of my complaints. The only meaningful specialization on no-applicable-method is the first argument: which is the generic-function. So, you can't specialize on a specific generic function, and you can't specialize on the arguments to a generic function. If no-applicable-method was defined as: (define-method (no-applicable-method (gf ) . args) (note the "."), then I could specialize on the arguments. Not that it would solve the problem of delegation. > So I don't think this is a significant > restriction. Well, I actually replaced no-applicable-method, and wrote a cond statement to "specialize" on the arguments. I can't just write a single generic-function on , because I want to delegate on "all methods for class-x, except a few". So, I would have to enumerate all of the generic functions on the delegate-class. Which I could do at any one point in time, but somebody could add a generic-function/method in the future. I did come up with a limited solution. In goops, you can change the class of an object. So, as long as you only have one place where you want to delegate, you can construct a sub-class, and then force an object to become the sub-class. The behavior then looks like delegation: the new sub-class is my "wrapper" (the CEO impostor) which only need implement a few methods, and the original class is the delagate. But, if I "delegated" somewhere else, it would break the first delegation. I think I could hack another solution via compute-applicable-methods (by replacing it). When I detect that I need to delegate, I return a special "delegate-this" method, which calls the generic-function with appropriate arguments fixed-up. Something like: (define-method (compute-applicable-methods (gf ) args) (if (need-to-delegate? gf args) (make-delegate-this gf args) (old-compute-applicable-methods gf args)) (define (make-delegate-this gf args) (construct-correct-data-structure delegate-this)) (define-method (delegate-this gf args) ; overly simplified: ; replace-wrapper-with-delegate needs to know ; what wrapper-class needs replacement (with what) (apply gf (map replace-wrapper-with-delegate args))) But this all smells bad to me. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user