Re: [emf-dev] EMF interface instance access pattern

[Alexander Fedorov <alexander.fedorov@xxxxxxxxxx>]

Ed,

Thank you for answering!

The "stability" and "huge investment of effort" are killer arguments.
I'm looking for effective usage of EMF and trying different approaches 
in my projects. May be it will produce something valuable.
For today the outcome is not yet big to trouble the platform.

Regards,
AF

09.07.2019 20:02, Ed Merks пишет:
> Alexander,
>
> I'm sure there are many different possibilities.  One would need to 
> explore them in detail and apply them in practice to understand and 
> learn what really would work best. But that's a huge investment of 
> effort...
>
> And it's all kind of a moot point, because such changes are unlikely 
> to be possible in a purely binary compatible way.  One would need to 
> fork a new version that's incompatible with the existing version and 
> then start forking all the downstream community and infrastructure 
> based on that new improved approach.
>
> So in the end, there is opposite question:
>
>     What new possibilities would this enable that are not possible 
> with the status quo?
>
> I'm sure there exist such things, but I'm also sure quite that not 
> even a small fraction of the existing downstream code base would ever 
> migrate to such a new thing.  I.e., would the platform adopt it 
> immediately?  One of the key values of EMF is that it's stable, 
> reliable, and performant...
>
> Regards,
> Ed
>
>
> On 09.07.2019 18:40, Alexander Fedorov wrote:
> > > one could imagine doing many things quite differently
> > Yes, the example below was just to initiate the discussion.
> >
> > With the custom templates we can generate any code, and there is a 
> > public API to "substitute" or "decorate" registries, validators and 
> > mostly everything.
> >
> > The question is a bit different: how would you do it today, with all 
> > the power that OSGi and DI can give for it?
> >
> > Regards,
> > AF
> >
> > 09.07.2019 16:02, Ed Merks пишет:
> > > Those patterns appear in may places and others have complained:
> > >
> > >   https://bugs.eclipse.org/bugs/show_bug.cgi?id=329209
> > >
> > > Certainly with alternative service-based patterns and with things 
> > > like modern dependency injection frameworks, one could imagine doing 
> > > many things quite differently.
> > >
> > > On 09.07.2019 11:27, Alexander Fedorov wrote:
> > > > Hello,
> > > >
> > > > In EMF runtime and generated code there is a "interface instance 
> > > > access" pattern like:
> > > >
> > > >   public interface Registry
> > > >   {
> > > >     public static final Registry INSTANCE = new RegistryImpl();
> > > >   }
> > > >
> > > > It is good and stable. It works perfect.
> > > > However, it may look "too static" for OSGi-based approach where 
> > > > interface should not reference its implementation.
> > > >
> > > > How would you implement it today for OSGi-oriented architecture 
> > > > executed by 1.8+ Java?
> > > >
> > > > Thanks,
> > > > AF
> > > >
> > > > _______________________________________________
> > > > emf-dev mailing list
> > > > emf-dev@xxxxxxxxxxx
> > > > To change your delivery options, retrieve your password, or 
> > > > unsubscribe from this list, visit
> > > > https://www.eclipse.org/mailman/listinfo/emf-dev
> > > _______________________________________________
> > > emf-dev mailing list
> > > emf-dev@xxxxxxxxxxx
> > > To change your delivery options, retrieve your password, or 
> > > unsubscribe from this list, visit
> > > https://www.eclipse.org/mailman/listinfo/emf-dev
> >
> > _______________________________________________
> > emf-dev mailing list
> > emf-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or 
> > unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/emf-dev
> _______________________________________________
> emf-dev mailing list
> emf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/emf-dev