Eclipse Community Forums: UML2 » Private visibility of UML class attributes

Help

Home

Home » Modeling » UML2 » Private visibility of UML class attributes

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

Private visibility of UML class attributes [message #477782]

Fri, 03 October 2008 18:19

Firas Swidan

Messages: 13
Registered: July 2009

Junior Member

Hi,

I am trying to use a simple UML -> Ecore -> java code transformation to
generate java code from a UML class diagram (on a side note, I had to read
material and view movies for 2-3 days to figure out how to do the above
basic operation. Though I am totally new to MDA, it would have been nice
to have a faster kick start).

I specify the visibility of an attribute in a UML2 class to private (using
UML2 tools graphical interface). However, the generated java code declares
the generated attribute as protected. Am I doing something wrong? I
noticed that the intermediate ecore model lacks the equivalent of
visibility. Is this the source of the problem? If so, is there a way to
bypass the ecore model and generate the java code directly from the UML
(my understanding is that ecore is a higher level of MOF abstraction than
UML. If so, it is weird that one needs to go up the MOF hierarchy before
going down again to the code level).

Thanks for any tips and corrections.
Firas.

Report message to a moderator

Re: Private visibility of UML class attributes [message #477783 is a reply to message #477782]

Fri, 03 October 2008 18:58

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------080500010607090402080502
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Firas,

I should mind my own business, but what the heck. Comments below.

Firas Swidan, PhD wrote:
> Hi,
>
> I am trying to use a simple UML -> Ecore -> java code transformation
> to generate java code from a UML class diagram (on a side note, I had
> to read material and view movies for 2-3 days to figure out how to do
> the above basic operation.
You might have dispensed with UML and started directly with Ecore. The
Ecore Tools editor is awesome:
http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml
> Though I am totally new to MDA, it would have been nice to have a
> faster kick start).
A tutorial analogous to this one would be handy:

Tutorial: Generating an EMF Model using XML Schema
< http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.emf.doc/tutorials/xlibmod/xlibmod.html>

Mind you, all the same ideas apply, other than that it starts with a
*.xsd instead of a UML model.
>
> I specify the visibility of an attribute in a UML2 class to private
> (using UML2 tools graphical interface). However, the generated java
> code declares the generated attribute as protected.
You should thing of the attributes as being equivalent to the generated
accessors in the API. I.e., if class Ahas attribute x, the generated
interface for A will have getX and and setX methods. In the
implementation (which you can hide in your plugin so that no one outside
your plugin can even see those classes) declares fields to correspond to
these. The default code generation patterns need to access these fields
in derived classes and hence make them protected.
> Am I doing something wrong?
Nope.
> I noticed that the intermediate ecore model lacks the equivalent of
> visibility.
Yes. Ecore is focused on defining the public API of the model, i.e.,
primarily Java interfaces. Either something is in the interface or it
is not. Interfaces don't support protected and private. The
implementation classes are not intended to be accessed by clients at
all. You can even hide them so it's impossible for clients to access them.
> Is this the source of the problem?
Yes and no.
> If so, is there a way to bypass the ecore model and generate the java
> code directly from the UML
You can certainly write templates directly against UML but I think it's
a bit hard to map all of UML onto Java is a generally meaningful way...
> (my understanding is that ecore is a higher level of MOF abstraction
> than UML.
Not sure which way your abstraction layers grow Ecore is effectively
equivalent to EMOF...
> If so, it is weird that one needs to go up the MOF hierarchy before
> going down again to the code level).
Probably you have some misconceptions. Keep in mind that while a UML
class diagram might use multiple inheritance, so if a UML class just
maps directly to a Java class and Java classes don't support multiple
inheritance then this simple mapping isn't fully general. So from an
Ecore point of view, a model (class) is defining an API and APIs don't
support this kind of protected and private visibility (and via
reflection, all data is visible, if if there isn't a method in the API
to access it).
>
> Thanks for any tips and corrections.
> Firas.
>

--------------080500010607090402080502
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Firas,<br>
<br>
I should mind my own business, but what the heck.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Private visibility of UML class attributes [message #477784 is a reply to message #477783]

Fri, 03 October 2008 19:19

Firas Swidan

Messages: 13
Registered: July 2009

Junior Member

Hi Ed,

thanks for the clarifications and the links. Though I have read/watched
many of your writings/videos, I find now the two points regarding mapping
ecore classes to java interfaces and dealing with multiple inheritance
very helpful.

I did not mean my previous email to be provoking. I am very excited from
the idea of code generation and the EMF project. I was trying to convey my
point of view hoping that it could be of some help to the project :-).

Thanks again and best wishes,
Firas.

Ed Merks wrote:

> Firas,

> I should mind my own business, but what the heck. Comments below.

> Firas Swidan, PhD wrote:
>> Hi,
>>
>> I am trying to use a simple UML -> Ecore -> java code transformation
>> to generate java code from a UML class diagram (on a side note, I had
>> to read material and view movies for 2-3 days to figure out how to do
>> the above basic operation.
> You might have dispensed with UML and started directly with Ecore. The
> Ecore Tools editor is awesome:
> http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml
>> Though I am totally new to MDA, it would have been nice to have a
>> faster kick start).
> A tutorial analogous to this one would be handy:

> Tutorial: Generating an EMF Model using XML Schema
>
< http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.emf.doc/tutorials/xlibmod/xlibmod.html>

> Mind you, all the same ideas apply, other than that it starts with a
> *.xsd instead of a UML model.
>>
>> I specify the visibility of an attribute in a UML2 class to private
>> (using UML2 tools graphical interface). However, the generated java
>> code declares the generated attribute as protected.
> You should thing of the attributes as being equivalent to the generated
> accessors in the API. I.e., if class Ahas attribute x, the generated
> interface for A will have getX and and setX methods. In the
> implementation (which you can hide in your plugin so that no one outside
> your plugin can even see those classes) declares fields to correspond to
> these. The default code generation patterns need to access these fields
> in derived classes and hence make them protected.
>> Am I doing something wrong?
> Nope.
>> I noticed that the intermediate ecore model lacks the equivalent of
>> visibility.
> Yes. Ecore is focused on defining the public API of the model, i.e.,
> primarily Java interfaces. Either something is in the interface or it
> is not. Interfaces don't support protected and private. The
> implementation classes are not intended to be accessed by clients at
> all. You can even hide them so it's impossible for clients to access them.
>> Is this the source of the problem?
> Yes and no.
>> If so, is there a way to bypass the ecore model and generate the java
>> code directly from the UML
> You can certainly write templates directly against UML but I think it's
> a bit hard to map all of UML onto Java is a generally meaningful way...
>> (my understanding is that ecore is a higher level of MOF abstraction
>> than UML.
> Not sure which way your abstraction layers grow Ecore is effectively
> equivalent to EMOF...
>> If so, it is weird that one needs to go up the MOF hierarchy before
>> going down again to the code level).
> Probably you have some misconceptions. Keep in mind that while a UML
> class diagram might use multiple inheritance, so if a UML class just
> maps directly to a Java class and Java classes don't support multiple
> inheritance then this simple mapping isn't fully general. So from an
> Ecore point of view, a model (class) is defining an API and APIs don't
> support this kind of protected and private visibility (and via
> reflection, all data is visible, if if there isn't a method in the API
> to access it).
>>
>> Thanks for any tips and corrections.
>> Firas.
>>

Report message to a moderator

Re: Private visibility of UML class attributes [message #477785 is a reply to message #477784]

Fri, 03 October 2008 19:41

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Firas,

I'm not easily provoked and didn't interpret your note that way. There
are many subtle complexities and it's just all a little overwhelming
when you first get started. There's a whole stack of exceedingly cool
technology here at Eclipse. The comment about dispensing with UML is
mostly in jest (as a provocation); after all, UML is about more than
class diagrams and generating code from them. But if that's literally
all you need it for, it might be overkill...

Good luck with your explorations and adventures.

Firas Swidan, PhD wrote:
> Hi Ed,
>
> thanks for the clarifications and the links. Though I have
> read/watched many of your writings/videos, I find now the two points
> regarding mapping ecore classes to java interfaces and dealing with
> multiple inheritance very helpful.
>
> I did not mean my previous email to be provoking. I am very excited
> from the idea of code generation and the EMF project. I was trying to
> convey my point of view hoping that it could be of some help to the
> project :-).
>
> Thanks again and best wishes,
> Firas.
>
>
>
> Ed Merks wrote:
>
>> Firas,
>
>> I should mind my own business, but what the heck. Comments below.
>
>> Firas Swidan, PhD wrote:
>>> Hi,
>>>
>>> I am trying to use a simple UML -> Ecore -> java code transformation
>>> to generate java code from a UML class diagram (on a side note, I
>>> had to read material and view movies for 2-3 days to figure out how
>>> to do the above basic operation.
>> You might have dispensed with UML and started directly with Ecore.
>> The Ecore Tools editor is awesome:
>> http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml
>>> Though I am totally new to MDA, it would have been nice to have a
>>> faster kick start).
>> A tutorial analogous to this one would be handy:
>
>> Tutorial: Generating an EMF Model using XML Schema
>>
> < http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.emf.doc/tutorials/xlibmod/xlibmod.html>
>
>
>> Mind you, all the same ideas apply, other than that it starts with a
>> *.xsd instead of a UML model.
>>>
>>> I specify the visibility of an attribute in a UML2 class to private
>>> (using UML2 tools graphical interface). However, the generated java
>>> code declares the generated attribute as protected.
>> You should thing of the attributes as being equivalent to the
>> generated accessors in the API. I.e., if class Ahas attribute x, the
>> generated interface for A will have getX and and setX methods. In
>> the implementation (which you can hide in your plugin so that no one
>> outside your plugin can even see those classes) declares fields to
>> correspond to these. The default code generation patterns need to
>> access these fields in derived classes and hence make them protected.
>>> Am I doing something wrong?
>> Nope.
>>> I noticed that the intermediate ecore model lacks the equivalent of
>>> visibility.
>> Yes. Ecore is focused on defining the public API of the model, i.e.,
>> primarily Java interfaces. Either something is in the interface or
>> it is not. Interfaces don't support protected and private. The
>> implementation classes are not intended to be accessed by clients at
>> all. You can even hide them so it's impossible for clients to access
>> them.
>>> Is this the source of the problem?
>> Yes and no.
>>> If so, is there a way to bypass the ecore model and generate the
>>> java code directly from the UML
>> You can certainly write templates directly against UML but I think
>> it's a bit hard to map all of UML onto Java is a generally meaningful
>> way...
>>> (my understanding is that ecore is a higher level of MOF abstraction
>>> than UML.
>> Not sure which way your abstraction layers grow Ecore is effectively
>> equivalent to EMOF...
>>> If so, it is weird that one needs to go up the MOF hierarchy before
>>> going down again to the code level).
>> Probably you have some misconceptions. Keep in mind that while a
>> UML class diagram might use multiple inheritance, so if a UML class
>> just maps directly to a Java class and Java classes don't support
>> multiple inheritance then this simple mapping isn't fully general.
>> So from an Ecore point of view, a model (class) is defining an API
>> and APIs don't support this kind of protected and private visibility
>> (and via reflection, all data is visible, if if there isn't a method
>> in the API to access it).
>>>
>>> Thanks for any tips and corrections.
>>> Firas.
>>>
>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Private visibility of UML class attributes [message #477786 is a reply to message #477785]

Mon, 06 October 2008 15:01

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Ed and Firas,

Firas,
The UML FAQ http://wiki.eclipse.org/MDT/UML2/FAQ provides some indication
of how to get generated code from your UML model.
Other "getting started" documentation can be found here
http://wiki.eclipse.org/MDT-UML2.
When you create your EMF project you can directly import .uml models.
You can also directly convert your .uml model from the UML editor by
using the menu item "UML Editor > Convert To > Ecore Model ...".
Keep in mind that anything that can be modeled in with EMF, can also be
expressed with UML (including generics)... but not vice versa.
You can also integrate OCL constraints with your UML models :
http://www.eclipse.org/modeling/mdt/uml2/docs/presentations/ EclipseCon2008_LongTalk_NewFeaturesOfUML2_files/frame.htm

Ed,
"...dispensing with UML.." ... ouch ;) . All your points are valid but I
wanted to point out that there are some really cool and intersting things
one can do with UML.
Take for example, redefinition, subsetting, derived unions, package
merge, profiles, not to mention ability to express behavioral aspects of a
model.

I think we should do a tag-team presentation at EclipseCon. You could
argue why EMF is good enough and I could point out the value that UML
provides.
In the end I would concede that EMF really is all that one needs ... just
kidding :-)

Cheers,
- James.

"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:gc5shm$4cp$1@build.eclipse.org...
> Firas,
>
> I'm not easily provoked and didn't interpret your note that way. There
> are many subtle complexities and it's just all a little overwhelming when
> you first get started. There's a whole stack of exceedingly cool
> technology here at Eclipse. The comment about dispensing with UML is
> mostly in jest (as a provocation); after all, UML is about more than class
> diagrams and generating code from them. But if that's literally all you
> need it for, it might be overkill...
>
> Good luck with your explorations and adventures.
>
>
> Firas Swidan, PhD wrote:
>> Hi Ed,
>>
>> thanks for the clarifications and the links. Though I have read/watched
>> many of your writings/videos, I find now the two points regarding mapping
>> ecore classes to java interfaces and dealing with multiple inheritance
>> very helpful.
>>
>> I did not mean my previous email to be provoking. I am very excited from
>> the idea of code generation and the EMF project. I was trying to convey
>> my point of view hoping that it could be of some help to the project :-).
>>
>> Thanks again and best wishes,
>> Firas.
>>
>>
>>
>> Ed Merks wrote:
>>
>>> Firas,
>>
>>> I should mind my own business, but what the heck. Comments below.
>>
>>> Firas Swidan, PhD wrote:
>>>> Hi,
>>>>
>>>> I am trying to use a simple UML -> Ecore -> java code transformation to
>>>> generate java code from a UML class diagram (on a side note, I had to
>>>> read material and view movies for 2-3 days to figure out how to do the
>>>> above basic operation.
>>> You might have dispensed with UML and started directly with Ecore. The
>>> Ecore Tools editor is awesome:
>>> http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml
>>>> Though I am totally new to MDA, it would have been nice to have a
>>>> faster kick start).
>>> A tutorial analogous to this one would be handy:
>>
>>> Tutorial: Generating an EMF Model using XML Schema
>>>
>> < http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.emf.doc/tutorials/xlibmod/xlibmod.html>
>>
>>> Mind you, all the same ideas apply, other than that it starts with a
>>> *.xsd instead of a UML model.
>>>>
>>>> I specify the visibility of an attribute in a UML2 class to private
>>>> (using UML2 tools graphical interface). However, the generated java
>>>> code declares the generated attribute as protected.
>>> You should thing of the attributes as being equivalent to the generated
>>> accessors in the API. I.e., if class Ahas attribute x, the generated
>>> interface for A will have getX and and setX methods. In the
>>> implementation (which you can hide in your plugin so that no one outside
>>> your plugin can even see those classes) declares fields to correspond to
>>> these. The default code generation patterns need to access these fields
>>> in derived classes and hence make them protected.
>>>> Am I doing something wrong?
>>> Nope.
>>>> I noticed that the intermediate ecore model lacks the equivalent of
>>>> visibility.
>>> Yes. Ecore is focused on defining the public API of the model, i.e.,
>>> primarily Java interfaces. Either something is in the interface or it
>>> is not. Interfaces don't support protected and private. The
>>> implementation classes are not intended to be accessed by clients at
>>> all. You can even hide them so it's impossible for clients to access
>>> them.
>>>> Is this the source of the problem?
>>> Yes and no.
>>>> If so, is there a way to bypass the ecore model and generate the java
>>>> code directly from the UML
>>> You can certainly write templates directly against UML but I think it's
>>> a bit hard to map all of UML onto Java is a generally meaningful way...
>>>> (my understanding is that ecore is a higher level of MOF abstraction
>>>> than UML.
>>> Not sure which way your abstraction layers grow Ecore is effectively
>>> equivalent to EMOF...
>>>> If so, it is weird that one needs to go up the MOF hierarchy before
>>>> going down again to the code level).
>>> Probably you have some misconceptions. Keep in mind that while a UML
>>> class diagram might use multiple inheritance, so if a UML class just
>>> maps directly to a Java class and Java classes don't support multiple
>>> inheritance then this simple mapping isn't fully general. So from an
>>> Ecore point of view, a model (class) is defining an API and APIs don't
>>> support this kind of protected and private visibility (and via
>>> reflection, all data is visible, if if there isn't a method in the API
>>> to access it).
>>>>
>>>> Thanks for any tips and corrections.
>>>> Firas.
>>>>
>>
>>

Report message to a moderator

Re: Private visibility of UML class attributes [message #626982 is a reply to message #477782]

Fri, 03 October 2008 18:58

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Private visibility of UML class attributes [message #626983 is a reply to message #477783]

Fri, 03 October 2008 19:19

Firas Swidan

Messages: 13
Registered: July 2009

Junior Member

Report message to a moderator

Re: Private visibility of UML class attributes [message #626984 is a reply to message #477784]

Fri, 03 October 2008 19:41

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Private visibility of UML class attributes [message #626985 is a reply to message #477785]

Mon, 06 October 2008 15:01

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Ed and Firas,

Firas,
The UML FAQ http://wiki.eclipse.org/MDT/UML2/FAQ provides some indication
of how to get generated code from your UML model.
Other "getting started" documentation can be found here
http://wiki.eclipse.org/MDT-UML2
When you create your EMF project you can directly import .uml models.
You can also directly convert your .uml model from the UML editor by
using the menu item "UML Editor > Convert To > Ecore Model ...".
Keep in mind that anything that can be modeled in with EMF, can also be
expressed with UML (including generics)... but not vice versa.
You can also integrate OCL constraints with your UML models :
http://www.eclipse.org/modeling/mdt/uml2/docs/presentations/ EclipseCon2008_LongTalk_NewFeaturesOfUML2_files/frame.htm

Ed,
"...dispensing with UML.." ... ouch ;) . All your points are valid but I
wanted to point out that there are some really cool and intersting things
one can do with UML.
Take for example, redefinition, subsetting, derived unions, package
merge, profiles, not to mention ability to express behavioral aspects of a
model.

I think we should do a tag-team presentation at EclipseCon. You could
argue why EMF is good enough and I could point out the value that UML
provides.
In the end I would concede that EMF really is all that one needs ... just
kidding :-)

Cheers,
- James.

"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:gc5shm$4cp$1@build.eclipse.org...
> Firas,
>
> I'm not easily provoked and didn't interpret your note that way. There
> are many subtle complexities and it's just all a little overwhelming when
> you first get started. There's a whole stack of exceedingly cool
> technology here at Eclipse. The comment about dispensing with UML is
> mostly in jest (as a provocation); after all, UML is about more than class
> diagrams and generating code from them. But if that's literally all you
> need it for, it might be overkill...
>
> Good luck with your explorations and adventures.
>
>
> Firas Swidan, PhD wrote:
>> Hi Ed,
>>
>> thanks for the clarifications and the links. Though I have read/watched
>> many of your writings/videos, I find now the two points regarding mapping
>> ecore classes to java interfaces and dealing with multiple inheritance
>> very helpful.
>>
>> I did not mean my previous email to be provoking. I am very excited from
>> the idea of code generation and the EMF project. I was trying to convey
>> my point of view hoping that it could be of some help to the project :-).
>>
>> Thanks again and best wishes,
>> Firas.
>>
>>
>>
>> Ed Merks wrote:
>>
>>> Firas,
>>
>>> I should mind my own business, but what the heck. Comments below.
>>
>>> Firas Swidan, PhD wrote:
>>>> Hi,
>>>>
>>>> I am trying to use a simple UML -> Ecore -> java code transformation to
>>>> generate java code from a UML class diagram (on a side note, I had to
>>>> read material and view movies for 2-3 days to figure out how to do the
>>>> above basic operation.
>>> You might have dispensed with UML and started directly with Ecore. The
>>> Ecore Tools editor is awesome:
>>> http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml
>>>> Though I am totally new to MDA, it would have been nice to have a
>>>> faster kick start).
>>> A tutorial analogous to this one would be handy:
>>
>>> Tutorial: Generating an EMF Model using XML Schema
>>>
>> < http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.emf.doc/tutorials/xlibmod/xlibmod.html>
>>
>>> Mind you, all the same ideas apply, other than that it starts with a
>>> *.xsd instead of a UML model.
>>>>
>>>> I specify the visibility of an attribute in a UML2 class to private
>>>> (using UML2 tools graphical interface). However, the generated java
>>>> code declares the generated attribute as protected.
>>> You should thing of the attributes as being equivalent to the generated
>>> accessors in the API. I.e., if class Ahas attribute x, the generated
>>> interface for A will have getX and and setX methods. In the
>>> implementation (which you can hide in your plugin so that no one outside
>>> your plugin can even see those classes) declares fields to correspond to
>>> these. The default code generation patterns need to access these fields
>>> in derived classes and hence make them protected.
>>>> Am I doing something wrong?
>>> Nope.
>>>> I noticed that the intermediate ecore model lacks the equivalent of
>>>> visibility.
>>> Yes. Ecore is focused on defining the public API of the model, i.e.,
>>> primarily Java interfaces. Either something is in the interface or it
>>> is not. Interfaces don't support protected and private. The
>>> implementation classes are not intended to be accessed by clients at
>>> all. You can even hide them so it's impossible for clients to access
>>> them.
>>>> Is this the source of the problem?
>>> Yes and no.
>>>> If so, is there a way to bypass the ecore model and generate the java
>>>> code directly from the UML
>>> You can certainly write templates directly against UML but I think it's
>>> a bit hard to map all of UML onto Java is a generally meaningful way...
>>>> (my understanding is that ecore is a higher level of MOF abstraction
>>>> than UML.
>>> Not sure which way your abstraction layers grow Ecore is effectively
>>> equivalent to EMOF...
>>>> If so, it is weird that one needs to go up the MOF hierarchy before
>>>> going down again to the code level).
>>> Probably you have some misconceptions. Keep in mind that while a UML
>>> class diagram might use multiple inheritance, so if a UML class just
>>> maps directly to a Java class and Java classes don't support multiple
>>> inheritance then this simple mapping isn't fully general. So from an
>>> Ecore point of view, a model (class) is defining an API and APIs don't
>>> support this kind of protected and private visibility (and via
>>> reflection, all data is visible, if if there isn't a method in the API
>>> to access it).
>>>>
>>>> Thanks for any tips and corrections.
>>>> Firas.
>>>>
>>
>>

Report message to a moderator

Previous Topic:	Private visibility of UML class attributes
Next Topic:	UML Operation Object to EOperation

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Apr 24 15:25:21 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter