What I am talking about is an abstract concept defined at the protocol level. It is not related to any programming language, although I described it using the terminology that is widely used in OOP. Obviously it can be expressed in any conventional programming language from C to Erlang, but that is irrelevant. I didn’t mean to distract the discussion from the core topic though, sorry.
Per my description above, this is not allowed. Polymorphism is not a functionally equivalent replacement for extension fields, but potentially it can be used to attain the same goals.
Anyway, I think this discussion is slightly out of place here. Our design process is built around somewhat more formalized proposals than what I scribbled there in my previous post; the topic requires much more thought and analysis from my end before it can be discussed constructively. I mentioned it to indicate that we are not blind to the message extensibility problem and that it is on the long-term roadmap. I understand the value of extension fields, but I think we could search for a solution that offers a more rigorous data model and greater type safety than simply pasting optional values at the end. The solution is missing from v1 currently, but it certainly does not mean that it won’t be introduced in a compatible manner in a subsequent minor revision.
From re-reading the OP post, I understand that the lack of unconstrained message extensibility (where “unconstrained” means that the extension capability is not dependent on the availability of padding fields, as we discussed) and the breakage are the only perceived issues in v1. Saying that “v1 does not address the key pain points” is at least unfair and it takes ignoring the fact that v1 provides viable solutions to the critical issues in v0, many of which are not mentioned in the OP post.
UAVCAN v1 is being deployed in highly complex vehicular applications where v0 could not be used due to its inherent limitations, only some of which were reviewed here. The most critical issue in v0 is the syntax-semantics entanglement, which by itself was an underlying cause for some other, more apparent issues, such as the over-specification of the standard data types. UAVCAN v0 is a great protocol for trivial UAV applications with unsophisticated hardware setups and straightforward design requirements, such as those that can be found in various basic industrial applications or hobby machines. The problem of v0 is that it breaks outside of that domain, and it is not possible to take v1 out of there without breaking backward compatibility. While the transition is painful, it is beneficial for everyone, especially the existing adopters of v0, because the much-improved architecture of v1 will increase the reach and coverage of its ecosystem, effectively increasing the available product options for integrators and at the same time increasing the reachable market for product manufacturers.
The improved ecosystem management policies and the new technical capabilities enable a very long design lifespan for v1, potentially over 10 years, although the exact amount will be defined by the feedback we receive from adopters. That bar might be too high for v0 due to its monolithic architecture.
Considering the state of the industry at large, one can see that v1 is a fundamental improvement over v0.
This is new information for me. Do they ship hardware for integration into 3rd-party systems with hard-coded node-IDs? Could you clarify, please, what is their motivation here? Clearly it’s an obstacle to integration.
There is another approach to segregating the CAN ID space so that v0 and v1 do not intersect based on the subject/service identifiers, but I will need to describe it later in a separate post. The core idea is that v0 utilizes the lower part of the range, whereas v1 utilizes the upper part of it. The compiler-based approach will not work because it cannot account for the integration-time identifier assignment.