message passing vs. generic functions 
Author Message
 message passing vs. generic functions


>Subject: R^4RS Authors Comments on Dylan

>Regarding the notion of "smart objects" and message passing, we in the CLOS
>community have basically decided that this is an artificial and restrictive
>paradigm.  We believe that the essence of OO programming is class
>inheritance and dynamic function dispatching.  The notion of
>object->class->method-table is not necessary for understanding this; it's a
>useful implementation technique for methods that only specialize on one
>argument, but it's not the appropriate way to conceptualize things.  In
>particular, it breaks down completely when the choice of implementation
>technique is based on two parameters (consider output, where the effect is
>dependent on both the type of object being output and the type of output
>destination (ASCII terminal, window, or file)).

I hate to open Pandora's box, but since this mailing list is probably
not read by droves of Smalltalk weenies, I may be able to do so without
causing a 2 week mail flood. Wish me luck.

I find the CLOS generic function approach to be advantageous to the
SmallTalk and old Flavors message sending approach for everything but
one important case: delegation. Sometimes you want to have an object
that special cases a couple of operations, but sends most of them on
to another object. Neither CALL-NEXT-METHOD nor NO-APPLICABLE-METHOD
is a satisfactory solution to this problem, as each must be used on
a per generic function (or per generic function metaclass) basis and
the delegating object does not know or want to know the complete set
of operations likely to be performed on it. The MOP (as defined in
the AMOP) also cannot solve this problem as the only specializable
arguments to COMPUTE-EFFECTIVE-METHOD are the generic function and
the method combination object. None of the arguments is available.
Only by changing the way that effective methods are computed on a
system-wide basis is there a hope of providing delegation,
and this is likely to be difficult to do and non-portable even
with a standardized MOP.

Said more succinctly, the concept of object delegation is foreign to the
generic function paradigm. The former is object centric. The latter
is function centric. The function centric approach is more natural for
Lisp, but the object centric approach seems more natural to me for
systems of distributed objects.

Sat, 04 Feb 1995 04:57:07 GMT  
 message passing vs. generic functions

>I find the CLOS generic function approach to be advantageous to the
>SmallTalk and old Flavors message sending approach for everything but
>one important case: delegation. Sometimes you want to have an object
>that special cases a couple of operations, but sends most of them on
>to another object.

This is true.  However, in my experience, automatic delegation like this is
a dangerous practice, and perhaps it shouldn't be facilitated.

The problem is that new operations may be added without the knowledge of
the designer of the delegating class.  Perhaps this new operation should be
special cased, but since the class hasn't been updated, it will just pass
it on naively.

The Symbolics Genera stream system makes extensive use of such classes, and
it's pretty big mess.

If you have a fixed list of operations on a set of classes (as languages
like C++ force you to do) then you don't have the problem of unexpected
operations being added.  But then you don't need to implement delegating
classes by specifying just the special-cases; since the list of normal
cases is available you can define all the delegating operations explicitly
(yes, it's tedious, but you can define a macro to automate it).
Barry Margolin
System Manager, Thinking Machines Corp.

Sat, 04 Feb 1995 12:34:46 GMT  
 message passing vs. generic functions
[There is some nice polite helpful commentary on the next screenful;
don't hit "N" yet...]

===begin flame===


>This is true.  However, in my experience, automatic delegation like this is
>a dangerous practice, and perhaps it shouldn't be facilitated.


On the basis of this statement, I move that the CLOS object system be
added to Pascal, and that a non-prescriptive object system be used in
Scheme, which is supposed to be a language for non-anal-fixated people.

===end flame===

Earlier on, I suggested that object dispatch went along with the metaphor
of smart objects better than generic functions, and someone replied along
the lines of "you can still think of the objects as smart if you want."
(Then someone else, not responding to my point, described the two
approaches as "function-centered" and "object-centered" without objection!)

My point, which I think got lost, is that the metaphor that a programming
language actually embodies is NOT irrelevant and NOT trivial.  Yes, you can
think of any mechanism as if it were any other mechanism, once you are
experienced enough to understand all the deep issues, but when you are
learning something, like for example OOP, it makes a *huge* difference
what metaphor is presented *by the language itself*.

What I am saying is that *even if we only had functions of one argument*
[think about adding OOP to pure lambda calculus if that helps :-) ] there
would be an important pedagogic difference between

        (FN OBJ)


        (ASK OBJ FN)

even though there would be no significant implementation difference and
either syntax can be written in terms of the other.  There would be no
difference to an experienced OOP programmer, but there would be a big
difference to someone who is just learning how to think about this new
paradigm.  That's what I mean about paying special attention to
educational concerns.

As for functions of more than one argument, I am really not satisfied
with any approach that I know about -- I think the language design
people have more work to do.  I mean, it does feel weird to me to
interpret "3-2" as "ask 3 to subtract 2 from itself" as Smalltalk does,
but with generic functions, I don't want to have to write int-int,
int-float, float-int, float-float, float-rational, etc etc etc.  Maybe
it'd be okay if I wrote int-int, float-float, rational-rational, etc.
and there were some smoothly integrated general raising mechanism.
Does that exist?  If so, I might argue for having BOTH object dispatch
(for OOP) and generic functions (for things like arithmetic) in the
language.  They feel very different to me, even if you can prove that
they're somehow equivalent.

Here's a test case for your rasising mechanism.  I want to implement
Logo-style words in Scheme.  That means that I want an abstract data type
that encompasses symbols, characters, strings, and numbers.  This in turn
means that it should be legal to do arithmetic on strings, provided that the
string turns out to be full of digits and decimal points and so on.

So, I need a raising mechanism that will let me raise "3" to 3,
"3/4" to 3/4, "3.14" to 3.14, and so on.

Sat, 04 Feb 1995 23:29:39 GMT  
 [ 3 post ] 

 Relevant Pages 

1. Passing a generic which is a function of other generics

2. Shared Memory vs. Message Passing (Dead Horse Flogging)

3. Distributed objects vs. generic functions and multi-methods

4. Message passing vs multi-me

5. message passing not-vs. multimethods

6. generic interface real function vs real

7. Distributed objects vs. generic functions and multi-methods

8. Generic Functions vs. CLOS Methods

9. Replace standard MESSAGE function in C4 with own message function

10. generic functions to redefine builtin functions - how ?

11. Speed of pass by reference vs pass by value

12. Return Values vs Status Queries vs Status Messages


Powered by phpBB® Forum Software