You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2017/05/25 06:17:37 UTC
Removing cruft
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
Re: Removing cruft
Posted by Kent Sølvsten <ke...@gmail.com>.
ok.
I was thinking that with thinking of the items as services, then @Service
injection would possibly be more suitable than @Structure - so that could
be another reason to not rush stuff.
I have no access to a dev env right now - what is the valuetypefactory used
for before activation?
On Fri, May 26, 2017 at 6:07 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> I was doing a spike on this;
>
> * The ValueTypeFactory is different than the others, in that it is used
> prior to model activation and can not really be a service straight up as it
> is now.
>
> * The Activation semantics are getting in the way of the refactoring. In
> fact that warrants its own post-3.0 refactoring and "deep thought".
>
> So, let's not worry about this right now.
>
> Niclas
>
>
>
> On Thu, May 25, 2017 at 4:51 PM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
>
> > 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.soelvsten@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
> >
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
Re: Removing cruft
Posted by Paul Merlin <pa...@apache.org>.
Niclas Hedhman a écrit :
> * The ValueTypeFactory is different than the others, in that it is used
> prior to model activation and can not really be a service straight up as it
> is now.
Can't it be an imported service then?
Re: Removing cruft
Posted by Niclas Hedhman <ni...@hedhman.org>.
I was doing a spike on this;
* The ValueTypeFactory is different than the others, in that it is used
prior to model activation and can not really be a service straight up as it
is now.
* The Activation semantics are getting in the way of the refactoring. In
fact that warrants its own post-3.0 refactoring and "deep thought".
So, let's not worry about this right now.
Niclas
On Thu, May 25, 2017 at 4:51 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> 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 <ke...@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
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Removing cruft
Posted by Niclas Hedhman <ni...@hedhman.org>.
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 <ke...@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
Re: Removing cruft
Posted by Kent Sølvsten <ke...@gmail.com>.
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