On Sun, Apr 22, 2018 at 11:22 AM, Robert Varga <[email protected]> wrote:

> On 22/04/18 10:01, Anil Vishnoi wrote:
> >
> >     If we can make Ipv4Address.equals() final, we can define it in way,
> >     which would prevent this sort of breakage happening again -- but
> >     that is:
> >     1) a restriction on how generated code can be used
> >     2) a relatively high-risk change (is there anybody manually
> subclassing
> >     generated classes?)
> >     3) probably not a 5-line patch implementation
> >
> >     The question to the community is:
> >
> >     Is that what we want MD-SAL Binding V1 to do Fluorine onwards?
> >
> > ​ Weather report with these rationale would help. If community care,
> > they will understand the issue and raise their concern if any, if not,
> > it's mdsal committers decision.
>
​Glad to know that equals can be fixed and no-zone can be implemented
without breaking backward compatibility, because your initial response said
it's not possible
*"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".
​ *
*​"*​

>
> I think you understand the Weather Item process, which is for
> integrating breaking work.
>
> This is a question about *embarking* on implementing a change, and the
> question has been asked.
>
> Let me ask you specifically:
>
> Does the proposed change address the problem you are perceiving and do
> you support it?
>
​The proposed changes that broke the backward compatibility -- No, but if
majority of community want to go with that, i am fine with that.
The new proposal that you mentioned to ​

​fix the equals() so that it does not break the backward compatibility --
Yes.​
​

>
> Thanks,
> Robert
>
>


-- 
Thanks
Anil
_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to