Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » EPackage to Profile mapping
EPackage to Profile mapping [message #476429] Thu, 25 October 2007 15:10 Go to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi,

The static profile definition capability relies on a mapping of EPackage
namespace URIs to URIs locating the corresponding UML Profiles (populated
in Eclipse environment from an extension point).

Why was it necessary to introduce this registry? It would seem, at first
blush, that EMF's support for registration of genmodels would cover this
need by mapping the EPackage to the GenModel, then getting the foreign
model from that.

I am particularly interested because, in OCL, I need to be able to map
EPackages not only to Profiles but to any UML package in order to find the
UML metamodel from which the Java classes describing run-time objects were
generated. Perhaps this mapping needs to be extended to metamodels as well
as profiles?

Thanks,

Christian
Re: EPackage to Profile mapping [message #476432 is a reply to message #476429] Fri, 26 October 2007 13:42 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Christian,

The very first attempt at implementing this did involve attempting to use
the foreign model but a dedicated extension point was deemed a better choice
for several reasons:

1. A generator model is a development time artifact that need not be
deployed with the profile.
2. As a performance concern, parsing the generator model just to get back
the .uml model which may be one of several foreign models seemed like a lot
of overhead.

For the above mentioned reasons, an extension point dedicated to profiles
seemed like a more robust alternative.

Cheers,

- James.


"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ffqbkh$9k$1@build.eclipse.org...
> Hi,
>
> The static profile definition capability relies on a mapping of EPackage
> namespace URIs to URIs locating the corresponding UML Profiles (populated
> in Eclipse environment from an extension point).
>
> Why was it necessary to introduce this registry? It would seem, at first
> blush, that EMF's support for registration of genmodels would cover this
> need by mapping the EPackage to the GenModel, then getting the foreign
> model from that.
>
> I am particularly interested because, in OCL, I need to be able to map
> EPackages not only to Profiles but to any UML package in order to find the
> UML metamodel from which the Java classes describing run-time objects were
> generated. Perhaps this mapping needs to be extended to metamodels as
> well
> as profiles?
>
> Thanks,
>
> Christian
Re: EPackage to Profile mapping [message #476436 is a reply to message #476432] Fri, 26 October 2007 17:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, James,

Thanks, that makes sense.

Any sense on the idea of extending this function to all generated Packages?
:-)

cW

James Bruck wrote:

> Hi Christian,
>
> The very first attempt at implementing this did involve attempting to use
> the foreign model but a dedicated extension point was deemed a better
> choice for several reasons:
>
> 1. A generator model is a development time artifact that need not be
> deployed with the profile.
> 2. As a performance concern, parsing the generator model just to get back
> the .uml model which may be one of several foreign models seemed like a
> lot of overhead.
>
> For the above mentioned reasons, an extension point dedicated to profiles
> seemed like a more robust alternative.
>
> Cheers,
>
> - James.
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:ffqbkh$9k$1@build.eclipse.org...
>> Hi,
>>
>> The static profile definition capability relies on a mapping of EPackage
>> namespace URIs to URIs locating the corresponding UML Profiles (populated
>> in Eclipse environment from an extension point).
>>
>> Why was it necessary to introduce this registry? It would seem, at first
>> blush, that EMF's support for registration of genmodels would cover this
>> need by mapping the EPackage to the GenModel, then getting the foreign
>> model from that.
>>
>> I am particularly interested because, in OCL, I need to be able to map
>> EPackages not only to Profiles but to any UML package in order to find
>> the UML metamodel from which the Java classes describing run-time objects
>> were
>> generated. Perhaps this mapping needs to be extended to metamodels as
>> well
>> as profiles?
>>
>> Thanks,
>>
>> Christian
Re: EPackage to Profile mapping [message #476438 is a reply to message #476436] Sun, 28 October 2007 00:29 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Christian,

The mapping could be extended. I'll make the long trek over to your
cubicle so we can discuss the details ;)

Cheers,
- James.


"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fft70e$lmn$1@build.eclipse.org...
> Hi, James,
>
> Thanks, that makes sense.
>
> Any sense on the idea of extending this function to all generated
> Packages?
> :-)
>
> cW
>
> James Bruck wrote:
>
>> Hi Christian,
>>
>> The very first attempt at implementing this did involve attempting to use
>> the foreign model but a dedicated extension point was deemed a better
>> choice for several reasons:
>>
>> 1. A generator model is a development time artifact that need not be
>> deployed with the profile.
>> 2. As a performance concern, parsing the generator model just to get back
>> the .uml model which may be one of several foreign models seemed like a
>> lot of overhead.
>>
>> For the above mentioned reasons, an extension point dedicated to profiles
>> seemed like a more robust alternative.
>>
>> Cheers,
>>
>> - James.
>>
>>
>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>> news:ffqbkh$9k$1@build.eclipse.org...
>>> Hi,
>>>
>>> The static profile definition capability relies on a mapping of EPackage
>>> namespace URIs to URIs locating the corresponding UML Profiles
>>> (populated
>>> in Eclipse environment from an extension point).
>>>
>>> Why was it necessary to introduce this registry? It would seem, at
>>> first
>>> blush, that EMF's support for registration of genmodels would cover this
>>> need by mapping the EPackage to the GenModel, then getting the foreign
>>> model from that.
>>>
>>> I am particularly interested because, in OCL, I need to be able to map
>>> EPackages not only to Profiles but to any UML package in order to find
>>> the UML metamodel from which the Java classes describing run-time
>>> objects
>>> were
>>> generated. Perhaps this mapping needs to be extended to metamodels as
>>> well
>>> as profiles?
>>>
>>> Thanks,
>>>
>>> Christian
>
Re: EPackage to Profile mapping [message #476843 is a reply to message #476438] Thu, 10 January 2008 16:17 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
James,

Any update on the in-cubicle discussion? Was a decision made to make any
changes here? Note that EMF has added support for registering dynamic
packages (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239)...
should consider a similar registry for dynamic profiles? Doing so might
obliviate the need for a profile registry, i.e. it would provide a discovery
mechanism for "known" profiles...

Kenn

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:fg0l61$p0k$1@build.eclipse.org...
> Hi Christian,
>
> The mapping could be extended. I'll make the long trek over to your
> cubicle so we can discuss the details ;)
>
> Cheers,
> - James.
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:fft70e$lmn$1@build.eclipse.org...
>> Hi, James,
>>
>> Thanks, that makes sense.
>>
>> Any sense on the idea of extending this function to all generated
>> Packages?
>> :-)
>>
>> cW
>>
>> James Bruck wrote:
>>
>>> Hi Christian,
>>>
>>> The very first attempt at implementing this did involve attempting to
>>> use
>>> the foreign model but a dedicated extension point was deemed a better
>>> choice for several reasons:
>>>
>>> 1. A generator model is a development time artifact that need not be
>>> deployed with the profile.
>>> 2. As a performance concern, parsing the generator model just to get
>>> back
>>> the .uml model which may be one of several foreign models seemed like a
>>> lot of overhead.
>>>
>>> For the above mentioned reasons, an extension point dedicated to
>>> profiles
>>> seemed like a more robust alternative.
>>>
>>> Cheers,
>>>
>>> - James.
>>>
>>>
>>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>>> news:ffqbkh$9k$1@build.eclipse.org...
>>>> Hi,
>>>>
>>>> The static profile definition capability relies on a mapping of
>>>> EPackage
>>>> namespace URIs to URIs locating the corresponding UML Profiles
>>>> (populated
>>>> in Eclipse environment from an extension point).
>>>>
>>>> Why was it necessary to introduce this registry? It would seem, at
>>>> first
>>>> blush, that EMF's support for registration of genmodels would cover
>>>> this
>>>> need by mapping the EPackage to the GenModel, then getting the foreign
>>>> model from that.
>>>>
>>>> I am particularly interested because, in OCL, I need to be able to map
>>>> EPackages not only to Profiles but to any UML package in order to find
>>>> the UML metamodel from which the Java classes describing run-time
>>>> objects
>>>> were
>>>> generated. Perhaps this mapping needs to be extended to metamodels as
>>>> well
>>>> as profiles?
>>>>
>>>> Thanks,
>>>>
>>>> Christian
>>
>
>
Re: EPackage to Profile mapping [message #476844 is a reply to message #476843] Fri, 11 January 2008 18:37 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Kenn,

Yes absolutely, UML could use a similar registry to provide a list of all
"known" profiles.
Thanks for pointing it out. I will raise a bugzilla on UML to address
this.

Cheers,
- James.


"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message
news:fm5gds$prk$1@build.eclipse.org...
> James,
>
> Any update on the in-cubicle discussion? Was a decision made to make any
> changes here? Note that EMF has added support for registering dynamic
> packages (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239)...
> should consider a similar registry for dynamic profiles? Doing so might
> obliviate the need for a profile registry, i.e. it would provide a
> discovery mechanism for "known" profiles...
>
> Kenn
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:fg0l61$p0k$1@build.eclipse.org...
>> Hi Christian,
>>
>> The mapping could be extended. I'll make the long trek over to your
>> cubicle so we can discuss the details ;)
>>
>> Cheers,
>> - James.
>>
>>
>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>> news:fft70e$lmn$1@build.eclipse.org...
>>> Hi, James,
>>>
>>> Thanks, that makes sense.
>>>
>>> Any sense on the idea of extending this function to all generated
>>> Packages?
>>> :-)
>>>
>>> cW
>>>
>>> James Bruck wrote:
>>>
>>>> Hi Christian,
>>>>
>>>> The very first attempt at implementing this did involve attempting to
>>>> use
>>>> the foreign model but a dedicated extension point was deemed a better
>>>> choice for several reasons:
>>>>
>>>> 1. A generator model is a development time artifact that need not be
>>>> deployed with the profile.
>>>> 2. As a performance concern, parsing the generator model just to get
>>>> back
>>>> the .uml model which may be one of several foreign models seemed like a
>>>> lot of overhead.
>>>>
>>>> For the above mentioned reasons, an extension point dedicated to
>>>> profiles
>>>> seemed like a more robust alternative.
>>>>
>>>> Cheers,
>>>>
>>>> - James.
>>>>
>>>>
>>>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>>>> news:ffqbkh$9k$1@build.eclipse.org...
>>>>> Hi,
>>>>>
>>>>> The static profile definition capability relies on a mapping of
>>>>> EPackage
>>>>> namespace URIs to URIs locating the corresponding UML Profiles
>>>>> (populated
>>>>> in Eclipse environment from an extension point).
>>>>>
>>>>> Why was it necessary to introduce this registry? It would seem, at
>>>>> first
>>>>> blush, that EMF's support for registration of genmodels would cover
>>>>> this
>>>>> need by mapping the EPackage to the GenModel, then getting the foreign
>>>>> model from that.
>>>>>
>>>>> I am particularly interested because, in OCL, I need to be able to map
>>>>> EPackages not only to Profiles but to any UML package in order to find
>>>>> the UML metamodel from which the Java classes describing run-time
>>>>> objects
>>>>> were
>>>>> generated. Perhaps this mapping needs to be extended to metamodels as
>>>>> well
>>>>> as profiles?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Christian
>>>
>>
>>
>
>
Re: EPackage to Profile mapping [message #625335 is a reply to message #476429] Fri, 26 October 2007 13:42 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Christian,

The very first attempt at implementing this did involve attempting to use
the foreign model but a dedicated extension point was deemed a better choice
for several reasons:

1. A generator model is a development time artifact that need not be
deployed with the profile.
2. As a performance concern, parsing the generator model just to get back
the .uml model which may be one of several foreign models seemed like a lot
of overhead.

For the above mentioned reasons, an extension point dedicated to profiles
seemed like a more robust alternative.

Cheers,

- James.


"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ffqbkh$9k$1@build.eclipse.org...
> Hi,
>
> The static profile definition capability relies on a mapping of EPackage
> namespace URIs to URIs locating the corresponding UML Profiles (populated
> in Eclipse environment from an extension point).
>
> Why was it necessary to introduce this registry? It would seem, at first
> blush, that EMF's support for registration of genmodels would cover this
> need by mapping the EPackage to the GenModel, then getting the foreign
> model from that.
>
> I am particularly interested because, in OCL, I need to be able to map
> EPackages not only to Profiles but to any UML package in order to find the
> UML metamodel from which the Java classes describing run-time objects were
> generated. Perhaps this mapping needs to be extended to metamodels as
> well
> as profiles?
>
> Thanks,
>
> Christian
Re: EPackage to Profile mapping [message #625339 is a reply to message #476432] Fri, 26 October 2007 17:09 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, James,

Thanks, that makes sense.

Any sense on the idea of extending this function to all generated Packages?
:-)

cW

James Bruck wrote:

> Hi Christian,
>
> The very first attempt at implementing this did involve attempting to use
> the foreign model but a dedicated extension point was deemed a better
> choice for several reasons:
>
> 1. A generator model is a development time artifact that need not be
> deployed with the profile.
> 2. As a performance concern, parsing the generator model just to get back
> the .uml model which may be one of several foreign models seemed like a
> lot of overhead.
>
> For the above mentioned reasons, an extension point dedicated to profiles
> seemed like a more robust alternative.
>
> Cheers,
>
> - James.
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:ffqbkh$9k$1@build.eclipse.org...
>> Hi,
>>
>> The static profile definition capability relies on a mapping of EPackage
>> namespace URIs to URIs locating the corresponding UML Profiles (populated
>> in Eclipse environment from an extension point).
>>
>> Why was it necessary to introduce this registry? It would seem, at first
>> blush, that EMF's support for registration of genmodels would cover this
>> need by mapping the EPackage to the GenModel, then getting the foreign
>> model from that.
>>
>> I am particularly interested because, in OCL, I need to be able to map
>> EPackages not only to Profiles but to any UML package in order to find
>> the UML metamodel from which the Java classes describing run-time objects
>> were
>> generated. Perhaps this mapping needs to be extended to metamodels as
>> well
>> as profiles?
>>
>> Thanks,
>>
>> Christian
Re: EPackage to Profile mapping [message #625341 is a reply to message #476436] Sun, 28 October 2007 00:29 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Christian,

The mapping could be extended. I'll make the long trek over to your
cubicle so we can discuss the details ;)

Cheers,
- James.


"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fft70e$lmn$1@build.eclipse.org...
> Hi, James,
>
> Thanks, that makes sense.
>
> Any sense on the idea of extending this function to all generated
> Packages?
> :-)
>
> cW
>
> James Bruck wrote:
>
>> Hi Christian,
>>
>> The very first attempt at implementing this did involve attempting to use
>> the foreign model but a dedicated extension point was deemed a better
>> choice for several reasons:
>>
>> 1. A generator model is a development time artifact that need not be
>> deployed with the profile.
>> 2. As a performance concern, parsing the generator model just to get back
>> the .uml model which may be one of several foreign models seemed like a
>> lot of overhead.
>>
>> For the above mentioned reasons, an extension point dedicated to profiles
>> seemed like a more robust alternative.
>>
>> Cheers,
>>
>> - James.
>>
>>
>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>> news:ffqbkh$9k$1@build.eclipse.org...
>>> Hi,
>>>
>>> The static profile definition capability relies on a mapping of EPackage
>>> namespace URIs to URIs locating the corresponding UML Profiles
>>> (populated
>>> in Eclipse environment from an extension point).
>>>
>>> Why was it necessary to introduce this registry? It would seem, at
>>> first
>>> blush, that EMF's support for registration of genmodels would cover this
>>> need by mapping the EPackage to the GenModel, then getting the foreign
>>> model from that.
>>>
>>> I am particularly interested because, in OCL, I need to be able to map
>>> EPackages not only to Profiles but to any UML package in order to find
>>> the UML metamodel from which the Java classes describing run-time
>>> objects
>>> were
>>> generated. Perhaps this mapping needs to be extended to metamodels as
>>> well
>>> as profiles?
>>>
>>> Thanks,
>>>
>>> Christian
>
Re: EPackage to Profile mapping [message #625891 is a reply to message #476438] Thu, 10 January 2008 16:17 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
James,

Any update on the in-cubicle discussion? Was a decision made to make any
changes here? Note that EMF has added support for registering dynamic
packages (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239)...
should consider a similar registry for dynamic profiles? Doing so might
obliviate the need for a profile registry, i.e. it would provide a discovery
mechanism for "known" profiles...

Kenn

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:fg0l61$p0k$1@build.eclipse.org...
> Hi Christian,
>
> The mapping could be extended. I'll make the long trek over to your
> cubicle so we can discuss the details ;)
>
> Cheers,
> - James.
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:fft70e$lmn$1@build.eclipse.org...
>> Hi, James,
>>
>> Thanks, that makes sense.
>>
>> Any sense on the idea of extending this function to all generated
>> Packages?
>> :-)
>>
>> cW
>>
>> James Bruck wrote:
>>
>>> Hi Christian,
>>>
>>> The very first attempt at implementing this did involve attempting to
>>> use
>>> the foreign model but a dedicated extension point was deemed a better
>>> choice for several reasons:
>>>
>>> 1. A generator model is a development time artifact that need not be
>>> deployed with the profile.
>>> 2. As a performance concern, parsing the generator model just to get
>>> back
>>> the .uml model which may be one of several foreign models seemed like a
>>> lot of overhead.
>>>
>>> For the above mentioned reasons, an extension point dedicated to
>>> profiles
>>> seemed like a more robust alternative.
>>>
>>> Cheers,
>>>
>>> - James.
>>>
>>>
>>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>>> news:ffqbkh$9k$1@build.eclipse.org...
>>>> Hi,
>>>>
>>>> The static profile definition capability relies on a mapping of
>>>> EPackage
>>>> namespace URIs to URIs locating the corresponding UML Profiles
>>>> (populated
>>>> in Eclipse environment from an extension point).
>>>>
>>>> Why was it necessary to introduce this registry? It would seem, at
>>>> first
>>>> blush, that EMF's support for registration of genmodels would cover
>>>> this
>>>> need by mapping the EPackage to the GenModel, then getting the foreign
>>>> model from that.
>>>>
>>>> I am particularly interested because, in OCL, I need to be able to map
>>>> EPackages not only to Profiles but to any UML package in order to find
>>>> the UML metamodel from which the Java classes describing run-time
>>>> objects
>>>> were
>>>> generated. Perhaps this mapping needs to be extended to metamodels as
>>>> well
>>>> as profiles?
>>>>
>>>> Thanks,
>>>>
>>>> Christian
>>
>
>
Re: EPackage to Profile mapping [message #625892 is a reply to message #476843] Fri, 11 January 2008 18:37 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Kenn,

Yes absolutely, UML could use a similar registry to provide a list of all
"known" profiles.
Thanks for pointing it out. I will raise a bugzilla on UML to address
this.

Cheers,
- James.


"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message
news:fm5gds$prk$1@build.eclipse.org...
> James,
>
> Any update on the in-cubicle discussion? Was a decision made to make any
> changes here? Note that EMF has added support for registering dynamic
> packages (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239)...
> should consider a similar registry for dynamic profiles? Doing so might
> obliviate the need for a profile registry, i.e. it would provide a
> discovery mechanism for "known" profiles...
>
> Kenn
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:fg0l61$p0k$1@build.eclipse.org...
>> Hi Christian,
>>
>> The mapping could be extended. I'll make the long trek over to your
>> cubicle so we can discuss the details ;)
>>
>> Cheers,
>> - James.
>>
>>
>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>> news:fft70e$lmn$1@build.eclipse.org...
>>> Hi, James,
>>>
>>> Thanks, that makes sense.
>>>
>>> Any sense on the idea of extending this function to all generated
>>> Packages?
>>> :-)
>>>
>>> cW
>>>
>>> James Bruck wrote:
>>>
>>>> Hi Christian,
>>>>
>>>> The very first attempt at implementing this did involve attempting to
>>>> use
>>>> the foreign model but a dedicated extension point was deemed a better
>>>> choice for several reasons:
>>>>
>>>> 1. A generator model is a development time artifact that need not be
>>>> deployed with the profile.
>>>> 2. As a performance concern, parsing the generator model just to get
>>>> back
>>>> the .uml model which may be one of several foreign models seemed like a
>>>> lot of overhead.
>>>>
>>>> For the above mentioned reasons, an extension point dedicated to
>>>> profiles
>>>> seemed like a more robust alternative.
>>>>
>>>> Cheers,
>>>>
>>>> - James.
>>>>
>>>>
>>>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>>>> news:ffqbkh$9k$1@build.eclipse.org...
>>>>> Hi,
>>>>>
>>>>> The static profile definition capability relies on a mapping of
>>>>> EPackage
>>>>> namespace URIs to URIs locating the corresponding UML Profiles
>>>>> (populated
>>>>> in Eclipse environment from an extension point).
>>>>>
>>>>> Why was it necessary to introduce this registry? It would seem, at
>>>>> first
>>>>> blush, that EMF's support for registration of genmodels would cover
>>>>> this
>>>>> need by mapping the EPackage to the GenModel, then getting the foreign
>>>>> model from that.
>>>>>
>>>>> I am particularly interested because, in OCL, I need to be able to map
>>>>> EPackages not only to Profiles but to any UML package in order to find
>>>>> the UML metamodel from which the Java classes describing run-time
>>>>> objects
>>>>> were
>>>>> generated. Perhaps this mapping needs to be extended to metamodels as
>>>>> well
>>>>> as profiles?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Christian
>>>
>>
>>
>
>
Previous Topic:stereotype application to an Operation
Next Topic:Primitive Type reuse
Goto Forum:
  


Current Time: Fri Aug 12 22:15:30 GMT 2022

Powered by FUDForum. Page generated in 0.02617 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top