Post by Tom Locke Post by Pascal Costanza Post by Steve Dekorte
And not knowing the type isn't just an unwanted side-effect, it's
actually the goal. Dynamic OO is about escaping from fragile and
inflexible type dependencies by using type independent messages
instead of type dependent functions.
You still haven't told us how you disambiguate the draw message
when your object inherits both from a weapon and a picture.
Especially when both draw messages have the same signature.
If there is type information associated with the *reference*, not the
object, e.g. as in a statically typed language, this can be used to
disambiguate. C# does this.
I don't know exactly how things work in C#, but I assume about the same
way as in Java. Now, what you're saying sounds like: suppose we have two
classes, Picture and Weapon, and a third class, Example, that (somehow)
inherits the draw method from both of the other classes.
Now, if we have
Picture x =new Example();
we know that draw from Picture is being called, rather than draw from
However, that does mean that we can't use our Example instance as both a
Picture and a Weapon in the same code. One way around that would be
Example x = new Example();
...and now you're explicitly indicating the namespace, just like you
except that the Java code smacks a bit kludgy to me.
Post by Tom Locke
It is conceivable that you could run into a big problem if you face
just the right interaction between multiple inheritance, polymorphism
and object identity. In practice this seems to be extremely rare. Is
this a big enough deal to dismiss object-dispatch in dynamically
typed languages? I'd say no, but that's more of a judgement call than
I feel that argument is somewhat backwards. We're not dismissing
object dispatch because of namespace issues, but because generic
functions are an alternative that is more powerful (I also find them
more elegant, but I recognize that is subjective).
The argument about name clashes was brought forward as a criticism of
generic functions, which were supposed to exist in a single namespace,
whereas, in object dispatch, method names are prefixed by an object, and
thus divided among multiple namespaces. If anything, object dispatch
would have an _advantage_ over generic functions here, so it could never
be a reason to dismiss object dispatch.
Having said that, I don't think the "object dispatch provides more
namespaces than generic functions" really makes sense. Whether you write
x.foo or (foo x) is just a matter of syntax. In as far as the type of x
helps disambiguate foo in the object dispatch case, it also helps
disambiguate foo in the generic function case.
In CLOS, methods must abide by certain restrictions set out by the
generic function. For example, the number of arguments must be
compatible. It is not allowed to define a method that takes three
arguments for a generic function that only takes two. However, this is
not an inherent property of generic functions; it's just a limitation of
CLOS. Without that restriction, I don't see how object dispatch
disambiguates more cases than generic functions. Generic functions can
dispatch on the type of their first argument every bit as well as object
Post by Tom Locke
What I wish I was more clear on, was how often, in GF based OO, one
ends up using names that object-dispatch people would consider overly
verbose, whether it be draw-gun at the definition site, or gun:draw
at the call site.
I think that is more a matter of culture than one of technical
necessity. For example, names like point-x are common in Lisp programs,
but not technically necessary (and often abbreviated locally by macros,
e.g. with-slots). Similarly, I find many (what I consider) overly
verbose names in Java code that are not dictated by technical necessity
as far as I know.
Also, as already pointed out, the real savings don't come from using
shorter identifiers, but from language features that allow programs to
contain fewer identifiers in the first place.
By and large, I agree with Pascal:
1. Generic functions are desirable. Compared to object dispatch, generic
functions are more powerful (and expressive).
2. Name clashes can arise. Since this happens regardless of how
dispatching is done, it is wise to make the namespace facility be
orthoganal to dispatching, as well.
Post by Tom Locke
I think this is a big reason why language design is such a mysterious
art - a deep understanding of the *pragmatic* reality of different
styles is only possible with a lot of experience, and few people have
the time to gain this experience in a wide range of paradigms.
The task is made even more difficult by the fact that , even if
something is superior, it will not always be recognized as such. People
will still cling to the way they're used to doing things, and they might
complain about your language perceived shortcomings loud enough that it
keeps other people away from your language. In the end, I think the best
you can do is make the language the best language for yourself. That
way, at least you can be happy. The rest of the world can take it or
"Trying to make bits uncopyable is like trying to make water not wet. The
sooner people accept this, and build business models that take this into
account, the sooner people will start making money again."
-- Bruce Schneier