Darren New wrote: > Christopher Smith wrote: >> Smalltalk would be dynamic and unbounded, because the polymorphism is >> entirely at runtime, and there is no requirement to define a base class. > > Every class depends from Object. In theory, you can actually create a > class without having Object in its superclass heirarchy, but in > practice nobody actually does that. 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:. > 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. 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". >> 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. The separate address space architecture is exactly *why* C doesn't guarantee that you can do that cast, and POSIX's dlsym() effectively guarantees that you can or you can at least pretend to so long as you never actually try to *use* the pointer as pointer to data. >> In general, as Java (and Ada before it) has demonstrated so well and so >> often, while there are advantages to a language define all aspects of >> the runtime environment, it can be a good think to leave some of the >> work to a platform. > > Yep. Not that I say C's approach is "wrong" as such, but to say (for > example) that C is better for writing OS-level code than something > else is ignoring that once you start writing OS-level code in C, > you're often abandoning C in favor of "whatever your C compiler > outputs for this undefined-semantics chunk of source code." :-) >
Actually, C makes a distinction between "undefined behavior" and "implementation defined behavior". One is an error, the other is not. --Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
