Weblogs Forum - Attempting to Define Interface Oriented Programming Languages

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Attempting to Define Interface Oriented Programming Languages

52 replies on 4 pages. Most recent reply: Feb 10, 2006 12:38 PM by D. Charles Lee

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 52 replies on 4 pages [ « | 1 2 3 4 ]

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: How C++ programmers think

Posted: Dec 30, 2005 11:19 AM

/* 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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: How C++ programmers think

Posted: Dec 30, 2005 11:25 AM

> 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).

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: How C++ programmers think

Posted: Dec 30, 2005 12:35 PM

/* 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.
*/

That sounds like a vtable to me. If I have

class animal
{ string species;

public
animal(string spec) : species;

virtual void make_noise(int i) = 0; // C++ way of saying "there's no default"
virtual void move(int i) { ... };
};

class dog : public animal
{ make_noise(int i) { ... };
};

Then dog's vtable will look like:

make_noise = dog_make_noise
move = animal_move

I've got the correct functions, but I don't need to actually search for which one to use.

/* There need only be one such table per classloader because class definitions are static.
*/

Yep.

/* 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.
*/

Assuming you can change the table's entries. If you couldn't, you'd just get code bloat -- so that's really the only reason to do things that way.

/* 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 would assume that's how it's done, but I really don't know. Somebody else will have to answer that.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: How C++ programmers think

Posted: Dec 31, 2005 9:24 AM

> > 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 Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: How C++ programmers think

Posted: Dec 31, 2005 9:37 AM

> [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".

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: How C++ programmers think

Posted: Jan 3, 2006 7:50 AM

> > > 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++.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: How C++ programmers think

Posted: Jan 3, 2006 9:32 AM

/* Yeah, but implementing something more efficient than a "naïve" solution doesn't make it fake...
*/

Well, when you put it that way ... (g)

D. Charles Lee

Posts: 1
Nickname: dxl57
Registered: Feb, 2006

Re: Attempting to Define Interface Oriented Programming Languages

Posted: Feb 10, 2006 12:38 PM

Hello
I 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

Charles Lee

Flat View: This topic has 52 replies on 4 pages [ « | 1 2 3 4 ]

Previous Topic

Next Topic