No abstract

The efficiency of dynamic dispatch is a major impediment to the adoption of multimethods in object-oriented languages. In this article, we propose a simple multimethod dispatch scheme based on compressed dispatch tables. This scheme is applicable to any object-oriented language using a method precedence order that satisfies a specific monotonous property (e.g., as Cecil and Dylan) and guarantees that dynamic dispatch is performed in constant time, the latter being a major requirement for some languages and applications. We provide efficient algorithms to build the dispatch tables, provide their worst-case complexity, and demonstrate the effectiveness of our scheme by real measurements performed on two large object-oriented applications. Finally, we provide a detailed comparison of our technique with other existing techniques.

Multiple inheritance and multiple dispatching are two sources of ambiguities in object-oriented languages. Solving ambiguities can be performed automatically, using techniques such as totally ordering the supertypes of each type or taking the order of the methods' arguments into account. Such implicit disambiguation has the drawback of being difficult to understand by the programmer and hiding programming errors. Conversely, solving ambiguities can be left up to the explicit intervention of the programmer. The most common explicit disambiguation technique consists in defining new methods for ambiguous invocations. However, finding ambiguities and adding as few methods as possible is a difficult task, especially in multi-method systems. In this report, we show that there always exists a unique minimal set of method redefinitions to explicitly disambiguate a set of multimethods. We propose an algorithm to compute the minimal disambiguation set, together with explanations: for each method that is to be added, the programmer is given the set of methods that caused the ambiguity. Key

No abstract

Object-oriented databases enforce behavioral schema consistency rules to guarantee type safety, i.e., that no run-time type error can occur. When the schema must evolve, some schema updates may violate these rules. In order to maintain behavioral schema consistency, traditional solutions require significant changes to the types, the type hierarchy and the code of existing methods. Such operations are very expensive in a database context. To ease schema evolution, we propose to support exceptions to the behavioral consistency rules without sacrificing type safety. The basic idea is to detect unsafe statements in a method code at compile-time and check them at run-time. The run-time check is performed by a specific clause that is automatically inserted around unsafe statements. This check clause warns the programmer of the safety problem and lets him provide exception-handling code. Schema updates can therefore be performed with only minor changes to the code of methods. Key-words:Object-oriented databases, schema evolution, type safety, covariance, contravariance. Relachement des règles de cohérence de schéma avec typage sûr pour une modélisation souple dans les SGBDOO Résumé : Les bases de donnéesà objets imposent aux schémas des règles de cohérence qui garantissent la sûreté de typage, c'est-à-dire qu'aucune erreur de type ne peut survenirà l'exécution. Lorsque le schéma doitévoluer, certaines misesà jour peuvent violer ces règles. Pour conserver la cohérence comportementale du schéma, les solutions traditionnelles nécessitent des modifications significatives des types, de leur hiérarchie ainsi que du code des méthodes pré-existantes. Ces opé-rations sont très coûteuses pour une base de donnée. Afin de faciliter l'évolution de schéma, nous proposons de supporter des exceptionsà ces règles de cohérence, sans sacrifier la sûreté de typage pour autant. L'idée essentielle est de détecter les instructions non sûresà la compilation, et de les vérifierà l'exécution. La vérification est effectuée graceà une opération particulière qui entoure automatiquement toute instruction non sûre. Cette opération avertit le programmeur du problème de sûreté, et lui permet de fournir le code de traitement de l'exception. Les misesà jour du schéma peuvent ainsiêtre effectuées, avec seulement des modifications mineures du code des méthodes.