Prototypes

Help requests on developing Logtalk applications

Moderator: Paulo Moura

Post Reply
mcculloch
Posts: 4
Joined: Sun Nov 04, 2012 6:10 pm

Prototypes

Post by mcculloch » Mon Nov 05, 2012 3:42 pm

I want to develop an OO Gtk wrapper for Prolog and Logtalk seems to be a great way to do that. However, I want to understand Logtalk completely and I'm struggling with a couple of concepts. First, can someone explain Prototypes in a way that a a C++ programmer can understand? I used to use PDC Prolog before it was Visual Prolog and that was class based.

I'm also a little confused with "A reflective class based system" in the docs. "class" inherits from "abstract_class" which inherits from "object" and they all instantiate "class". I'm guessing "class", "abstract_class" and "object" in this case are example atoms and not keywords for Logtalk. Am I wrong? If I want to use only class based hierarchies, should I always include the code in this section? The circular reference is hard for me wrap my head around.

Thanks,
John

Paulo Moura
Logtalk developer
Posts: 475
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: Prototypes

Post by Paulo Moura » Mon Nov 05, 2012 5:14 pm

Hi John,

Welcome to the Logtalk discussion forums.
mcculloch wrote:I want to develop an OO Gtk wrapper for Prolog and Logtalk seems to be a great way to do that. However, I want to understand Logtalk completely and I'm struggling with a couple of concepts. First, can someone explain Prototypes in a way that a a C++ programmer can understand? I used to use PDC Prolog before it was Visual Prolog and that was class based.
As you know, in a class-based system, a class represents an abstraction of the common properties of a set of objects, its instances. In contrast, in a prototype-based system, there's no distinction between abstractions and examples of those abstractions, only objects (aka as prototypes), which can be used to represent anything. Prototypes can be self-defined, standalone objects, or can be derived from existing prototypes (aka parent prototypes). Logtalk includes several usage examples, of both classes and prototypes. One of the examples, "shapes", contains two versions, one prototype-based and the other class-based, of a very simple geometric shapes hierarchy. The aim of this example is to compare the pros and cons of using either prototypes or classes for defining object hierarchies. I suggest that you start by playing with this and the other examples to get yourself acquainted with Logtalk.

Note that Logtalk supports both classes and prototypes. However, the support for classes follows the model found e.g. on Smalltalk (in that classes are usually themselves instances of other classes, their metaclasses) rather then the model that you have in e.g. C++ or Java.
mcculloch wrote:I'm also a little confused with "A reflective class based system" in the docs. "class" inherits from "abstract_class" which inherits from "object" and they all instantiate "class". I'm guessing "class", "abstract_class" and "object" in this case are example atoms and not keywords for Logtalk. Am I wrong? If I want to use only class based hierarchies, should I always include the code in this section? The circular reference is hard for me wrap my head around.
The atoms "class", "abstract_class", and "object" are just object identifiers. There are only three different types of entities in Logtalk: objects, protocols (aka interfaces), and categories. An object can play several roles. For example, an object that specializes another object and instantiates a third object plays the roles of class, subclass, and instance. The object it specializes plays the role of a superclass. The object it instantiates plays the role of a metaclass. Thus, in Logtalk, the term "object" is used in a generic sense, while terms such as "class", "instance", or "prototype" depend on the role an object is playing in a given context.

As far as the "circular reference" goes, is really not circular in the sense that there are no inheritance loops. "object" represents what's common to all objects. Thus, in this example, all objects inherit from "object". "abstract_class" represents what's common to all classes. Thus, all classes inherit from it (but remember that classes are also objects in Logtalk). "class" represents what's common to all instantiable classes. If you draw a digram with the three classes and their instantiation and specialization relations, it will become more clear (you can also generate the diagram from the code using the "diagrams" tool, assuming that you're using Logtalk 3.x).

Note that you can certainly reuse the "roots" example code but there's nothing fundamental in it except as an illustration of what you can build in Logtalk. The important bit for using classes in Logtalk is that an object can only be interpreted as a class/instance if it specializes/instantiates other objects. Stand-alone objects or objects that extend other objects are interpreted as prototypes.

Hope this helps. Happy logtalking,

Paulo
Paulo Moura
Logtalk developer

mcculloch
Posts: 4
Joined: Sun Nov 04, 2012 6:10 pm

Re: Prototypes

Post by mcculloch » Tue Nov 06, 2012 4:30 pm

Thanks Paulo,

I did some Googling on Prototypes vs classes. Between that and your reply, I think I have it now. I still feel more comfortable with classes. That being said, should a root class of a hierarchy specialize some special class? Does it need to specialize or instantiate itself?

Also, for anyone curious about why I would want to write a Gtk wrapper in Logtalk, when XGP and XPCE are available. XGP is for Mac OS X only and XPCE is for SWI Prolog only. I use gprolog and want my code to support any prolog that Logtalk supports and also supports calling C code.

Thank,
John

Paulo Moura
Logtalk developer
Posts: 475
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: Prototypes

Post by Paulo Moura » Tue Nov 06, 2012 8:40 pm

mcculloch wrote: I did some Googling on Prototypes vs classes. Between that and your reply, I think I have it now. I still feel more comfortable with classes. That being said, should a root class of a hierarchy specialize some special class? Does it need to specialize or instantiate itself?
An object playing the role of a root class will need at least to specializes or instantiate other class. An object without specialization or instantiation relations is compiled as a prototype. The typical solution is to have a class that it's its own metaclass. I.e. a class that instantiates itself. Another way of look at it is to think that, if every class in an instance of some class, you would have an infinite metaclass regression unless, at some point, a class instantiates itself.

Also note that, if you want to be able to send messages to an object playing the role of a class (e.g. a new/1 message for creating a new object), then the object will need to have a metaclass. Otherwise, there would be place to lookup for the message declaration.
mcculloch wrote:Also, for anyone curious about why I would want to write a Gtk wrapper in Logtalk, when XGP and XPCE are available. XGP is for Mac OS X only and XPCE is for SWI Prolog only. I use gprolog and want my code to support any prolog that Logtalk supports and also supports calling C code.
I think the most difficult part will be that there's no Prolog standard for foreign language interfaces, even if you restrict yourself to call C code. But you should be able to encapsulate the non-portable bits into Prolog dialect specific objects implementing a common protocol. Logtalk also supports conditional compilation directives, which will probably become handy.

Cheers,

Paulo
Paulo Moura
Logtalk developer

Paulo Moura
Logtalk developer
Posts: 475
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: Prototypes

Post by Paulo Moura » Wed Nov 07, 2012 11:29 pm

Paulo Moura
Logtalk developer

mcculloch
Posts: 4
Joined: Sun Nov 04, 2012 6:10 pm

Re: Prototypes

Post by mcculloch » Thu Nov 08, 2012 4:12 pm

Thanks. The link was helpful. I now know to instantiate each root class to itself, and then I can declare all subclasses with just "specializes".

I have thought about the difference between the C linking methods for different prologs. I will start with gprolog since that's what I use. If that goes well, I may or may not look at other implementations. I won't bother with SWI since it has XPCE. Frankly, if Visual Prolog were available cross-platform, I would just use that. I really liked it, but I don't use Windows anymore.

John

Paulo Moura
Logtalk developer
Posts: 475
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: Prototypes

Post by Paulo Moura » Thu Nov 08, 2012 4:27 pm

mcculloch wrote: Thanks. The link was helpful. I now know to instantiate each root class to itself, and then I can declare all subclasses with just "specializes".
You may also make the root class instantiate a metaclass where the metaclass instantiates itself. Then, all subclasses (direct or indirect) of the root class, just need a specialization relation with the superclass. But not that the equivalent to class methods as in e.g. Java or C++ require a metaclass. I.e. class methods are simply instance methods defined in the class of the class, i.e. in its meta-class. Check (if you have not done it already) the "classmethods", "classvars", "instmethods", and "instvars" examples.
mcculloch wrote: I have thought about the difference between the C linking methods for different prologs. I will start with gprolog since that's what I use. If that goes well, I may or may not look at other implementations. I won't bother with SWI since it has XPCE. Frankly, if Visual Prolog were available cross-platform, I would just use that. I really liked it, but I don't use Windows anymore.
GNU Prolog is one of the most popular back-end compilers for Logtalk.

Cheers,

Paulo
Paulo Moura
Logtalk developer

mcculloch
Posts: 4
Joined: Sun Nov 04, 2012 6:10 pm

Re: Prototypes

Post by mcculloch » Tue Nov 13, 2012 7:32 pm

Now, I think I've made a mistake with GNU Prolog. I've found several built in predicates that don't do what one would expect. For example, directory_files returns a list of files names and file_properties pretends that it can give you an absolute file name for that file. It really only assumes that the file is in the current directory. I've tested it many ways. This makes file operations in gprolog difficult. If I have to go to SWI Prolog, I won't bother with a Gtk+ wrapper, I'll just use XPCE.

John

Paulo Moura
Logtalk developer
Posts: 475
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: Prototypes

Post by Paulo Moura » Tue Nov 13, 2012 7:53 pm

mcculloch wrote:Now, I think I've made a mistake with GNU Prolog. I've found several built in predicates that don't do what one would expect. For example, directory_files returns a list of files names and file_properties pretends that it can give you an absolute file name for that file. It really only assumes that the file is in the current directory. I've tested it many ways. This makes file operations in gprolog difficult. If I have to go to SWI Prolog, I won't bother with a Gtk+ wrapper, I'll just use XPCE.
GNU Prolog have good documentation and a good file system access API. Not sure what you mean by "file_properties". For getting the absolute file path for a file, you can use the absolute_file_name/2 built-in predicate. Try, for example:

Code: Select all

| ?- directory_files('.', Files), member(File, Files), absolute_file_name(File, Path).
Cheers,

Paulo
Paulo Moura
Logtalk developer

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests