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/06/06 07:42:48 UTC
API change suggestion
I have found a small annoying discrepancy;
interface PropertyDescriptor
interface AssociationDescriptor
shares a whole bunch of methods, which are in fact the same thing;
QualifiedName qualifiedName();
Type type();
AccessibleObject accessor();
boolean isImmutable();
boolean queryable();
And in the Jooq ES, that I am working on, a great deal of duplication code
can be avoided if they shared a common super type.
I can't think of a good name for such super type, as StateDescriptor
already exists, which is an Composite level construct. We never really have
the equivalent of "fragments" for the
property/association/manyassociation/namedassociation concepts, as we
should have.
We could call it StateDescriptor and rename the current StateDescriptor,
which when I look at it doesn't have a totally solid name matching its
purpose.
WDYAT?
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: API change suggestion
Posted by Kent Sølvsten <ke...@gmail.com>.
thanks for the explanation.
I was actually guessing that it was related to the configuration of
services, so now i learned something new!
/Kent
On Thu, Aug 3, 2017 at 2:57 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Thu, Aug 3, 2017 at 2:41 AM, Kent Sølvsten <ke...@gmail.com>
> wrote:
>
> >
> > Another (unrelated) thought looking at this API : What is the meaning of
> > properties for a service or a transient (ServiceDescriptor extends
> > StatefulCompositeDescriptor)?
> >
>
> Well, they still have "state" even if that state is not persistable.
>
> For transients, one primary function would be to provide public Property
> access, rather than a setter/getter culture, i.e. I might want to have a
> struct-like data type.
>
> One usecase for services (for all) is that "state" is common/shared across
> all fragments within the Composite, unlike member fields. This is rather
> useful, even for services, to have a shared state within the composite,
> especially when these are private and we don't want to expose such state to
> the outside world.
>
> So, I don't think there is anything wrong here, perhaps other than that
> "state" has come to mean "persisted state" in too much of the documentation
> and discussion.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
Re: API change suggestion
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Aug 3, 2017 at 2:41 AM, Kent Sølvsten <ke...@gmail.com>
wrote:
>
> Another (unrelated) thought looking at this API : What is the meaning of
> properties for a service or a transient (ServiceDescriptor extends
> StatefulCompositeDescriptor)?
>
Well, they still have "state" even if that state is not persistable.
For transients, one primary function would be to provide public Property
access, rather than a setter/getter culture, i.e. I might want to have a
struct-like data type.
One usecase for services (for all) is that "state" is common/shared across
all fragments within the Composite, unlike member fields. This is rather
useful, even for services, to have a shared state within the composite,
especially when these are private and we don't want to expose such state to
the outside world.
So, I don't think there is anything wrong here, perhaps other than that
"state" has come to mean "persisted state" in too much of the documentation
and discussion.
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: API change suggestion
Posted by Kent Sølvsten <ke...@gmail.com>.
On Thu, Aug 3, 2017 at 2:50 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Kent,
> You may have a point (not sure yet), but I don't grok the "shared
> description" part of it. Shared with what? The Descriptors are already
> "shared" across instances.
>
>
The "shared" was really awful naming. I was thinking of shared between
types, not instances.
> Let's look at this individually instead;
>
>
> QualifiedName qualifiedName();
>
> Is it not reasonable that a Descriptor has a qualifiedName() and that this
> sits in a common "Descriptor" supertype?
>
> Type type();
>
> Is it not reasonable that a Descriptor has a type() since they all are
> generics.
>
> AccessibleObject accessor();
>
> Here is a kind of implementation detail, but it already is in each of the
> Descriptor interfaces.
>
I kind of agree. Need to think about a better API suggestion.
Maybe something like
EntityDescriptor {
PropertiesDescriptor properties();
AssociationsDescriptor associations();
}
and then reinterpret StateDescriptor as the part common among properties
and associations as you hinted
?
>
>
> boolean isImmutable();
> boolean queryable();
>
> For these two, I think your point is much more valid. This is about
> "feature of" or "capability of" the Property/Association that the
> Descriptor refers to. And maybe here is what we should look at a design
> change eventually. Maybe something like;
>
>
> <T extends Capability> T capability( T capabilityType );
>
> and that will end up as;
>
> Immutability i = descriptor.capability( Immutability.class );
> if( i.isImmutable() ){ }
>
> Querability q = descriptor.capability( Queryability.class );
> if( q.isQueryable() ) { }
>
> And maybe, just maybe, that this can be made fully extendable so that SPIs
> can become more independent on support within the Core Runtime. Say that
> the Metrics SPI want to add;
>
> Monitorable m = descriptor.capability Monitorable.class );
> boolean isMonitored = m.isEnabled();
> String channelName = m.channelName();
>
>
I really, really, really like the capability idea! Not quite sure which
parts could be generic "capabilities". We could probably keep the existing
explicit API as syntactical sugar giving users both options, but think
twice before adding new methods. Requires some more thought ...
>
> WDYT?
>
Re: API change suggestion
Posted by Niclas Hedhman <ni...@hedhman.org>.
Kent,
You may have a point (not sure yet), but I don't grok the "shared
description" part of it. Shared with what? The Descriptors are already
"shared" across instances.
Let's look at this individually instead;
QualifiedName qualifiedName();
Is it not reasonable that a Descriptor has a qualifiedName() and that this
sits in a common "Descriptor" supertype?
Type type();
Is it not reasonable that a Descriptor has a type() since they all are
generics.
AccessibleObject accessor();
Here is a kind of implementation detail, but it already is in each of the
Descriptor interfaces.
boolean isImmutable();
boolean queryable();
For these two, I think your point is much more valid. This is about
"feature of" or "capability of" the Property/Association that the
Descriptor refers to. And maybe here is what we should look at a design
change eventually. Maybe something like;
<T extends Capability> T capability( T capabilityType );
and that will end up as;
Immutability i = descriptor.capability( Immutability.class );
if( i.isImmutable() ){ }
Querability q = descriptor.capability( Queryability.class );
if( q.isQueryable() ) { }
And maybe, just maybe, that this can be made fully extendable so that SPIs
can become more independent on support within the Core Runtime. Say that
the Metrics SPI want to add;
Monitorable m = descriptor.capability Monitorable.class );
boolean isMonitored = m.isEnabled();
String channelName = m.channelName();
WDYT?
On Thu, Aug 3, 2017 at 2:41 AM, Kent Sølvsten <ke...@gmail.com>
wrote:
> Not sure i like the idea of the interfaces inheriting a common parent
> interface.
>
> What about restricting the hierarchy to the implementation?
>
> public class PropertyModel implements PropertyDescriptor, PersistentElement
> {
> ...
> }
>
>
> public class AssociationModel implements AssociationDescriptor,
> PersistentElement {
> ...
> }
>
> (they could if desired extend a common base class)
>
> and then add methods to the SPI to "cast"
>
> public interface PolygeneSPI ... {
> PersistentElement sharedDescriptionFor(PropertyDescriptor property);
> PersistentElement sharedDescriptionFor(AssociationDescriptor property);
> }
>
> That should allow extensions to reuse "shared methods" and we avoid
> exposing the shared stuff to application code, leaving us with freedom to
> refactor later.
>
> Another (unrelated) thought looking at this API : What is the meaning of
> properties for a service or a transient (ServiceDescriptor extends
> StatefulCompositeDescriptor)?
>
> WDYT?
>
> /Kent
>
>
>
>
> On Wed, Aug 2, 2017 at 1:18 PM, Paul Merlin <pa...@apache.org> wrote:
>
> > Niclas Hedhman a écrit :
> > > I have found a small annoying discrepancy;
> > >
> > > interface PropertyDescriptor
> > > interface AssociationDescriptor
> > >
> > > shares a whole bunch of methods, which are in fact the same thing;
> > >
> > >
> > > QualifiedName qualifiedName();
> > >
> > > Type type();
> > >
> > > AccessibleObject accessor();
> > >
> > > boolean isImmutable();
> > >
> > > boolean queryable();
> > >
> > >
> > > And in the Jooq ES, that I am working on, a great deal of duplication
> > code
> > > can be avoided if they shared a common super type.
> > >
> > > I can't think of a good name for such super type, as StateDescriptor
> > > already exists, which is an Composite level construct. We never really
> > have
> > > the equivalent of "fragments" for the
> > > property/association/manyassociation/namedassociation concepts, as we
> > > should have.
> > >
> > > We could call it StateDescriptor and rename the current
> StateDescriptor,
> > > which when I look at it doesn't have a totally solid name matching its
> > > purpose.
> > >
> > > WDYAT?
> >
> > I stumbled upon this unfortunate modeling that leads to code duplication
> > in the past. Did you end up changing this?
> >
> > If not then we may have to wait for 4.0 as this would be an API breaking
> > change, right? In that case we should create an issue and assign it to
> > 4.0 already so we don't forget.
> >
> > Cheers
> >
> >
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: API change suggestion
Posted by Kent Sølvsten <ke...@gmail.com>.
Not sure i like the idea of the interfaces inheriting a common parent
interface.
What about restricting the hierarchy to the implementation?
public class PropertyModel implements PropertyDescriptor, PersistentElement
{
...
}
public class AssociationModel implements AssociationDescriptor,
PersistentElement {
...
}
(they could if desired extend a common base class)
and then add methods to the SPI to "cast"
public interface PolygeneSPI ... {
PersistentElement sharedDescriptionFor(PropertyDescriptor property);
PersistentElement sharedDescriptionFor(AssociationDescriptor property);
}
That should allow extensions to reuse "shared methods" and we avoid
exposing the shared stuff to application code, leaving us with freedom to
refactor later.
Another (unrelated) thought looking at this API : What is the meaning of
properties for a service or a transient (ServiceDescriptor extends
StatefulCompositeDescriptor)?
WDYT?
/Kent
On Wed, Aug 2, 2017 at 1:18 PM, Paul Merlin <pa...@apache.org> wrote:
> Niclas Hedhman a écrit :
> > I have found a small annoying discrepancy;
> >
> > interface PropertyDescriptor
> > interface AssociationDescriptor
> >
> > shares a whole bunch of methods, which are in fact the same thing;
> >
> >
> > QualifiedName qualifiedName();
> >
> > Type type();
> >
> > AccessibleObject accessor();
> >
> > boolean isImmutable();
> >
> > boolean queryable();
> >
> >
> > And in the Jooq ES, that I am working on, a great deal of duplication
> code
> > can be avoided if they shared a common super type.
> >
> > I can't think of a good name for such super type, as StateDescriptor
> > already exists, which is an Composite level construct. We never really
> have
> > the equivalent of "fragments" for the
> > property/association/manyassociation/namedassociation concepts, as we
> > should have.
> >
> > We could call it StateDescriptor and rename the current StateDescriptor,
> > which when I look at it doesn't have a totally solid name matching its
> > purpose.
> >
> > WDYAT?
>
> I stumbled upon this unfortunate modeling that leads to code duplication
> in the past. Did you end up changing this?
>
> If not then we may have to wait for 4.0 as this would be an API breaking
> change, right? In that case we should create an issue and assign it to
> 4.0 already so we don't forget.
>
> Cheers
>
>
Re: API change suggestion
Posted by Paul Merlin <pa...@apache.org>.
Niclas Hedhman a écrit :
> I have found a small annoying discrepancy;
>
> interface PropertyDescriptor
> interface AssociationDescriptor
>
> shares a whole bunch of methods, which are in fact the same thing;
>
>
> QualifiedName qualifiedName();
>
> Type type();
>
> AccessibleObject accessor();
>
> boolean isImmutable();
>
> boolean queryable();
>
>
> And in the Jooq ES, that I am working on, a great deal of duplication code
> can be avoided if they shared a common super type.
>
> I can't think of a good name for such super type, as StateDescriptor
> already exists, which is an Composite level construct. We never really have
> the equivalent of "fragments" for the
> property/association/manyassociation/namedassociation concepts, as we
> should have.
>
> We could call it StateDescriptor and rename the current StateDescriptor,
> which when I look at it doesn't have a totally solid name matching its
> purpose.
>
> WDYAT?
I stumbled upon this unfortunate modeling that leads to code duplication
in the past. Did you end up changing this?
If not then we may have to wait for 4.0 as this would be an API breaking
change, right? In that case we should create an issue and assign it to
4.0 already so we don't forget.
Cheers