Delegation in goops?

Delegation in goops?

[Alan Grover]

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

Re: Delegation in goops?

[Neil Jerram]

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

Re: Delegation in goops?

[Alan Grover]

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

Re: Delegation in goops?

[Alan Grover]

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