Home » Modeling » OCL » Environment and name resolving
| |
Re: Environment and name resolving [message #57648 is a reply to message #57578] |
Tue, 03 June 2008 10:51 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.zeligsoft.com
--=-yfgvPrt33Mqbi2ZRbFEK
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Felix,
All of these (partially) qualified names will find the Car type, as all
of "second" "first" and "model" are unique names within the namespaces
containing Person.
Cheers,
Christian
On Mon, 2008-06-02 at 14:22 +0200, Felix Dorner wrote:
> Hi,
>
> I have troubles understanding how name resolving exactly works.
>
> Given the following hierarchy, (Packages small letters, Classes capitalized)
>
> model::first
> ::Person
> ::second
> ::Car
>
> In the context of Person, which of the following path names would
> resolve the "Car" element?
>
> a) "second::Car"
>
> b) "first::second::Car"
>
> c) "model::first::second::Car"
>
>
>
> Thanks,
> Felix
>
>
>
--=-yfgvPrt33Mqbi2ZRbFEK
Content-Type: text/html; charset=utf-8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Felix,<BR>
<BR>
All of these (partially) qualified names will find the Car type, as all of "second" "first" and "model" are unique names within the namespaces containing Person.<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Mon, 2008-06-02 at 14:22 +0200, Felix Dorner wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi,</FONT>
<FONT COLOR="#000000">I have troubles understanding how name resolving exactly works.</FONT>
<FONT COLOR="#000000">Given the following hierarchy, (Packages small letters, Classes capitalized)</FONT>
<FONT COLOR="#000000">model::first</FONT>
<FONT COLOR="#000000"> ::Person</FONT>
<FONT COLOR="#000000"> ::second</FONT>
<FONT COLOR="#000000"> ::Car</FONT>
<FONT COLOR="#000000">In the context of Person, which of the following path names would </FONT>
<FONT COLOR="#000000">resolve the "Car" element?</FONT>
<FONT COLOR="#000000">a) "second::Car"</FONT>
<FONT COLOR="#000000">b) "first::second::Car"</FONT>
<FONT COLOR="#000000">c) "model::first::second::Car"</FONT>
<FONT COLOR="#000000">Thanks,</FONT>
<FONT COLOR="#000000">Felix</FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-yfgvPrt33Mqbi2ZRbFEK--
|
|
|
Re: Environment and name resolving [message #57674 is a reply to message #57602] |
Tue, 03 June 2008 10:53 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.zeligsoft.com
--=-qH4tvBgMOOkLhbmOyzmG
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Felix,
I'm not sure ... it may be different for Ecore and for UML. Have a look
in the debugger at what utilities the
Environment::lookupPathName(List<String>) or whatever it's called (don't
have it in front of me) uses.
cW
On Mon, 2008-06-02 at 14:48 +0200, Felix Dorner wrote:
> As OCL has already implemented this complex mechanism, how difficult
> would it be to get its service to resolve an element by a path name,
> given a class or an operation where the lookup should start?
>
> Felix
--=-qH4tvBgMOOkLhbmOyzmG
Content-Type: text/html; charset=utf-8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Felix,<BR>
<BR>
I'm not sure ... it may be different for Ecore and for UML. Have a look in the debugger at what utilities the Environment::lookupPathName(List<String>) or whatever it's called (don't have it in front of me) uses.<BR>
<BR>
cW<BR>
<BR>
On Mon, 2008-06-02 at 14:48 +0200, Felix Dorner wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">As OCL has already implemented this complex mechanism, how difficult </FONT>
<FONT COLOR="#000000">would it be to get its service to resolve an element by a path name, </FONT>
<FONT COLOR="#000000">given a class or an operation where the lookup should start?</FONT>
<FONT COLOR="#000000">Felix</FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-qH4tvBgMOOkLhbmOyzmG--
|
|
| | |
Re: Environment and name resolving [message #57744 is a reply to message #57695] |
Tue, 03 June 2008 13:01 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.zeligsoft.com
--=-vXE1v7EUBZeVSDhuO0F4
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Felix,
No, not really. In the fact of refactoring of the model structure,
you'd have to change any of these qualifications anyway.
cW
On Tue, 2008-06-03 at 14:25 +0200, Felix Dorner wrote:
> Christian W. Damus wrote:
> > Hi, Felix,
> >
> > All of these (partially) qualified names will find the Car type, as all
> > of "second" "first" and "model" are unique names within the namespaces
> > containing Person.
>
> Strike! Thats what I thought. I guess that there are no "style"
> guidelines though...?
>
> Thanks,
> Felix
--=-vXE1v7EUBZeVSDhuO0F4
Content-Type: text/html; charset=utf-8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Felix,<BR>
<BR>
No, not really. In the fact of refactoring of the model structure, you'd have to change any of these qualifications anyway.<BR>
<BR>
cW<BR>
<BR>
On Tue, 2008-06-03 at 14:25 +0200, Felix Dorner wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Christian W. Damus wrote:</FONT>
<FONT COLOR="#000000">> Hi, Felix,</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> All of these (partially) qualified names will find the Car type, as all </FONT>
<FONT COLOR="#000000">> of "second" "first" and "model" are unique names within the namespaces </FONT>
<FONT COLOR="#000000">> containing Person.</FONT>
<FONT COLOR="#000000">Strike! Thats what I thought. I guess that there are no "style" </FONT>
<FONT COLOR="#000000">guidelines though...?</FONT>
<FONT COLOR="#000000">Thanks,</FONT>
<FONT COLOR="#000000">Felix</FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-vXE1v7EUBZeVSDhuO0F4--
|
|
| |
Re: Environment and name resolving [message #57794 is a reply to message #57769] |
Tue, 03 June 2008 18:58 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.zeligsoft.com
--=-Z047iOkjuDjRUyYtjfWK
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Felix,
If hasBrain is a static operation, then you would do:
Gender::hasBrain()
or (though discouraged because it looks like Gender might be a variable;
the OCL spec allows both forms)
Gender.hasBrain()
If hasBrain is not static, then you must do:
Gender::male.hasBrain()
HTH,
Christian
On Tue, 2008-06-03 at 20:46 +0200, Felix Dorner wrote:
> Hi Christian,
>
> the whole issue is that I don't understand how instance specifications
> are handled. For example Enumeration literals. These are instances of
> their Enum type and according to the OCL spec accessed, e.g. via
> Gender::male or Gender::female.
>
> Now what if that Enumeration defines additional features, say a query
> operation "hasBrain()". How would I call that operation:
>
> Gender::male::hasBrain()
>
> or
>
> Gender::male.hasBrain()
>
> ?
>
>
> Thanks again for your help.
>
> Felix
--=-Z047iOkjuDjRUyYtjfWK
Content-Type: text/html; charset=utf-8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Felix,<BR>
<BR>
If hasBrain is a static operation, then you would do:<BR>
<BR>
Gender::hasBrain()<BR>
<BR>
or (though discouraged because it looks like Gender might be a variable; the OCL spec allows both forms)<BR>
<BR>
Gender.hasBrain()<BR>
<BR>
If hasBrain is not static, then you must do:<BR>
<BR>
Gender::male.hasBrain()<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
On Tue, 2008-06-03 at 20:46 +0200, Felix Dorner wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi Christian,</FONT>
<FONT COLOR="#000000">the whole issue is that I don't understand how instance specifications </FONT>
<FONT COLOR="#000000">are handled. For example Enumeration literals. These are instances of </FONT>
<FONT COLOR="#000000">their Enum type and according to the OCL spec accessed, e.g. via </FONT>
<FONT COLOR="#000000">Gender::male or Gender::female.</FONT>
<FONT COLOR="#000000">Now what if that Enumeration defines additional features, say a query </FONT>
<FONT COLOR="#000000">operation "hasBrain()". How would I call that operation:</FONT>
<FONT COLOR="#000000">Gender::male::hasBrain()</FONT>
<FONT COLOR="#000000">or</FONT>
<FONT COLOR="#000000">Gender::male.hasBrain()</FONT>
<FONT COLOR="#000000">?</FONT>
<FONT COLOR="#000000">Thanks again for your help.</FONT>
<FONT COLOR="#000000">Felix</FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-Z047iOkjuDjRUyYtjfWK--
|
|
| |
Re: Environment and name resolving [message #57842 is a reply to message #57818] |
Tue, 03 June 2008 22:35 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.zeligsoft.com
--=-DSm0WKGDGLsoYq499CUK
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Felix,
Does your OCL Console show M2 as the current modeling level?
You want M1 for OCL expressions in the context of classifiers in your
model. Otherwise, your OCL expressions are in the context of
classifiers in the UML metamodel. The fully qualified reference to the
Gender type worked because OCL was able to jump from the UML scope to
"root" scope by searching the resource set for top-level namespaces.
Note that, for parsing expressions at M1 level, you will also need to
have the target metamodel set to UML (not Ecore) if you are working with
a UML model.
Cheers,
Christian
On Tue, 2008-06-03 at 21:11 +0200, Felix Dorner wrote:
> Christian W. Damus wrote:
> > Hi, Felix,
> >
> > If hasBrain is a static operation, then you would do:
> >
> > Gender::hasBrain()
> >
> > or (though discouraged because it looks like Gender might be a variable;
> > the OCL spec allows both forms)
> >
> > Gender.hasBrain()
> >
> > If hasBrain is not static, then you must do:
> >
> > Gender::male.hasBrain()
>
> Ok. I just found out how to use the OCL console and verified this
> myself. I guess the selected element provides the context for the
> expressions I enter? I have a class and an Enum both in the same (root)
> package. If I select the class, then then "Gender::male.hasBrain()"
> doesnt resolve. When I do it fully qualified it does
> ("root::Gender::male.hasBrain()"): So do those "partially qualified
> paths" only work if the path elements (without the tail) are all packages?
>
> Felix
--=-DSm0WKGDGLsoYq499CUK
Content-Type: text/html; charset=utf-8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Felix,<BR>
<BR>
Does your OCL Console show M2 as the current modeling level?<BR>
<BR>
You want M1 for OCL expressions in the context of classifiers in your model. Otherwise, your OCL expressions are in the context of classifiers in the UML metamodel. The fully qualified reference to the Gender type worked because OCL was able to jump from the UML scope to "root" scope by searching the resource set for top-level namespaces.<BR>
<BR>
Note that, for parsing expressions at M1 level, you will also need to have the target metamodel set to UML (not Ecore) if you are working with a UML model.<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Tue, 2008-06-03 at 21:11 +0200, Felix Dorner wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Christian W. Damus wrote:</FONT>
<FONT COLOR="#000000">> Hi, Felix,</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> If hasBrain is a static operation, then you would do:</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> Gender::hasBrain()</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> or (though discouraged because it looks like Gender might be a variable; </FONT>
<FONT COLOR="#000000">> the OCL spec allows both forms)</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> Gender.hasBrain()</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> If hasBrain is not static, then you must do:</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> Gender::male.hasBrain()</FONT>
<FONT COLOR="#000000">Ok. I just found out how to use the OCL console and verified this </FONT>
<FONT COLOR="#000000">myself. I guess the selected element provides the context for the </FONT>
<FONT COLOR="#000000">expressions I enter? I have a class and an Enum both in the same (root) </FONT>
<FONT COLOR="#000000">package. If I select the class, then then "Gender::male.hasBrain()" </FONT>
<FONT COLOR="#000000">doesnt resolve. When I do it fully qualified it does </FONT>
<FONT COLOR="#000000">("root::Gender::male.hasBrain()"): So do those "partially qualified </FONT>
<FONT COLOR="#000000">paths" only work if the path elements (without the tail) are all packages?</FONT>
<FONT COLOR="#000000">Felix</FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-DSm0WKGDGLsoYq499CUK--
|
|
|
Goto Forum:
Current Time: Fri Aug 16 20:07:13 GMT 2024
Powered by FUDForum. Page generated in 0.04970 seconds
|