14

I am reading introduction to Scala paper and found following statement:

It should be noted that some object-oriented languages do not have the concept of class.

Question: Which object-oriented languages do not have class concept and how do they handle type(class) - object(type instance) relationship ?

om-nom-nom
  • 62,329
  • 13
  • 183
  • 228
tommyk
  • 3,187
  • 7
  • 39
  • 61
  • 10
    Javascript, [prototypical inheritance](http://en.wikipedia.org/wiki/Prototype-based_programming). – deceze Dec 18 '12 at 11:03
  • *"Your questions should be reasonably scoped. If you can imagine an entire book that answers your question, you’re asking too much."* - http://stackoverflow.com/faq#dontask – deceze Dec 18 '12 at 11:11
  • Perl 5 bless. I do not know what it's called. – senia Dec 18 '12 at 11:31

1 Answers1

6

Although it is common in popular languages to conflate them, classes and types are different concepts. A class is properly understood as a blueprint for an object, defining the attributes and methods that instances of the class possess, but an (object) type is an interface, describing what methods can be called with what parameters.

Thus, it is not difficult to imagine languages without classes. All you need is some kind of a construct for creating objects and for giving (new) objects attributes and methods; Javascript is a well known example. Inheritance will look a bit unusual in such languages, but certainly can be done (see for example Antero Taivalsaari's article "On the notion of inheritance").

ibid
  • 3,891
  • 22
  • 17
  • It's not conflated. Classes *are* types, but not all types are classes. – Ingo Dec 19 '12 at 12:45
  • 2
    Some languages treat classes as types, but conceptually they are orthogonal concepts. – ibid Dec 19 '12 at 14:06
  • I am not speaking about how "languages treat" them, but about what they are. You say: blueprints for objects. Well, I could say types are blueprints for values, objects are values, specifically values that are blueprinted by classes, hence classes are types. – Ingo Dec 19 '12 at 23:17
  • @Ingo Classes define behavior, types define contracts and substitutability. A subclass is not necessary a subtype of the parent type. http://c2.com/cgi/wiki?SubTypingAndSubClassing – ewernli Dec 20 '12 at 08:07
  • Why, @ewernli, classes may or may not define behaviour, as well as types. One can pair a n-tuple of values with a n-tuple of functions and declare that the latter define "the behaviour" of the former. – Ingo Dec 20 '12 at 08:20
  • It is correct, @ewernli, that subtyping is not the same as subclasssing - but from this we cannot conclude that classes are not types. We must not confuse mechanisms provided by languages, like inheritance, etc. with the concept of classes. They still remain a special form of tuples, or records, if you like that term more. – Ingo Dec 20 '12 at 08:26
  • @ibid In papers of W. R. Cook, I understand that in many cases inheritance is not subtyping. But also, he says that "classes are types", so can you elaborate a bit your metaphor: "classes and types are conceptually orthogonal"? – Ta Thanh Dinh Mar 23 '16 at 16:29