Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Why is MyDslFactory.eINSTANCE the common way to get a factory?(Is there a reason why tutorials and books don't use guice-injection for instantiation of factories?)
Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1832962] Wed, 30 September 2020 07:00 Go to next message
Jan Hermes is currently offline Jan HermesFriend
Messages: 27
Registered: September 2020
Junior Member
Hello Community,

I was wondering if there is a reason why in the tutorials and books I have seen so far the factory for creating EObjects of the model is always instantiated by using
static val factory = MyDslFactory.eINSTANCE

But this prohibits future extension of the factory that I use in my code.

Is there any reason why I should not implement a binding (possible annotated with @SingletonBinding) in the RuntimeModule that instantiates the desired factory?

I mean something like this:

class PslpRuntimeModule extends AbstractPslpRuntimeModule {

	def MyDslFactory bindMyDslFactory() {
		val factory = MyDslFactory.eINSTANCE
		return new MyDslDecoratingFactory(factory)
	}
}


Now at the desired places I could just use the factory by injecting it via
@Inject MyDslFactory factory


Or is there a more elegant (or canonical) way of having the same flexibility?

Regards
Jan Hermes
Re: Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1832964 is a reply to message #1832962] Wed, 30 September 2020 07:02 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 13976
Registered: July 2009
Senior Member
i dont think there is a reason
only 20% of user might make use of it.
and 1% of these have the need to decorate it



Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/it-services/methods-and-tools/xtext
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1832969 is a reply to message #1832964] Wed, 30 September 2020 08:01 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31900
Registered: July 2009
Senior Member
There can be only one EPackage and given that org.eclipse.emf.ecore.EPackage.getEFactoryInstance() and org.eclipse.emf.ecore.EFactory.getEPackage() are opposites, there is only one factory. Also, given an EObject x, x.eClass().getEPackage().getEFactoryInstance() can return only the one factory. Your binding will not help replace that and will it not be generally used throughout the frameworks.

There is an factory_override extension point that allows a single overriding replacement of the default generated factory; that would still be accessible via XyzFactory.eINSTANCE.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1832983 is a reply to message #1832969] Wed, 30 September 2020 10:29 Go to previous messageGo to next message
Jan Hermes is currently offline Jan HermesFriend
Messages: 27
Registered: September 2020
Junior Member
Hello,

thank you both for the answers.

@Ed Merks:
Ok thats actually what I've been searching for... Would this "factory_override" then essentially be setting the factory into the registry, so that when "MyDslFactory.eINSTANCE" is called, "MyDslFactoryImpl.init()" would take the factory from the registry instead of generating it newly?

I'm talking about this bit of generated code in MyDslFactoryImpl:

  public static MyDslFactory init()
  {
    try
    {
      MyDslFactory theMyDslFactory = (MyDslFactory)EPackage.Registry.INSTANCE.getEFactory(MyDslPackage.eNS_URI);
      if (theMyDslFactory != null)
      {
        return theMyDslFactory;
      }
    }
    catch (Exception exception)
    {
      EcorePlugin.INSTANCE.log(exception);
    }
    return new MyDslFactoryImpl();
  }


I just couldn't find the factory_override extension point.

Regards
Jan Hermes
Re: Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1833003 is a reply to message #1832983] Wed, 30 September 2020 13:17 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31900
Registered: July 2009
Senior Member
It looks like this:
   <extension
         point="org.eclipse.emf.ecore.factory_override">
      <factory
            class=a.b.c.MyFactoryImpl"
            uri="...">
      </factory>
   </extension>
The uri="..." should be one for which there is an org.eclipse.emf.ecore.generated_package elsewhere, and the MyFactoryImpl typically extends the generated factory (and of course must implement the MyFactory interface.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1833057 is a reply to message #1833003] Thu, 01 October 2020 13:42 Go to previous messageGo to next message
Jan Hermes is currently offline Jan HermesFriend
Messages: 27
Registered: September 2020
Junior Member
Ok thanks, I will check it out and report back :)
Re: Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1833059 is a reply to message #1833057] Thu, 01 October 2020 14:07 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7162
Registered: July 2009
Senior Member
Hi

To answer your original question, I think the reason is prevailing practice.

Dependency injection did not exist, or at least was not fashionable at the time when EMF was developed. You are using protocols/APIs that were appropriate 20 years ago.

Now, if EMF were redeveloped, an approach that exploits dependency injection might be adopted, but I'm not sure how. It might be nice for EPackage / EFactory / Resource / ResourceSet to be injected but certainly not EObject. I'm not convinced that DI would solve the existing EMF's / My / Your ResourceSetImpl battle.

I've only used dependency injection within the context of Xtext where sometimes it seems helpful but other times a real pain. We considered adopting DI for OCL and IIRC couldn't really see significant advantages, just a lot of rework and study.

I suspect that it would need a real DI expert to demonstrate an exemplary architecture for it to be considered. That demonstrated, a DI overlay for EMF might be possible. For now the DSLStandaloneSetup.injector provides a gateway.

Regards

Ed Willink
Re: Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1833063 is a reply to message #1833059] Thu, 01 October 2020 15:31 Go to previous messageGo to next message
Jan Hermes is currently offline Jan HermesFriend
Messages: 27
Registered: September 2020
Junior Member
Hi

Yes of course you are right, I'm just a friend of using everything the same way in one project.

E.g. when I use DI for some things with Singleton-Injections and Instance-Injections and so on, I would like to do this same procedure in the whole project for every task. And not suddenly change to a static value in a class that I instantiate via "eINSTANCE".

There were even situations where I injected the factory at the top of the class without even realizing, that the factory is the one thing that I do not inject but instantiate via a static value reference, which lead to errors because guice tried to inject the uninitiated factory.

The robustness for change is of course another benefit, but if there is an extension point for that which is easily accessible I'm also happy with that.

Regarding the extension point:

The language fragments of XText create this structure for emf-generation and writes a lot of <extension ... point=.... > into the file builder.. But I couldn't see any high-level access for adding a new extension point that the fragment will write into the file.
Do I need to write my own generator fragment for that?

Regards
Jan Hermes
Re: Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1833064 is a reply to message #1833063] Thu, 01 October 2020 15:50 Go to previous message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 13976
Registered: July 2009
Senior Member
Xtext can perfectly handle merging of plugin xmls and if it cant it will generate plugin.xml_gen so that you can merge manually. so there is no need for a own fragment

Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/it-services/methods-and-tools/xtext
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Previous Topic:Is there a workaround for using Guice 4.x with Xtext 2.21 ?
Next Topic:Integrate Kotlin src-dependencies into the workflow with gradle
Goto Forum:
  


Current Time: Mon Jun 14 22:28:26 GMT 2021

Powered by FUDForum. Page generated in 0.07570 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top