polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent SĂžlvsten <kent.soelvs...@gmail.com>
Subject Re: API change suggestion
Date Thu, 03 Aug 2017 06:23:27 GMT
On Thu, Aug 3, 2017 at 2:50 AM, Niclas Hedhman <niclas@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?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message