preferences (was: generic functions)

[Jecel Mattos de Assumpcao Jr.]

I agree with some of what Rene' and Patrick have said about generic
functions, but must admit to being an object/message passing fan.

It is very true that objects alone are not sufficient for all "grains"
of modularity that one might want in a system. Yes, you will have to
patch some basic class ( in Smalltalk, for example ) to make your
application work and that can be a mess in an "image" shared by many
users on a network. Generic functions seem to be the answer - you
"patch" the class hierarchy from the outside, without disturbing
other users of the same classes. I found the Cecil approach even
more interesting than Dylan's, for example, but I don't know as much
as I would like about either one.

But if we look at SmalltalkAgents for the Mac, however, we see that
this problem *can* be addressed in the object/message passing framework.
This language allows local "name scopes" when looking up messages, so
you can patch the Number class without affecting other users or even
other applications of your own.

I think that this is just the tip of the iceberg - the problem is more
complex than it seems. I have placed this in the "preferences" subproject
in Merlin. I have identified these preference levels ( at least ):

   - object: an object might decide what font to use or what color
     it should be

   - application: all of the objects in an application might share
     a sound volume or cursor shape

   - user: will the prompts be in English or French?

   - machine: screen resolution and compiler

   - site: date and time, users and permissions

Don't let my examples fool you - any characteristic might be defined at
any level. I wasn't able to arrange these things in a strict order, but
the one I listed them here is a reasonable one.

What does this have to do with generic functions? I am pointing out that
they are simply not enough! Adding the argument types to the "lookup"
of the code to be executed does make the system more flexible, but there
is a *lot* more context that could be taken into account here than just
that. I am looking for a solution to the whole problem, not a limited
subset of it.

A single dispatching solution to a problem that is inherently
multi-dispatching ( and my experience says that these are not that
common ) has traditionally been based on either double-dispatching
or coercing. It would be interesting to compare these two solutions
with generic functions for one or two real world examples to see
how much we would gain ( or lose ).

Regards,
-- Jecel