Business Object Components?

Erik Persson

Department of Computer Science

Lund Institute of Technology

Lund University

Box 118

S-221 00 Lund

Sweden

Erik.Persson@cs.lth.se

Abstract: Although the term business objects is notoriously polysemous, most authors making use of it seem to assume that business objects, apart from being ob­jects in the ob­ject-oriented sense, should also be re­usable, “plug-and-play” com­­po­nents. How­ever, the starting-point of the vision of ob­ject-orien­ta­tion is fun­damentally dif­ferent from that of soft­ware com­po­­nents, and objects and com­ponents cannot, as is often taken for granted, be fitted together without con­sider­able difficulties. To be more pre­­cise, these two programming paradigms clash in the con­cept of im­ple­men­­­ta­tion in­­heritance, which, while being funda­men­tal to most strains of ob­ject-oriented programming, viciously under­mines the plug-and-play com­posa­bi­l­ity required by software com­po­nentry, owing to a set of issues commonly, albeit somewhat ineptly, re­ferred to as “the fragile base class problem”. Below, having outlined what class fragility is, I will try to show how it af­fects business objects and how three impor­tant can­di­date plat­forms for the im­ple­mentation of busi­ness objects, viz. Newi, Java, and COM+, fare with re­­fe­ren­ce to it. Here­upon will follow a brief description of en­cap­su­lated pro­gram­ming, which is a novel style of programming attempting to har­mon­ise ob­ject-orienta­tion and soft­ware com­po­nentry on the basis of en­cap­su­lated in­herit­ance. This re­formed in­heritance mecha­nism, de­­­signed so as to eschew all kinds of class fragility, forms the basis of a new basic building block of software, the cap­sule, which in effect will assimilate the ob­ject and com­­po­nent con­cepts. Finally, I will also dis­­cuss how en­­cap­su­lated pro­gramming can be brought to bear on the three afore­­­mentioned candidates for a business objects plat­form.

Keywords: business objects, software components, encapsulated programming

1           Introduction

Business objects are often held to be, as it were, the ultimate software compo­nents, potentially pro­vid­ing for very high levels of reuse and software agility. For such business objects to become viable, various obstacles, will, however, have to be ove­r­come, of which a very serious one, viz. class fragility, provides the topic of this study.

The idea that the assembly of prefabricated parts or com­­po­nents, forming the basis of the in­dustrial pro­duc­tion of com­puter hardware and most other artefacts, can be taken advantage of also in the production of soft­ware was broached in Douglas Mc­­Ilroy’s famous invited address Mass Pro­duced Soft­ware Com­­po­nents, de­livered at the NATO con­­fer­ence on soft­­ware engi­neer­ing in Garmisch in 1968.[1] The basis of such soft­ware com­ponentry is the machine metaphor, a con­ception of a computer pro­gram­me as a machine-like contrivance built from parts, making en­cap­­­­­sulation and reuse the key­stones of software construction. In con­trast, ob­­­­ject-orienta­tion, originating slight­ly earlier with the SIMU­LA 67 language, rests on a world meta­­­­phor, which arises na­turally in the do­­main of soft­ware simu­la­­tions targeted by the SI­MU­LA lan­guage.[2] The allure of object-ori­ented soft­ware ­– including business objects – largely con­­sists in its em­­bodi­ment of a men­­tal mo­del of a set of real-world or imaginat­ive en­ti­ties that renders an ob­­­ject-oriented pro­gram­­me akin to a “micro­­­cosm” of message-ex­­chang­­ing ob­jects. In an oddly Platonic vein, the dynamically chang­ing, ‘material world’ of objects inside an exe­cuting object-oriented programme mirrors the unchanging, hier­archical­­ly structured, ‘ideational world’ of classes sculpted by a pro­gram­mer demi­urge. In sum, the lodestar of object-orien­ta­tion is hier­archical mo­delling, that of soft­ware com­­po­nentry the en­cap­­­­­su­la­tion of parts. Can these two fundamentally different outlooks be re­conciled?

In the 80s, as the interest in object-orientation, soft­ware com­po­nentry, and soft­ware reuse started to grow rapidly, Brad Cox made the in­genious and in­triguing at­tempt to amal­gamate the com­po­nent and ob­ject con­cepts through his notion of Soft­­ware-ICs.[3] These were binary packaged Objective-C ob­­jects, possess­­ing many of the dyna­mic pro­­­­­­­per­ties now wide­­ly held to be necessary for com­po­nents. The sup­port for im­ple­men­tation in­heritance implied by the object-oriented paradigm, however, gave rise to a number of “fragility” pro­blems that tend to seriously undermine the com­ponent idea. Through clever design, Cox attempted to counter the problems, although he was not able to re­solve all the issues involved.

Since the early 90s, the suitability of objects as com­po­nents has become in­creas­ing­ly contentious. In particular, weighty criticism has been levelled at im­ple­mentation in­­­herit­ance, the bedrock of ob­­­­ject-orien­ta­tion, but also the source of the fragility pro­blems. For example, Cuno Pfister, the chairman of Oberon micro­­systems, strikingly declares, “It may well turn out that im­ple­men­tation in­­herit­ance is the GOTO state­­ment of the nineties”.[4] Additionally, various problems pertaining to ob­ject-oriented frame­works seem to be de­rivable from imple­men­ta­­tion in­herit­ance.[5] ‘The fragile base class problem’ caused the de­signers of Micro­­soft’s Com­po­nent Ob­ject Model (COM), the as yet most success­­­­ful com­po­nent infra­struc­ture, to abandon im­ple­men­ta­tion in­herit­ance alto­­­gether. Rival com­po­­nent techno­­­logies, such as Open­­Doc and Java­Beans, have re­­tained full sup­port for im­­ple­men­tation in­herit­ance and the object-oriented approach, there­by, how­ever, also re­tain­ing the liability to the class fragility pro­blems. Pace the many advocates of such ‘traditional’ object-orientation, the swiftly rising star of component-oriented pro­gramming, as advocated in e.g. Szyperski’s sug­­ge­sti­ve­­ly named book Com­­po­nent Soft­­­­ware. Beyond Ob­ject-Oriented Pro­­gram­ming[6], seems to be beaming in the direction taken by the designers of COM.

Below, I will briefly adumbrate what class fragility is and why it is harmful to the business objects vision. I will then suggest how object-orientation and soft­ware com­po­nentry can be reconciled through encapsulated programming, a novel pro­gram­ming style that attempts to correct the deficiencies of the object-oriented in­herit­ance mechanism.[7] I will also discuss how the adoption of this programming style would affect classical Newi-style business objects as well as business objects im­ple­mented as COM components or as Java language objects, such as JavaBeans.

2           Class Fragility and Business Objects

In­heritance is widely held to be the dif­ferentia specifica of ob­ject-orienta­tion[8], but has become increas­ing­ly debated, as it clearly is also the source of mis­­cellaneous pro­blems.[9] According to Wegner and others, inheritance is es­sen­tial­ly a mecha­nism for the “in­cre­men­­tal modi­fica­tion” of a super­class by a sub­class[10], mak­ing poss­ible the pro­­­gram­ming style called pro­gram­ming-by-difference.[11] Be­­sides in­herit­ance, poly­­mor­­ph­ism is generally con­sidered essential to ob­ject-ori­ented pro­gram­ming.[12] Where poly­mor­phism is supported, values and vari­ables may be of more than a single type, where­as the ant­onym mono­­mor­phism implies that any value or variable in a pro­­gram­me may be of one and only one type. In ob­ject-oriented pro­­gram­­­ming, poly­morphism is yoked closely together with in­herit­ance, insofar as object references usually are poly­­morphic and re­­fer to objects that may be either of the type of the ob­ject re­fer­ence or of any sub­type of this particular type. In some pro­gram­­ming lan­guages that sup­port dy­namic typing, such as Small­talk or Ob­­jective-C, ob­ject re­ferences may hold re­ferences to any type of ob­­ject. When poly­morphism is taken ad­vant­age of, method re­­so­lution will happen at run-time by means of dy­na­­­mic or late bind­ing.

There are two distinct variants of inheritance, inter­face in­herit­ance (or subtyping) and im­ple­men­ta­tion inheritance (or sub­class­ing). The former term denotes the in­herit­ance of type (i.e. inter­face or protocol), the latter the in­herit­­ance of behaviour and state (i.e. implementation). Where­­as the virtuousness of interface inheritance is not very contro­­versial[13], imple­men­tation in­­heritance has ever and anon been decried as un­in­terest­ing[14] or po­ten­tially male­ficent[15]. Techno­logies such as COM and CORBA di­rect­ly sup­­port only interface in­heritance, where­­as most ob­ject-oriented pro­gram­ming lan­guages merge interface and im­ple­menta­tion in­heritance into one con­cept. An im­­por­tant ex­­cep­tion is Java, which of­fers a clear separa­tion of the two in­heritance types. In C++, interface in­­heritance may be simu­lated through public in­heritance of an ab­stract class, which has only pure virtual func­tion members, whilst pure im­­­ple­men­­­­ta­tion in­heritance may be simulated with private in­herit­­ance.[16]

Inheritance is sometimes said to “break encap­sula­tion”, be­cause it makes super­classes expose im­­­­­­ple­men­ta­tion details to their subclasses.[17] In this context, it is note­worthy that, in general, a class exposes two interfaces that usually inter­sect: the client inter­­face in­tended for ‘or­di­nary’ run-time usage and the specialisa­tion inter­face in­tended for subclassing.[18] In many object-oriented lan­guages, such as C++ and Java, it is poss­ible to restrict access to methods and instance data by the use of access modi­fiers. In C++ and Java, the methods and data of the client interface are declared pub­lic, those of the specia­lisation interface pro­tected, and im­ple­men­ta­tion details, which are to be accessible through neither inter­face, private. In both these lan­guages, mem­bers of the client interface will always be part of the specia­lisa­tion interface as well.

Whereas strict observance of the principles of infor­ma­tion hiding and data ab­strac­tion will mitigate the problem of en­cap­su­lation break[19], it will still at times be ne­cess­ary to have access to the source code of a superclass in order to be able to im­ple­ment a subclass cor­rect­ly. In par­ti­cular, this may be the case when a superclass method is over­­ridden by a method in a sub­class or when a sub­­class de­fines a method that will be recursively called from the super­class.[20] The cause of this need is that a sub­class – in contrast to an ordinary client – will share the important variable self (also known as this) with its super­­class. In­herit­ance-based reuse is at times re­ferred to as white-box re­use, because source code access is re­quired for the specia­­lisa­tion of the reused code. This need for source code access is evidently a serious obstacle on the road to markets for plug-and-play software com­ponents or business objects. For software componentry, ex­­tensi­bility mecha­­nisms sup­­porting black-box reuse, such as aggrega­tion, are, hence, frequent­ly claimed to be superior to white-box mecha­nisms.

2.1         “The Fragile Base Class Problem”

The locution “the fragile base class problem” emerged within Microsoft during the de­sign and de­ve­lop­ment of COM. Strictly speaking, this term seems in­appropriate, since, what is “broken” and thus “fragile”, will in most cases be a subclass rather than a base class, although the under­lying causes of the fragility often lie with a base class. Some authors use the term also for scenarios, where neither a base class, nor a sub­­class, but a client of a class is what “breaks”. In my con­­tention, the term “the fragile base class problem” is mis­­­leading and should be abandoned. Instead, I suggest class fragility as an overriding term for all fragility problems that per­tain­ to the use of classes; these can be further subdivided into subclass fragility and client fragility.[21]

Moreover, the term “the fragile base class pro­blem” is made to refer to different pheno­mena by different authors. Most­ly, the concept is understood as re­ferring to pro­­blems that occur when base class im­ple­me­ntations evolve in­de­pen­dent­ly of their sub­classes, and this will also be the sense used here.[22] There are two dis­tinct varieties of the problem, viz. syn­tac­tic and se­mantic fragility.[23] Since it will not be possible to explore these problems, which are both quite in­tric­ate and quite technical in nature, in de­tail here, we will focus on their con­sequences for components and business objects.

2.2         Syntactic Fragility

Source code references to external func­­tions and data (i.e. func­­tions and data de­fined out­side the current source code file) are tra­di­tionally re­solved at “link time” through static link­ing by a linker. However, in GUI en­viron­­­­ments, such as Windows and OS/2, run-time or dy­na­­mic linking to Dy­na­mic Link Lib­raries (DLLs) has caught the wind.[24] At the cost of an extra memory in­­­direction for each external re­ference, dy­na­mic linking makes it possible to upgrade a DLL with­out having to re-com­­pile and re-link all applications that make use of it, pro­vided that the functions and the data re­ferred to by these are not re­moved, renamed, or their types/signatures changed in the new DLL. This is a major benefit, mak­ing it easy to dis­tri­bute fixes and up­grades of binaries shared by a large number of pro­gram­mes without breaking them. For one thing, the Windows API is distributed as a set of DLLs. Un­for­tu­nately, such flexibility is only possible when procedure-ori­ented lan­­guages, such as C, are used; when ob­ject-oriented lan­guages are relied upon, the syntactic fragile class problem will stand in the way.

Syntactic fragility will make it necessary to re­com­­pile un­­modified subclasses and clients, whenever changes in the inter­face of a base class have been made, lest the sub­classes should “break” during exe­cution. Recompila­tion will be ne­cess­ary even upon apparently very harmless changes to the inter­face of the base class, such as a simple re­order­ing of its members. The problems derive from the way virtual methods and in­­­stance data are organised in tables and referenced by tabular offsets in the compiled and linked bina­ries of ob­ject-oriented pro­gram­mes. Un­for­tunately, the layout and size of these tables, which need to be known at com­pile-time, will tend to be affected by any modi­fication to the class interface, however slight.

Syntactic fragility causes two problems, re­com­pi­la­tion ava­lanches and the break­down of release-to-release binary com­pati­bility. Re­com­pi­la­tion ava­lanches tend to af­­fect pro­­grammer productivity very ad­versely, as appli­cations grow large and com­pi­la­tion- and link-time­s become increasingly protracted. In com­piled object-oriented lan­­­guages, this is ex­acerbated by the across-the-board use of file in­clusion directives and file time stamps to deter­mine which code needs re­com­pila­tion. In C++ and some other lan­­guages, the problem is primarily restricted to class inter­face changes by a clear­-cut se­paration of the class inter­­face from its imple­men­tation through header files, although some im­ple­men­­ta­tion de­tails ex­­posed by the inter­face of a class, such as in-line function mem­bers, may oc­ca­sionally add to the fragi­lity.[25] Languages that do not keep interface and im­ple­­men­ta­tion apart in dif­ferent files will be more vulner­able to syn­tactic fragi­l­ity, as not only interface changes, but any changes to the im­ple­­men­ta­tion part of a class will trigger the recom­pilation of sub­classes and clients.

The breakdown of release-to-release binary com­pati­bility af­fects system reliability ad­versely, inasmuch as the intro­duc­tion of a new version of an ob­ject-oriented DLL will possibly in­­validate all applica­tions that rely on this DLL, as the offsets used to address data and virtual func­tion members as well as the table sizes and layouts pre­sumed by any existing subclasses may no longer be correct. This obviously is a major obstacle for plug-and-play soft­ware componentry and business objects.

Various attempts to dispel syntactic class fragility have been made. Some of these, such as the run-time method dispatch of Smalltalk-80, Brad Cox’ Software-ICs[26], or IBM’s SOM (System Object Model)[27], only provide partial solutions and in doing so incur a more or less serious performance penalty to boot.

In the Java Virtual Machine (JVM), syntactic fragility is avoided by suspending 1) name re­so­lu­tion to link time (which happens either at load-time or at run-time) and 2) the deter­mi­na­tion of the storage layout of ob­jects to run-time.[28] Un­for­tu­nate­ly, the con­sider­able load-time/run-time per­form­ance penalty implied by this approach will have to be paid afresh every time a Java pro­­gramme is exe­­cuted and will grow con­sider­ably worse with code size and code com­plexity.[29] The success of Java is largely a con­sequence of the security benefits of the virtual machine approach for the – not very performance-critical – browser-based execution of code snippets down­loaded over the Internet. On the other hand, if the JVM approach is abandoned for com­pi­la­tion to native code, as is often sug­gested when the per­­­­form­ance problems of Java are de­bated or performance-critical application areas, such as web server or embedded systems programming, are considered, syn­tactic fragility will ne­cessarily re­appear.

Microsoft’s COM (Compo­nent Object Model) eschews syn­tactic fragility through the convention that published COM inter­­faces must be im­­mut­­able.[30] Finally, Newi’s co­operative business ob­­jects[31], which rely on semantic messaging for intercom­munica­tion, are not liable to syn­­­­tactic fragility at all, since dispatch is made dyna­­mi­cal­ly at message-time in a message loop. Although this kind of semantic messag­ing is much slower than ordinary method calls, the granularity of Newi’s busi­ness objects will en­sure that inter-object messaging will be comparatively rare, primarily hap­pen­ing due to direct user inter­­action.[32] Notably, both COM and Newi introduce a “layered” programming model, where inter-com­po­nent calls differ significantly from intra-com­po­nent calls. This two-layered approach allows both these technologies to pro­­­vide language inde­pen­­dence through the definition of a binary interface at the upper component/business object echelon.

2.3         Semantic Fragility

Semantic fragility is much more elusive in nature than its syntactic sibling, as it arises from evo­lu­tionary changes not to the interface of a class, but to its im­ple­mentation. It may show up, when­ever a new version of a base class, from which sub­classes have been derived through im­­­plementa­tion in­­­herit­ance, is introduced, pro­vided the base class makes a – direct or in­di­rect – poly­morphic self-re­cursive down-call. Since every poly­morphic self-call may po­ten­tially be resolved into a down-call, we can just as well say that the problem is latently overhanging in any class that makes at least one poly­morphic self-call. In addition, it may show up upon revision of a base class, the in­stance data of which are directly accessed from a sub­class. Mikhajlov and Se­ke­rinski, who have investi­gated this pro­­blem at length, dis­cern five dis­tinct cases of it, some of which are quite in­­volved.[33]

These cases will not need to be retold here; the bottom line is that whenever a base class is revised, any (unmodified) code taking advantage of the base class through subclassing may unexpectedly start to malfunction, although care has been taken to en­sure that the modifications in the base class will be entirely behaviour-preserving.[34] This will cause a breakdown of release-to-release semantic com­pati­bility and will compel subclass programmers to get access to and analyse the source code of base classes. Just like the lack of release-to-release binary com­pati­bility, this will of course seriously undermine the software componentry and business objects visions.

Since implementation inheritance is a crucial feature of object-oriented languages and these languages eo ipso are liable to semantic fragility, the problem has attracted con­siderable attention by researchers. Two kinds of countermeasures against se­mantic fragility that have been suggested are:

·     to “discipline” implementation inheritance by the establish­ment of a set of “rules”

·     to abandon implementation inheritance alto­gether

The former avenue, which has been dealt with in a number of research papers, seems to lead up to awkward and byzantine schemes that will force pro­­­­­gram­­mers to per­form complex analyses of the source code inter­de­pen­­dencies of methods, method group­­ings, self calls, etc.[35] Further­more, these schemes presume that the subclass pro­­gram­mer has access to the source code of super­­classes, which will be highly unde­sir­able in com­­po­nent/business objects scenarios. The latter avenue of forgoing imple­men­tation in­heritance altogether – taken, for instance, in Microsoft’s COM – will raise the hackles of many ad­vocates of ob­ject-orientation accustomed to the reliance on inheritance as a handy ex­tensi­bility mechanism.

3           Encapsulated Programming and Business Objects

Elsewhere, we have suggested that the clash of ob­ject-orienta­tion and com­­­­­­­po­nent-orienta­tion can be resolved through en­cap­sulated pro­­­gram­­­ming, a new programming style designed so as to be im­pervious to all kinds of class fragility, while still re­tain­ing sup­port for a restricted, “dis­ciplined” form of im­ple­men­tation in­herit­ance.[36] En­cap­­su­lated programming is based on two basic mandates:

·     Firstly, syntactic fragility is to be eschewed in one way or the other, be it through a semantic messaging mechanism as in Newi, an interface immutability con­vention as in COM, or the postponement to load-time/run-time of name lookup and of the computation of object layout as in JVM.[37]

·     Secondly, semantic fragility is to be addressed through the espousal of en­­­cap­su­lated in­­­herit­ance, which modi­­fies im­­ple­men­ta­tion in­herit­ance by banning poly­morphic self-re­­cursive down-calls and direct access to superclass data.[38]

In our terminology, an object that avoids syntactic fragility and sup­ports en­cap­sulated inheritance is called a capsule. Since, in our view at least, class fragility must be overcome, if the visions of software compo­nents and business objects are not to remain on the drawing-board, capsules should provide a suitable shape for the im­ple­mentation of components and business objects.

We will now try to clarify how encapsulated pro­gram­ming will affect business ob­jects, using Newi-style business objects, Java objects, and COM components as examples. We have chosen to look at Java and COM because of their current im­portance on the market overt, whereas Newi will be con­sidered both because of its historical impact on the business object com­mun­ity through the writings of Oliver Sims, “the father of busi­ness objects”, and because of its principal im­port­­ance.

3.1         Newi-style business objects

Newi’s semantic messaging mecha­nism effectively immunised Newi classes against syn­tactic fragility, although, by virtue of its support for im­ple­mentation in­herit­ance and poly­morphic self-re­­cursive down-calls, its objects were amenable to se­man­tic fragility. However, this was some­what mitigated by the fact that sub­classes and clients did not have direct access to super­class data. Thus, by removing the possi­bility of sending messages to self (but, of course, not to super!) from the Newi infra­struc­­ture, Newi could easily have been made to support encapsulated inheri­tance and the en­capsulated programming para­digm.

3.2         Java and JavaBeans

Java code executed in the Java Vir­tual Ma­chine is not liable to syntactic fragility, although the virtual machine approach may imply a significant performance penalty. This can be countered through dy­na­mic linking and com­pi­l­ing with cach­ing, which is a scheme that re­fines the JVM approach by cach­ing the linked and verified byte­codes – as well as any snip­pets of binary code re­sult­ing from dynamic com­pilation – in a cached image that, after a version control, can be taken advantage of on sub­sequent exe­­cu­tion of the code.[39] This approach will, I believe, reduce the performance pe­­nalty of the virtual machine approach considerably and still steer clear of syntactic fragility.

In order to avoid semantic fragility, the Java inheritance mechanism needs an over­haul so as to provide support for encapsulated in­heritance. Two minor measures will suf­fice: Firstly, all data members should be made private; thus, one should not be al­lo­wed to use the access modifiers protected and public on data members. Secondly, poly­­morphic self-calls of methods that are neither final, nor private should be dis­al­lowed. As the Java designers will not be likely to accept such bold reformation of their language, one may instead choose to use these rules as guidelines for the de­sign of Java or JavaBeans classes intended as reusable components or business objects.

In this context, it should be noted that encapsulated pro­gramming clashes with the workings of white-box frameworks, which tend to make heavy use of polymorphic down calls in accordance with the so-called Hollywood principle (don’t call us, we call you). Although certainly controversial, giving up the current frame­work reliance of the ob­ject-oriented approach appears to us a both necessary and highly bene­ficial step. In our experience, the chief cause for the low productivity and steep learn­ing curves of object-oriented pro­grammers as compared to developers that work with com­­po­­nent-based RAD tools stems from the reliance on appli­cation frame­works, which have an extremely high surface area[40] and thus are very dif­ficult to master and use. Application frameworks also violate funda­mental prin­ciples of soft­ware engineer­­ing, such as en­cap­sulation, infor­ma­tion hiding, and the mi­ni­misation of cross-module coupling, and, thus, tend to breed code complexity, undermine main­taina­bility, and create dangerously tight couplings between appli­cation code and frame­­works.[41]

The Java approach is, however, highly framework-oriented, and the thickets of frame­works surrounding the Java language tend to grow increasingly dense every day. For the Java programmer, it will not be a realistic option to dispense with all these frameworks. He can, however, use a two-layer strategy to mitigate the problems by abiding by the prin­ciples of encapsulated pro­gram­ming in Java and JavaBeans classes in­tended as re­usable components or business objects, while still taking ad­vantage of the Java frame­works internally in these.

3.3         COM

COM is already immune both to syntactic and to se­man­tic fragility, but lacks sup­port for implementation inheritance. It seems that COM would gain much by getting support for a simple-to-use extension mechanism, such as encapsulated in­herit­ance, since the extension mechanisms presently available to the COM programmer, dele­ga­tion and aggregation, tend to be both un­wieldy and difficult to use correctly.[42]

4           Conclusions

If business objects are to be objects in the object-oriented sense and also capable of being used as plug-and-play com­po­nents, the problems of class fragility caused by the flawed in­herit­ance mechanism of today’s ob­ject-oriented approach must be addressed. We have argued that the fragility problems can be ex­punged through the adoption of en­cap­su­lated pro­gramming and outlined how techno­logies such as Newi, Java, and COM can be modified so as to adhere to this style.

Business objects, being software representations of the things and entities of ‘the real world’, will need to be much more large-grained and flexible than the ordinary objects of object-oriented programming. Although the Newi product now seems to have faded out of sight in the hands of SSA, I believe that Newi-style, large-granular, directly user-mani­pul­able com­­po­­nents interoperating through se­mantic messaging as envisioned by Oliver Sims in his first book[43] still hold great promise as the proper shape for busi­ness ob­jects, in particular if modified according to the lines suggested above. For one thing, various on-going de­ve­lop­ments, such as the rise of XML and SOAP and the possibly im­mi­nent arrival of 3-D user interfaces, may make for a better apprecia­tion of this vision of busi­ness objects. By re­liance not on proprietary niche-technology, but on the rapidly matur­ing COM+, Java, or CORBA techno­logy com­­pages as infra­structural under­pin­nings, such business ob­jects should be able to gain in attractiveness in the market­­place. In the Panopeus project, of which this essay is a spin-off, I am cur­rent­ly in the pro­cess of de­­ve­lop­ing and ex­­ploring the agenda of realistic com­puting on the basis of this kind of large-grained business objects, semantic messaging, 3‑D user interface techno­logy, and en­cap­sulated programming.[44]

5           Acknowledgements

This research has been supported by Crafoordska stiftelsen and Helge Ax:son John­sons stiftelse.

6           References

[Berr95]         G. Berrisford: How the Fuzziness of the Real-World Limits Reuse by Inheritance between Bu­si­ness Objects, in J. Murphy, B. Stone (eds.): OOIS’95. 1995 International Con­fer­ence on Object Oriented Information Systems. Proceedings, Springer-Verlag, 1996, pp. 3-18

[Betz94]        M. Betz: Interoperable Objects, Dr. Dobb’s Journal, October 1994, pp. 18-39

[BM98]          J. Bosch, S. Mitchell (eds.): Object-Oriented Technology. ECOOP’97 Workshop Reader. ECOOP’97 Workshops. Jyväskylä, Finland, June 1997. Proceedings, Lecture Notes in Computer Science 1357, Springer-Verlag, 1998

[BMMB99]    J. Bosch, P. Molin, M. Mattsson, P.-O. Bengtsson: Object-Oriented Frameworks: Problems & Experiences, in [FSJ99] pp. 55-82, see also see http://www.ipd.hk-r.se/bosch/papers/ex-frame.ps

[Booc87]       G. Booch: Software Components with Ada, Benjamin/ Cum­mings, 1987

[Booc94]       G. Booch: Object-Oriented Analysis and Design (2nd ed.), Addison-Wesley, 1994

[Broc95]        K. Brockschmidt: Inside OLE (2nd ed.), Microsoft Press, 1995

[Chap96]       D. Chappell: Understanding ActiveX and OLE. A Guide for Developers & Managers, Micro­soft Press, 1996

[CN91]          B. Cox, A. J. Novobilski: Object-Oriented Programming - An Evolutionary Approach (2nd ed.), Addison Wesley, 1991

[Coll95]         D. Collins: Designing Object-Oriented User Interfaces, Benjamin/Cummings, 1995

[Cook89]       S. Cook (ed.): ECOOP 89. Proceedings of the Third European Conference on Object-Oriented Programming, British Computer Society Workshop Series, Cambridge University Press, 1989

[Cox86]         B. J. Cox: Object-Oriented Programming - An Evolutionary Approach, Addison Wesley, 1986

[CV65]           F. J. Corbató, V. A. Vyssotsky: Introduction and Overview of the Multics System, in AFIPS Conference Proceedings of the 1965 Fall Joint Computer Conference, AFIPS Press, 1965, pp. 185-196

[CW85]         L. Cardelli, P. Wegner: On Understanding Types, Data Abstraction, and Polymorphism, Com­­puting Surveys, Vol. 17, No. 4, December 1985, pp. 471-522

[DLS97]         K. De Hondt, C. Lucas, P. Steyaert: Reuse Contracts as Component Interface Descriptions, in [WBS97] pp. 43-49 and [BM98] pp. 338-342

[DN66]          O.-J. Dahl, K. Nygaard: SIMULA- An Algol Based Simula­tion Language, Communications of the ACM, Vol. 9, No. 9, pp. 671-678, 1966

[Duga94]        B. Dugan: Simula and Smalltalk: A Social and Political History 1994, see http://www.cs.washington.edu/homes/brd/history.html

[FCDR95]      I. R. Forman, M. H. Conner, S. H. Danforth, L. K. Raper: Release-to-Release Binary Com­patibility in SOM, in OOPSLA’95 Tenth Annual Conference on Object-Oriented Pro­gram­ming Systems, Languages, and Applications, ACM SIGPLAN Notices, Vol. 30, No. 10, October 1995, pp. 426-438

[Fran97]        M. Franz: Dynamic Linking of Software Components, Computer, March 1997, pp. 74-81, see also http://dlib.computer.org/co/books/co1997/pdf/r3074.pdf

[Free87]         P. Freeman (ed.): Tutorial: Software Reusability, IEEE Computer Society Press, 1987

[FSJ99]          M. E. Fayad, D. C. Schmidt, R. E. Johnson (eds.): Building Application Frameworks, John Wiley & Sons, 1999

[GHJV94]       E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, 1996

[GJS96]          J. Gosling, B. Joy, G. Steele: The Java™ Language Specification, Addison-Wesley, 1996, see also ftp://ftp.javasoft.com/docs/specs/langspec-1.0.pdf

[GM96]          J. Gosling, H. McGilton: The Java Language Environ­ment. A White Paper, May 1996, see http://java.sun.com/docs/white/langenv

[GR83]           A. Goldberg, D. Robson: Smalltalk-80. The Language and its Implementation, Addison-Wesley, 1983

[Hami97]       J. Hamilton: Programming with DirectToSOM™ C++, John Wiley & Sons, 1997

[Hauc93]        F. Hauck: Inheritance Modeled with Explicit Bindings, in OOPSLA’93 Eight Annual Conference on Object-Oriented Pro­gramming Systems, Languages, and Applications, ACM SIG­PLAN Notices, Vol. 28, No. 10, October 1993, pp. 231-239

[Ichb83]         J. D. Ichbiah: On the Design of Ada, in R. E. A. Mason (ed.): Information Processing 83. Proceedings of the IFIP 9th World Computer Congress. Paris, France, September 19-23, 1983. IFIP Congress Series. Volume 9. Participants Edi­tion, North-Holland, 1983, reprinted in [Free87] pp. 59-68

[Jell97]          T. Jell (ed.): CUC96. Component-Based Software Engineering, SIGS Books, 1997

[JF88]            R. E. Johnson, B. Foote: Designing Reuseable Classes, Journal of Object-Oriented Pro­gramming, Vol. 1, No. 2, June/July 1988, pp. 22-35

[Kay93]         A. C. Kay: The Early History of Smalltalk, ACM SIG­PLAN Notices, Vol. 28, No. 3, March 1993, pp. 69-95

[Kerr93]        R. Kerr: Inheritance––Just a Programmer’s Hack?, Object Magazine, March-April 1993, pp. 18-20

[Kind97]         Charlie Kindel: COM: What Makes it Work. Black-box En­­­­cap­sulation through Multiple, Immutable Interfaces, in Proceedings First International Enterprise Distributed Ob­­­­ject Computing Workshop. October 24-26, 1997. Gold Coast, Australia, IEEE Computer Society, 1997, pp. 68-77

[KL92]          G. Kiczales J. Lamping: Issues in the Design and Specification of Class Libraries, in OOPSLA’92 Seventh Annual Conference on Object-Oriented Programming Systems, Languages, and Applications, ACM SIGPLAN Notices, Vol. 27, No. 10, October 1992, pp. 435-451

[Lamp93]      J. Lamping: Typing the Specialization Interface, in OOPSLA’93 Eight Annual Conference on Object-Oriented Pro­gramming Systems, Languages, and Applications, ACM SIGPLAN Notices, Vol. 28, No. 10, October 1993, pp. 201-214

[LC85]           L. Ledbetter, B. Cox: Software-ICs, BYTE, June 1985, pp. 307-316

[Lewi97]        T. Lewis: If Java Is the Answer, What Was the Question?, Computer, March 1997, pp. 136, 133-135

[Lisk87]         B. Liskov: Data Abstraction and Hierarchy, in L. Power, Z. Weiss (eds.): OOPSLA’87 Addendum to the Proceedings, ACM SIGPLAN Notices, Vol. 23, No. 5, May 1988

[LY99]          T. Lindholm, F. Yellin: The Java™ Virtual Machine. Second Edition, Addison-Wesley, 1999, see also http://java.sun.com/docs/books/vmspec/2nd‑edition/html/VMSpecTOC.doc.html

[Magn91]       B. Magnusson: Code Reuse Considered Harmful, Journal of Object-Oriented Pro­gramming, November/December, 1991, p. 8

[Matt00]        M. Mattsson: Evolution and Composition of Object-Oriented Frameworks, Ph.D. thesis, Department of Software Engineering and Computer Science, University of Karlskrona/ Ronneby, 2000

[MB97]          M. Mattsson, J. Bosch: Framework Composition: Pro­blems, Causes and Solutions, in Proceed­ings TOOLS USA '97, see http://www.ipd.hk‑r.se/bosch/papers/frwkcomp.ps, also as Composition Problems, Causes and Solu­tions (slightly revised) in [FSJ99] pp. 467-487

[McIl68]        M. D. McIlroy: Mass Produced Software Components, in P. Naur, J. Randell (eds.): Software Engineering. Report on A Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October, 1968, NATO Science Committee, 1969, pp. 138-150, also reprinted in [NRB76], pp. 88-98

[Meye97]       B. Meyer: Object-Oriented Software Construction (2nd ed.), Prentice Hall, 1997

[Mezi97]        M. Mezini: Maintaining the Consistency of Class Libraries During Their Evolution, in Proceedings of the 1997 ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages & Applications (OOPSLA’97), ACM SIGPLAN Notices, Vol. 32, No. 10, October 1997, pp. 1-21

[Micr94]          Microsoft Corporation: OLE 2 Programmer’s Reference. Volume 1-2, Microsoft Press, 1994

[MS97a]         L. Mikhajlov, E. Sekerinski: The Fragile Base Class Pro­­blem and Its Solution, Turku Centre for Computer Science Technical Report No 117, June 1997, see also http://www.tucs.abo.fi/publications/techreports/TR117.html

[MS97b]         L. Mikhajlov, E. Sekerinski: The Fragile Base Class Problem and Its Impact on Component Systems, in [WBS97] pp. 59-68 and [BM98] pp. 353-358

[MS98]          L. Mikhajlov, E. Sekerinski: A Study of the Fragile Base Class Problem, in E. Jul (ed.): ECOOP’98 – Object-Oriented Programming. 12th European Conference. Brussels, Belgium, July 20-24, 1998. Proceedings, in G. Goos, J. Hartmanis, J. van Leeuwen, Lecture Notes in Computer Science 1445, Springer-Verlag, 1998, pp. 354-382

[MSL96]        K. Mens, P. Steyaert, C. Lucas: Reuse Contracts: Managing Evolution in Adaptable Systems, in [Mühl97] pp. 37-42

[Mühl97]       M. Mühlhäuser (ed.): Special Issues in Object-Oriented Programming. Workshop Reader of the 10th European Conference on Object-Oriented Programming. ECOOP’96, Linz, July 1996, dpunkt.Verlag, 1997

[Myer96]       B. A. Myers: A Brief History of Human Computer Interaction Technology, Carnegie-Mellon Uni­versity School of Computer Science Technical Report CMU-CS-96-163 and Hu­man Computer Interaction Institute Technical Report CMU-HCII-96-103, De­cember 1996, see also http://www.cs.cmu.edu/~amulet/papaers/uihistory.tr.html

[ND78]          K. Nygaard, O.-J. Dahl: The Development of the SIMULA language, ACM SIGPLAN Notices, Vol. 13, No. 8, August 1978, pp. 245-272

[NRB76]        P. Naur, B. Randell, J.M. Buxton (eds.): Software Engineering: Concepts and Techniques, Petrocelli/ Charter, 1976

[PB92]           C. Ponder, B. Bush: Polymorphism Considered Harmful, ACM SIGPLAN Notices, Vol. 27, No. 6, June 1992, pp. 76-79

[Pers98]         E. Persson: The Quest for the Software Chip. The Roots of Software Components – A Study and Some Specula­tions, published with text loss in J. Bosch, G. Hedin, K. Kos­kimies, B. Bruun Kristensen (eds.): NOSA ’98. Pro­ceed­ings of the First Nordic Workshop on Software Arch­itecture, Re­search Report 14/98, Depart­ment of Com­­puter Science and Business Ad­mi­ni­stra­­tion, Uni­vers­ity of Karlskrona/Ronneby, ISSN 1103-1581, ISRN HK/R-RES–98/14–SE, for a revised version (without text loss) see http://www.ide.hk‑r.se/~bosch/NOSA98/ErikPersson.pdf or http://www.soc.hk-r.se/research/1998/tqsc.ps

[Pers99a]       E. Persson: Wisps of Realistic Computing. Bestowing Utility upon Virtual Worlds through 3-D Business Objects, in J. Bosch (ed.): NOSA’99. Proceedings of the Second Nordic Work­shop on Software Architecture, Re­search Report 13/99, Department of Computer Science and Software Engineering, University of Karls­krona/ Ronneby, ISSN 1103-1581, ISRN HK/R‑RES‑99/13‑SE, see also http://www.ipd.hk‑r.se/bosch/NOSAR/NOSA99/Erik-Persson.pdf

[Pers99b]       E. Persson: The Twilight of Objects, Technical Report No. LU-CS-TR:99-215, ISSN 1404-1200 Report 83, 1999, Department of Computer Science, Lund Institute of Technology, Lund University, August 10, 1999

[Petz99]        C. Petzold: Programming Windows (5th ed.), Microsoft Press, 1999

[Pfis97]         C. Pfister: Component Software. A Case Study Using BlackBox Components, Draft, June 11, 1997, see http://www.oberon.ch/docu/case_study/index.html

[Potr97]        P. Potrebic: Be Engineering Insights: What’s the Fragile Base Class (FBC) Problem?, Be Newsletter, Issue 79, June 25, 1997, see http://www‑classic.be.com/aboutbe/benewsletter/Issue79.html

[Pres93]         L. Press: Before the Altair – The History of Personal Computing, Communications of the ACM, Vol. 36, No. 9, September 1993, pp. 27-33, see also http://som.csudh.edu/fac/lpress/articles/hist.htm

[PS94]           D. Pountain, C. Szyperski: Extensible Software Systems, BYTE, May 1994, pp. 57-62

[PS96]           C. Pfister, C. Szyperski: Why Objects Are Not Enough, in [Jell97] pp. 141-147, see also http://www.fit.qut.edu.au/~szypersk/pub/CUC96a.ps.gz

[Rich97]        J. Richter: Advanced Windows (3rd ed.), Microsoft Press, 1997

[Roge97]        D. Rogerson: Inside COM. Microsoft’s Component Object Model, Microsoft Press, 1997

[Sakk89]        M. Sakkinen: Disciplined Inheritance, in [Cook89] pp. 39-56

[SG95]           R. Stata, J. V. Guttag: Modular Reasoning in the Presence of Subclassing, in OOPSLA’95 Tenth Annual Conference on Object-Oriented Programming Systems, Languages, and Applications, ACM SIGPLAN Notices, Vol. 30, No. 10, October 1995, pp. 200-214

[Sims94]        O. Sims: Business Objects: Delivering Cooperative Objects for Client/Server, McGraw-Hill, 1994

[SLMD96]     P. Steyaert, C. Lucas, K. Mens, T. D’Hondt: Reuse Contracts: Managing the Evolution of Reusable Assets, in Proceedings of the 1996 ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages & Applications (OOPSLA’96), ACM SIGPLAN Notices, Vol. 31, No. 10, October 1996, pp. 268-285

[Snyd86]        A. Snyder: Encapsulation and Inheritance in Object-Oriented Languages, in N. Meyrowitz (ed.): OOPSLA’86 Conference Proceedings. September 29 - October 2, 1986. Portland, Oregon, ACM SIGPLAN Notices, Vol. 21, No. 11, 1986, pp. 38-45

[Stein87]        L. A. Stein: Delegation Is Inheritance, in N. Meyrowitz (ed.): OOPSLA ’87. Conference Pro­ceedings. October 4 - 8, 1987. Orlando, Florida, ACM SIGPLAN Notices, Vol. 22, No. 12, December 1987, pp. 138-146

[Stro96]         B. Stroustrup: A History of C++: 1979-1991, in T. J. Bergin, Jr., R. G. Gibson, Jr., History of Programming Lan­guages–II, ACM Press/Addison-Wesley, 1996, pp. 699-767

[Sun99]          Sun Microsystems, Inc.: The Java HotSpot™ Per­form­ance Engine Architecture, White Paper, April 1999, see http://www.javasoft.com/products/hotspot/whitepaper.html

[Szyp98]        C. Szyperski: Component Software. Beyond Object-Ori­ented Programming, ACM Press/Addison-Wesley, 1998

[Taiv93]        A. Taivalsaari: A Critical View of Inheritance and Reusa­bility in Object-Oriented Programming, Ph.D. Thesis, Uni­versity of Jyväskylä, Jyväskylä Studies in Computer Science, Economics and Statistics, 1993

[Taiv96]        A. Taivalsaari: On the Notion of Inheritance, ACM Com­put­ing Surveys, Vol. 28, No. 3, September 1996, pp. 438-479

[TK89]          R. P. Ten Dyke, J. C. Kunz: Object-Oriented Programming, IBM Systems Journal, Vol. 28, No. 3, 1989, pp. 465-478

[Venn99]       B. Venners: Interview. James Gosling Looks Back at the Java Language’s Past and Forward to its Future, JavaOne Today, June 18, 1999, see http://www.javaworld.com/javaworld/javaone99/j1-99-gosling.html

[VMMD98]    M. Vellon, K. Marple, D. Mitchell, S. Drucker: The Architecture of a Distributed Virtual Worlds System, Microsoft Research, 1998, see http://www.research.microsoft.com/vwg/papers/oousenix.htm

[WBS97]        W. Weck, J. Bosch, C. Szyperski (eds.): Proceedings of the Second International Workshop on Component-Oriented Programming (WCOP '97), TUCS General Publication No. 5, September 1997, see also http://www.tucs.abo.fi/publications/general/G5.pdf

[Wegn87]      P. Wegner: Dimensions of Object-Based Language Design, in N. Meyrowitz (ed.): OOPSLA ’87. Conference Proceed­ings. October 4 - 8, 1987. Orlando, Florida, ACM SIG­PLAN Notices, Vol. 22, No. 12, December 1987, pp. 168-182

[Wegn88]      P. Wegner: Inheritance as an Incremental Modification Mechanism or What Like Is and Isn’t Like, in S. Gjessing, K. Nygaard (eds.): ECOOP ’88. European Conference on Object-Oriented Programming. Oslo, Norway, August 15–17, 1988. Proceedings, (G. Goos, J. Hart­manis (eds.): Lecture Notes in Computer Science 322), Springer-Verlag, 1988, pp. 55-77

[WK94]         S. Williams, C. Kindel: The Component Object Model: Technical Overview, Dr Dobb’s Journal, December, 1994, see also http://www.microsoft.com/oledev/olecom/Com_modl.htm

 

 


[1]   [McIl68]. [Pers98] provides a survey of the history of the software component idea.

[2]   SIMULA was devised by Dahl and Nygaard from 1961 on­wards; see [ND78] and [DN66]. Cf. also [Duga94], where an attempt is made to expound and explicate the advent of ob­ject-orientation against the background of an “ideo­logy of simulation” pur­­portedly popular in science at this time. Si­mula­tion was also the applica­tion area that originally motivated Stroustrup to develop C++ (see [Stro96] p. 700 et seqq.). Cf. also [TK89], [Kay93], [Booc94] p. 36 et seq., [Coll95] p. 19 et seqq., [Pres93], and [Myer96].

[3]   See [LC85] and [Cox86]. In an IFIP keynote speech [Ichb83], Jean Ichbiah also as­so­ciated the package and generics facilities of Ada with Mc­Ilroy’s software com­po­nent vision, and Grady Booch later (in [Booc87] p. 7 et passim) formulated and promulgated an Ada com­ponent pro­­gramme. In popular lore, a Scandinavian modelling-oriented branch of object-orienta­tion is often contraposed to an American reuse-oriented one; cf. e.g. [Kerr93].

[4]   [Pfis97]. [PB92] criticises polymorphism as a dis­guised go­to.

[5]   [BMMB99] and [MB97]. See also [Matt00].

[6]   [Szyp98]

[7]   [Pers99b] provides a more detailed exposé of class fragility and encapsulated program­ming.

[8]   So [Wegn87] p. 169, where the classical definition “object-oriented = objects + classes + inheritance” was set down. Not all will agree with this definition. For example, [Sakk89] argues that in­herit­ance is dispensable to object-orientation.

[9]   Thorough treatments of inheritance and its pro­blems are found in [Szyp98] p. 72 et seqq. and [Meye97] p. 459 et seqq. et passim. Id. op. p. 809 et seqq. proposes an interesting taxo­nomy of inheritance and also includes a survey of biological taxo­nomy. [Taiv93] is a dissertation, [Taiv96] a survey article devoted exclusively to in­herit­ance.

[10] [Wegn88]. Cf. also [Taiv96] p. 474. This interpretation holds quite well for single inherit­ance. When multiple inheritance is considered, in­­heritance may addi­tionally become a mecha­nism for the com­bi­na­tion or mix-in of use­ful behaviour.

[11] [JF88]

[12] [CW85] discerns and discusses various classes of polymorphism.

[13] However, [Berr95] questions the apti­tude of inherit­ance for the modelling of an inherently fuzzy world.

[14] So, for example, [Lisk87] p. 33 and p. 24.

[15] [Magn91]

[16] [GHJV94] p. 17.

[17] [Snyd86]

[18] [Lamp93]

[19] Cf. [Lisk87].

[20] Just to get a glimpse of the severity of the problems, one may con­sider what happens, if a superclass method A calls a virtual method B that is overridden in a subclass and the subclass im­­ple­men­tation of B then calls A. In order to be able to avoid vicious loops of re­cursive in­vo­ca­tions or at least to com­prehend why the code locks up, a subclass im­ple­menter unfortunate­ly needs access to the source code of the super­classes.

[21] Cf. [Lewi97] p. 135.

[22] So, for example, [Betz94], [MS97a-b], [MS98], and [Szyp98] p. 102 et seqq. [MS97a], [MS98], and [Szyp98] provide detailed accounts of this problem.

[23] See [PS94], [PS96], [MS97a], [Pfis97] chapter 3.4., and [Szyp98] p. 102 et seqq.

[24] The UNIX counter­part is known as “shared libraries”. [Fran97] presents an interesting bird’s eye-view of the different varieties of dynamic linking and tracks the concept back to the Multics operating system of the 60s (see [CV65] p. 191). The functioning of Windows DLLs is detailed in [Rich97] p. 529 et seqq. and [Petz99] p. 1243 et seqq.

[25] Private member declarations are indeed implementation details and should consequently not be exposed in the interface of an object. In C++, modification of private members will, however, change the table layout and offsets and, thus, must be part of the class interface. Additionally, the existence of friend declarations or inline functions may bring to naught the encapsulation of private members. In the BeOS system APIs, which are exposed as C++ classes, various – mostly very unprepossessing – work­arounds to the C++ fragility problems are resorted to, as documented by [Potr97].

[26] In both Smalltalk and Objective-C, the problem of instance data fragility is unresolved. See [GR83] p. 586 et seqq., [FCDR95] p. 435, and [CN91] p. 26, p. 69 et seqq., and p. 137 et seqq. In his book, Brad Cox made a strong plea for supplier-side bind­ing as the basis for software com­ponentry. Admitting that method re­solu­tion through run-time sup­plier-side searches will be very inefficient, he also pro­posed various optimisation techniques.

[27] [Hami97] p. 43 et seq. lists some of the unsupported changes. SOM also introduces a very com­­plex programming model and a number of nasty catches that will force the programmer to acquire a thorough under­stand­ing of its – quite intricate – inner workings; see id. op. p. 37.

[28] See [Venn99], [GM96] section 5.1, [GJS96] p. 220 et seqq., and [LY99] sections 2.17.3 and 4.9.

[29] In order to enhance the run-time performance, Sun’s HotSpot™ Per­form­ance Engine uses a number of different techniques, including the dyna­mic compilation and adaptive optimisation of the code seg­ments (called hot spots), where a programme spends most exe­cu­tion time. See [Sun99] and http://www.javasoft.com/products/hotspot. Recent bench­mark results for various Java virtual machines are available at http://www.volano.com/benchmarks.html.

[30] See, for example, [Broc95], [Micr94], [WK94], [Kind97], [Roge97], or [Chap96]. Since inter­faces are immutable, what may change between different versions of a COM class or com­­po­nent is not the inter­faces per se, but the set of interfaces sup­ported by the COM class. Through inter­face negotiation, which is supported by all COM interfaces, it is possible for a client to check, whether a COM object supports a particular in­ter­­­­face.

[31] See [Sims94].

[32] [Sims94] p. 277 et seqq.

[33] See [MS97a] p. 4 et seqq. and [MS98] p. 359 et seqq.

[34] It is also possible to introduce similar se­mantic problems by the use of delegation, since de­le­ga­­tion is equi­valent to inheritance, as established by [Stein87]. [Szyp98] p. 48 et seqq. shows that similar dif­fi­culties also haunt libraries that use callbacks.

[35] Significant examples include Lamping’s type system for the specialisa­tion inter­­face (see [Lamp93]; cf. also [KL92] and [Hauc93]), Stata’s and Guttag’s division of labor speci­fica­tions (see [SG95]), the reuse contracts of Steyaert et al. (see [SLMD96], [MSL96], and [DLS97]), Mezini’s meta­level declarations (see [Mezi97]; cf. also [Szyp98] p. 109 et seqq.), and Mikhajlov’s and Sekerinski’s rules for base class re­vi­sion and sub­class construction (see [MS97a-b] and [MS98]).

[36] See [Pers99b].

[37] Additionally, in systems that do not rely on Newi-style semantic messaging methods must not be de­leted, nor method signatures be modified.

[38] Arguably, 1) direct access of data members from clients and 2) polymorphic self-calls of methods that are neither final, nor private should also be prohibited. It should be noted that the latter ban implicitly rules out poly­morphic self-re­cursive down-calls. Although these two steps will not be strictly necessary in order to avoid semantic fragility, orthogonality and con­sistency concerns strongly vindicate them. See [Pers99b] p. 20 for a detailed motivation.

[39] See [Pers99b] p. 14 et seqq. for a more detailed discussion of this scheme.

[40] Surface area is defined by [CN91] p. 17 as the number of things that must be understood and pro­perly dealt with for one pro­gram­mer’s code to function correctly in combination with an­other’s.

[41] Some of these problems are discussed in [BMMB99] and [MB97]. Cf. also [Matt00].

[42] Interestingly, in the Microsoft Research V-Worlds project, support for imple­men­ta­tion in­herit­ance has been added to COM. See [VMMD98].

[43] [Sims94]

[44] [Pers99a] can be construed as a ‘manifesto’ for this agenda.