Darren New wrote: > Christopher Smith wrote: >> Yes, but being an instance of "23" is very different from being an >> instance of "Number", yes? For starters, since "23" isn't a class, you >> won't have an instance methods. > > Right. But it still makes you a child of "Object", doesn't it? No. You could descend the tree to all of Object's children, and you'd never get to an object that extends from "nil". >> It would still be bounded, as when you invoke a polymorphic function, >> you still have to bind the invocation on an instance of a base class >> (even if all objects must be of that type). > If everything is an object, and everything depends from Object, what > would be the boundary? When you say "bind the invocation on an > instance of a base class", which base class are you talking about, and > how does this differ from (say) Smalltalk? Let's take C# as an example. Let's say I want to polymophically invoke "square()". Now, you could try binding to Object, but Object.square() doesn't exist (unless you add it), so it won't work. In Smalltalk or with a C++ template, I could just say I want to invoke "square" and I don't have to specify which base class's method I'm binding to. In fact, there need not be a common base class for the method at all. *That* is the difference. > I can't think of anything else it would be. If you know exactly what > line of code to which you will dispatch on a particular call, the only > "polymorphism" would be in the name, not in the meaning. If the same > line dispatches to the same destination whenever it's called, you > could disambiguate simply by giving every function a unique name. Yeah, but static polymorphism means that your source code looks like it is invoking only one method, but the compiler resolves it to the unique method. So, overloading probably does fit the "static polymorphism" bill pretty well. >>>> 2) bounded vs. unbounded is about whether the programmer has to "bind" >>>> the polymorphism to a specific base type. >>> What if every type descends from Object, tho? Is that bounded or >>> unbounded? >> If you still have to bind it to a type, even if that type could be >> Object, they define that is "bounded". > Sorry. If you still have to bind *what* to a type? Let's say I have a method called "call" that Phone implements and EquityFuture implements. As much as you'd wonder how or why you'd want to, if you wanted to polymorphically invoke either with a language limited to "bounded" polymorphism, you're going to have to create some made up junk type that both Phone and EquityFuture implement, and then bind to that junk type. With an unbounded polymorphic system, you'd just invoke the method and not worry about a common base type with the method in it. > If every method can be overridden in a child class, and all objects > depend from the same superclass, I'm not sure what boundary you'd wind > up with. I guess so long all methods are implemented as virtual methods in Object, it really wouldn't really notice the difference. Of course, that would mean that all methods would exist for all objects, which is kind of insane. > What would be the "specific base type" that the "new" operator is > "bound" to in Smalltalk? Again, in Smalltalk there isn't any binding going on. It just does message dispatch at runtime, with no notion of the message being bound to a particular type. >>>> I can't think of one off the top of my head that is static and >>>> bounded, but someone probably has a generics mechanism that works >>>> that way. >>> Ada's tagged types, I'd think? >> I was thinking about that, but I can't remember exactly how it works. >> Certainly it was the most plausible scenario I could come up with. > > Actually, it's dynamic in part. Not too unlike C++'s mechanisms. Yeah, that's what I feared. I could see something like it that would be 100% static though. >>>> One way to think of it is how much work is being left to do at >>>> runtime. >>>> A dynamic unbounded system has no idea what type it is working with or >>>> what method it is invoking, so it has a lot of work to do at runtime. >>> I would think Eiffel is dynamic unbounded with O(1) dispatch, yes? >> Most Eiffel implementations use vtables like C++, so yes. Note that O(1) >> != no overhead. > > Right. But it's not backing up the tree of inheritance. I was > disputing "a lot of work at runtime" more than "no overhead". Sorry, I was comparing overhead vs. the non-polymorphic case. Eiffel is actually dynamic and bounded, so its overhead is a lot lower than a dynamic unbounded system, but even so, invocation overhead with a polymorphic method is non-trivially higher than a non-polymorphic one. > > I don't get why you were hung up on dlsym() specifically. > > I wasn't. That was your example. :-) There's a whole bunch of OS-type > things you can't easily do in C without going outside the language > definition. (True of most languages, but most people don't claim their > language is especially good for writing OSes.) You misunderstood what I was getting at with dlsym(). The problem with dlsym() is that technically C doesn't ensure you can cast void*'s to function pointers, but POSIX's definition of dlsym()'s basically requires it. So, no matter what language you *implement* dlsym() in, it's a C API,and technically you can't be sure you can actually use it from C. Kind of stupid, but it is what it is. > Only if you can invoke that binary. Remember, once the turing machine > is done, all you have is the turing machine's tape. After that, you > have to apply some interpretation to the symbols to see what was > computer. > > Or a better example I thought of on the drive home: SQL is turing > complete. That doesn't mean you could implement Firefox in it. Sure, > you could take a table that represents a web server and its contents, > and leave behind a table that is indexed by X and Y and the third, > fourth, and fifth columns are the RGB values at that position. But > that isn't Firefox. You could write something in SQL that would generate the Firefox binary though. :-)
--Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
