On 18/04/18 21:17, Anil Vishnoi wrote: > > > On Wed, Apr 18, 2018 at 10:31 AM, Robert Varga <[email protected] > <mailto:[email protected]>> wrote: > > Object.equals() is required to be reflexive. Your statement "this is > not correct behavior" is based on your human understanding of the > model (most notably reading English text in description), not > something automation can infer. Therefore codegen cannot generate an > .equals() method, which would be both conforming to the API contract > and supporting "correct behavior". >
Hello Anil,
> Sorry robert, but i am not able to make sense out of what you are
> saying. English language can be interpreted in many ways, but hopefully
> you will agree that patterns has clear interpretation. Both ipv4-address
> and ipv4-address-no-zone has clear pattern defined.
>
> typedef ipv4-address-no-zone {
> type ipv4-address {
^^^^^^^^^^^^^^^^^
> pattern '[0-9\.]*';
> }
> }
>
>
> typedef ipv4-prefix {
> type string {
> pattern
> '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
> + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
> + '/(([0-9])|([1-2][0-9])|(3[0-2]))';
> }
> }
Wrong type, you meant to quote this:
> typedef ipv4-address {
> type string {
> pattern
> '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
> + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
> + '(%[\p{N}\p{L}]+)?';
> }
but aside from that, yes those patterns are clear. What is clear to
humans, but not machines, is that:
1) an ipv4-address string really has two parts, a dotted-quad and an
optional zone prefixed with %
2) ipv4-address-no-zone is an ipv4-address, which does not have a zone
Arriving at this distinction by analyzing the patterns involved is the
challenge here -- as those are the only bits which a
machine-understandable. I am pretty sure an algorithm to solve that
problem, if it is even possible, would run in non-linear time and would
probably be a major breakthrough in information technology.
> And apart from that the failure is happening because equals is expecting
> different class then ipv4address (which is changed in the above gerrit).
> org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev130715.Ipv4Address<Ipv4Address{_value=0.1.2.3}>
> but was:
> org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev130715.Ipv4AddressNoZone<Ipv4Address{_value=0.1.2.3}>
>
>
> I believe this is most probably happening because the way mdsal is
> generating the code now for no-zone in your latest patch.
>
> Currently generated code for ipv4-address-no-zone is extending
> ipv4-addresss (which is weird to me , subset extending superset)
You have to understand how YANG type system works, which is detailed in
RFC7950 sections 4.2.4, 4.2.5, 7.3 and 7.4.
TL;DR; of that is that all YANG types are derived from a set of fixed
built-in types. Derivation works by placing additional restrictions on
the data, not extending the data set -- which is where the weirdness you
perceive comes from.
In in any case
> public class Ipv4AddressNoZone extends Ipv4Address
is an accurate mapping of the semantic relationship between the two types:
- any valid Ipv4AddressNoZone is a valid Ipv4Address, but not vice-versa.
- creating an Ipv4Address from an Ipv4AddressNoZone is dirt cheap
- creating an Ipv4AddressNoZone from an Ipv4Address requires validation
It is therefore clear that IetfInetUtil should be handing out
Ipv4AddressNoZone objects -- as that is the semantically correct type
capture of what is inside an Inet4Address.getAddress() array.
> Given that both ipv4-address-no-zone and ipv4-address are different
> construct by definition, if mdsal generates these construct separately
> (without extending) that should keep the backward compatibility without
> breaking any downstream code.
They are not completely different constructs, they are related through
derivation:
- string is the base type of ipv4-address
- ipv4-address is a type derived from string
- ipv4-address-no-zone is a type derived from ipv4-address
Regards,
Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
