Rationale behind lack of object composition?

[JacquesRobin]

Hello,

We are wondering what is the design rationale behind's Logtalk's absence of a containment relationship between objects. Most object-oriented languages (e.g., UML, Java, JavaScript) allow an object to contain other objects. In addition, they also allow grouping classes or objects into packages (or modules in the case of JavaScript). So those OO languages allow the developer to express multiple levels of encapsulation like Russian dolls.

In contrast, Logtalk seems to only offer a single level of encapsulation: clauses into objects or category and that's it. There is no language construct to further encapsulate those clause encapsulating entities into higher granularity container entities.

This seems to us to be a limitation for "programming in the large". For example, it would be convenient to encapsulate all the entities constituting a library into a reusable component implementing a protocol but distributing (delegating) the responsibilities of this implementation among multiple entities encapsulated inside the component (as in a UML Structured Classifiers). As far as we understand, in the current version of Logtalk, a library is just a flat set of entities scattered in a set of files that by convention gets loaded by a loader file, but they no Logtalk language construct for that and hence no benefit from associated reflection and meta-programming built-in entities or predicates. For example, we would like to be able to pass a whole reusable library as parameter to an object or predicate for code analysis or transformation purposes.

Is there something specific about the declarative logic programming context of Logtalk, that we have not understood, that motivated this design choice?

Thanks for insights on this topic.

[pmoura]

We are wondering what is the design rationale behind's Logtalk's absence of a containment relationship between objects. Most object-oriented languages (e.g., UML, Java, JavaScript) allow an object to contain other objects.

Actually, what most OOP languages allow is objects to contain references to other objects. The language syntax may provide an appearance of objects being able to contain other objects. But that's essentially syntactic sugar.

In addition, they also allow grouping classes or objects into packages (or modules in the case of JavaScript). So those OO languages allow the developer to express multiple levels of encapsulation like Russian dolls.

As you noted, that's a different feature: multiple namespaces. Logtalk currently provides single namespace for objects, protocols, and categories. Although I played and even prototyped an implementation of multiple namespaces, never found a satisfactory design and solution.

In contrast, Logtalk seems to only offer a single level of encapsulation: clauses into objects or category and that's it. There is no language construct to further encapsulate those clause encapsulating entities into higher granularity container entities.

Logtalk objects are indeed designed to encapsulate predicate directives and predicate definitions (clauses). But nothing prevents an object of containing a clause where arguments are references to other objects. That's illustrated by several examples bundled with the Logtalk distribution (see e.g. the delegates example).

This seems to us to be a limitation for "programming in the large". For example, it would be convenient to encapsulate all the entities constituting a library into a reusable component implementing a protocol but distributing (delegating) the responsibilities of this implementation among multiple entities encapsulated inside the component (as in a UML Structured Classifiers).

Have you looked into the design patterns sample implementations?

As far as we understand, in the current version of Logtalk, a library is just a flat set of entities scattered in a set of files that by convention gets loaded by a loader file, but they no Logtalk language construct for that and hence no benefit from associated reflection and meta-programming built-in entities or predicates. For example, we would like to be able to pass a whole reusable library as parameter to an object or predicate for code analysis or transformation purposes.

Could the technical solutions illustrated by this blog post be useful in your case?

[pmoura]

Actually, what most OOP languages allow is objects to contain references to other objects. The language syntax may provide an appearance of objects being able to contain other objects. But that's essentially syntactic sugar.

I am not sure it is syntactic sugar. There is IMHO a semantic difference between the part-whole relationship between two entities that is semantically more tightly coupled than other relationships between two entities, hence the UML distinction between composite associations and regular associations. When a language has no syntax to express this distinction is it therefore somewhat semantically less expressive.

I'm well aware of the different types of associations, including how they are represented in UML and their associated semantics. But UML is a modeling language. For a programming language, implementing associations, notably, composition, the common solution is have an object containing a reference to other objects (e.g. its parts). The way that reference is represented can translate to different lifetime semantics for the associated objects. But I don't think object lifetime is your main concern, correct?

...
Because of the special semantic tight coupling between part-whole, the best place to syntactically define the part is probably inside the whole rather than in an arbitrarily distant place of the code with the addition of a reference to the part in the whole.

Perhaps you can provide an example, taken from your application context, but using a common OOP language (e.g. C++, Java, ...), where a part is syntactically defined inside the whole? That would simplify illustrating how to achieve the same functionality in Logtalk.

[ACleverDisguise]

https://www.tutorialspoint.com/java/java_innerclasses.htm seems to have a salient example.

[pmoura]

Salient how? Java recommended uses for inner classes don't include the general representation of association and composition relations mentioned by @JacquesRobin. Most of the use cases for inner classes can be accomplished in Logtalk using categories.

[JacquesRobin]

Salient how? Java recommended uses for inner classes don't include the general representation of association and composition relations mentioned by @JacquesRobin. Most of the use cases for inner classes can be accomplished in Logtalk using categories.

Hi, I don't know Java very well, but the following article does seem to state that Java inner classes can precisely be used to implement UML composition to distinguish them from UML aggregation and association: https://www.baeldung.com/java-composition-aggregation-association.

And in JavaScript also has inner objects (though not inner classes):
const myUniversity = {
departments : [
{
name : "Computer Science",
professors: [PauloMoura, JacquesRobin]
}
]
}

const PauloMoura = {name: "Paulo Moura"}
const JacquesRobin = {name : "Jacques Robin"}

In this example, the university object is composed of departments objects, each of which is associated to professor objects.

[pmoura]

In that JavaScript example, myUniversity, PauloMoura, and JacquesRobin are variables (holding references to objects). But the definition of the PauloMoura and JacquesRobin variables (and thus the corresponding objects) are outside the object assigned to the myUniversity variable. A Logtalk version of this example (without any refactoring attempt) could be:

:- object(myUniversity).

	:- public(departments/1).
	departments([
		department('Computer Science', [pauloMoura,jacquesRobin])
	]).

:- end_object.


:- object(pauloMoura).

	:- public(name/1).
	name('Paulo Moura').

:- end_object.


:- object(jacquesRobin).

	:- public(name/1).
	name('Jacques Robin').

:- end_object.

Thus, the "each [department] is associated to professor objects" is accomplished in same abstract way.

The departments array does hold objects (where each object, representing a department, can be referenced using the array indexes). This translates the idea that "the university object is composed of departments objects". In the Logtalk version, a list of compound terms is used. If necessary, those compound terms can be interpreted as parametric object proxies. For example, we could define:

:- object(department(_Name_, _Professors_)).

	:- public(name/1).
	name(_Name_).

	:- public(professors/1).
	professors(_Professors_).

:- end_object.

This would support queries such as:

| ?- myUniversity::departments([Department| _]), Department::name(Name).
Department = department('Computer Science',[pauloMoura,jacquesRobin]),
Name = 'Computer Science'
yes

Similar support could be accomplished in the original JavaScript example by writing:

departments : [
    {
        name : "Computer Science",
        professors: [PauloMoura, JacquesRobin],
        getName: function() {return this.name;}
    }
]

But, assuming multiple departments, how can we avoid repeating the getName (and other) method definitions so that everything would still be containing inside the departments object?

That Java article is interesting. I wonder why official Sun/Oracle documentation don't mention (as far as I remember and could find again in a quick search) using inner classes for composition. But let's look into it from a Logtalk perspective. Any access to the Room objects is indirect via the Building object. The representation of rooms is abstracted by the outer class: for the clients of the building object, that rooms are implemented using an inner class is immaterial, correct? Hard to see, at least from this particular example, any motivation to have the equivalent to inner classes in Logtalk. In a Logtalk version of this example, representing the individual rooms using a private predicate (which could be dynamic if necessary to add/remove rooms at runtime) would work fine. All the predicates that worked on the room representation could also be moved to a category for nicer code modularization. Not everything needs to be an object.