/* It does make sense, I suppose, if methods can be treated as Objects. This would also allow taking an Object and modifying it to replace method implementations. I suppose this is how languages like Ruby work?*/

I don't know about Ruby, so I can't say. There are languages (like Objective C and Javascript) that offer "prototype-based" OOP. These let you change what methods an object has, or what those methods do, at run time. I've never looked into the implementation, but this sounds like a table of pointers.

> A vtable is a table of function pointers that goes in the> object's data portion, and those pointers refer to the> functions that implement all virtual methods related to> that object.

I'm going to use Java as an example only because it's the language I feel most confident speaking about.

In Java, the lookup is based on the Object type. It looks in the Objects most specific type first for the method and then goes through it's lineage until it finds the method or runs out of super classes.

Obvously, doing this search on every call is silly so one way to optimize this is to place the result of the look up in a table: Type.method -> method location. There need only be one such table per classloader because class definitions are static. If one String's identityHashCode method is located in the Object class, all Strings identityHashcode implementations are.

Now, if you put this table in the Object data itself things are a lot more interesting. Now two Objects of the same class could have different implementations. I've just started really looking into functional programming but it makes sense that this would be the case if you can change or add methods to an Object dynamically.

I'm just wondering if that's how it's done in functional languages or if I'm talking out of my ass (again).

/* I'm going to use Java as an example only because it's the language I feel most confident speaking about.*/

That's fine. I've been using C++ because (a) non-virtual methods can demonstrate the gotchas, (b) I have at least a little knowledge of how it's often implemented, and (c) it should be readable.

/* In Java, the lookup is based on the Object type. It looks in the Objects most specific type first for the method and then goes through it's lineage until it finds the method or runs out of super classes.*/

Perl says it does this, which makes it possible to do some odd things with autoloading. I know that conceptually this is how C++ and Java act.

/* Obvously, doing this search on every call is silly so one way to optimize this is to place the result of the look up in a table: Type.method -> method location.*/

> > There exists different opinions on this matter. :)> (Java> > makes you make the same choice - final or not final,> but> > the default is the opposite of C++) > > Again, this is not correct. Making a method final doesn't> make in non-virtual. It makes it possible for the runtime> to inline it but this is side-effect of it's true purpose:> disallowing overriding.

Yes, I know, but, as you say, it has the effect of a non-virtual function (which can't be overridden in C++, only hidden).

> If I'm not mistaken, you can> extend a class in C++ and define the same method on that> extended class whether it is virtual or not.

That's correct, but as mentioned above, the effect is quite different (overriding for virtual, hiding for non-virtual).

> [Terje] could you explain what you mean by this> implementation method being used to "fake classes"? In> this case, how do you define "real" classes, and can you> provide any "authority" as to what should be the proper> definition of "class"?> > Many beginning programmers believe the methods are> actually laid out in memory right next to the data of an> object. That could be done, but since the various methods> are going to be identical functions, it's much more common> to lay out any necessary vtables and the data in the> object itself, and make the methods functions that can be> found when needed.> > That's what I mean by "fake classes." In truth, that's> not a Computer Science term. It's just something that> comes as a bit of a surprise to beginning programmers.

Yeah, but implementing something more efficient than a "naïve" solution doesn't make it fake... As has been pointed out in the discussion, this is more or less how _all_ the languages implement OO (at least the statically typed ones).

> I'm not aware of any authority for the terms. OTOH, show> Java programmers object oriented C code (such as the Linux> kernel), they'll almost all say "Oh, I get it -- they're> faking OOP!"

Now you may be getting at something. :) Indeed, it's possible to write OO code even in assembly, it's just not very easy, as there's no support for OO in that language. The usual terminology in this matter is, in my experience, what I said here, namely that OO is a design methodology or paradigm - a way of structuring the code, etc., and whether or not a language has _support_ for OO, determines how easy it is to write OO-programs in the language. There's no "faking" involved - only whether or not the language has support for it, or if you have to do it all, "manually".

> > > There exists different opinions on this matter. :)> > (Java> > > makes you make the same choice - final or not final,> > but> > > the default is the opposite of C++) > > > > Again, this is not correct. Making a method final> doesn't> > make in non-virtual. It makes it possible for the> runtime> > to inline it but this is side-effect of it's true> purpose:> > disallowing overriding.> > Yes, I know, but, as you say, it has the effect of a> non-virtual function (which can't be overridden in C++,> only hidden).

But the method is still virtual from the Java language perspective. The compiler doesn't statically bind the method calls.

> > If I'm not mistaken, you can> > extend a class in C++ and define the same method on> that> > extended class whether it is virtual or not.> > That's correct, but as mentioned above, the effect is> quite different (overriding for virtual, hiding for> non-virtual).

Yes, it's very different from how final methods work in Java. But it's exactly how static methods work in Java. That's the point. Final in java is not analogous to non-virutal in C++.

HelloI don't understand most of terms you are using. But I found your article, because I definitely need interface-oriented (language or) programming. The company called, BioCAT (www.TheBioCAT.com), which is developing customized analysis software for researchers in Biomedical Science, is in need for tools to simply the customization process.

Each individual (researcher) needs unique interface design and analysis. The analysis methods are quite limited, but interface are various for every individual. So I thought about interface-oriented programming which fasten the 'customization' process. I'd like to hear how you are going to develop this language. If you have some specific context you can develop on, it will be good for you too. Please tell me your progress about this project.Thanks