New DSDL directive for simple compile-time checks

[pavel.kirienko]

This is like uavcan.node.Heartbeat .

Which I suggest to call simply “name”. The last part of it could be referred to as “short name”. The full notation could be like this: https://github.com/UAVCAN/pydsdl/blob/008c8f16a45ed2a73d7fc22bdc2991c6a538ae55/pydsdl/dsdl_definition.py#L80-L103

[kjetilkjeka]

I should have been more clear, indeed. What I meant is that having two root namespaces located one inside the other is not allowed, because it may lead to problems and is not useful.

How is this possible, isn’t the definition of a root namespace that it isn’t contained inside another namespace?

Is what you mean that when naming a type it must either be inside the exact same namespace (and use the short name) or you must use the fully qualified name?

My suggestion applies specifically to root namespaces , not nested namespaces. Your example is not affected by this restriction; it would be only if ecs was the root namespace.

I still don’t understand this restriction. Does this restriction disallow having a root.esc1.control namespace and a root.esc2.control namespace? Or a root.esc1.Command definitions together with a root.esc2.Command definitions?

This is like uavcan.node.Heartbeat .

Which I suggest to call simply “name”. The last part of it could be referred to as “short name”. The full notation could be like this: https://github.com/UAVCAN/pydsdl/blob/008c8f16a45ed2a73d7fc22bdc2991c6a538ae55/pydsdl/dsdl_definition.py#L80-L103

I think of “name” instantly as short name, if you think of it as the fully qualified name perhaps we should avoid using only “name” to avoid ambiguities. I suggest:
uavcan.node - “namespace”
Heartbeat - “short-name”
uavcan.node.Heartbeat - “fully qualified name”

[pavel.kirienko]

How is this possible, isn’t the definition of a root namespace that it isn’t contained inside another namespace?

Exactly, and that’s what we’re checking. Suppose a parser is invoked to parse a namespace, and that namespace needs to use types defined in another namespace. Both will have to be supplied to the parser. Now, the parser will need to ensure that one namespace directory is not nested within the other.

I still don’t understand this restriction. Does this restriction disallow having a root.esc1.control namespace and a root.esc2.control namespace? Or a root.esc1.Command definitions together with a root.esc2.Command definitions?

Neither of those is affected. What is prohibited is that you can’t invoke a parser with two root namespace directories both ending with the same final path component: /foo/bar/uavcan, /abc/baz/uavcan; because that would imply that either the same definitions are supplied twice, or members of the same root namespace are distributed across several directories. The latter is dangerous because if a parser is ever invoked on only one of those directories, it will be unable to detect possible conflicts with the other.

I think of “name” instantly as short name, if you think of it as the fully qualified name perhaps we should avoid using only “name” to avoid ambiguities. I suggest:
uavcan.node - “namespace”
Heartbeat - “short-name”
uavcan.node.Heartbeat - “fully qualified name”

Ok, let’s avoid saying “name” and use either “fully qualified name” (can we just say “full name” for brevity?) or “short name”.

[pavel.kirienko]

DSDL processing tools (e.g. parsers) should issue a warning when a non-deprecated type is dependent on a deprecated type. This would typically mean that the developer forgot to update a dependency version number somewhere in a dependent definition.

Or do we want to treat that as an error? That would make sense to ensure that all dependencies are updated timely? In that case it should also be specified in the spec.

Example:

Foo:

@deprecated
# ...definition...

Accepted dependency:

@deprecated     # The referred version of foo is deprecated, so is this one
Foo.1.0 foo

Incorrect dependency:

# This type should be deprecated by extension
# The developer probably forgot to bump the version number of Foo
Foo.1.0 foo