Namespaces feature design

[pmoura]

Currently, Logtalk provides a single, flat namespace for all entities (objects, protocols, and categories). This results in the potential of name conflicts, notably between Logtalk development and application developers. For example, adding a new library to the Logtalk distribution can result in a name clash with a third-party application library. Two independent contributors can publish libraries using the same name for some entities, preventing using both libraries in the same application. Supporting multiple namespaces can help minimizing these name conflicts.

Implementing support for multiple namespaces requires new and updated language constructs, new syntax, and significant changes to the reflection API and developer tools. It's not clear that backwards compatibility can be preserved, even if support for a default namespace is provided. The tentative plan is to include support for multiple namespaces in the next generation (4.x) of Logtalk.

Ideal goals

Optional feature

It should be possible to write simple applications without forcibly defining a new namespace.

Default namespace

There should be a default namespace, used when the loaded code doesn't include any namespace declarations.

Load code to a given namespace

It should be possible to load code doesn't include any namespace declarations into a (non-default) namespace.

Namespace aliases

Similar to what's already supported for entities and predicates, it should be possible to define an alias for a namespace, notably as a solution to shorten the name of long namespaces.

[yrashk]

With the express understanding that I base this on some conjectures, I'd like to see how this can work from my perspective. Just something to start with.

Namespaced entity definition

If we consider that a [default] definition of an entity may contain a namespace, then perhaps something like this can work.

Term-based

:- object((ns, obj)).
:- end_object.

:- object(ns-obj).
:- end_object.

:- object(ns:obj). %% too much of a clash with Prolog modules?
:- end_object.

Relation/property-based

:- object(obj, namespace(ns)).
:- end.

Loading into a namespace

Overriding

logtalk_load(Files, [namespace(myns)])

Mapping

logtalk_load(Files, [namespaces(ns-myns)])

Using a namespaced entity

Fully-qualified

(ns, obj)::message.
ns-obj::message.

Imported

:- uses_namespace(ns).

pred  :- obj::message.

Standard library

current_object and co can still work but unify with the fully-qualified name (say, ns-obj) and object_property may have a new property to indicate the non-namespaced entity

[pmoura]

One of the issues of an entity identifier in a entity opening directive including an explicit namespace is that the argument becomes a compound term. In multiple places in the current code base, a compound is interpreted as meaning a parametric object or a parametric category. Also, for protocols, we go from an atom to a compound. A possible solution is to introduce a namespace/1 directive. For example:

:- namespace(my_company_name).

:- object(foo).
    ...
:- end_object.

The namespace/1 directive also helps with backwards compatibility. It would always be optional so that a default namespace, or a loading option, could be effective.

Any entity relations (in the entity opening directive) would also default to the declared namespace. But an entity opening directive may also declare relations with other entities that may belong to a different namespace. in this case, new syntax is unavoidable. We already use the (::)/2 infix operator for public/protected/private relation. Thus, we will need to use a different operator. for example:

:- namespace(my_company_name).

:- object(bar,
    implements(core:expanding).
    ...
:- end_object.

The (:)/2 infix operator may be a reasonable choice as it's a standard operator and thus we avoid inventing a new operator (which is always risky for portability).

[pmoura]

An alternative operator for connecting namespaces with entity identifiers would be a (@)/2 infix operator. But this is more problematic. E.g. ECLiPSe already uses it for meta-predicate semantics.

[pmoura]

Standard library

current_object and co can still work but unify with the fully-qualified name (say, ns-obj) and object_property may have a new property to indicate the non-namespaced entity

Another possible solution is to introduce variants of the reflection predicates that take an additional namespace argument. The existing predicates (and the applications using them) would continue to work in all cases where a single/default namespace is used at runtime. As an example, a current_object(Namespace, Object) would allow enumerating (by backtracking) all objects from a namespace.

I would prefer to avoid non-namespaced entities and instead have e.g. user as a default namespace when no namespace directives or options are used.

[yrashk]

I agree that there should always be a namespace.

[pmoura]

We also need syntax for sending a message to an object qualified by a namespace. For example:

?- ns/obj::message.

Here, using the (:)/2 operator isn't the best choice visually. Compare:

?- ns:obj::message.

[yrashk]

I like the visual delineation of /

[pmoura]

The uses/1 directive can be extended to support referencing entities from other namespaces without a namespace qualification when using explicit message-sending. For example:

:- object(...).

    :- uses([system/list]).

    foo :-
        list::member(..., ...).

:- end_object.