Home » Modeling » TMF (Xtext) » Getting started: predefined set of simple types
| Getting started: predefined set of simple types [message #63184] |
Mon, 27 July 2009 11:59  |
Eclipse User |
|
|
|
Originally posted by: panajotes.gmx.de
Hi,
To become more familiar with the Xtext grammar syntax I started to play
around with your "getting started" example of Entities and their Properties.
There is only one small thing I want to change but horribly fail in doing
so. Instead of letting the user define SimpleTypes in the model with the
keyword "type", I want to predefine the set of simple types in my grammar.
So if the user wants to create a new property the code-assistance feature of
the generated editor should not only provide the names of already created
entities but also the predefined types like e.g. String, Integer...
All approaches of using enums or predefing the name attribute, like below,
failed.
Property:
name=ID ":" type=[Type]";";
Type:
SimpleType | Entity;
SimpleType:
name=("String" | "Int" | "Boolean");
Do you have a hint for me?
Thanks and Regards,
Thomas.
|
|
| |
| Re: Getting started: predefined set of simple types [message #345339 is a reply to message #63210] |
Tue, 28 July 2009 03:05  |
| Eclipse User |
|
|
|
Originally posted by: panajotes.gmx.de
Hi Sebastian,
thanks again for your help.
I tried the alternative type assignment too but what I really want would be
something like this:
Property:
name=ID ":" type=([Type] | "String" | "Int");
The problem with that seems to be, that no type can be infered which matches
all three alternatives, right? This it at least what I understand from the
error message. But actually this is not clear for me, because the value of
the cross-reference as well as "String" and "Int" should be of type STRING.
Concerning the best practices thing. So what would you suggest if I want to
model a language like Java for example? There you have a list of predefined
simple types, too. Isn't modeling them in the grammar instead of code, like
you would have to when using the scope provider approach, the more
convenient way?
Regards,
Thomas.
"Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
news:h4kjlb$bpj$1@build.eclipse.org...
> Hi Thomas,
>
> to provide some default values for simple types you can either try to
> implement a scope provider that provides access to your built in types or
> your can try to use an alternative for the type assignment in your
> property.
>
> Property:
> name=ID ":" (type=[Type] | simpleType=("String"|"Int"));
>
> Please not that it not considered best practice to hard code the data
> types in your language.
>
> Regards
> Sebastian
>
> --
> Need professional support for Eclipse Modeling?
> Go visit: http://xtext.itemis.com
>
> Am 27.07.2009 17:59 Uhr, schrieb Thomas:
>> Hi,
>>
>> To become more familiar with the Xtext grammar syntax I started to play
>> around with your "getting started" example of Entities and their
>> Properties. There is only one small thing I want to change but horribly
>> fail in doing so. Instead of letting the user define SimpleTypes in the
>> model with the keyword "type", I want to predefine the set of simple
>> types in my grammar. So if the user wants to create a new property the
>> code-assistance feature of the generated editor should not only provide
>> the names of already created entities but also the predefined types like
>> e.g. String, Integer...
>>
>> All approaches of using enums or predefing the name attribute, like
>> below, failed.
>>
>> Property:
>> name=ID ":" type=[Type]";";
>>
>> Type:
>> SimpleType | Entity;
>>
>> SimpleType:
>> name=("String" | "Int" | "Boolean");
>>
>> Do you have a hint for me?
>>
>> Thanks and Regards,
>> Thomas.
|
|
|
| Re: Getting started: predefined set of simple types [message #347895 is a reply to message #345339] |
Tue, 28 July 2009 04:12 |
| Eclipse User |
|
|
|
Hi Thomas,
please see below.
Am 28.07.2009 9:05 Uhr, schrieb Thomas:
> Hi Sebastian,
>
> thanks again for your help.
>
> I tried the alternative type assignment too but what I really want would
> be something like this:
>
> Property:
> name=ID ":" type=([Type] | "String" | "Int");
>
> The problem with that seems to be, that no type can be infered which
> matches all three alternatives, right? This it at least what I
> understand from the error message. But actually this is not clear for
> me, because the value of the cross-reference as well as "String" and
> "Int" should be of type STRING.
The error message is right. While "String" and "Int" are keywords (from
a grammar's perspective) they will be assigned as ecore::EString to the
attribute type of the eClass Property. The cross reference [Type] on the
other hand is a yourmetamodel::Type and not an EString. Type and EString
are not compatible because the first is an EClass while the latter is an
EDataType which leads to the fact, that Property.type must be both an
EReference and an EAttribute.
>
> Concerning the best practices thing. So what would you suggest if I want
> to model a language like Java for example? There you have a list of
> predefined simple types, too. Isn't modeling them in the grammar instead
> of code, like you would have to when using the scope provider approach,
> the more convenient way?
>
Well Java is not designed in a best practice way in each and every
corner case. Have a look at Smalltalk for a better example :-)
A custom implementation of the scope provider may introduce an implicit
import of a resource called AllDatatypes.dsl which contains the simple
types as String, Int etc. This would model them in the DSL and neither
in the grammar directly nor in code.
Hope that helps,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
> Regards,
> Thomas.
>
> "Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
> news:h4kjlb$bpj$1@build.eclipse.org...
>> Hi Thomas,
>>
>> to provide some default values for simple types you can either try to
>> implement a scope provider that provides access to your built in types
>> or your can try to use an alternative for the type assignment in your
>> property.
>>
>> Property:
>> name=ID ":" (type=[Type] | simpleType=("String"|"Int"));
>>
>> Please not that it not considered best practice to hard code the data
>> types in your language.
>>
>> Regards
>> Sebastian
>>
>> --
>> Need professional support for Eclipse Modeling?
>> Go visit: http://xtext.itemis.com
>>
>> Am 27.07.2009 17:59 Uhr, schrieb Thomas:
>>> Hi,
>>>
>>> To become more familiar with the Xtext grammar syntax I started to play
>>> around with your "getting started" example of Entities and their
>>> Properties. There is only one small thing I want to change but horribly
>>> fail in doing so. Instead of letting the user define SimpleTypes in the
>>> model with the keyword "type", I want to predefine the set of simple
>>> types in my grammar. So if the user wants to create a new property the
>>> code-assistance feature of the generated editor should not only provide
>>> the names of already created entities but also the predefined types like
>>> e.g. String, Integer...
>>>
>>> All approaches of using enums or predefing the name attribute, like
>>> below, failed.
>>>
>>> Property:
>>> name=ID ":" type=[Type]";";
>>>
>>> Type:
>>> SimpleType | Entity;
>>>
>>> SimpleType:
>>> name=("String" | "Int" | "Boolean");
>>>
>>> Do you have a hint for me?
>>>
>>> Thanks and Regards,
>>> Thomas.
>
|
|
|
| Re: Getting started: predefined set of simple types [message #348950 is a reply to message #347895] |
Tue, 28 July 2009 04:41 |
| Eclipse User |
|
|
|
Originally posted by: panajotes.gmx.de
Hi Sebastian,
see comments below.
"Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
news:h4mbt7$se0$1@build.eclipse.org...
> Hi Thomas,
>
> please see below.
>
> Am 28.07.2009 9:05 Uhr, schrieb Thomas:
>> Hi Sebastian,
>>
>> thanks again for your help.
>>
>> I tried the alternative type assignment too but what I really want would
>> be something like this:
>>
>> Property:
>> name=ID ":" type=([Type] | "String" | "Int");
>>
>> The problem with that seems to be, that no type can be infered which
>> matches all three alternatives, right? This it at least what I
>> understand from the error message. But actually this is not clear for
>> me, because the value of the cross-reference as well as "String" and
>> "Int" should be of type STRING.
>
> The error message is right. While "String" and "Int" are keywords (from a
> grammar's perspective) they will be assigned as ecore::EString to the
> attribute type of the eClass Property. The cross reference [Type] on the
> other hand is a yourmetamodel::Type and not an EString. Type and EString
> are not compatible because the first is an EClass while the latter is an
> EDataType which leads to the fact, that Property.type must be both an
> EReference and an EAttribute.
Thanks for the detailed description. This is clear now :-)
>> Concerning the best practices thing. So what would you suggest if I want
>> to model a language like Java for example? There you have a list of
>> predefined simple types, too. Isn't modeling them in the grammar instead
>> of code, like you would have to when using the scope provider approach,
>> the more convenient way?
>>
>
> Well Java is not designed in a best practice way in each and every corner
> case. Have a look at Smalltalk for a better example :-)
> A custom implementation of the scope provider may introduce an implicit
> import of a resource called AllDatatypes.dsl which contains the simple
> types as String, Int etc. This would model them in the DSL and neither in
> the grammar directly nor in code.
Sounds like a good compromise. I will try this.
Thanks again and regards,
Thomas.
> Hope that helps,
> Sebastian
>
>
> --
> Need professional support for Eclipse Modeling?
> Go visit: http://xtext.itemis.com
>
>> Regards,
>> Thomas.
>>
>> "Sebastian Zarnekow" <Sebastian.Zarnekow@itemis.de> wrote in message
>> news:h4kjlb$bpj$1@build.eclipse.org...
>>> Hi Thomas,
>>>
>>> to provide some default values for simple types you can either try to
>>> implement a scope provider that provides access to your built in types
>>> or your can try to use an alternative for the type assignment in your
>>> property.
>>>
>>> Property:
>>> name=ID ":" (type=[Type] | simpleType=("String"|"Int"));
>>>
>>> Please not that it not considered best practice to hard code the data
>>> types in your language.
>>>
>>> Regards
>>> Sebastian
>>>
>>> --
>>> Need professional support for Eclipse Modeling?
>>> Go visit: http://xtext.itemis.com
>>>
>>> Am 27.07.2009 17:59 Uhr, schrieb Thomas:
>>>> Hi,
>>>>
>>>> To become more familiar with the Xtext grammar syntax I started to play
>>>> around with your "getting started" example of Entities and their
>>>> Properties. There is only one small thing I want to change but horribly
>>>> fail in doing so. Instead of letting the user define SimpleTypes in the
>>>> model with the keyword "type", I want to predefine the set of simple
>>>> types in my grammar. So if the user wants to create a new property the
>>>> code-assistance feature of the generated editor should not only provide
>>>> the names of already created entities but also the predefined types
>>>> like
>>>> e.g. String, Integer...
>>>>
>>>> All approaches of using enums or predefing the name attribute, like
>>>> below, failed.
>>>>
>>>> Property:
>>>> name=ID ":" type=[Type]";";
>>>>
>>>> Type:
>>>> SimpleType | Entity;
>>>>
>>>> SimpleType:
>>>> name=("String" | "Int" | "Boolean");
>>>>
>>>> Do you have a hint for me?
>>>>
>>>> Thanks and Regards,
>>>> Thomas.
>>
>
|
|
| |
| Re: Getting started: predefined set of simple types [message #372090 is a reply to message #63210] |
Wed, 29 July 2009 04:34 |
| Eclipse User |
|
|
|
Hi Sebastian and Thomas,
Sorry Thomas for hijacking your thread, but I face similar problems as
yours.
Sebastian Zarnekow wrote:
> Hi Thomas,
>
> to provide some default values for simple types you can either try to
> implement a scope provider that provides access to your built in types
I tried to take this approach for one of my example but faced two problems
:
1) As I didn't want to parse a file providing primitive types (int &
string in this example) again & again, I chose to create these instances
as static members of a dedicated java class and to extend the
ScopeProvider to always return those.
It turns out that works fine when I statically parse my files & use the
resulting (meta)model instance. On the other hand, it generates errors
when I use this in the dynamic xtext based editor. As a matter of fact, at
validation, the Validator checks that all referenced EObject instances are
contained in a resource, which is not the case for those instances I
created.
2) Some of my types are created only when an instance using them is
encountered. For example, the array types, that references another type
(what's contained in the array).
With my previous approach that introduced an additional indirection (as
explained in my other message on this thread), that was not a problem.
There were two kind of indirection, either
Variable=>PrimitiveDatatyper=>PrimitiveDatatypeKind in the case of
primitive types, Variable=>DatatypeReference->Type in the case of user
defined types and
Variable=>ArrayDatatyper=>[PrimitiveDatatyper|DatatypeReference|ArrayDatatyper]
in the case of an array (=> are containment, -> are not).
An approach would be to lazily create array types when required, make them
contained by my root element and reference them from variable using them.
However, taking that approach in xtext will likely make me face the same
kind of problems as described in the "Processing ecore with
non-containment references" thread.
> [...]
>
> Regards
> Sebastian
Regards,
Julien
|
|
|
| Re: Getting started: predefined set of simple types [message #372478 is a reply to message #372090] |
Wed, 29 July 2009 05:22 |
| Eclipse User |
|
|
|
Hi Julien
please see below.
Am 29.07.2009 10:34 Uhr, schrieb Julien Bigot:
> Hi Sebastian and Thomas,
>
> Sorry Thomas for hijacking your thread, but I face similar problems as
> yours.
>
> Sebastian Zarnekow wrote:
>> Hi Thomas,
>>
>> to provide some default values for simple types you can either try to
>> implement a scope provider that provides access to your built in types
>
> I tried to take this approach for one of my example but faced two
> problems :
>
> 1) As I didn't want to parse a file providing primitive types (int &
> string in this example) again & again, I chose to create these instances
> as static members of a dedicated java class and to extend the
> ScopeProvider to always return those.
> It turns out that works fine when I statically parse my files & use the
> resulting (meta)model instance. On the other hand, it generates errors
> when I use this in the dynamic xtext based editor. As a matter of fact,
> at validation, the Validator checks that all referenced EObject
> instances are contained in a resource, which is not the case for those
> instances I created.
It is not a good idea to create eobjects that are not contained in any
resource. It is a better idea to add them to a resource and keep that
one in memory.
>
> 2) Some of my types are created only when an instance using them is
> encountered. For example, the array types, that references another type
> (what's contained in the array).
> With my previous approach that introduced an additional indirection (as
> explained in my other message on this thread), that was not a problem.
> There were two kind of indirection, either
> Variable=>PrimitiveDatatyper=>PrimitiveDatatypeKind in the case of
> primitive types, Variable=>DatatypeReference->Type in the case of user
> defined types and
> Variable=>ArrayDatatyper=>[PrimitiveDatatyper|DatatypeReference|ArrayDatatyper]
> in the case of an array (=> are containment, -> are not).
> An approach would be to lazily create array types when required, make
> them contained by my root element and reference them from variable using
> them. However, taking that approach in xtext will likely make me face
> the same kind of problems as described in the "Processing ecore with
> non-containment references" thread.
>
I do not understand why PrimitiveDatatypeKind should be contained in the
PrimitiveDatatyper. I guess this one should be a cross ref, shouldn't it?
Regarding your Array problem. I don't think that this is the same
problem as in the mentioned thread. How do nested array types look like
in your concrete syntax? Maybe we can come up with a grammar that will
parse this one gracefully without any reference/containment problem. I
guess the Variable=>ArrayDatatyper .. notation visualizes the (frozen)
structure of your metamodel?
>> [...]
>>
>> Regards
>> Sebastian
>
> Regards,
> Julien
>
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
| Re: Getting started: predefined set of simple types [message #372886 is a reply to message #372478] |
Wed, 29 July 2009 07:52 |
| Eclipse User |
|
|
|
Hi Sebastian,
Thank you for your answers, additional comments and question are below.
Sebastian Zarnekow wrote:
> Hi Julien
>
> please see below.
>
> Am 29.07.2009 10:34 Uhr, schrieb Julien Bigot:
>> Hi Sebastian and Thomas,
>>
>> Sorry Thomas for hijacking your thread, but I face similar problems as
>> yours.
>>
>> Sebastian Zarnekow wrote:
>>> Hi Thomas,
>>>
>>> to provide some default values for simple types you can either try to
>>> implement a scope provider that provides access to your built in types
>>
>> I tried to take this approach for one of my example but faced two
>> problems :
>>
>> 1) As I didn't want to parse a file providing primitive types (int &
>> string in this example) again & again, I chose to create these instances
>> as static members of a dedicated java class and to extend the
>> ScopeProvider to always return those.
>> It turns out that works fine when I statically parse my files & use the
>> resulting (meta)model instance. On the other hand, it generates errors
>> when I use this in the dynamic xtext based editor. As a matter of fact,
>> at validation, the Validator checks that all referenced EObject
>> instances are contained in a resource, which is not the case for those
>> instances I created.
>
> It is not a good idea to create eobjects that are not contained in any
> resource. It is a better idea to add them to a resource and keep that
> one in memory.
Ok, then I guess I should create a Resource that is not an XtextResource
since it hasn't been parsed by xtext. But should I add it to the
ResourceSet or should I keep it out of it ? I'm quite new to EMF and thus
I don't fully get what concepts Resource's and ResouceSet's capture.
Another question is what URI I should set for this in-memory Resource.
>> 2) Some of my types are created only when an instance using them is
>> encountered. For example, the array types, that references another type
>> (what's contained in the array).
>> With my previous approach that introduced an additional indirection (as
>> explained in my other message on this thread), that was not a problem.
>> There were two kind of indirection, either
>> Variable=>PrimitiveDatatyper=>PrimitiveDatatypeKind in the case of
>> primitive types, Variable=>DatatypeReference->Type in the case of user
>> defined types and
>>
Variable=>ArrayDatatyper=>[PrimitiveDatatyper|DatatypeReference|ArrayDatatyper]
>> in the case of an array (=> are containment, -> are not).
>> An approach would be to lazily create array types when required, make
>> them contained by my root element and reference them from variable using
>> them. However, taking that approach in xtext will likely make me face
>> the same kind of problems as described in the "Processing ecore with
>> non-containment references" thread.
>>
> I do not understand why PrimitiveDatatypeKind should be contained in the
> PrimitiveDatatyper. I guess this one should be a cross ref, shouldn't it?
This is not a containing reference but an attribute, since
PrimitiveDatatypeKind is an enumeration. Anyway, that shouldn't make any
difference.
To summarize, my actual ecore metamodel looks like that (is there an
official DSL for ecore models ?):
eclass Datatyper (interface) {} // basically a reference to a type
enum PrimitiveDatatypeKind { INT, STRING }
eclass PrimitiveDatatyer extends Datatyper {
attr kind: PrimitiveDatatypeKind ([1..1]);
}
eclass Type { // user defined types
attr name: EString([1..1]);
}
eclass DatatypeReference extends Datatyper {
ref referenced: Type ([1..1] non-containing);
}
eclass ArrayDatatyper extends Datatyper {
ref subType: Datatyper ([1..1] containing);
}
eclass Variable {
attr name: EString ([1..1]);
ref type: Datatyper ([1..1] containing);
}
as I said, the Datatyper acts as a reference to a type, handling the cases
where the type is described by an enumeration and thus referenced by an
attribute (primitive types) and the case where the type is created on the
fly and thus not referenced without containment (array)
> Regarding your Array problem. I don't think that this is the same
> problem as in the mentioned thread. How do nested array types look like
> in your concrete syntax?
An exemple of Array variable in the DSL could be:
int[] myVar;
and the associated xtext grammar:
Variable:
type=Datatyper name=ID ';'
;
Datatyper:
(PrimitiveDatatyper|DatatypeReference) ({ArrayDatatyper.subType=current}
'[' ']' )*
;
enum PrimitiveDatakind :
INT='int'|STRING='string'
;
PrimitiveDatatyper:
kind=PrimitiveDatakind
;
DatatypeReference:
referenced=[Type]
;
> Maybe we can come up with a grammar that will
> parse this one gracefully without any reference/containment problem. I
> guess the Variable=>ArrayDatatyper .. notation visualizes the (frozen)
> structure of your metamodel?
My current grammar works rather well, except it introduces this additional
indirection when referring to types : Variable=>TypeReference->Type
instead of Variable->Type as one would expect.
You gave me the first half of the solution by solving the problem with
primitive types (create a fixed number of instances of Type statically).
This means that now, for a user defined type, I have
Variable->UserDefinedType and for a primitive type,
Variable->PrimitiveType where both UserDefinedType and PrimitiveType
extend Type.
The only problem remaining is the case of arrays.
One approach would be to modify the metamodel to put the fact that the
variable stands for an array in the Variable meta-class. Something like
Variable[array=true]->Type.
That doesn't seem any cleaner than my current solution however. I don't
model array variables of a given type, but variables whose type is array
of something.
>>> [...]
>>>
>>> Regards
>>> Sebastian
>>
>> Regards,
>> Julien
>>
> Regards,
> Sebastian
Regards,
Julien
|
|
|
| Re: Getting started: predefined set of simple types [message #373291 is a reply to message #372886] |
Wed, 29 July 2009 09:38 |
| Eclipse User |
|
|
|
Hi Julien,
please see below.
Am 29.07.2009 13:52 Uhr, schrieb Julien Bigot:
> Hi Sebastian,
>
> Thank you for your answers, additional comments and question are below.
>
> Sebastian Zarnekow wrote:
>> Hi Julien
>>
>> please see below.
>>
>> Am 29.07.2009 10:34 Uhr, schrieb Julien Bigot:
>>> Hi Sebastian and Thomas,
>>>
>>> Sorry Thomas for hijacking your thread, but I face similar problems as
>>> yours.
>>>
>>> Sebastian Zarnekow wrote:
>>>> Hi Thomas,
>>>>
>>>> to provide some default values for simple types you can either try to
>>>> implement a scope provider that provides access to your built in types
>>>
>>> I tried to take this approach for one of my example but faced two
>>> problems :
>>>
>>> 1) As I didn't want to parse a file providing primitive types (int &
>>> string in this example) again & again, I chose to create these instances
>>> as static members of a dedicated java class and to extend the
>>> ScopeProvider to always return those.
>>> It turns out that works fine when I statically parse my files & use the
>>> resulting (meta)model instance. On the other hand, it generates errors
>>> when I use this in the dynamic xtext based editor. As a matter of fact,
>>> at validation, the Validator checks that all referenced EObject
>>> instances are contained in a resource, which is not the case for those
>>> instances I created.
>>
>> It is not a good idea to create eobjects that are not contained in any
>> resource. It is a better idea to add them to a resource and keep that
>> one in memory.
>
> Ok, then I guess I should create a Resource that is not an XtextResource
> since it hasn't been parsed by xtext. But should I add it to the
> ResourceSet or should I keep it out of it ? I'm quite new to EMF and
> thus I don't fully get what concepts Resource's and ResouceSet's
> capture. Another question is what URI I should set for this in-memory
> Resource.
>
You can use an XtextResource as well. The fact that it uses a parser to
load a file and a serializer to save it back to the file system does not
matter. Actually XMLResources tend to use a parser as well :-)
The EMF book is a quite good starter to get used to the concepts of the
framework.
Personally I'ld prefer to add the resouce to the resource set. This way
you built in types may be collected by the garbage collector and
resources in the same resource set will help the framework to find
existing instances.
>>> 2) Some of my types are created only when an instance using them is
>>> encountered. For example, the array types, that references another type
>>> (what's contained in the array).
>>> With my previous approach that introduced an additional indirection (as
>>> explained in my other message on this thread), that was not a problem.
>>> There were two kind of indirection, either
>>> Variable=>PrimitiveDatatyper=>PrimitiveDatatypeKind in the case of
>>> primitive types, Variable=>DatatypeReference->Type in the case of user
>>> defined types and
>>>
> Variable=>ArrayDatatyper=>[PrimitiveDatatyper|DatatypeReference|ArrayDatatyper]
>
>>> in the case of an array (=> are containment, -> are not).
>>> An approach would be to lazily create array types when required, make
>>> them contained by my root element and reference them from variable using
>>> them. However, taking that approach in xtext will likely make me face
>>> the same kind of problems as described in the "Processing ecore with
>>> non-containment references" thread.
>>>
>> I do not understand why PrimitiveDatatypeKind should be contained in
>> the PrimitiveDatatyper. I guess this one should be a cross ref,
>> shouldn't it?
>
> This is not a containing reference but an attribute, since
> PrimitiveDatatypeKind is an enumeration. Anyway, that shouldn't make any
> difference.
>
> To summarize, my actual ecore metamodel looks like that (is there an
> official DSL for ecore models ?):
Try to google for emfatic. But it has a rather noisy syntax. Java-like
pseudocode is fine for me.
>
> eclass Datatyper (interface) {} // basically a reference to a type
>
> enum PrimitiveDatatypeKind { INT, STRING }
>
> eclass PrimitiveDatatyer extends Datatyper {
> attr kind: PrimitiveDatatypeKind ([1..1]);
> }
>
> eclass Type { // user defined types
> attr name: EString([1..1]);
> }
>
> eclass DatatypeReference extends Datatyper {
> ref referenced: Type ([1..1] non-containing);
> }
>
> eclass ArrayDatatyper extends Datatyper {
> ref subType: Datatyper ([1..1] containing);
> }
>
> eclass Variable {
> attr name: EString ([1..1]);
> ref type: Datatyper ([1..1] containing);
> }
>
> as I said, the Datatyper acts as a reference to a type, handling the
> cases where the type is described by an enumeration and thus referenced
> by an attribute (primitive types) and the case where the type is created
> on the fly and thus not referenced without containment (array)
>
>> Regarding your Array problem. I don't think that this is the same
>> problem as in the mentioned thread. How do nested array types look
>> like in your concrete syntax?
>
> An exemple of Array variable in the DSL could be:
>
> int[] myVar;
>
> and the associated xtext grammar:
>
> Variable:
> type=Datatyper name=ID ';'
> ;
>
> Datatyper:
> (PrimitiveDatatyper|DatatypeReference) ({ArrayDatatyper.subType=current}
> '[' ']' )*
> ;
>
> enum PrimitiveDatakind :
> INT='int'|STRING='string'
> ;
>
> PrimitiveDatatyper:
> kind=PrimitiveDatakind
> ;
>
> DatatypeReference:
> referenced=[Type]
> ;
>
>> Maybe we can come up with a grammar that will parse this one
>> gracefully without any reference/containment problem. I guess the
>> Variable=>ArrayDatatyper .. notation visualizes the (frozen) structure
>> of your metamodel?
>
> My current grammar works rather well, except it introduces this
> additional indirection when referring to types :
> Variable=>TypeReference->Type instead of Variable->Type as one would
> expect.
This indirection is a common approach. You'll end up with
SomethingDeclaration and SomethingReference in many languages.
>
> You gave me the first half of the solution by solving the problem with
> primitive types (create a fixed number of instances of Type statically).
> This means that now, for a user defined type, I have
> Variable->UserDefinedType and for a primitive type,
> Variable->PrimitiveType where both UserDefinedType and PrimitiveType
> extend Type.
> The only problem remaining is the case of arrays.
>
> One approach would be to modify the metamodel to put the fact that the
> variable stands for an array in the Variable meta-class. Something like
> Variable[array=true]->Type.
> That doesn't seem any cleaner than my current solution however. I don't
> model array variables of a given type, but variables whose type is array
> of something.
You are right, the fact "Variable's type is an array" does not belong to
the variable directly, but to its type. ArrayType should be a sibling of
UserDefinedType and PrimitiveType and refer to its component type as a
Type. That's actually the way you modeled it in your grammar.
>
>>>> [...]
>>>>
>>>> Regards
>>>> Sebastian
>>>
>>> Regards,
>>> Julien
>>>
>> Regards,
>> Sebastian
>
> Regards,
> Julien
>
>
Hope that helps,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
| Re: Getting started: predefined set of simple types [message #374560 is a reply to message #373291] |
Wed, 29 July 2009 12:49 |
| Eclipse User |
|
|
|
Hi Sebastian,
First, thanks for all the clarifications.
There are still a few things not completely clear to me as you'll find
below.
Fell free to tell me to just check the EMF Book however. I guess I'm
focusing on tiny details now that don't have much importance.
Sebastian Zarnekow wrote:
> Hi Julien,
> please see below.
> [...]
> You can use an XtextResource as well. The fact that it uses a parser to
> load a file and a serializer to save it back to the file system does not
> matter. Actually XMLResources tend to use a parser as well :-)
I was rather thinking about a simple ResourceImpl that doesn't support any
kind of serialization.
> The EMF book is a quite good starter to get used to the concepts of the
> framework.
Thank you for the advice, I will consider buying it.
> Personally I'ld prefer to add the resouce to the resource set. This way
> you built in types may be collected by the garbage collector and
> resources in the same resource set will help the framework to find
> existing instances.
I'll go that way until I better understand Resources and ResourceSets then
!
>> [...]
>> My current grammar works rather well, except it introduces this
>> additional indirection when referring to types :
>> Variable=>TypeReference->Type instead of Variable->Type as one would
>> expect.
> This indirection is a common approach. You'll end up with
> SomethingDeclaration and SomethingReference in many languages.
>> You gave me the first half of the solution by solving the problem with
>> primitive types (create a fixed number of instances of Type statically).
>> This means that now, for a user defined type, I have
>> Variable->UserDefinedType and for a primitive type,
>> Variable->PrimitiveType where both UserDefinedType and PrimitiveType
>> extend Type.
>> The only problem remaining is the case of arrays.
>>
>> One approach would be to modify the metamodel to put the fact that the
>> variable stands for an array in the Variable meta-class. Something like
>> Variable[array=true]->Type.
>> That doesn't seem any cleaner than my current solution however. I don't
>> model array variables of a given type, but variables whose type is array
>> of something.
>
> You are right, the fact "Variable's type is an array" does not belong to
> the variable directly, but to its type. ArrayType should be a sibling of
> UserDefinedType and PrimitiveType and refer to its component type as a
> Type. That's actually the way you modeled it in your grammar.
Not exactly, in my grammar ArrayType is a sibling of TypeReference, not of
UserDefinedType and PrimitiveType.
This is due to the fact that I need ArrayTypes to be contained by Variable
instances.
I cannot create all the ArrayTypes instances somewhere and only reference
them without containment from Variables. There is a possibly infinite
number of ArrayTypes.
In order to break that lack of symmetry between ArrayTypes and other
Types, I thought about lazily instantiating ArrayTypes when they are used
by Variables, but make them contained by the root element or something
like that.
That would be very complicated for only little benefits however.
As I don't think I am the first one to encounter that problem I just
wanted to know if there is a best practice in that case ?
> Hope that helps,
> Sebastian
|
|
|
| Re: Getting started: predefined set of simple types [message #375457 is a reply to message #374560] |
Wed, 29 July 2009 15:37 |
| Eclipse User |
|
|
|
Hi Julien,
please see below.
Am 29.07.2009 18:49 Uhr, schrieb Julien Bigot:
> Hi Sebastian,
>
> First, thanks for all the clarifications.
>
> There are still a few things not completely clear to me as you'll find
> below.
>
> Fell free to tell me to just check the EMF Book however. I guess I'm
> focusing on tiny details now that don't have much importance.
>
> Sebastian Zarnekow wrote:
>
>> Hi Julien,
>
>> please see below.
>
>> [...]
>> You can use an XtextResource as well. The fact that it uses a parser
>> to load a file and a serializer to save it back to the file system
>> does not matter. Actually XMLResources tend to use a parser as well :-)
> I was rather thinking about a simple ResourceImpl that doesn't support
> any kind of serialization.
>
Ok, that should work :-)
>> The EMF book is a quite good starter to get used to the concepts of
>> the framework.
> Thank you for the advice, I will consider buying it.
It's definitly worth it as it gives a very good introduction in the EMF
concepts and is a quite good reference.
>
>> Personally I'ld prefer to add the resouce to the resource set. This
>> way you built in types may be collected by the garbage collector and
>> resources in the same resource set will help the framework to find
>> existing instances.
> I'll go that way until I better understand Resources and ResourceSets
> then !
>
>>> [...]
>>> My current grammar works rather well, except it introduces this
>>> additional indirection when referring to types :
>>> Variable=>TypeReference->Type instead of Variable->Type as one would
>>> expect.
>
>> This indirection is a common approach. You'll end up with
>> SomethingDeclaration and SomethingReference in many languages.
>
>>> You gave me the first half of the solution by solving the problem with
>>> primitive types (create a fixed number of instances of Type statically).
>>> This means that now, for a user defined type, I have
>>> Variable->UserDefinedType and for a primitive type,
>>> Variable->PrimitiveType where both UserDefinedType and PrimitiveType
>>> extend Type.
>>> The only problem remaining is the case of arrays.
>>>
>>> One approach would be to modify the metamodel to put the fact that the
>>> variable stands for an array in the Variable meta-class. Something like
>>> Variable[array=true]->Type.
>>> That doesn't seem any cleaner than my current solution however. I don't
>>> model array variables of a given type, but variables whose type is array
>>> of something.
>>
>> You are right, the fact "Variable's type is an array" does not belong
>> to the variable directly, but to its type. ArrayType should be a
>> sibling of UserDefinedType and PrimitiveType and refer to its
>> component type as a Type. That's actually the way you modeled it in
>> your grammar.
>
> Not exactly, in my grammar ArrayType is a sibling of TypeReference, not
> of UserDefinedType and PrimitiveType.
> This is due to the fact that I need ArrayTypes to be contained by
> Variable instances.
> I cannot create all the ArrayTypes instances somewhere and only
> reference them without containment from Variables. There is a possibly
> infinite number of ArrayTypes.
>
> In order to break that lack of symmetry between ArrayTypes and other
> Types, I thought about lazily instantiating ArrayTypes when they are
> used by Variables, but make them contained by the root element or
> something like that.
> That would be very complicated for only little benefits however.
>
> As I don't think I am the first one to encounter that problem I just
> wanted to know if there is a best practice in that case ?
Usually one would override ILinkingService#getLinkedObjects to
instantiate objects lazily - if it's definitly necessary. In your case a
combination of
ArrayTypeReference extends DatatypeReference {
arrayType: ArrayType
}
and
ArrayType extends Type {
componentType: Type;
}
should work out very well.
>
>> Hope that helps,
>> Sebastian
>
>
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
| |
Goto Forum:
Current Time: Tue Jul 15 06:43:05 EDT 2025
Powered by FUDForum. Page generated in 0.05409 seconds |
Home