I’d like to make this a first class citizen in the API anyway. That should remove the need to create a subclass for Mapper.
It will probably need a few attempts… Currently doing all this on a github branch [1] to not break too many things while playing around. But once you all feel comfortable with the direction I’ll commit it to our main repos. LieGrue, strub [1] https://github.com/struberg/incubator-johnzon/tree/JOHNZON-71 > Am 27.03.2016 um 19:26 schrieb Romain Manni-Bucau <[email protected]>: > > Le 27 mars 2016 18:17, "Mark Struberg" <[email protected]> a écrit : >> >> What other extensions? What is the use case? > > Reusing the classmapping mainly > >> Again: it’s not part of the contract, so we might break this with any > release… >> > > This is fine while info are available > >> LieGrue, >> strub >> >> >>> Am 27.03.2016 um 17:54 schrieb Romain Manni-Bucau <[email protected] >> : >>> >>> Le 27 mars 2016 17:44, "Mark Struberg" <[email protected]> a écrit : >>>> >>>> Hi! >>>> >>>> I’m currently rewviewing and cleaning up stuff. >>>> >>>> Here are a few questions: >>>> >>>> 1.) Why is the Mapper ct public? It should imo only get created via >>> MapperBuilder. >>>> 2.) Why are the config switches in Mapper protected? >>>> >>> >>> Both are used by extensions in other projects. >>> >>>> I’m currently refactoring all this out into a MapperConfig which is >>> immutable and can get passed around without duplicating too much. >>>> >>> >>> No pb to break it while info is available to potential extensions >>> >>>> LieGrue, >>>> strub >>
