This preview shows page 1. Sign up to view the full content.
Unformatted text preview: her extensions. In fact the current formalization opened up a whole suit of new research issues that seem promising. In the following sections, we outline few weaknesses of ORLog and discuss several extensions that we have planned as our future work to remove some of its de ciencies. 104 8 > > > > > > >p > > > > > > > > > > > > < k o) = r (S m > > > > > >p > > > > > > > > > > > > :o
0 7! if o mk ] 62 S and 9q such that o : q 2 S r (S mk q) = p, p mk ] 2 S and (8r such that o : r 2 S one of the following holds. r (S mk r) = r, and r mk ] 62 S , or r (S mk r) = p, or o mk < r] 2 S , or r mk > r] 2 S .)]
0 7! 7! 7! 0 0 7! 7! 7! 7! 7! 0 if o mk ] 62 S and o q@mk ] 2 S and 9q such that o :: q 2 S r (S mk q) = p , p mk ] 2 S and (8r such that o : r 2 S one of the following holds. r (S mk r) = r, and r mk ] 62 S , or o mk < r] 2 S , or r mk > r] 2 S , or r (S mk r) = u, and 9v such that o : v 2 S r (S mk v) = w.)]
7! 7! 0 0 0 7! 7! 0 7! 7! 7! 7! 0 7! 0 7! in all other cases. Figure 19: New de nition of r to incorporate re-introduction of properties. 7.2.1 Function Symbols in ORLog
One of the technical reason for not allowing function symbols in our language was to ensure static computability of inheritability using r at compile time. Although inclusion of function symbols is desirable for the modeling of much more interesting databases and dynamic creation of objects, it threatens static computation of inheritability since the object hierarchy may potentially become in nite, and termination of r can not be guaranteed anymore. However, we believe function symbols can still be included in ORLog in a restricted way. The idea is to de ne suitable properties for admissibility of clauses that create new objects such that the depth and breadth of the object hierarchy still remain nite. A partial solution to this e ect is already at hand, while we are investigating a much more general solution such that a larger class of programs can be made admissible. 105 7.2.2 Dynamic Object Hierarchies
Recall that we have assumed a static object hierarchy in every ORLog program primarily by not allowing i- and p-atoms in the rule bodies of is-a clauses again to be able to manage static computing of inheritability of clauses. If we relax this restriction, static determination of inheritability would not be possible, and similar to Dobbie and Topor 29], for example, we will have to adopt a model theoretic semantics based on strati cation as in negation in logic programs. In 21], we investigate the issue of dynamic is-a hierarchy and de ne a stable model semantics for behavioral inheritance. The language there is similar, and we believe that the idea can be extended to ORLog without much complication. One important consequence of allowing dynamic object hierarchies is that we are no longer required to compute inheritability at compile time. Hence, we may now safely allow function symbols in our language and make it more expressive, since in niteness of the hierarchy does not matter any more. Another consequence will be that instead of a least intended model, we will have several minimal models for ORLog programs. A downside is that the high computational complexity of stable models will be incurred in this case. 7.2.3 Encapsulation in ORLog
Another most fundamental and essential concept of object-orientation is encapsulation. While this issue has been a subject of intense research in the logic programming community for quite some time, researchers in object-oriented logic programming did not address this issue seriously. Partly the reason may be issues like inheritance have given priority and not much has been achieved until now. Encapsulation is an essential software engineering technique which help de ne objects with interfaces that restrict the access to the state of an object only through the set of public methods of the object interface. As such, it frees the users from the burden of knowing the internal structure and state of the objects by hiding all unnecessary details. This mechanism is referred to as structural encapsulation as opposed to the notion of behavioral encapsulation that refers to the concept of hiding the implementation details of the methods in objects. Objects themselves, however, can access their own properties irrespective of the state of the encapsulation status, or the interface. Although the ideas seem to be very simple, researchers could not agree on a logical 106 account of these simple idea until recently. Much of the research were centred around the context of modules in logic programming. Miller's theory of modules 59] was instrumental in de ning a limited account of encapsulation. Dynamic visibility has been studied in 8] again in the context of modules. But all these proposals failed to give an e ective interface mechanism that can be used in objects. Recently, we proposed an elegant solution to this problem in 21] which addresses the issue in an object-oriented context. Although the language considered in 21] is slightly di erent and mo...
View Full Document