5 from o to produce p m 5 which is not behavioral

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: a expression o m ! 5] from o to produce p m ! 5] which is not behavioral inheritance as in code reuse. Furthermore, due to clauses (12) and (13), F-logic will have two minimal models { in one model it will inherit (12) in r and override (13) and in another model it will inherit (13) in r and override (12). By contrast, in ORLog we have only one model in which we inherit neither. By analogy with the literature on negation 33], we can say that F-logic's approach to multiple inheritance is brave while ours is cautious. Rather than debate on which is better, we would like to remark that a brave semantics for multiple inheritance destroys any hopes of a complete proof theory1. Besides, a nice feature of our framework is the ability to simulate the brave semantics at a \local" level, to a limited extent. This can be accomplished by using the withdrawal atoms. E.g., in Example 3.2, clause (7) withdraws method t0 de ned ! That is not to say, a complete proof theory for the cautious semantics is straightforward, as can be seen from this paper. 1 99 in p from being inherited in r. Since t0 is also de ned in q, r can now inherit t0 from the unique source q. A second di erence with F-logic is that in F-logic a necessarily monotonic signature inheritance is built into the logic. There are situations where a signature de ned in a superclass may have to be withdrawn from a (not necessarily immediate) subclass. F-logic's inheritable and non-inheritable method expressions help solve this problem to a limited extent. However, consider the situation where a signature is de ned in o, and is inherited up to the class r, where r : q, q : p, p : o and suppose it has to be withdrawn from s, where s : r. It is not clear how this can be accomplished in F-logic. In ORLog, this can be done rather easily by using an appropriate withdrawal atom. Finally, we remark that the concepts of locality, inheritability, and withdrawal of properties are quite useful in themselves and we are not aware of any other logic where they are given a formal status. ! ! 6.2 Comments on Implementation Issues Despite several of its e ciency related drawbacks, the ORLog system compares very nicely with contemporary research prototypes in its class. Most of the translation based implementations have similar drawbacks, if not serious ones. It is easy to make an important observation in almost all implementations other than ORLog. Most languages take a success-failure based (deduction based) approach to overriding, hence any implementation will have to rely heavily on negation. In fact, it can be shown by taking a pathological case that to decide on the inheritability of any single method, we will have to compute the whole database. Whereas, the point of de nition based approach to overriding as in ORLog makes it simple, intuitive, and e cient to the greatest extent possible. This makes ORLog a viable candidate for a serious implementation. However, the ORLog experience o ers guidelines for addressing several important issues and suggests that enhancements are possible on the present system. First, the time spent by the interface in Coral calls can be saved by managing to run Coral in a dedicated mode and make Coral talk to the interface. In that way, we need to invoke Coral only once from the interface, use shared memory space and data structures between Coral and the interface, and spend minimal amount of time in transferring 100 control from the interface to Coral, and vice-versa. This can be improved in yet another potentially involved way. We can change the Coral interface to accept ORLog code, and then translate the code internally to Coral's native language. Secondly, one of our goals is to eventually exploit Coral features such as modules, execution control through meta-annotations, etc. This can be achieved very easily just by adding a simple identity function in the translator and passing the declarations to Coral. Finally, in its current form, ORLog does not support persistent objects. This essential functionality needs to be added. A possible way to add this feature would require to extend Exodus storage manager used in Coral with object management capabilities. 101 Chapter 7 Conclusion and Future Research The goal of this thesis was primarily to develop a logical account of behavioral inheritance in deductive object-oriented databases. To understand what behavioral inheritance means and how inheritance of behaviors work in a network of objects organized in some specialization-generalization hierarchy, we rst needed to develop an abstract data model, called the OR model, for database schema design. OR model was instrumental in visualizing the semantics of inheritance at a higher level of abstraction. It thus laid the foundation of the logical query language ORLog and its underlying semantics, which was the main focus of this work. The OR model we presented in this thesis can be viewed as an extension of SDM in the direction of OO models. It incorporates a balanced mix of features from the two paradigms and enriched the model by introducing the new concepts such as property withdrawal and re-introduction, accessibility of properties, strati ed constraints, methods in relationships, inheritance con ict...
View Full Document

{[ snackBarMessage ]}

Ask a homework question - tutors are online