![]() The definition of the above comes from the documentation, but my query at the end is my own example it might have helped to see this explicitly in the documentation because it hadn't occurred to me the first time that I read it that it could be used in this way to obtain pure values that can be passed around, especially since in another part of the documentation it says that you create new objects using create_object which is side-effectful. What the documentation does not make clear, which is why I may have missed this functionality, is that when you essentially call a parameterized object (except you are not really calling it so much as just constructing an ordinary Prolog term) you get a pure value you can carry around and then send messages to, e.g.: :- object(circle(_Radius, _Color)). Again, though, I am welcome to hearing what I may be missing here. However, this does not seem like a good mechanism for creating instances of abstract data structures because it is not a pure and declarative operation in particular, the last thing that I want to do in a language like Prolog is to bring in the need to manually manage instances of data structures like I would have to do in an imperative language without garbage collection! So this is the source of much of my confusion because it seems like LogTalk is trying to make it easier to work with data structures but in practice it seems like it does so by turning Prolog into an imperative programming language. This makes sense if it should be viewed as creating a module, because it is a bit like asserting new clauses in the database. The reason for me saying this is that, assuming I understand the documentation correctly, creating a new object is inherently a side-effectful act. From it I get the impression that, rather than thinking of LogTalk as being about object-oriented programming, I should be thinking of it as being a system for writing composable modules, which makes a lot more sense.Īs for abstract data types, I agree that having a nice way to define them would be a boon, but I don't see how LogTalk really helps with this. Categories also provide runtime transparency. % with engines (and other components), we may start "assembling" some cars :- object(sedan,Ĭategories are independently compiled and thus allow importing objects to be updated by simple updating the imported categories without requiring object recompilation. Horsepower_rpm( HP, RPM) :- ^^horsepower_rpm( ClassicHP, ClassicRPM), % "super" call HP is truncate( ClassicHP * 1.23), % a souped up version of the previous engine :- category(sport, % a typical engine defined as a category :- category(classic, % a protocol describing engine characteristics :- protocol(carenginep). A simple object, defining a list member public predicate: A single source file can contain any number of entity definitions. ![]() ![]() Objects can be created dynamically but are usually static and defined in source files. Defining an objectĪn object encapsulates predicate declarations and definitions. An extends relation between two objects implies that both objects play the role of prototypes, with one of them extending the other, its parent prototype. For example, when an object instantiates another object, the first object plays the role of an instance and the second object plays the role of a class. Relations between entities define patterns of code reuse and the roles played by the entities. Logtalk provides objects, protocols, and categories as first-class entities. Some of the most important entity and predicate directives will be introduced in the next sections. ^^/1 - super call (of an inherited or imported predicate).to the object that received the message being processed) ::/1 - sending a message to self (i.e.Moreover, Logtalk can transparently interpret most Prolog modules as Logtalk objects. ![]() One important consequence is that Prolog code can be easily encapsulated in objects with little or no changes. Logtalk uses standard Prolog syntax with the addition of a few operators and directives for a smooth learning curve and wide portability. To keep its size reasonable, this tutorial necessarily assumes that the reader have a working knowledge of Prolog and is biased towards describing Logtalk object-oriented features. Logtalk is implemented in highly portable code and can use most modern and standards compliant Prolog implementations as a back-end compiler. Logtalk is an object-oriented logic programming language that extends and leverages Prolog with modern code encapsulation and code reuse mechanisms without compromising its declarative programming features.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |