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?)

Show: Today's Messages :: Show Polls :: Message Navigator

Why is MyDslFactory.eINSTANCE the common way to get a factory? [message #1832962]

Wed, 30 September 2020 07:00

Jan Hermes

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

Report message to a moderator

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

Christian Dietrich

Messages: 14664
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

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

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

Ed Merks

Messages: 33133
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/

Report message to a moderator

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

Jan Hermes

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

Report message to a moderator

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

Ed Merks

Messages: 33133
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/

Report message to a moderator

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

Jan Hermes

Messages: 27
Registered: September 2020

Junior Member

Ok thanks, I will check it out and report back :)

Report message to a moderator

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

Ed Willink

Messages: 7655
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

Report message to a moderator

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

Jan Hermes

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

Report message to a moderator

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

Christian Dietrich

Messages: 14664
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

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

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 [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 09:41:34 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter