Darren New <dne### [at] sanrrcom> wrote:
> >   In what basis can you call it an OO language?

> That it has objects. Classes are a help, too.

  Then a modular language like Modula3 would be an OO language. It isn't.

> >   Having modules is not sufficient.

> OO without inheritance != modules. That's kind of the point I'm making.

  Classes without inheritance is simply a modular language.

  Don't get confused by the *name* "object-oriented". It's just a name
picked for shortness and clarity. It does not mean that having "objects"
is enough for a language to be object-oriented. The term means a lot
more than that.
  If you have modules only, that's not object-orientedness.

> >   If you inherit class X from class Y you are saying "X is a Y" (that is,
> > it implements everything Y implements and behaves like Y).

> Yes? So?

  So you are inheriting, thus you have inheritance, thus object-orientedness.

> That may be how you define it. However, note that with only interfaces, 
> you can't get a heirarchy like you're talking about.

  If you can't inherit one interface from another, thus being able to
construct a hierarchy, then it's not an object-oriented language.
What you have is basically a modular language with simple interfaces.

> >   If you make a class which implements an interface you are doing inheritance.
> > Limited perhaps, but still inheritance.

> And it's also possible to have OO languages in which there is no 
> inheritance. "Delegation-based OO" is what it's called.

  I believe you can make a hierarchy of more specific classes depending
on more abstract classes with that, can't you?

> >   (By the way, what does memory management have to do with OO?)

> The same thing modularity does. If you have to know what the lifetime of 
> an object and all its sub-objects are, then you've broken the 
> modularity. If I have to know whether my "window" instance holds onto a 
> reference to the "bitmap" item inside my "picture" instance, then the 
> author of "efficient_window" is not free to cache that information in an 
> implementation that inherits from "window".

  I may be unusually dumb today, but I did not understand anything of that.

  You are making some point about someone breaking modularity by bad
object-oriented design, or something similar. What escapes me completely
is what this has to do with object-oriented languages. (OO languages
provide you the tools; OO design is a completely different issue.)

> FWIW, Alan Kay, the guy who invented "OO", decided that dynamic dispatch 
> and memory management were the two requirements for OO.

  Those may be *minimum* requirements, but are they *sufficient*
requirements? I strongly don't think so.
  If a language doesn't even have the concept of a "module" in any shape
or form, then that language simply can't be an OO language.
  Modules are an essential tool for encapsulation and abstraction.
You simply can't have objects if you don't have modules.

  It would be quite funny to have an object-oriented language with
no objects whatsoever.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message