Kent,
yeah, you have a point.
I was thinking more; I can have this done today, and avoid another breaking
change later.
The @Deprecated approach could of course also be taken. But I think either
needs to be done.
Niclas
On Thu, May 25, 2017 at 4:21 PM, Kent Sølvsten <kent.soelvs...@gmail.com>
wrote:
> I think you are right, but not sure the timing is right (3.0 should get
> out of the door - i hope to become more active after that is done).
>
> But maybe we should deprecate all of those methods - i guess most/all of
> them can already be obtained by @Structure injections ...
> Spend some later 3.x releases refactoring internally (introduce them as
> services, accessed by the module implementation), and then remove the
> methods altogether in 4.0.
>
> ?
>
> /Kent
>
> Den 25-05-2017 kl. 08:17 skrev Niclas Hedhman:
> > Gang,
> >
> > since the UnitOfWork system is now Composites, shouldn't that mean that
> we
> > can clean up a lot of "special features" in there, and replace with
> > standard ways, such as Services instead of explicitly know SPIs reachable
> > from Module.
> >
> > In fact, all I am talking about is present in a single interface
> >
> > public interface ModuleSpi extends Module
> > {
> > EntityStore entityStore();
> >
> > IdentityGenerator identityGenerator();
> >
> > Serialization serialization();
> >
> > MetricsProvider metricsProvider();
> >
> > ValueTypeFactory valueTypeFactory();
> > }
> >
> >
> > And isn't that the same "should be provided by default" that we discussed
> > earlier?
> >
> > I think this shows that there is a fundamental issue, and we should
> simply
> > replace all of the above with services insread.
> >
> > WDYT?
> >
> >
> > Cheers
>
>
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
