DOCSLIB.ORG

Scalable Multiple Representation and Dynamic Classification by Multiple Specialization of Objects in OO-Prolog

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Scalable Multiple Representation and Dynamic Classification by Multiple Specialization of Objects in OO-Prolog International Journal of Computer Trends and Technology Volume 68 Issue 11, 24-42, November 2020 ISSN: 2231 – 2803 /doi:10.14445/22312803/IJCTT-V68I11P104 © 2020 Seventh Sense Research Group® Scalable multiple representation and dynamic classification by multiple specialization of objects in OO-Prolog Macaire Ngomo#1 # CM IT CONSEIL – Engineering and Innovation Department – 32 rue Milford Haven 10100 Romilly Sur Seine (France) Abstract - This study takes place within the framework of the The inheritance management model of the OO-Prolog representation of knowledge by objects and within the language is based on the non-determinism of logic framework of our work on the marriage of logic and objects. programming, on explicit naming, and on the concept of full On the one hand, object-oriented programming has proved attribute naming, which allows conflicts to be resolved to be appropriate for constructing complex software before they arise. The OO-Prolog language adopts a dynamic systems. On the other hand, logic programming is inheritance for both attributes and methods. This is a distinguished by its declarative nature, integrated inference, difference with classical models such as the ObjVLisp model and well-defined semantic capabilities. In particular, from which it was inspired. Let us recall that ObjVLisp inheritance is a refinement mechanism whose mode of makes a static inheritance of the instance variables, which application leaves several design choices. In the context of results in the flattening of the inheritance graph regarding the this marriage, we describe the semantics of multiple state of an object. The result is that an object in ObjVLisp is inheritances in a non-deterministic approach, the conceptual a vector of instance variables where all inheritance choices of integration of multiple inheritances made for the information has disappeared. design of the OO-Prolog language (an object-oriented extension of the Prolog language respecting logical II. THE OBJECT PARADIGM AND ITS semantics) as well as its application to multiple evolutionary DIMENSIONS representations that support classificatory reasoning and to The paradigm of object-based programming, born with dynamic classification by multiple specifications of logical Smalltalk [37] at the end of the 1970s, has become very objects. popular: object-based languages, object-based representations in artificial intelligence, object databases, Keywords — Object-oriented logic programming, object- object-based design in software engineering, etc. The oriented representation, multiple inheritances, multi-point of paradigm of object-based programming is now being used view, classificatory reasoning. in many different fields. It gives great power of expression, ease of maintenance, and reusability superior to other I. INTRODUCTION paradigms: imperative (example with C), functional Inheritance is a refinement mechanism whose mode of (example with LISP [89] [90] [90]) or logical (example application leaves a number of design choices. In this article, with PROLOG [88] [91] [90]), etc. However, it requires a we describe the semantics of inheritance [11] [12] in a non- greater abstraction capacity than imperative or functional deterministic approach as well as the conceptual choices of programming to choose the "objects" to be reified and integration of monotonous multiple inheritances made for the define inheritance and composition between classes in a design of the OO-Prolog language (an object-oriented meaningful and coherent way. extension of the Prolog language respecting logical The main dimensions of the object paradigm which are semantics) [72] [73] [74] [75] [76] [77] [78] [79] as well as classification, inheritance which introduces the notions of its application to the dynamic classification by multiple generalization and specialization, encapsulation and specializations of logical objects. Our work concerns the polymorphism (generic functions), were brought together for multiple and evolutionary representation of objects that the first time in Smalltalk 76 [37], although the ideas of class supports reasoning by classification [68] [21] [24] [17] [14] and instance, and inheritance had matured with SIMULA [30] [52] [53] [54] [55] [57] [NEBEL 90] [QUI93] [58] [35]. [23]. Classes were seen as objects, created by metaclasses, in This representation must, therefore, allow a dynamic the object languages created above Lisp, then in Smalltalk classification of logical objects and follow classificatory 80 [37]. This vision was taken up again in Java, where reasoning. Reasoning by classification consists of finding the everything is an object, the elements of world representation, most specialized class or category to which an object belongs the elements of graphical interfaces, and the elements of the and retrieving knowledge related to this location. language like functions, classes, events, errors, and This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/) Macaire Ngomo et al. / IJCTT, 68(11), 24-42, 2020 exceptions. The composition was later added as an case with Java and UML, which distinguish two forms of autonomous dimension with UML and is present in modern inheritance: class inheritance is an inheritance of structures languages such as Java. and behaviours, interface inheritance is only an inheritance of behaviours. An inherited class is generally an abstract A. Encapsulation class, which will have no instance, but which constitutes an In the object paradigm, encapsulation concerns the algebraic type (a structure with operations). You can have as grouping of variables and functions into classes and the many levels of inheritance as you want. When a class grouping of classes and interfaces into packages. Classes, inherits from a more abstract class, it inherits its attributes functions, and packages are also namespaces that ensure and its operations or methods. uniqueness within the names of the elements composing Multiple inheritances them. From the outside, it may be necessary to prefix the names of imported public elements by the name of the class Multiple inheritance is an extension to the simple or package from which the referenced element comes (or by inheritance model where one class is allowed to have several this or by super). Encapsulation ensures the grouping in the parent classes to model multiple generalizations. An object same elements (classes or packages) of lower-level elements can be considered from several points of view. This is the strongly linked. It ensures the protection and partial main reason we have to consider multiple inheritances. For visibility of the elements outside. Encapsulation ensures the example, the cathedral of Notre-Dame de Paris is both a independence between a class's layout, a function, a work of art and a place of worship. Care must be taken to package, and how it is presented concerning the other avoid homonymy, which should not mix two structures objects using it. The public presentation of an element instead of giving them two different names. At first glance, ensures that a contract will bind that element about what it it seems that one class can inherit from several classes does, but not how it does it, which is the responsibility of its because an object can have several parts, and the object has implantation. Therefore, it can be changed without affecting been attributed to the properties of its parts (metonymy). the operation of the other elements that use it, for example, However, only the question of points of view corresponds to to change internal variables or the algorithms used. The inheritance because if an object is composed of several parts, encapsulation and access levels (private, public, etc.) give it will be constructed by a compositional mechanism. At the rise to the reusability of software elements and software design stage, it is legitimate to describe a class inheriting evolution. from several classes. If the programming language used does not allow multiple inheritances, the problem will have to be B. Inheritance solved at the implementation stage. The organization of classes in specialization hierarchies The use of multiple inheritances is not without its makes it possible to create complex classes from more problems. For example, if the two base classes have general classes by refining the general description. A attributes or methods with the same name, there are naming subclass is built from another class by adding members or collisions that need to be resolved. In programming, restricting members existing in the other class. The managing multiple inheritances of structures is difficult mechanism by which a class retrieves information inherited because if inheritance causes a conflict over attributes, you from its superclasses is called inheritance. Inheritance is, have to rename an attribute in one of the classes or see the therefore, a mechanism for sharing information by factoring design error that causes the Conflict. If inheritance causes a in members. Inheritance between classes allows the reuse of conflict of methods, a conflict resolution strategy, i.e., a the structures or behaviours introduced, and facilitating choice or combination procedure as in CLOS [6] [22] [43], updating, avoiding duplication of information. When several should be used. This is why some languages such as classes have common characteristics, it is possible to create Smalltalk or Java prohibit multiple inheritances of a more general classifier that groups
Load more

Recommended publications
  • Dynamically Typed Languages
    Dynamically Typed Languages Laurence Tratt [email protected] Bournemouth University, Poole, Dorset, BH12 5BB, United Kingdom. Mar 13, 2009 Dynamically typed languages such as Python and Ruby have experienced a rapid grown in popularity in recent times. However, there is much confusion as to what makes these languages interesting relative to statically typed lan- guages, and little knowledge of their rich history. In this chapter I explore the general topic of dynamically typed languages, how they differ from statically typed languages, their history, and their defining features. 1 Introduction As computing is often split into software and hardware, so programming languages are often split into dynamically and statically typed languages. The traditional, simplified, definition of dynamically typed languages are that they do not enforce or check type- safety at compile-time, deferring such checks until run-time. While factually true, this definition leaves out what makes dynamically typed languages interesting|for example that they lower development costs [Ous98] and provide the flexibility required by specific domains such as data processing [MD04]. For many people, dynamically typed languages are the youthful face of a new style of programming introduced in the past few years. In fact, they trace their roots back to the earliest days of high-level programming languages in the 1950's via Lisp [McC60]. Many important techniques have been pioneered in dynamically typed languages from lexical scoping [SJ75] to Just-In-Time (JIT) compilation [Ayc03], and they remain a breeding ground for new ideas. Systems programming { seen as `serious' and thus demanding statically typed lan- guages { is often contrasted with scripting programming { seen as `amateurish' and thus needing little more than dynamically typed languages [Ous98].
    [Show full text]
  • A Bibliography of Publications in ACM SIGPLAN Notices, 1980–1989
    A Bibliography of Publications in ACM SIGPLAN Notices, 1980{1989 Nelson H. F. Beebe University of Utah Department of Mathematics, 110 LCB 155 S 1400 E RM 233 Salt Lake City, UT 84112-0090 USA Tel: +1 801 581 5254 FAX: +1 801 581 4148 E-mail: [email protected], [email protected], [email protected] (Internet) WWW URL: http://www.math.utah.edu/~beebe/ 20 June 2019 Version 3.26 Title word cross-reference 1 [1625, 1284, 1078]. 1/83 [509]. 100 [1190]. 11 [95, 390, 139, 393]. 11/780 [139]. 1100 [58]. 16-bit [1828]. 164 [721]. 1838 [1612]. 1978 [39]. 1980 [1943, 245]. 1980's [760]. 1981 [1946, 312, 311, 345, 354]. 1982 [1948]. #16G [797]. 1983 [1952, 1953]. 1984 [1955, 1956]. 1985 [1142]. 1986 [1960, 1961, 1962, 18, 19]. 1987 ∗ 3 + [1637]. 2 [1822]. = [328, 1637]. [1586]. [20, 25, 1239, 1357]. 1989 [39]. 198x TM 8 [1105]. [1827]. Ada [140]. [1850]. λ [39, 1388]. [1887]. n [1108]. N ≤ 8 [998, 1145, 1011]. ! 0 [1914]. [1637]. 2' [832, 1004, 941, 1383, 918, 1191, 1500, 1006, 1193, 919, 920, 949, 1007, 1145, 1196, * [918]. 950, 1376, 526, 843, 1158, 837, 1633, 800, 782, 913, 748, 1155, 1149, 791, 790, 1554, -calculus [1887]. -dimensional [1822]. 452, 634, 459, 1183, 966, 688, 842, 967]. 2000 -ively [1521]. [1833, 1844, 1847]. /information [195]. 3 [1924, 1477]. 32 [375, 371]. 32-bit [1828]. 370 [1203]. 0-201-17928-8 [1614]. 002R [1356]. 1 2 432 [650, 387]. 4381 [1269]. ACM-SIGPLAN [1943]. ACM/SIGPLAN [1971]. Acore [1645]. 6 [619]. 68 [513, 66, 107].
    [Show full text]
  • Model Transformations in Converge. In: 2Nd Workshop in Software Model Engineering (Wisme 2003), October 2003, San Francisco
    Middlesex University Research Repository An open access repository of Middlesex University research http://eprints.mdx.ac.uk Tratt, Laurence and Clark, Tony (2003) Model transformations in converge. In: 2nd Workshop in Software Model Engineering (WiSME 2003), October 2003, San Francisco. [Conference or Workshop Item] This version is available at: https://eprints.mdx.ac.uk/5911/ Copyright: Middlesex University Research Repository makes the University’s research available electronically. Copyright and moral rights to this work are retained by the author and/or other copyright owners unless otherwise stated. The work is supplied on the understanding that any use for commercial gain is strictly forbidden. A copy may be downloaded for personal, non-commercial, research or study without prior permission and without charge. Works, including theses and research projects, may not be reproduced in any format or medium, or extensive quotations taken from them, or their content changed in any way, without first obtaining permission in writing from the copyright holder(s). They may not be sold or exploited commercially in any format or medium without the prior written permission of the copyright holder(s). Full bibliographic details must be given when referring to, or quoting from full items including the author’s name, the title of the work, publication details where relevant (place, publisher, date), pag- ination, and for theses or dissertations the awarding institution, the degree type awarded, and the date of the award. If you believe that any material held in the repository infringes copyright law, please contact the Repository Team at Middlesex University via the following email address: [email protected] The item will be removed from the repository while any claim is being investigated.
    [Show full text]
  • PDF US Letter Paper
    Logtalk 2.6 Documentation July 2000 Paulo Jorge Lopes de Moura [email protected] TECHNICAL REPORT DMI—2000/1 Department of Mathematics and Informatics University of Beira Interior Rua Marquês d'Ávila e Bolama 6201-001 Covilhã — Portugal Table of contents Table of contents USER MANUAL.....................................................................................................................................................................8 Logtalk features .......................................................................................................................................................9 Integration of logic and object-oriented programming..........................................................................................9 Integration of event-driven and object-oriented programming..............................................................................9 Support for both prototype and class-based systems .............................................................................................9 Support for multiple object hierarchies................................................................................................................10 Separation between interface and implementation ..............................................................................................10 Private, protected and public inheritance.............................................................................................................10 Private, protected and public object predicates....................................................................................................10
    [Show full text]
  • The Language List - Version 2.4, January 23, 1995
    The Language List - Version 2.4, January 23, 1995 Collected information on about 2350 computer languages, past and present. Available online as: http://cui_www.unige.ch/langlist ftp://wuarchive.wustl.edu/doc/misc/lang-list.txt Maintained by: Bill Kinnersley Computer Science Department University of Kansas Lawrence, KS 66045 [email protected] Started Mar 7, 1991 by Tom Rombouts <[email protected]> This document is intended to become one of the longest lists of computer programming languages ever assembled (or compiled). Its purpose is not to be a definitive scholarly work, but rather to collect and provide the best information that we can in a timely fashion. Its accuracy and completeness depends on the readers of Usenet, so if you know about something that should be added, please help us out. Hundreds of netters have already contributed to this effort. We hope that this list will continue to evolve as a useful resource available to everyone on the net with an interest in programming languages. "YOU LEFT OUT LANGUAGE ___!" If you have information about a language that is not on this list, please e-mail the relevant details to the current maintainer, as shown above. If you can cite a published reference to the language, that will help in determining authenticity. What Languages Should Be Included The "Published" Rule - A language should be "published" to be included in this list. There is no precise criterion here, but for example a language devised solely for the compiler course you're taking doesn't count. Even a language that is the topic of a PhD thesis might not necessarily be included.
    [Show full text]
  • A History of Object- Oriented Programming Languages and Their Impact on Program Design and Software Development
    A History of Object- Oriented Programming Languages and their Impact on Program Design and Software Development Page 1 A program is simply a sequence of commands instructing a computer what to do. The degrees of freedom available in devising this list, make programs potentially the most complex and intricate entities ever envisioned by humans. For this reason, it is imperative that they are subdivided, otherwise they would soon become unmanageable and incomprehensible. It is essentially the different ways in which this can be accomplished which has engendered the development of programming design methods and subsequently languages which facilitate their implementation. Early languages could be categorised as procedural and applicative. The former predominantly embody a series of instructions to assign values to variables, while the latter resemble mathematical function definitions and ideally have no statements, only expressions without side effects (Parker 1988). During the 1960s, a new discipline, object- orientation emerged. Although the first language of this type originated towards the end of the 1960s, it is only in the last decade that its employment has become widespread because of the benefits it confers over existing methods. As the requirement for systems becomes ever more prodigious and elaborate, it is perceived as a means by which greater reliability and easier maintenance can be achieved. In order to understand the advantages stipulated by the inventors of object-oriented languages, it is important to appreciate the conceptual distinctions between these and traditional imperative programming languages. In the latter, a software schema may be data or process driven, with functions and variables attributed different levels of importance.
    [Show full text]
  • Reflective Programming and Open Implementations
    Reflective Programming and Open Implementations Dr. Stéphane Ducasse [email protected] http://www.iam.unibe.ch/~ducasse/ University of Bern 2000/2001 i. Table of Contents 1. Reflective Programming and Open Implementations 1 Class as Objects 34 Goal of this Lecture 2 Some Class Properties 35 Outline of the Lecture 3 Some Method based Properties 36 What we could have made... 4 Metaclass Responsibilities 37 History,Concepts,Definitions and Examples 5 Outline 38 Why Do We Need Reflective Programming? 6 Why ObjVlisp? 39 Why Do We Need Reflective Programming? 7 The Loops Approach 40 Traditional vs Reflective Answers 8 The Smalltalk Pragmatical Approach 41 Role ot Reflective Prog in Software Engineering 9 ObjVlisp in 5 Postulates (i) 42 Definitions (I) 10 How to Stop Infinite Recursion? 43 Consequences 11 ObjVlisp in 5 Postulates (ii) 44 Meta Programming in Programming Language Context 12 Unification between Classes and Instances 45 Three Approaches 13 About the 6th ObjVlisp’s Postulate 46 Infinite Tower of (Meta)Interpreters 14 Instance Structure: Instance Variables 47 Reflective Languages 15 Instance Behavior: Methods 48 Open Implementation and MOPs 16 Minimal Structure of an Object 49 The Basic Claim of Open Implementation 17 Class as an Object: Structure 50 Meta Object Protocols 18 The class Class: a Reflective class 52 Meta Programming in CLOS 19 A Complete Example 53 Infinite Tower vs Open Implementation 20 Outline 54 A Simple Application as Example 21 Message Passing (i) 55 Programming in Explicit Metaclass Context 22 Message Passing (ii) 56 Reusing Meta Programs 23 Object Creation by Example 57 MetaProgramming in OO Context 24 Object Creation: the Method new 58 MetaProgramming by Example 25 Object Allocation 59 Costs of Reflective Programming 26 Object Initialization 60 Designing Reflective Systems 27 Object Creation: the Metaclass Role 61 Meta-Problems 28 Class Creation 62 Meta and Open are not Limited to Programming Languages 29 A Simple Instantiation Graph 63 2.
    [Show full text]