Re: SOS: Simple Object System

[Maciek Godek]

2008/9/24 Clinton Ebadi <address@hidden>:
>
>> The other is that in GOOPS a method is something
>> different than what is commonly known in OOP, because
>> a class doesn't know its methods (and furthermore,
>> methods can be created at any time of program execution,
>> not only during class definition). I'm not saying that
>> it's good or bad (but it's quite confusing when a few similar
>> but different notions share one name)
>
> Interestingly enough, CLOS predates C++ and Java ;-)

No wonder -- lambda calculus is a formal system to express concepts
and you can express practically anything in it. C was invented to program
von Neumann machines, and both C++ and Java are derivatives of C.

Note however that both these languages were invented to address
the particular needs of OOP and as such are well suited for that purpose
(or at least that's what the most people think. CLOS is rarely used
compared to C++ and Java -- can you explain why?)

> Separating classes and generic functions makes the language more
> powerful--now two orthogonal concepts may be combined in arbitrary
> ways. The classic example of having generic functions are multimethods
> wherein you can dispatch on the type of every argument of the
> generic. A simple example of this is the (simplified) present method
> from CLIM:
>
>  (define-generic present (instance view))
>
> Which then allows you to do nifty things like:
>
>  (define-method (present (instance <image>) (view <text-view>))
>     (format #t "[~A]" (alt-text-of instance)))
>  (define-method (present (instance <image>) (view <graphical-view>))
>     (display the image somehow))
>
> etc.

And what about
(define-method (present (zone <timezone>) (part-of-year <season>))
(define-method (present (santa <donor>) (child <acceptor>)))
?
I mean of course these examples are artificial, but that's not their point :)
(I won't expose it now to keep the reader in suspense, but stay tuned
as it will certainly appear in the sequel)

> Doing this with a single-dispatch system is much less aesthetically
> pleasing. Note also that multimethods are only one of many advantages
> to having generic functions--they also enable method combinations and
> a few other things. Stylistically, they make the OO system integrate
> cleanly with the rest of the language rather than having its own
> specialized syntax for method invocation.

I see your point, but I can't agree with it -- multimethods certainly
cause ambiguity and make the code harder to read (you can't tell
which method will be called unless you know the types of all its
arguments).

I've got a feeling that CLOS is an attempt to mimic synonymy that
is present (yes, present!) in natural languages. Yet it causes a lot
of confusion!

Note that in C++like syntax, you always precede the name of the
method with the object's name, and therefore you always specify
the context for your expression. (the object is the context)

This resembles the let form known from lisp, that is also used
to build context. (No expression in the world is context-free, but
the multimethods of CLOS seem to deny this simple truth)

>> There is also another issue concerning the fact that
>> methods are available in global namespace -- the
>> performance of the interpreter is always penalized
>> by the type lookup (obviously, this doesn't have to
>> be the case if the code is compiled)
>
> Type lookup in GOOPS should be very fast--there are a few fairly
> simple implementation techniques that more or less eliminate the
> overhead of method dispatch (or at least turn it into a few very low
> overhead table lookups). /The Art of the Metaobject Protocol/ is a
> good inexpensive book that gives a decent overview of how to implement
> a fast CLOS.

I'm not arguing about this -- especially that there's great conceptual
gain that results with this sort of elasticity. (Performance is the last
thing I care about right now. But I hope you're right :>)

>> But the most important feature of OOP that is missed
>> in GOOPS (because of global namespace methods) is the lack
>> of the clean separation of interface and implementation
>> in the way it's done in java, C# and the like.
>
> Actually, CLOS/GOOPS are perhaps the cleanest way to separate
> interface from implementation. You define a protocol as a set of
> generic functions and define methods upon them -- with no concern for
> the actual classes used with the protocol.

The disadvantage is that (unlike in Java, C# etc.) the "interface" isn't an
explicit object. I agree that this can be overcome with a proper discipline
imposed on source code, but the documentation of GOOPS makes me
think that no such discipline has yet been developed.

> In this way you can do implementation sharing via class inheritance or
> something akin to Java interfaces (if I understand them properly; I
> refuse to use such a language) and implement the protocol for
> arbitrary classes without having to arbitrarily force them to inherit
> from unrelated classes.

I don't quite get what you mean (I'd need an example).
BTW Java seems to gain popularity instead of loosing it.
(And I think that stupidity of mankind and human ignorance
are not the only reasons)

I admit that my arguments are somewhat abstract -- I haven't written
anything using GOOPS or CLOS, only read some documentation
(and although my mind was initially tabula rasa, but as I was getting
deeper into that forest, I kept having more and more doubts. Maybe
it's because I knew C++ before GOOPS?)

Best regards
M.