Christopher Smith wrote:
On the contrary. It is a common Smalltalk idiom to implement decorators
as descendants from "nil" (not UndefinedObject, but rather an instance
of UndefinedObject) that implement doesNotUnderstand:.
OK. I never saw that.
Note, however, that if your decorator is a descendent of nil, and nil is
a descendent of Object, you're still a type of object. :-)
That's why I said it was bounded. Unlike C++, where you can have two
classes who share *no* common ancestor.
Yes, but you can't do polymorphism between them. We're talking about
"unbounded polymorphism", not "unbounded class hierarchy". When
Smalltalk does it's polymorphic dispatch, its only requirement is that
the receiver be an object (which is different from a subclass of Object,
as odd as that may seem), and since everything is an object, it doesn't
even have to check that.
Right. So wouldn't that make smalltalk "unbounded"?
When you use a vtable in C++, there is no way
to say, "invoke member foo() on whatever type this object is an instance
of". It is always "invoke whatever is in the vtable for Bar::foo() for
this object".
Yes. That's what makes C++ bounded, yes?
Maybe it's just that, not having read the paper, I don't understand the
use of the technical terms.
The only "rule" being violated, AFAIK, is casting between pointers to
data and pointers to functions.
Right. Well, ok, now put it on an architecture where data is in one
address space and code in another. Suddenly it's not working again.
And so on.
Not at all. I'd be highly surprised if said architecture had a fully
POSIX compliant dlsym(). So, instead you'd use whatever is the
appropriate equivalent for said architecture and all is well again.
Right. And whatever the equivalent is? You wouldn't be able to write it
in C. That's all I'm saying. Basically, if you're programming in C,
there's no guarantee you're able to do that at all. The OS would have to
implement dlsym() in a language other than C. (Of course, for something
like Ada, the compiler would be generating non-Ada code (i.e., machine
language) to implement the same thing, so it's really not that different.)
Which may be better or worse than other languages, where (say) there
might be a facility to do something, and the hardware/OS provides a
different way to do that which is incompatible but would be sufficient
for your purposes, and you find the language doesn't allow you to use
that other facility because it's incompatible with the language. :)
Actually, C makes a distinction between "undefined behavior" and
"implementation defined behavior". One is an error, the other is not.
Fair enough.
Pardon the rant. It's just one of those things like people saying "these
languages are both Turing complete, therefore they're equally powerful",
that when you actually understand what's going on with Turing
Completeness, you realize it's (a) a factually incorrect statement, and
(b) to the extent it's correct, it's proving the opposite of what the
speaker thinks it does.
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
