Some extra notes that I wrote to Teams after this:

[Yesterday 11:47 AM] Bjarne Boström (Guest)

Thus what our Codegen does cannot be compiled for https://reference.opcfoundation.org/Machinery/Result/v100/docs/7.2 OK, an overload (not override) would be fine (though the original method would still exist). However the Machinery Result model specifically says "The ResultTransferTypeoverwrites the Method GenerateFileForReadto specify the concrete type of the generateOptions Argument of the Method."
​[Yesterday 11:48 AM] Bjarne Boström (Guest)
This is because the core spec says to do that, but in my opinion this should not be allowed. Yes, I can technically "fix" this in our Codegen by faking that the override never took place (i.e. keeping the parameter as "Object" as our BaseDataType mapping is), but then there wasn't any reason to do so in the first place.
​[Yesterday 11:49 AM] Bjarne Boström (Guest)
i.e. once a Method has been defined in a TypeDefinition, it can never be removed nor the inputs altered
​[Yesterday 11:52 AM] Bjarne Boström (Guest)

Thus some of this must be done:

1. Remove the clients-can-use-supertype part from spec (as it wont apply, plus there is other breakages of this as well with other subtyping rules)

2. Remove subtyping of input args (removing TemporaryFileTransferType method)

3. Do nothing and accept that the Part3 conflicts itself. Probably this is what happens as I do not see 1&2 happening. But regradless I would recommend writing some section that this "feature" shouldn't be used (unless there is no other way).

4. Something else??

Also one additional note: I'm not sure does OPC UA has Method overloading (method with the same name, but different input paramters) i.e. can one make multiple Methods with the same name and different parameters. Since in the Typespace all BrowsePaths must be unique I assume this is not the case, but in the instances it could be possible. IF both overriding and overloading take place, it is not possible to differentiate is the subtyped method an override or an overload.

Jim to write note and request feedback.

Bjarne,

Method overloading is not supported in OPC UA types. OPC UA is not going to change how methods work and will continue to allow derived types to add additional optional parameters to the end of the argument lists. Given that the spec is not going to change you seem to imply that how it works is not sufficiently specified. Please provide proposed enhanced wording to clarify the specification given the functionality will not change.

Hi Jim,

I'll try explain this better, but I'm sort of maybe repeating myself a bit, sorry.

Basically the very fact that OPC UA allows "changing" the signature introduces the concept of method overloading in object-oriented terms, i.e. that is the problem here.

Since OPC UA is basically an object oriented language and the previously mentioned https://reference.opcfoundation.org/Core/Part3/v105/docs/4.5.3 "Clients that only know the supertype to handle an instance of the subtype as if it were an instance of the supertype;" means https://en.wikipedia.org/wiki/Liskov_substitution_principle applies.

That means it is not possible to remove a method signature from a subtype, thus if a subtype "changes" the signature so that a parameter would be subtype, that introduces a new Method and the original remains (!), thus the Method overloading concept is introduced (assuming here the same name was used for the Method as the original).

A client not knowing the subtype would just see the original method ("super type view", the '4.5.3' above) and must be able to call that. Another client seeing the subtype would see 2 methods (the original supertype and the one from the subtype). This is how all object-orientend programming languages work to my knowledge (most of that is from Java though). Typically it is however allowed to change the return type in overriding to be a subtype, as that doesn't break the method contract for "supertype callers", but any changes to input parameters does introduce a new method (and if it is the same name, an overload in Java-terms at least). Only if the input parameters are the same it is an override.

Thus, the OPC UA spec contradicts itself. The same problem does exist when an InstanceDeclaration can change the DataType to a subtype (i.e. users of the original TypeDefinition for that InstanceDeclaration do see the original DataType and as far as I understand per Liskov be allowed to use that). But skipping this here as that has been discussed previously and it is a no can do situation (i.e. the very concept of "VariableTypes" causes the problem I believe, cannot be fixed).

And specifically the problem I have is within Java and our (Prosys OPC UA SDK)
Codegen tool because I basically have to fake each such subtype to remove the subtyping of the method parameter because java enforces Liskov. Or like I could also make this an "overload", but as you said this concept doesn't properly exist in OPC UA before this "maddness" and thus we are not handling it and thus basically for the type to work at all the easiest solution is to just correct the subtype to have the same signature (as it should have been).

The Java part can be ignored as that is like "my problem", but using purely the spec itself it both allows and disallows changing the signature and while not allowing overloading it is just a contradiction I wish could be solved somehow.. but as said, I do not see TemporaryFileTransferType changing. But maybe it could just be noted "sorry we made a mistake, do not make anymore types like this" or something.

Trying to explain also with more simple terms.

Lets say we have types A and B and B is subtype of A.

Let A have method foo(Number).

Using normal object oriented inheriting rules and https://reference.opcfoundation.org/Core/Part3/v105/docs/4.5.3 B shall have also method foo(Number), otherwise the listed rules (and Liskov) are broken and B cannot be used as A.

Then https://reference.opcfoundation.org/Core/Part3/v105/docs/6.3.3.3 "magically" allows an "override" of foo(Number) with e.g. foo(Int32) on B. But that cannot be, as it is not an override, as foo(Number) shall also exist, otherwise clients with "A-only-knowledge" cannot treat B as the A-supertype. Thus, B shall have both foo(Number) and foo(Int32) and the foo(Int32) is an overload, not override.

Thus, a contradiction.

Or do I miss something here?

P.S.
Like yes, in Java one could make B.foo(Number) to throw e.g. DoNotUseException, but that would be bad design typically.

From an implementation standpoint, the Server must implement the method with the signature of the base type where the method is originally defined (like foo(Number) in A). The contract foo(Number) does not imply the method needs to be able to process all sub-types of Number without Error. The more restricted override in B is allowed so long as the override does not violate the contract in A (i.e. int32 is a valid Number). The method signature is valuable for Clients because it gives a Client better information as to what type of values will likely be accepted by the method and produce a non-error result.

Added an additional statement to 6.3.3.3 describing what the required behavior of methods with optional arguments that are overridden.

Still no viable conclusion on what to do here -- deferred to a future release.