Can Programming be Liberated from the Two-Level Style? Multi-Level Programming with DeepJava Thomas Kühne Daniel Schreiber Darmstadt University of Technology Darmstadt University of Technology ¢¡¤£¦¥¨§©£ § ¦ ¡ "!## ¢$ ¦£ !&% ¥'£© (¢£¢) * ¨+ +§ ),- ¨ ¡$.¨¦-!/# $ ¨£ 243¨5 £7698:¡4(¢£¢.;=< Abstract the days of FORTRAN, types such as 0+1 @ % A§A< A ¨< 0?B Since the introduction of object-oriented programming few 0?> or were either directly supported or had programming languages have attempted to provide program- to be emulated with the help of supported types. There was mers with more than objects and classes, i.e., more than no direct support for handling the creation and management two levels. Those that did, almost exclusively aimed at de- of multiple instances of a type and in combination with the scribing language properties—i.e., their metaclasses exert lacking support for data abstraction this caused program linguistic control on language concepts and mechanisms— structures that hardly reflected the corresponding domain often in order to make the language extensible. In terms types. In contrast, object-oriented languages allow the use of supporting logical domain classification levels, however, of such types, as if they had been built-in into the language. they are still limited to two levels. One way to analyze the reason for this advantage of In this paper we conservatively extend the object-oriented object-oriented languages is to interpret user definable types programming paradigm to feature an unbounded number as a feature of an extensible language. The natural conse- of domain classification levels. We can therefore avoid the quence then is to look into other ways of making a language introduction of accidental complexity into programs caused extensible. However, even though many attempts have been by accommodating multiple domain levels within only two made to create languages and systems with programmer con- programming levels. We present a corresponding language trol over their concepts and semantics [29], none of them design featuring “deep instantiation” and demonstrate its managed to attract the majority of programmers. features with a running example. Finally, we outline the We argue that object-oriented languages are not success- implementation of our compiler prototype and discuss the ful because they feature a form of extensibility, but because potentials of further developing our language design. they provide means for accurately reflecting the problem do- main. They can thus be understood as allowing programmers Categories and Subject Descriptors D.3.3 [Programming to achieve a “direct mapping” [30] from problem domain to Languages]: Language Constructs and Features; D.3.2 program structure. However, given that object-oriented pro- [Programming Languages]: Language Classifications—Ex- gramming languages support only two levels (classes and tensible languages objects) for reflecting the logical domain classification lev- General Terms Languages, Design els, obviously the “direct mapping” quality cannot be main- tained if the problem domain involves more than two classi- Keywords domain metatypes, ontological metamodeling, fication levels. deep characterization In this paper, we use a running example that features three domain classification levels in order to demonstrate 1. Introduction how workaround techniques—that accommodate multiple Among the factors responsible for the success of object- domain levels within two programming levels—introduce oriented programming languages is certainly their ability to accidental complexity into programs (section 2). After rec- extend the number of types available to programmers. In ognizing the need for deep characterization and explaining our corresponding deep instantiation mechanism (section 3), we then show how multi-level support and deep instantia- tion can be integrated into a programming language and ap- Permission to make digital or hard copies of all or part of this work for personal or ply its features to our example (section 4). Subsequently, we classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation briefly describe our prototype compiler (section 5) and con- on the first page. To copy otherwise, to republish, to post on servers or to redistribute clude with a discussion of related work (section 6) and the to lists, requires prior specific permission and/or a fee. potentials of further developing our language design (sec- OOPSLA'07, October 21–25, 2007, Montréal, Québec, Canada. Copyright c 2007 ACM 978-1-59593-786-5/07/0010. $5.00 tion 7). 2. Multi-Level Programming tween classes and metaclasses) (see also section 6). In our approach, we continue to use ontological classification. In this section we introduce the concept of domain classifi- =AF¡©%. Fig. 2 shows 0O 3¢£¨< cation levels and demonstrate the accidental complexity in- PRQ as the domain type of 2001 troduced by mapping multiple domain levels into two pro- < gramming levels. 0=IKJI assuming that an on- line store offers products of F ¦< 2.1 Ontological Metamodeling various types, such as 0B , < < 0=INJMI 0+1SI , , etc. Note that =AF¡©%7 3¢£< In order to understand PFQ (a) Generalization ontological linguistic 0?O is not a gen- the difference between < classifier classifier metaclasses as used eralization of 0?INJ-I , i.e., not 2001 in reflective languages DVD Object the latter’s supertype, but its (targeting flexibility and type. Fig. 3 illustrates the «instanceOf» «instanceOf» difference between a super- extensibility [13]) and @F¡©%7$< type (here 0O ) and 'F¡ %T 3¢£< metaclasses used for represents PUQ 2001 a type (here 0O ) mirroring a multi-level < domain model in a pro- of 0?INJ-I using a 3D Venn (b) Classification diagram notation in which gram structure, it is Figure 1. Ontological vs Lin- the third dimension is used Figure 3. Super vs important to make an guistic Classification Meta explicit distinction be- to denote instantiation. Fig- tween linguistic classification versus ontological classifica- ures 3(a) & 3(b) graphically tion [23]. depict that the set theoretic interpretations of instantiation Fig. 1 uses the UML [34] notation for objects and classes and specialization are the elementhood (2) and the subset to show the relationships between a real product (the DVD (⊂) relations respectively, showing types and their subtypes “2001: A Space Odyssey”), the object representing it (object as sets and their subsets. < < It is easy to distinguish between the two cases, where a C¦D¢DFE 0 C¦D¢DFE 0 ) and their respective classifiers. Looking at from a language perspective results in its classification as concept X is either the type or supertype of a given concept < (/H.£$%$< T , by using the following litmus test: Take an instance I 0 G 0 C¢D¦D2E < an , since constitutes the usage of the UML < (&H,£ %$< C¢D¦D2E 0=IKJ-I 1 (here 0 ) of T (here ) and check whether it can be concept 0+G . regarded as an (indirect) instance of X. If yes (as is the case If one wants to under- =AF¡©%7$< with 0O ), then X is T ’s supertype. If not (as is the @2¡ % 3¢£¨< stand what the type of domain PUQ < ProductType metatypes case with 0?O ), then X is T ’s type. In this case, C¦D¢DFE 0 is in terms of the do- taxRate : Integer main where it occurs, one using absolute terminology, X may then be regarded as a needs to examine the do- metatype (relative to I). «instanceOf» While one can easily come up with examples involving main element it represents 2 domain further levels giving rise to meta-metatypes and so forth, (here the DVD “2001: A types Space Odyssey”) and then DVD three levels are already sufficient to demonstrate the diffi- culties entailed by the necessity to accommodate multiple determine the latter’s do- taxRate = 19 main type. In our example, price : Float domain levels within only two programming levels. the domain type turns out < «instanceOf» 2.2 Workarounds to be 0=IKJI . The fact that in an object-oriented pro- domain A number of design patterns such as the “Item Description” < instances C¦D¢DFE gram object 0 would 2001 pattern [12] or the “Type Object” pattern [20] testify to the < have class 0?ILJMI reflects price = 19.95 recurring need for representing structures like that of Fig. 2, that the “instance of” re- involving multiple domain levels, with only two program- lationship between objects Figure 2. Three Domain ming levels. As in our online store example, there is often the and their classes is of on- Classification Levels need to have a dynamic type level, i.e., be able to introduce < 5+¡¤&@ < Q 0?B tological nature. In other new types such as 0=VWIXIKJ-I , , etc. at runtime. As words, the programming levels mirror the domain classifi- a consequence, these types cannot be mapped to classes, but cation levels. need to be represented at the object level. Fig. 4 shows the < In a reflective language, 0?INJ-I would be further clas- generic structure of the “Item Description” pattern in which Y¨£$!#%¢ 3$ 2§A< ¦§Z /£¦[< 5 ©!#!$< 0 0 sified as 0+1 , i.e., the classification would change from plays the role of a type for at run- ontological (between objects and classes) to linguistic (be- time. 1 2 ]^^¤_$` In recent versions “Object” has been replaced by “Instance Specification”. For instance, element \ could be regarded as the type for all copies Here, we are sticking to “Object” for brevity and clarity. of this movie that may differ in packaging, condition when sold used, etc. described by ∗ n ItemDescription Description Item language tio i ip te types cr m es type attributes instance attributes d s e s t p c y t ∗ isOfType a f a i t ProductType Product t r «instanceOf» «instanceOf» e a m n r n i taxRate : Integer price : Float e a t t m a o p described by d a description an item type values instance values language Figure 4.