Talk:Class-based OOP

I don't agree with the title of this article. I think nobody actually uses the term "Class-based OOP" to describe object-oriented programming using classes. I would rather have something like "Object-oriented programming in statically typed languages", or merge back into object-oriented programming, which seems to have become biased towards run-time aspect of OOP. esap July 4, 2005 22:06 (UTC)

Static typing and classes are not related to each other in any way. Wouter Lievens 4 July 2005 22:20 (UTC)

Obviously, the current title is for the lack of a better term. Because OOP can be with or without classes, I think it makes sense to have a separate article for OOP with classes. Oh, how about this title "OOP with classes"? -- Taku July 5, 2005 01:10 (UTC)

I think classes contain both compile-time and run-time aspect [among others], and the compile-time aspect gives rise to many important properties of object oriented programming, such as invariants, interfaces, object identity, method types, member types, the difference between public and private members, type of object references and subtyping constraints. From this article, to me it seemed that only those parts of the "object-oriented programming" article were moved to this article that depended on these statically typed aspects of classes, hence the proposal to change the title. However, my opinion is that these snippets taken from the object-oriented programming article are more about object-oriented programming in general when used with a static type system than about object-oriented programming involving classes. Of course, it's possible to develop this article to the direction of describing just the object-oriented programming with classes, but I feel currently it's both missing half of that [e.g. run-time aspects] and has things that are way beyond that scope [e.g. discussing drawbacks of mixing subclassing and subtyping, which are related to design of static type systems]. esap July 5, 2005 17:40 (UTC)

Well said. Now I realize that it probably makes little sense to talk in one article about OOP in C++ or Java and OOP in Ruby. Ruby uses classes but is untyped and uses very differently than C++ or Java. Objective-C is also a language that is similar but is again different than the three. I agree to merge this back to Object-oriented programming for now. -- Taku July 7, 2005 02:26 (UTC)

I think it does make sense to talk about OOP for both C++ and for Ruby in the same article, and I'd even recommend that, at minimum for being able to establish NPOV. And I'd prefer that article to be the object-oriented programming article. However, it's clear that there are distinctions between the two styles of OOP that need to be clearly understood and stated. I think it's preferable to just state clearly which concepts and constructs derive from the model of OOP used in Ruby, and which constructs derive from the model of OOP used in C++ or Java. When this is done, I think all conflict between those two models disappears, then they are just two facets of the same thing. I've changed the article so there is a separate section for discussing static type system with OOP. I don't know if the article already contains sufficient description of the model of OOP used in Ruby, but I suggest there should be a clearly distinct portion of the article to describe that, to make it clear which parts apply only to that style, and which parts apply to other styles. OOP is somewhat heterogeneous collection of practices and constructs, and it's important to make that explicit when describing it. esap 21:25, July 17, 2005 (UTC)

I don't understand what the fuss is about. Ruby is dynamically typed, i.e. only objects have a "type pointer" whereas variables don't. On the other hand, Java is statically typed, so that both an object and a variable have a (possibly different) type. Wouter Lievens 21:39, 17 July 2005 (UTC)

Static typing is normally taken to mean that type checking happens *before* execution. This means static typing can find problems with the code at an early stage in development. If these checks could only be done when the program is being run, this would cause many problems to be found too late, in the sense that then testing would be the only way to find such simple errors. And testing cannot prove the absence of errors (static typing can!). Static typing does influence the way software is written, because the programmer can rely that simple mistakes that can be automatically found by the type checker do not exist in the code. The effects to the language design are much greater than simply assigning type to both variables and objects. For example, static typing is essential for being able to describe APIs, because without static type checks, you would have no way of knowing whether the two parts of the code that interact via the API work together in all situations or not. Having this information available allows you to write big pieces of code without the code being reduced into a complex mess, because it facilitates modularity by making clear and formally checkable distinctions between different parts of code. This means it's easy to give two parts of code to different people to code and be certain that they can't break each others' code silently. esap 08:43, July 18, 2005 (UTC)

I agree that static typing has many advantages, but I don't see how that is related to the original point? Wouter Lievens 08:50, 18 July 2005 (UTC)

The discussion has been about how to organize the description of OOP, such that both points of view ("OOP as in Ruby" and "OOP as in C++") will be adequately represented, and such that the descriptions give an accurate picture about each model or style of OOP. It's very easy to mix the model of OOP used in Ruby and the model used in, say, C++, because both use similar terminology (e.g. object, class, inheritance, etc.), but in such way that the uses of the same term or concept do not mean exactly the same thing. In particular, this applies to concepts where C++ or Java relies on static typing. There is a closely related concept in Ruby as well, but which is not compile-time (because I believe there is no compile-time in Ruby), which is often named similarly than the corresponding C++ or Java concept. I think similar issue occurs with the model of OOP used in CLOS, because it also has strong emphasis on run-time constructs. One clear example is the concept of "class" in C++ and the concept of class in CLOS. The classes in CLOS are a full-blown implementation of what C++ people call with the name "RTTI" or "Run-time type information". In C++, classes and RTTI about classes are clearly distinct things. esap 09:20, July 18, 2005 (UTC)

I'm aware of that, that is why we say CLOS has a meta-object protocol and is a fully reflective language, whereas C++ is not. But the concept of "class" is pretty much the same in both languages (though what you can do with the class differs greatly). Java lies somewhere in between. My point is: there is no need for introducing new concepts to distinguish "OOP in Ruby/Python/Smalltalk" and "OOP in Java/C++/Eiffel", because that distinction already exists in the concepts Dynamic Typing versus Static Typing. It's the same discussion as in Scheme versus Haskell or Perl versus C. So I ask, what's the fuss about? We need only mention that A) static/dynamic typing are both used in OOPL and B) some OOPL's are reflective, some are not. I'm not saying the article's ok right now, I'm saying the discussion above can be reduced to these 2 topics. Wouter Lievens 10:12, 18 July 2005 (UTC)

I agree, although I would not make such strict distinctions between reflective vs. non-reflective, since there can be various intermediate steps, where reflective facilities are supported to some extent. Of course, the impact of these language design decisions do influence the model of programming that is used. But on the overall, I think we agree. I think we can conclude that there isn't much fuss, only the article needs some work. esap 17:55, July 18, 2005 (UTC)

Note

Just a note. Don't use the word "untyped" as it is nonsensical in this context. Every class-based language is typed, as all objects are typed (i.e. have a "pointer" to their class object or vtable). The essential difference is: are variables typed (static typing) or are they not (dynamic typing). Just seeking terminology compromise here :-) Wouter Lievens 21:37, 17 July 2005 (UTC)