On Tue, 24 Jan 2017 19:01:46 +0100 Robert Varga <n...@hq.sk> wrote: > On 01/24/2017 06:17 PM, Michael Vorburger wrote: > > One question around this: these look like hand-written APIs, > > which really should be backed by a model. Is there a particular > > reason for this? > > > > using https://immutables.github.io for these could be interesting.. > > but probably more of a potential next step separate follow-up, than > > something to mix into this. But now that there is a super generic > > String[] API anymore, which is used to be, which this addresses, > > moving to adopting (e.g.) Immutables.org instead of coding those > > out as they are would be useful, IMHO. > > Actually, these things should have an associated yang model, from > there all the stuff that immutables.org does comes out for free (in > fact binding2 is using immutables internally). > > I mean really, > https://github.com/opendaylight/genius/blob/master/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/MatchInfo.java > is tied to model-defined entity.
Yes, and it ends up building a YANG-model-defined entity. > https://github.com/opendaylight/genius/blob/master/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java > looks exactly how AD-SAL classes used to look like... > > Scratch that, it actually *is* a copy of an AD-SAL class: > https://github.com/opendaylight/controller/blob/stable/helium/opendaylight/sal/api/src/main/java/org/opendaylight/controller/sal/packet/IPv4.java Exactly, this code apparently dates back to the AD-SAL-to-MD-SAL transition. I agree we should switch to the YANG builders eventually; I started the transition mainly to get away from untyped arrays (of String, Long or BigInteger), and it turned out it wasn't too hard to do a clean migration for these classes. Switching completely to the YANG models would be a lot more involved (but we should consider it!). Thanks for your watchfulness! Regards, Stephen
pgpZR6SQyNG0i.pgp
Description: OpenPGP digital signature
_______________________________________________ sfc-dev mailing list sfc-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/sfc-dev
