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 Wed, 02 Aug 2017 18:41:25 GMT
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 <paulmerlin@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
>
>

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