You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@johnzon.apache.org by Mark Struberg <st...@yahoo.de> on 2016/03/27 17:47:59 UTC
API vs impl
We currently have no ‚API‘ for Mapper etc. That means that we pretty much expose all internals to the public. That is fine as long as no one comes whining why we change some signatures.
Imo we should start to make it clear what is considered an end-user contract and what is purely internal and subject to get changed.
Probably not that important if a user really only relies on JSON-P and JSON-B, but might hit us if we like/need to refactor internal things.
LieGrue,
strub
Re: API vs impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 27 mars 2016 20:23, "Mark Struberg" <st...@yahoo.de> a écrit :
>
>
> > Am 27.03.2016 um 19:16 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
>:
> >
> > Le 27 mars 2016 17:48, "Mark Struberg" <st...@yahoo.de> a écrit :
> >>
> >> We currently have no ‚API‘ for Mapper etc. That means that we pretty
much
> > expose all internals to the public. That is fine as long as no one comes
> > whining why we change some signatures.
> >>
> >
> > This is not true and not having an interface allows end users to extend
it
> > in a smooth manner for advanced things.
>
> Which we will most certainly break with any minor refactoring…
>
That s ok.
>
> >> Imo we should start to make it clear what is considered an end-user
> > contract and what is purely internal and subject to get changed.
> >
> > Once again contract != interface. Your MappingConfig is a very good and
due
> > refactoring which would solve most of current issues.
>
> Still needs review. First draft is committed to my github branch. Still a
few miles to go :(
> What I aim for is that the MapperBuilder builds a config. All mutable.
But if you create a Mapper then we do a clone() on the *current*
MapperConfiguration and pass this to the Mapper where there is no way to
change it later.
>
While clone is not Cloneable still +1 if acessible from a Mapper child.
>
> > Side note: -1000 to any spi for the impl.
>
> I would love to see an own SPI package at least. Currently the people
using Mapper can not be sure what will remain stable in the future and
which signatures might change…
>
Yes and no. We dont have internals yet I d say.
> Probably it becomes less important if the JSON-B spec adopts a capable
API.
> One of my goals is to have something the JSON-B EG can look at and
probably adopt the approach.
> Not sure if their time and manpower allows it, but currently the jsonb
Adapters are really way too limited.
>
+1 but mapper goal is to stay lighter in term of spi instantiation and
easier to start hacking by anyone.
> LieGrue,
> strub
Re: API vs impl
Posted by Mark Struberg <st...@yahoo.de>.
> Am 27.03.2016 um 19:16 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Le 27 mars 2016 17:48, "Mark Struberg" <st...@yahoo.de> a écrit :
>>
>> We currently have no ‚API‘ for Mapper etc. That means that we pretty much
> expose all internals to the public. That is fine as long as no one comes
> whining why we change some signatures.
>>
>
> This is not true and not having an interface allows end users to extend it
> in a smooth manner for advanced things.
Which we will most certainly break with any minor refactoring…
>> Imo we should start to make it clear what is considered an end-user
> contract and what is purely internal and subject to get changed.
>
> Once again contract != interface. Your MappingConfig is a very good and due
> refactoring which would solve most of current issues.
Still needs review. First draft is committed to my github branch. Still a few miles to go :(
What I aim for is that the MapperBuilder builds a config. All mutable. But if you create a Mapper then we do a clone() on the *current* MapperConfiguration and pass this to the Mapper where there is no way to change it later.
> Side note: -1000 to any spi for the impl.
I would love to see an own SPI package at least. Currently the people using Mapper can not be sure what will remain stable in the future and which signatures might change…
Probably it becomes less important if the JSON-B spec adopts a capable API.
One of my goals is to have something the JSON-B EG can look at and probably adopt the approach.
Not sure if their time and manpower allows it, but currently the jsonb Adapters are really way too limited.
LieGrue,
strub
Re: API vs impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 27 mars 2016 17:48, "Mark Struberg" <st...@yahoo.de> a écrit :
>
> We currently have no ‚API‘ for Mapper etc. That means that we pretty much
expose all internals to the public. That is fine as long as no one comes
whining why we change some signatures.
>
This is not true and not having an interface allows end users to extend it
in a smooth manner for advanced things.
> Imo we should start to make it clear what is considered an end-user
contract and what is purely internal and subject to get changed.
Once again contract != interface. Your MappingConfig is a very good and due
refactoring which would solve most of current issues.
Side note: -1000 to any spi for the impl.
> Probably not that important if a user really only relies on JSON-P and
JSON-B, but might hit us if we like/need to refactor internal things.
>
> LieGrue,
> strub