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 <kent.soelvs...@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 <paulmer...@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
