You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned in the post about meta-transport, highly hierarchical definitions are hard to view because the representation of namespace members is inherently flat which does not reflect the data structure.
Fixed port-IDs make top-level types very salient. It is also natural since a nested type does not need to have a fixed port-ID. This solution is unavailable for top-level types that don't have a fixed port-ID, such as in the linked case; an alternative is to simply add a special character pattern, such as an underscore, in place of the fixed port-ID. For example, a DSDL file Frame.1.0.uavcan would become _.Frame.1.0.uavcan. Example:
Alternatively, non-top-level types could be named starting with . like .Error.1.0.uavcan. That would make them hidden on Unix-like systems which is interesting.
These are very easy to implement but they are probably not the best possible solutions; other suggestions are welcome.
The text was updated successfully, but these errors were encountered:
As mentioned in the post about meta-transport, highly hierarchical definitions are hard to view because the representation of namespace members is inherently flat which does not reflect the data structure.
Fixed port-IDs make top-level types very salient. It is also natural since a nested type does not need to have a fixed port-ID. This solution is unavailable for top-level types that don't have a fixed port-ID, such as in the linked case; an alternative is to simply add a special character pattern, such as an underscore, in place of the fixed port-ID. For example, a DSDL file
Frame.1.0.uavcan
would become_.Frame.1.0.uavcan
. Example:Alternatively, non-top-level types could be named starting with
.
like.Error.1.0.uavcan
. That would make them hidden on Unix-like systems which is interesting.These are very easy to implement but they are probably not the best possible solutions; other suggestions are welcome.
The text was updated successfully, but these errors were encountered: