Re: setf.scm

[Chris.Bitmead@misys.com.au]

>> It seems to me you've just identified a classic case where multi-methods
> are >>great.
>
>Yes, that was the point.  Of course that assumes you're satisfied
>with hand-waving.  But I want an engineering design (pattern?)
>for a maintainable, extensible, robust understandable package.
>I want someone to show me how multi-methods makes that easier.
> If you can't get the built in dispatch to do what you want then MOP?
>
>If you suggest using the MOP then you're basically agreeing that
multi-methods are >not useful for real systems.

I'm no expert on MOP, but it seems to me that multi-methods, with or
without MOP is a way to formalise and standardise a way to define functions
that work differently according to their type.

If I've got 1000 functions to write for different display devices and
display objects, do I really care if I have to fiddle with the MOP in order
to get the dispatch algorithm right according to how I want things done?
Not that I can really see why you need to change the MOP anyway.

The point of multi-methods is that the 1000 functions can be fully
independant. I can just write it and load it. I don't have to worry about
where it should be called from, or how to dispatch to it.

Isn't that self-evidently a good thing?