{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

Encapsulation appears to be not covered in this

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: he translated program is then evaluated in Prolog. Encapsulation appears to be not covered in this framework, and overriding seems to be limited. Persistence is not supported by OOLP+. Dynamic updating of instances and classes is possible vis-a-vis Prolog, and hence methods with side-e ects are supported too. However, unlike many conventional object-oriented languages, OOLP+ does not allow invoking a speci c method from a speci c class, partly due to the translational approach to implementation. It is, however, obvious from this discussion that this approach is the simplest and probably the cheapest. Whether the approach is desired in terms of exibility, design, execution cost, etc, that remains an open question. 88 5.1.3 ROCK & ROLL ROCK & ROLL 10]combines the capability of an imperative database programming language (ROCK) and a logic based rst-order query language (ROLL). The imperative programming language is used for de ning objects and classes, for writing method codes and as sole means of updating and changing the states of databases. The query language ROLL can be used to de ne rules and to express queries over extensional databases de ned using ROCK. These two languages interact with and complement each other in a synergistic way. The fundamental principle behind its design is to use conventional language components judiciously and intelligently in complementary areas through language integration that does not require any extension of the components individually. It should be clear that Coral++ is a coupling between two languages through compilation and translation, while ROCK & ROLL is an integration of two languages. Type system mismatch in this system is reduced since both the component languages are based on a common data model called the OM that makes it possible to perform strong type checking. Also since the data values accessed by one component can be accessed directly by the other, any special treatment or preprocessing of the data across platforms are not needed that further reduces the mismatch problem. A particular strength of this system is that users can write programs in which ROLL may invoke any ROCK method as long as it is side-e ect free, without any need for additional syntax. Whether a method call has a side-e ect or not can be detected at compile time. In a complementary way, ROLL methods can be invoked in ROCK even with di erent binding patterns for their arguments. Overriding and overloading of ROLL methods are allowed and the process of (late) binding of a call to an implementation is handled in a way analogous to that for ROCK methods. Finally, the implementation includes a ROLL front-end for ROCK in which declarative component of programs can be de ned, tested, type checked and compiled. In way, it can be said that this system is based on implementation of a deductive query language over an object-oriented database. 89 5.2 Objectives of the Interface Several well-known deductive object-oriented database systems and research prototypes are known to have been built using other existing systems as back-ends. For example OOLP+ 25], OIL 76], Logical-objects 13], LLO 56]. Following the same direction, we propose a scheme for implementing ORLog in Coral 65] using a translational approach. Although a direct implementation of ORLog is obviously possible, we chose to follow the translational approach for the following reasons. Since the idea in a logic based language is to allow the user to program in a declarative way, query optimization then becomes a system level concern. However, the research into query optimization in deductive object-oriented databases is still in its infancy. While sophisticated optimization techniques are being researched, we try to take advantage of what has been successfully utilized in deductive databases for query optimization. This motivates our translation based approach where users perceive their applications naturally in an object-oriented way and never go through the mental exercise of mapping them into a non-object-oriented model. But still take advantage of the superior query optimization techniques available in the deductive paradigm. We make use of the reduction technique we have developed in the previous chapter by customizing it for the Coral environment. We develop an user interface and command interpreter for ORLog. The interface can be viewed as an object-oriented front-end for Coral. For the moment, we only concentrate on the query processing aspect of the language and leave out persistence for simplicity. 5.3 Implementation of the ORLog System In this section we discuss the design and prototype implementation of ORLog using Coral deductive database system as a back-end. We will rst present an overview of the system, outline the system architecture, and discuss design considerations. Finally we review its performance and future enhancements. 5.3.1 Overview of the Interface The primary goal of this prototype is (i) to provide a complete programming environment in ORLog that will reduce every ORLog program and answer queries by 90 executing the reduced program in Coral, and (ii) to use Coral deductive database system as the backbone inference engine maintaining a comple...
View Full Document

{[ snackBarMessage ]}

Ask a homework question - tutors are online