Eclipse Community Forums: TMF (Xtext) » Why is MyDslFactory.eINSTANCE the common way to get a factory?

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 03:00

Eclipse User

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 03:02

Eclipse User

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

Re: Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1832969 is a reply to message #1832964]

Wed, 30 September 2020 04:01

Eclipse User

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.

Re: Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1832983 is a reply to message #1832969]

Wed, 30 September 2020 06:29

Eclipse User

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 09:17

Eclipse User

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.

Re: Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1833057 is a reply to message #1833003]

Thu, 01 October 2020 09:42

Eclipse User

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 10:07

Eclipse User

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 11:31

Eclipse User

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 11:50

Eclipse User

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

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:

-=] Back to Top [=-

Current Time: Tue Jul 01 15:30:24 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter