Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Convert model to Javabeans #83
referenced this issue
Jun 24, 2016
In the new object model classes has consideration been given to avoiding actually exposing the Java Collection Framework interfaces as part of the API so that it might possible to switch to different internal implementations in the future without needing to change the API? For example, in the Gedcom class in the v3-development branch I see it currently uses java.util.HashMaps internally and the associated getters and setters expose java.util.Maps. Might that limit the ability to support alternate internal implementations in the future such as a primitive collections framework like Trove or an in-memory database like MapDB? Instead could families, for example, be exposed by a new Families class that has methods to add, update, delete, get and iterate on the contained Family objects? That might also be more friendly to exposing the API via REST which would support modern web UI use of the library. From a REST perspective Families would be the natural resource between a Gedcom resource and a Family resource.
I hadn't considered that, no. I did look at the Trove framework as a possible aid to reducing the memory footprint but I didn't want to introduce transitive dependencies to users...but that doesn't mean I couldn't do what you're suggesting.
Seems to me like there is a lot of advantage in implementing the Java Collection Framework interfaces ... those interfaces are ubiquitous and everyone knows how to use them, including other tools. I suppose if this were done, and it interfered with some technology that expects things to implement Java collection interfaces (like JSTL and EL) then the non-Java collections could be wrapped in Java collections, perhaps.
That said, writing wrapper classes around all the collections (and there are LOTS of them) could be done.
This will require some thought.