Eclipse Community Forums: OCL » deleteElement when variables and operations have the same names

Help

Home

Home » Modeling » OCL » deleteElement when variables and operations have the same names

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

deleteElement when variables and operations have the same names [message #57888]

Thu, 05 June 2008 16:51

Jonathan MUSSET

Messages: 43
Registered: July 2009

Member

Hi,
I'm using the EcoreEnvironment and I need to add some elements like
Variable and Operation.
I'm using the following code :

((EcoreEnvironment)helper.getOCL().getEnvironment()).addElem ent(newVariable.getName(),
newVariable,
true);

((EcoreEnvironment)helper.getOCL().getEnvironment()).defineO peration(owner,
name, type, params, constraint);

So, it is quite simple to register Variable and define a new operation,
but How can I delete my elements?
In my opinion, it is dangerous to call the deleteElement method
(Operations can have the same names)... Is there another solution?

helper.getOCL().getEnvironment().deleteElement(oldVariable.g etName());
helper.getOCL().getEnvironment().deleteElement(oldOperation. getName());
??? Is it the good solution to delete an operation?

Regards,

Jonathan

Report message to a moderator

Re: deleteElement when variables and operations have the same names [message #57914 is a reply to message #57888]

Thu, 05 June 2008 18:01

Adolfo Sanchez-Barbudo Herrera

Messages: 260
Registered: July 2009

Senior Member

Hi Jonathan,

deleteElement doesn't remove operations from the environment, just
variables.

I'm not sure if you can "undefine" operations, at least the API doesn't
seem to allow it. I'm curious of knowing about the scenerio in which it
could be needed.

Cheers,
Adolfo.

Jonathan MUSSET escribió:
> Hi,
> I'm using the EcoreEnvironment and I need to add some elements like
> Variable and Operation.
> I'm using the following code :
>
> ((EcoreEnvironment)helper.getOCL().getEnvironment()).addElem ent(newVariable.getName(),
> newVariable,
> true);
>
> ((EcoreEnvironment)helper.getOCL().getEnvironment()).defineO peration(owner,
> name, type, params, constraint);
>
> So, it is quite simple to register Variable and define a new operation,
> but How can I delete my elements?
> In my opinion, it is dangerous to call the deleteElement method
> (Operations can have the same names)... Is there another solution?
>
> helper.getOCL().getEnvironment().deleteElement(oldVariable.g etName());
> helper.getOCL().getEnvironment().deleteElement(oldOperation. getName());
> ??? Is it the good solution to delete an operation?
>
> Regards,
>
> Jonathan

Report message to a moderator

Re: deleteElement when variables and operations have the same names [message #57938 is a reply to message #57888]

Thu, 05 June 2008 19:10

Eclipse User

Originally posted by: cdamus.zeligsoft.com

--=-IEQJpEsE9bBlbcEgaTSc
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Jonathan,

To follow up Adolfo's very helpful answer with some information about
the API intent of the Environment::defineOperation method: this API is
intended to be used by the OCL parser in processing additional operation
definitions ("def expressions"). Also, specialized environment
implementations (subclassing, for example, the EcoreEnvironment) might
use it to add custom operations as described in the "Customizing the
Environment" topic in the Developer Guide. Otherwise, it isn't intended
to be used by clients.

Note that you can use the OCLHelper::define(...) API to create
additional operations using OCL, that are local to the current
environment.

As Adolfo indicated, there is currently no way to un-define an operation
except by disposing the environment and creating a new one. If you
would like to raise an enhancement request in bugzilla, we could
consider the use cases for a feature in the next release.

Cheers,

Christian

On Thu, 2008-06-05 at 18:51 +0200, Jonathan MUSSET wrote:

> Hi,
> I'm using the EcoreEnvironment and I need to add some elements like
> Variable and Operation.
> I'm using the following code :
>
> ((EcoreEnvironment)helper.getOCL().getEnvironment()).addElem ent(newVariable.getName(),
> newVariable,
> true);
>
> ((EcoreEnvironment)helper.getOCL().getEnvironment()).defineO peration(owner,
> name, type, params, constraint);
>
> So, it is quite simple to register Variable and define a new operation,
> but How can I delete my elements?
> In my opinion, it is dangerous to call the deleteElement method
> (Operations can have the same names)... Is there another solution?
>
> helper.getOCL().getEnvironment().deleteElement(oldVariable.g etName());
> helper.getOCL().getEnvironment().deleteElement(oldOperation. getName());
> ??? Is it the good solution to delete an operation?
>
> Regards,
>
> Jonathan

--=-IEQJpEsE9bBlbcEgaTSc
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, Jonathan, 
 
To follow up Adolfo's very helpful answer with some information about the API intent of the Environment::defineOperation method:  this API is intended to be used by the OCL parser in processing additional operation definitions ("def expressions").  Also, specialized environment implementations (subclassing, for example, the EcoreEnvironment) might use it to add custom operations as described in the "Customizing the Environment" topic in the Developer Guide.  Otherwise, it isn't intended to be used by clients. 
 
Note that you can use the OCLHelper::define(...) API to create additional operations using OCL, that are local to the current environment. 
 
As Adolfo indicated, there is currently no way to un-define an operation except by disposing the environment and creating a new one.  If you would like to raise an enhancement request in bugzilla, we could consider the use cases for a feature in the next release. 
 
Cheers, 
 
Christian 
 
On Thu, 2008-06-05 at 18:51 +0200, Jonathan MUSSET wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi,
I'm using the EcoreEnvironment and I need to add some elements like 
Variable and Operation.
I'm using the following code :

 ((EcoreEnvironment)helper.getOCL().getEnvironment()).addElem ent(newVariable.getName(), 
newVariable,
 true);
 
 ((EcoreEnvironment)helper.getOCL().getEnvironment()).defineO peration(owner, 
 name, type, params, constraint);
 
So, it is quite simple to register Variable and define a new operation, 
but How can I delete my elements?
In my opinion, it is dangerous to call the deleteElement method 
(Operations can have the same names)... Is there another solution?

 helper.getOCL().getEnvironment().deleteElement(oldVariable.g etName()); 
 helper.getOCL().getEnvironment().deleteElement(oldOperation. getName()); 
??? Is it the good solution to delete an operation?

Regards,

Jonathan
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-IEQJpEsE9bBlbcEgaTSc--

Report message to a moderator

Re: deleteElement when variables and operations have the same names [message #58237 is a reply to message #57938]

Wed, 11 June 2008 11:34

Jonathan MUSSET

Messages: 43
Registered: July 2009

Member

Thanks for your answers
It's OK for me. The bug number is Bug 236604.
Adolfo, I'm working on the MTL plugin and I have to define and un-define
an MTL/OCL helper, because the helper mustn't be accessible everywhere...
Cheers,

Jonathan

Christian W. Damus a écrit :
> Hi, Jonathan,
>
> To follow up Adolfo's very helpful answer with some information about
> the API intent of the Environment::defineOperation method: this API is
> intended to be used by the OCL parser in processing additional operation
> definitions ("def expressions"). Also, specialized environment
> implementations (subclassing, for example, the EcoreEnvironment) might
> use it to add custom operations as described in the "Customizing the
> Environment" topic in the Developer Guide. Otherwise, it isn't intended
> to be used by clients.
>
> Note that you can use the OCLHelper::define(...) API to create
> additional operations using OCL, that are local to the current environment.
>
> As Adolfo indicated, there is currently no way to un-define an operation
> except by disposing the environment and creating a new one. If you
> would like to raise an enhancement request in bugzilla, we could
> consider the use cases for a feature in the next release.
>
> Cheers,
>
> Christian
>
> On Thu, 2008-06-05 at 18:51 +0200, Jonathan MUSSET wrote:
>> Hi,
>> I'm using the EcoreEnvironment and I need to add some elements like
>> Variable and Operation.
>> I'm using the following code :
>>
>> ((EcoreEnvironment)helper.getOCL().getEnvironment()).addElem ent(newVariable.getName(),
>> newVariable,
>> true);
>>
>> ((EcoreEnvironment)helper.getOCL().getEnvironment()).defineO peration(owner,
>> name, type, params, constraint);
>>
>> So, it is quite simple to register Variable and define a new operation,
>> but How can I delete my elements?
>> In my opinion, it is dangerous to call the deleteElement method
>> (Operations can have the same names)... Is there another solution?
>>
>> helper.getOCL().getEnvironment().deleteElement(oldVariable.g etName());
>> helper.getOCL().getEnvironment().deleteElement(oldOperation. getName());
>> ??? Is it the good solution to delete an operation?
>>
>> Regards,
>>
>> Jonathan

Report message to a moderator

Re: deleteElement when variables and operations have the same names [message #58337 is a reply to message #58237]

Wed, 11 June 2008 15:11

Adolfo Sanchez-Barbudo Herrera

Messages: 260
Registered: July 2009

Senior Member

Hi Jonnatan,

I would need more info to see if this alternative can help you...but,
Have you tried to create a nested Environment just in the moment where
you need to add the helper operation, so that you use the nested
environment in that scope (variables from parent environments should be
accessible). Once you don't need the operation anymore, you can go on
with your previous (parent) environment.

If your necessities are similar to the scoping problem in programming
languages, using scoped Environments should help you in your task.

Cheers,
Adolfo.

Jonathan MUSSET escribió:
> Thanks for your answers
> It's OK for me. The bug number is Bug 236604.
> Adolfo, I'm working on the MTL plugin and I have to define and un-define
> an MTL/OCL helper, because the helper mustn't be accessible everywhere...
> Cheers,
>
> Jonathan
>
>
> Christian W. Damus a écrit :
>> Hi, Jonathan,
>>
>> To follow up Adolfo's very helpful answer with some information about
>> the API intent of the Environment::defineOperation method: this API
>> is intended to be used by the OCL parser in processing additional
>> operation definitions ("def expressions"). Also, specialized
>> environment implementations (subclassing, for example, the
>> EcoreEnvironment) might use it to add custom operations as described
>> in the "Customizing the Environment" topic in the Developer Guide.
>> Otherwise, it isn't intended to be used by clients.
>>
>> Note that you can use the OCLHelper::define(...) API to create
>> additional operations using OCL, that are local to the current
>> environment.
>>
>> As Adolfo indicated, there is currently no way to un-define an
>> operation except by disposing the environment and creating a new one.
>> If you would like to raise an enhancement request in bugzilla, we
>> could consider the use cases for a feature in the next release.
>>
>> Cheers,
>>
>> Christian
>>
>> On Thu, 2008-06-05 at 18:51 +0200, Jonathan MUSSET wrote:
>>> Hi,
>>> I'm using the EcoreEnvironment and I need to add some elements like
>>> Variable and Operation.
>>> I'm using the following code :
>>>
>>> ((EcoreEnvironment)helper.getOCL().getEnvironment()).addElem ent(newVariable.getName(),
>>> newVariable,
>>> true);
>>>
>>> ((EcoreEnvironment)helper.getOCL().getEnvironment()).defineO peration(owner,
>>>
>>> name, type, params, constraint);
>>>
>>> So, it is quite simple to register Variable and define a new
>>> operation, but How can I delete my elements?
>>> In my opinion, it is dangerous to call the deleteElement method
>>> (Operations can have the same names)... Is there another solution?
>>>
>>> helper.getOCL().getEnvironment().deleteElement(oldVariable.g etName());
>>> helper.getOCL().getEnvironment().deleteElement(oldOperation. getName());
>>> ??? Is it the good solution to delete an operation?
>>>
>>> Regards,
>>>
>>> Jonathan

Report message to a moderator

Re: deleteElement when variables and operations have the same names [message #58405 is a reply to message #58337]

Wed, 11 June 2008 16:45

Adolfo Sanchez-Barbudo Herrera

Messages: 260
Registered: July 2009

Senior Member

> using scoped Environments should help you in your task.

Sorry, I meant, nested Environments ;)

Cheers,
Adolfo.

Report message to a moderator

Re: deleteElement when variables and operations have the same names [message #58574 is a reply to message #58337]

Wed, 11 June 2008 22:31

Eclipse User

Originally posted by: cdamus.zeligsoft.com

--=-A2XQD7CXSwq7xg8zb5PR
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi, Adolfo,

The problem with using nested environments is that the
AbstractEnvironment implementation "bubbles up" operation definitions to
the root environment. Perhaps a custom environment implementation could
prevent that, though ...

cW

On Wed, 2008-06-11 at 16:11 +0100, Adolfo S=C3=A1nchez-Barbudo Herrera wrot=
e:

> Hi Jonnatan,
>=20
> I would need more info to see if this alternative can help you...but,=20
> Have you tried to create a nested Environment just in the moment where=20
> you need to add the helper operation, so that you use the nested=20
> environment in that scope (variables from parent environments should be=20
> accessible). Once you don't need the operation anymore, you can go on=20
> with your previous (parent) environment.
>=20
> If your necessities are similar to the scoping problem in programming=20
> languages, using scoped Environments should help you in your task.
>=20
> Cheers,
> Adolfo.
>=20
>=20
> Jonathan MUSSET escribi=C3=B3:
> > Thanks for your answers
> > It's OK for me. The bug number is Bug 236604.
> > Adolfo, I'm working on the MTL plugin and I have to define and un-defin=
e=20
> > an MTL/OCL helper, because the helper mustn't be accessible everywhere.=
...
> > Cheers,
> >=20
> > Jonathan
> >=20
> >=20
> > Christian W. Damus a =C3=A9crit :
> >> Hi, Jonathan,
> >>
> >> To follow up Adolfo's very helpful answer with some information about=20
> >> the API intent of the Environment::defineOperation method: this API=20
> >> is intended to be used by the OCL parser in processing additional=20
> >> operation definitions ("def expressions"). Also, specialized=20
> >> environment implementations (subclassing, for example, the=20
> >> EcoreEnvironment) might use it to add custom operations as described=20
> >> in the "Customizing the Environment" topic in the Developer Guide. =20
> >> Otherwise, it isn't intended to be used by clients.
> >>
> >> Note that you can use the OCLHelper::define(...) API to create=20
> >> additional operations using OCL, that are local to the current=20
> >> environment.
> >>
> >> As Adolfo indicated, there is currently no way to un-define an=20
> >> operation except by disposing the environment and creating a new one. =
=20
> >> If you would like to raise an enhancement request in bugzilla, we=20
> >> could consider the use cases for a feature in the next release.
> >>
> >> Cheers,
> >>
> >> Christian
> >>
> >> On Thu, 2008-06-05 at 18:51 +0200, Jonathan MUSSET wrote:
> >>> Hi,
> >>> I'm using the EcoreEnvironment and I need to add some elements like=20
> >>> Variable and Operation.
> >>> I'm using the following code :
> >>>
> >>> ((EcoreEnvironment)helper.getOCL().getEnvironment()).addElem ent(newVa=
riable.getName(),=20
> >>> newVariable,
> >>> true);
> >>> =20
> >>> ((EcoreEnvironment)helper.getOCL().getEnvironment()).defineO peration(=
owner,=20
> >>>
> >>> name, type, params, constraint);
> >>> =20
> >>> So, it is quite simple to register Variable and define a new=20
> >>> operation, but How can I delete my elements?
> >>> In my opinion, it is dangerous to call the deleteElement method=20
> >>> (Operations can have the same names)... Is there another solution?
> >>>
> >>> helper.getOCL().getEnvironment().deleteElement(oldVariable.g etName())=
;
> >>> helper.getOCL().getEnvironment().deleteElement(oldOperation. getName()=
);=20
> >>> ??? Is it the good solution to delete an operation?
> >>>
> >>> Regards,
> >>>
> >>> Jonathan

--=-A2XQD7CXSwq7xg8zb5PR
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, Adolfo, 
 
The problem with using nested environments is that the AbstractEnvironment implementation "bubbles up" operation definitions to the root environment.  Perhaps a custom environment implementation could prevent that, though ... 
 
cW 
 
On Wed, 2008-06-11 at 16:11 +0100, Adolfo Sánchez-Barbudo Herrera wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Jonnatan,

I would need more info to see if this alternative can help you...but, 
Have you tried to create a nested Environment just in the moment where 
you need to add the helper operation, so that you use the nested 
environment in that scope (variables from parent environments should be 
accessible). Once you don't need the operation anymore, you can go on 
with your previous (parent) environment.

If your necessities are similar to the scoping problem in programming 
languages, using scoped Environments should help you in your task.

Cheers,
Adolfo.

Jonathan MUSSET escribió:
> Thanks for your answers
> It's OK for me. The bug number is Bug 236604.
> Adolfo, I'm working on the MTL plugin and I have to define and un-define 
> an MTL/OCL helper, because the helper mustn't be accessible everywhere...
> Cheers,
> 
> Jonathan
> 
> 
> Christian W. Damus a écrit :
>> Hi, Jonathan,
>>
>> To follow up Adolfo's very helpful answer with some information about 
>> the API intent of the Environment::defineOperation method: this API 
>> is intended to be used by the OCL parser in processing additional 
>> operation definitions ("def expressions"). Also, specialized 
>> environment implementations (subclassing, for example, the 
>> EcoreEnvironment) might use it to add custom operations as described 
>> in the "Customizing the Environment" topic in the Developer Guide. 
>> Otherwise, it isn't intended to be used by clients.
>>
>> Note that you can use the OCLHelper::define(...) API to create 
>> additional operations using OCL, that are local to the current 
>> environment.
>>
>> As Adolfo indicated, there is currently no way to un-define an 
>> operation except by disposing the environment and creating a new one. 
>> If you would like to raise an enhancement request in bugzilla, we 
>> could consider the use cases for a feature in the next release.
>>
>> Cheers,
>>
>> Christian
>>
>> On Thu, 2008-06-05 at 18:51 +0200, Jonathan MUSSET wrote:
>>> Hi,
>>> I'm using the EcoreEnvironment and I need to add some elements like 
>>> Variable and Operation.
>>> I'm using the following code :
>>>
>>> ((EcoreEnvironment)helper.getOCL().getEnvironment()).addElem ent(newVariable.getName(), 
>>> newVariable,
>>> true);
>>> 
>>> ((EcoreEnvironment)helper.getOCL().getEnvironment()).defineO peration(owner, 
>>>
>>> name, type, params, constraint);
>>> 
>>> So, it is quite simple to register Variable and define a new 
>>> operation, but How can I delete my elements?
>>> In my opinion, it is dangerous to call the deleteElement method 
>>> (Operations can have the same names)... Is there another solution?
>>>
>>> helper.getOCL().getEnvironment().deleteElement(oldVariable.g etName()); 
>>> helper.getOCL().getEnvironment().deleteElement(oldOperation. getName()); 
>>> ??? Is it the good solution to delete an operation?
>>>
>>> Regards,
>>>
>>> Jonathan
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-A2XQD7CXSwq7xg8zb5PR--

Report message to a moderator

Previous Topic:	how to detect cycle in OCL
Next Topic:	query Instance specification

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 13:18:14 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter