School(ID:1746/sch012)

? Separate class hierarchies in an OO Language ??

OO language with an emphasis on the rationalisation of types and classes, and a clean separation between, and separate inheritance hierarchies for  them.

Pontificia Universidade Catolica, Sao Paulo Brazil

Smalltalk-like in appearance, but learning from Eiffel, DuoTalk, Pool, C++, Beta

"This pseudo-variable is called self in Smalltalk, current in Eiffel, this in C++; in School it is also called self. The correct typing of this pseudo-variable poses some difficulties. When a method is inherited, and self has a new type in the heir, the method can become ill-typed. In order to avoid that, the type of self in the new class must be a subtype of the original type of self. In most OOPLs, as the type and class hierarchies are the same, the above requirement is always satisfied. In School, with separate hierarchies, there must be a constraint to
avoid this problem."
Related languages
Smalltalk => School   Influence
School => Green   Incorporated features of
School => LUA   Influence
School => Sather   Influence
References:
  • Ierusalimschy, Roberto A denotational approach for type-checking in object-oriented programming languages. Monografias em Ciencia da Computado 12/92, PUC-Rio, Rio de Janeiro, Brazil, 1992. view details
  • Rodriguez, Noemi de la Rocque; Ierusalimschy, Roberto; Rangel, José Lucas "Types in School" view details DOI Abstract: Since Smalltalk, many programming languages have tried to capture the flexibility of object-oriented languages into a static type system. Almost every object-oriented language presents its own concept of type system. Usually, these different type systems are incompatible, in the sense that a correct hierarchy in one language can not be easily translated to another language. Differences arise in points like single versus multiple inheritance (e.g. Beta versus Eiffel), separate hierarchies  for types and classes (e.g. Pool and DuoTaik), possibility of redefinition of signatures of inherited  methods (e.g. C++ does not allow, while Eiffel does), and many other topics.
    One of the reasons for those differences is the lack of a clear definition for the concept of "type" and the role of a "type system" in such languages. In (pure) OOPLs, objects carry their own operations, and these operations are the only visible part of an object; the only thing one can do with an object is to send a message to it. So, if we want to characterize types as, for example, "a collection of values sharing a common structure or shape", we should use only the operations as the visible structure of an object. Therefore, a good definition for types in 00 languages is that the type of an object is its interface, that is, its collection of operations. Following the above definition of type, we can say that a type error in an OO program is the sending of a message to an object that has no method for it. 2 Statically typed languages are those that can ensure the absence of such errors by a type-checking procedure performed during compile-time.
    School is a programming language designed to keep the basic semantics of object-oriented languages, mainly SmM_ltalk, with a secure type system. All values in School are objects. Variables do not contain objects, but references to them, and both assignment and parameter passing manipulate references. All comunication between objects are based on late-binding, and the binding depends solely on the receiver. Moreover, the type system has no influence over the semantics of the language.
    The main rule that has guided the development of School's type system has been to avoid any construction that can cause a "message not understood error" at run-time; obeying this rule, we have tried to make the language as flexible as possible. In order to do that, School has separate hierarchies for types and classes (specifications and implementations), structural subtyping, and constrained genericity. At the end, we arrived in a terse language that can model most type facilities presented by other 00 languages.
    This paper explains the type system of School. The next section discusses the separation between types and classes. Section 3 explains the facilities for constrained genericity. In section 4 we show the expressiveness of the language, and how specific facilities from other languages can be modeled in School. As usual, the last section draws some conclusions.
          in [ACM SIGPLAN] SIGPLAN Notices 28(08) August 1993 view details