Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » importing native java source code(how does xtend do it)
importing native java source code [message #982588] Tue, 13 November 2012 03:51 Go to next message
Martin Baker is currently offline Martin Baker
Messages: 31
Registered: July 2009
Member
I want my language to be able to import all of these:


    * Other files containing my language.
    * native java source code (classes and interfaces)
    * java library code.


This should be possible, since xtend can do all this, so I decide to copy the way that xtend import works.

However, there is something I don't understand, when I look at the EMF model generated by xtend I see this:
<eClassifiers xsi:type="ecore:EClass" name="XtendImport">
    <eOperations name="isWildcard" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
    <eOperations name="getImportedTypeName" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="importedNamespace" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="static" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="extension" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
    <eStructuralFeatures xsi:type="ecore:EReference" name="importedType" eType="ecore:EClass platform:/resource/org.eclipse.xtext.common.types/model/JavaVMTypes.ecore#//JvmType"/>
  </eClassifiers>


Where do the eOperations "isWildcard" and "getImportedTypeName" come from? How do they get into the model? and where are they defined? I would appreciate any help in understanding this.

Martin
Re: importing native java source code [message #984127 is a reply to message #982588] Wed, 14 November 2012 07:23 Go to previous messageGo to next message
Jan Koehnlein is currently offline Jan Koehnlein
Messages: 656
Registered: July 2009
Senior Member
Xtend is a general purpose language with a lot of additional stuff.
You're likely to get lost when copying from there. What you want is to
reuse the Java part of it. You can do this by extending Xbase. I'd
suggest to have a look at the 7 Languages documentation:

http://www.eclipse.org/Xtext/7languages.html

To answer your question nevertheless: Xtend uses an imported Ecore model
(i.e. not derived from the grammar). So the operations have been added
manually.


Am 13.11.12 09:51, schrieb Martin Baker:
> I want my language to be able to import all of these:
>
>
> * Other files containing my language.
> * native java source code (classes and interfaces)
> * java library code.
>
> This should be possible, since xtend can do all this, so I decide to
> copy the way that xtend import works.
>
> However, there is something I don't understand, when I look at the EMF
> model generated by xtend I see this:
> <eClassifiers xsi:type="ecore:EClass" name="XtendImport">
> <eOperations name="isWildcard" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
> <eOperations name="getImportedTypeName" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute"
> name="importedNamespace" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="static"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="extension"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="importedType"
> eType="ecore:EClass
> platform:/resource/org.eclipse.xtext.common.types/model/JavaVMTypes.ecore#//JvmType"/>
>
> </eClassifiers>
>
> Where do the eOperations "isWildcard" and "getImportedTypeName" come
> from? How do they get into the model? and where are they defined? I
> would appreciate any help in understanding this.
>
> Martin


--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Re: importing native java source code [message #984329 is a reply to message #984127] Wed, 14 November 2012 10:56 Go to previous messageGo to next message
Martin Baker is currently offline Martin Baker
Messages: 31
Registered: July 2009
Member
*Author:* Jan
> Kohnlein *Date:* Wed, 14 November 2012 07:23
> Xtend is a general purpose language with a lot of additional stuff.
> You're likely to get lost when copying from there. What you want is to
> reuse the Java part of it. You can do this by extending Xbase. I'd
> suggest to have a look at the 7 Languages documentation:
>
> http://www.eclipse.org/Xtext/7languages.html
>
> To answer your question nevertheless: Xtend uses an imported Ecore model
> (i.e. not derived from the grammar). So the operations have been added
> manually.

Thanks very much for your reply, yes I did look at the 7 Languages. Most of them use the magic 'importedNamespace' name like this:
'import' importedNamespace=QualifiedNameWithWildcard;

If I understand this correctly this will let me use other files in my language, java library code, and it will see my own native classes/interfaces but not their internal structure. That is, It won't allow me to call methods on my own native java code.

The only exception is httprouting which uses:
'import' importedType=[ types::JvmType | QualifiedName];
plus a custom ImportedNamespaceScopeProvider
I assume this will let me call methods on my own native java code?

Since I want to do all of these then I guess I need to combine both types of import.

I will experiment with this, it does seem quite messy at the moment, the documentation hints that there are some improvements coming to this aspect of xbase so I will look forward to any improvements.

Thanks,

Martin
Re: importing native java source code [message #985738 is a reply to message #984329] Thu, 15 November 2012 16:42 Go to previous messageGo to next message
Jan Koehnlein is currently offline Jan Koehnlein
Messages: 656
Registered: July 2009
Senior Member
Hmmm, I don't get what you want.

In Xbase expressions, your DSL methods are callable if you have inferred
a JvmOperation from them (JvmModelInferrer). This is not so much
connected to imports as methods are usually called on objects, and
imports allow to refer to types with unqualified names. An exception to
this rule are static methods and extension methods.

Maybe you could give an example what you're trying to achieve?


Am 14.11.12 16:56, schrieb Martin Baker:
> *Author:* Jan
>> Kohnlein *Date:* Wed, 14 November 2012 07:23
>> Xtend is a general purpose language with a lot of additional stuff.
>> You're likely to get lost when copying from there. What you want is to
>> reuse the Java part of it. You can do this by extending Xbase. I'd
>> suggest to have a look at the 7 Languages documentation:
>>
>> http://www.eclipse.org/Xtext/7languages.html
>>
>> To answer your question nevertheless: Xtend uses an imported Ecore model
>> (i.e. not derived from the grammar). So the operations have been added
>> manually.
>
> Thanks very much for your reply, yes I did look at the 7 Languages. Most
> of them use the magic 'importedNamespace' name like this:
> 'import' importedNamespace=QualifiedNameWithWildcard;
>
> If I understand this correctly this will let me use other files in my
> language, java library code, and it will see my own native
> classes/interfaces but not their internal structure. That is, It won't
> allow me to call methods on my own native java code.
>
> The only exception is httprouting which uses:
> 'import' importedType=[ types::JvmType | QualifiedName];
> plus a custom ImportedNamespaceScopeProvider
> I assume this will let me call methods on my own native java code?
>
> Since I want to do all of these then I guess I need to combine both
> types of import.
>
> I will experiment with this, it does seem quite messy at the moment, the
> documentation hints that there are some improvements coming to this
> aspect of xbase so I will look forward to any improvements.
>
> Thanks,
>
> Martin


--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Re: importing native java source code [message #985822 is a reply to message #985738] Fri, 16 November 2012 04:47 Go to previous messageGo to next message
Martin Baker is currently offline Martin Baker
Messages: 31
Registered: July 2009
Member
> *Subject:* Re: importing native java source code *Author:* Jan
> Kohnlein *Date:* Thu, 15 November 2012 16:42
> Hmmm, I don't get what you want.
>
> In Xbase expressions, your DSL methods are callable if you have inferred
> a JvmOperation from them (JvmModelInferrer). This is not so much
> connected to imports as methods are usually called on objects, and
> imports allow to refer to types with unqualified names. An exception to
> this rule are static methods and extension methods.
>
> Maybe you could give an example what you're trying to achieve?

Yes, this code that I have listed below runs fine on xtend, but I want it to run in my own DSL (and it almost does, but not quite) the line:
rep1=newArrayList(te.getRep())

causes the error
Couldn't resolve reference to JvmIdentifiableElement 'getRep'.

The 'interfaces' directory contains native java interfaces and enums, the package 'euc' contains other classes in my language.

The approach that I have taken is to borrow parts of the xtend grammar to create a sort of 'xtend lite' without the richstring, annotations and many other features but basically functional, which I can add to later to give some specific functionality that I need. I realise, from what you said recently, that this in not the approach that you would have recommended. However, I have come this far and it seems very close to working, if I could just solve these problems.

My grammar is here
My ImportedNamespaceScopeProvider is here
My JvmModelInferrer is here
All other files are left with their default values as generated by mwe2.

Here is the code which was originally .xtend but is now in my dsl language (.euclid)
package euc
import interfaces.Field
import interfaces.Domain
import interfaces.TYPE
import java.util.List

public class Vect implements Domain {
	
	val Field te;
    val int dimen;
	var TypeExpression[] rep1
	var TypeExpression rep
    
	new(Field t,int d){
		te=t
		dimen =d
	    rep1=newArrayList(te.getRep())
	    rep=new TypeExpression(TYPE::RECORD,rep1);
	}

    override TypeExpression getRep(){
    	rep
    }
    
    /**
     * constructs a compound expression from a list of expressions
     * representing the elements.
     * 
     * How can we ensure these elements are of type 'te' which is 'Field'
     */
	def Expression vect(Expression[] xs){
		return new Expression(xs,this);
	}

	def Expression operator_plus(Expression a,Expression b){
	  var Expression[] elements = null;
	  try {
	  	for(int i: 0..(dimen-1)) {
			var Expression element = te.operator_plus(a.elt(i),b.elt(i))
			if (elements == null) elements = newArrayList(element)
			else elements.add(element)
		}
	  } catch (Exception e) {
	      println("Vect.add error="+e)
	  }
	  return new Expression(elements,this);
	}

	def Expression operator_multiply(Expression a,Expression b){
		return new Expression(a.intValue*b.intValue,this);
	}

	def Expression[] coerce(Expression a){
		return a.arrayValue;
	}
}

Re: importing native java source code [message #985932 is a reply to message #985822] Fri, 16 November 2012 12:55 Go to previous messageGo to next message
Jan Koehnlein is currently offline Jan Koehnlein
Messages: 656
Registered: July 2009
Senior Member
I don't know the exact semantics of your language, but as I get it, 'te'
is of type 'Field', while 'getRep()' is defined in the class 'Vect'.
This would neither work in Xtend nor Java.


Am 16.11.12 10:47, schrieb Martin Baker:
>> *Subject:* Re: importing native java source code *Author:* Jan
>> Kohnlein *Date:* Thu, 15 November 2012 16:42
>> Hmmm, I don't get what you want.
>>
>> In Xbase expressions, your DSL methods are callable if you have inferred
>> a JvmOperation from them (JvmModelInferrer). This is not so much
>> connected to imports as methods are usually called on objects, and
>> imports allow to refer to types with unqualified names. An exception to
>> this rule are static methods and extension methods.
>>
>> Maybe you could give an example what you're trying to achieve?
>
> Yes, this code that I have listed below runs fine on xtend, but I want
> it to run in my own DSL (and it almost does, but not quite) the line:
> rep1=newArrayList(te.getRep())
> causes the error
> Couldn't resolve reference to JvmIdentifiableElement 'getRep'.
> The 'interfaces' directory contains native java interfaces and enums,
> the package 'euc' contains other classes in my language.
>
> The approach that I have taken is to borrow parts of the xtend grammar
> to create a sort of 'xtend lite' without the richstring, annotations and
> many other features but basically functional, which I can add to later
> to give some specific functionality that I need. I realise, from what
> you said recently, that this in not the approach that you would have
> recommended. However, I have come this far and it seems very close to
> working, if I could just solve these problems.
>
> My grammar is
> https://github.com/martinbaker/euclideanspace/blob/master/com.euclideanspace.euclid/src/com/euclideanspace/euclid/Editor.xtext
>
> My ImportedNamespaceScopeProvider is
> https://github.com/martinbaker/euclideanspace/blob/master/com.euclideanspace.euclid/src/com/euclideanspace/euclid/scoping/EditorImportedNamespaceScopeProvider.java
>
> My JvmModelInferrer is
> https://github.com/martinbaker/euclideanspace/blob/master/com.euclideanspace.euclid/src/com/euclideanspace/euclid/jvmmodel/EditorJvmModelInferrer.xtend
>
> All other files are left with their default values as generated by mwe2.
>
> Here is the code which was originally .xtend but is now in my dsl
> language (.euclid)
> package euc
> import interfaces.Field
> import interfaces.Domain
> import interfaces.TYPE
> import java.util.List
>
> public class Vect implements Domain {
>
> val Field te;
> val int dimen;
> var TypeExpression[] rep1
> var TypeExpression rep
> new(Field t,int d){
> te=t
> dimen =d
> rep1=newArrayList(te.getRep())
> rep=new TypeExpression(TYPE::RECORD,rep1);
> }
>
> override TypeExpression getRep(){
> rep
> }
> /**
> * constructs a compound expression from a list of expressions
> * representing the elements.
> * * How can we ensure these elements are of type 'te' which is 'Field'
> */
> def Expression vect(Expression[] xs){
> return new Expression(xs,this);
> }
>
> def Expression operator_plus(Expression a,Expression b){
> var Expression[] elements = null;
> try {
> for(int i: 0..(dimen-1)) {
> var Expression element = te.operator_plus(a.elt(i),b.elt(i))
> if (elements == null) elements = newArrayList(element)
> else elements.add(element)
> }
> } catch (Exception e) {
> println("Vect.add error="+e)
> }
> return new Expression(elements,this);
> }
>
> def Expression operator_multiply(Expression a,Expression b){
> return new Expression(a.intValue*b.intValue,this);
> }
>
> def Expression[] coerce(Expression a){
> return a.arrayValue;
> }
> }
>
>


--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Re: importing native java source code [message #985944 is a reply to message #985932] Fri, 16 November 2012 14:21 Go to previous message
Martin Baker is currently offline Martin Baker
Messages: 31
Registered: July 2009
Member
> *Subject:* Re: importing native java source code *Author:* Jan
> Kohnlein *Date:* Fri, 16 November 2012 12:55
> I don't know the exact semantics of your language, but as I get it, 'te'
> is of type 'Field', while 'getRep()' is defined in the class 'Vect'.
> This would neither work in Xtend nor Java.

The signature for getRep() is declared in the interfaces 'Domain' and 'Field' which is implemented by various classes.

This code works fine when I change the file types from .euclid to .xtend (but only if I install bleeding edge versions of xtext/xbase which I don't have at the moment due to the conflicts this causes).

Do you think the problem in my DSL could also be fixed in bleeding edge xbase? If so is there some workaround as moving to bleeding edge seems to cause various conflicts with different versions.

I could probably avoid using native java interfaces if I could define interfaces in my DSL (I notice that xbase supports interfaces, unlike xtend). Do you think that's the way for me to go?

Would it help for me to upload my runtime code to github in addition to the DSL code?

Martin
Previous Topic:Integrate content assistance in properties view of GMF editor (XtextSourceViewer)
Next Topic:resolving cross-references
Goto Forum:
  


Current Time: Sat Aug 30 10:22:43 EDT 2014

Powered by FUDForum. Page generated in 0.03573 seconds