* Delegation in goops? @ 2006-02-10 18:11 Alan Grover 2006-02-11 11:34 ` Neil Jerram 0 siblings, 1 reply; 4+ messages in thread From: Alan Grover @ 2006-02-10 18:11 UTC (permalink / raw) 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. So, I looked at the goops MOP. "compute-applicable-methods" would let me decide when to delegate or not. But, "next-method" is implemented in such a way that it doesn't call "compute-applicable-methods". Though not perfectly clear to me why, next-method returned "no-method". "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" so you would get the same problems as above. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Delegation in goops? 2006-02-10 18:11 Delegation in goops? Alan Grover @ 2006-02-11 11:34 ` Neil Jerram 2006-02-19 15:24 ` Alan Grover 0 siblings, 1 reply; 4+ messages in thread From: Neil Jerram @ 2006-02-11 11:34 UTC (permalink / raw) Cc: guile-user Alan Grover <awgrover@mail.msen.com> 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. > So, I looked at the goops MOP. > > "compute-applicable-methods" would let me decide when to delegate or > not. But, "next-method" is implemented in such a way that it doesn't > call "compute-applicable-methods". Though not perfectly clear to me why, > next-method returned "no-method". The functioning of next-method is based on inheritance. > "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" so you would get the same problems > as above. 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 <top> to ensure that it matches all possible arg types.) So I don't think this is a significant restriction. Regards, Neil _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Delegation in goops? 2006-02-11 11:34 ` Neil Jerram @ 2006-02-19 15:24 ` Alan Grover [not found] ` <6efab2350602250249r22295420vbd66286e5a05d12e@mail.gmail.com> 0 siblings, 1 reply; 4+ messages in thread From: Alan Grover @ 2006-02-19 15:24 UTC (permalink / raw) Neil Jerram wrote: > Alan Grover <awgrover@mail.msen.com> 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 <top> 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 <generic>) . 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 <top>, 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 <generic>) 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <6efab2350602250249r22295420vbd66286e5a05d12e@mail.gmail.com>]
* Re: Delegation in goops? [not found] ` <6efab2350602250249r22295420vbd66286e5a05d12e@mail.gmail.com> @ 2006-03-03 18:44 ` Alan Grover 0 siblings, 0 replies; 4+ messages in thread From: Alan Grover @ 2006-03-03 18:44 UTC (permalink / raw) I had previously asked about delegation in goops, and had proposed an ugly solution. I think I see another solution, since the effect I think I'm looking for is effectively subclassing but using an already allocated object. 1) If I create a subclass of the delegatee, I get the proper GF dispatch. Thus, by default, all GF's are "delegated" unless I override. 2) If I share the allocated object, than the state is affected as expected. Subclassing is easy, even "dynamically," since I can get the class of an object, and modify the delegator's super-classes. It appears that I can customize the getter/setter methods at class creation time, so I could construct "delegate" functions for the knowable list (and presumably, re-construct if the delegatee class changes). If I didn't want any slots in my delagator, I think I could almost re-use the delegatee as the allocated data. Otherwise, I just have to construct the getter/setters that refer to the delegatee. The 'compute-get-n-set is defined on <class>, so I'd probably have to make my own <delegator-class>, which makes sense. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-03-03 18:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-10 18:11 Delegation in goops? Alan Grover
2006-02-11 11:34 ` Neil Jerram
2006-02-19 15:24 ` Alan Grover
[not found] ` <6efab2350602250249r22295420vbd66286e5a05d12e@mail.gmail.com>
2006-03-03 18:44 ` Alan Grover
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).