Skip to content

Defining rules for namespaced modules #819

Open
@perazz

Description

@perazz

Motivation

I'm opening this issue to discuss defining rules for namespaced modules.

Specification

There are quite a few things that need be defined. I've started a base implementation in fpm that should make it easy to change them on the go, but the sooner we get to an agreement the better, so I think this is a good place to discuss.

  1. Namespace separator/ namespaced module identifier.

I like the idea of _FPM_ which seems to have no collisions with other fpm functionality and looks like _MOD_ which is basically a namespace separator for module entities. However, simpler options are also possible, e.g., \ or %

  1. Default namespace.

I think non-namespaced entities should resolve to a default namespace. I would name it

character(*), parameter :: DEFAULT_NAMESPACE = "default"

This means that both default-namespace and non-namespaced module identifiers would be resolved to the default namespace, e.g.:

_FPM_my_mod_1         ! belongs to the default namespace
default_FPM_my_mod_2  ! also belongs to the default namespace
my_package_FPM_my_mod ! belongs to namespace `my_package`
  1. Namespace priority/cascade

Within a namespace, no duplicate module names are allowed and in general, namespace==package, but not necessarily. I would vote for not prefixing all modules by default, but only resolving potentially colliding ones. In this case, something like:

  • Is namespace required in the dependency manifest? Resolve to its modules first;
  • Fallback to default / not-defined modules otherwise

Prior Art

PHP has good guidelines

Additional Information

Also related to #814

Metadata

Metadata

Assignees

No one assigned

    Labels

    specificationIssue regarding fpm manifest and model

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions