| EMF interface refs in generated code [message #537575] |
Wed, 02 June 2010 23:51  |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
In response to an improperly directed posting to emf-dev (below), Ed's response was:
GenModel properties like Suppress EMF Types set to true and Root Extends Interface set to blank will hide EMF from the public APIs, though of course they'll still be lurking behind the implementations.
[Scott]
Hi Ed. Follow up: The Suppress EMF Types and Root Extends are set as you describe, but it seems that the Enumerator type reference is still being added (no others are added...just the Enumerator ref). I'm trying to verify the EMF version from my colleagues...in case it might be a bug.
Is there something else/additional needed for enumeration types?
Thanksinadvance,
Scott
---- Scott's original question below -----
Scott Lewis wrote:
> Hi Folks,
>
> My apologies in advance if this is in the faq...I'm asking this on behalf of another party and can't track all discussions/history on EMF.
>
> What my colleague wants to do is to have EMF generate *interface* classes that do not reference or extend EMF.
> They are doing this now, for the most part (e.g. wrt EObject, etc), but they have some enumerator types (i.e. extends org.eclipse.emf.common.util.Enumerator). Is there an easy way to prevent this reference from being generated?
>
> Thanksinadvance,
>
> Scott
>
> _______________________________________________
> emf-dev mailing list
> emf-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/emf-dev
|
|
|
| Re: EMF interface refs in generated code [message #537578 is a reply to message #537575] |
Thu, 03 June 2010 00:10  |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Scott,
With the older type safe enumerator pattern for Java 1.4 we could hide
the implementation details in a derived class, but with an actual Java
5.0 enum.we can't extend it to implement the additional interface in a
hidden way. An EEnumLiteral's getInstance must be an Enumerator. Of
course you can implement an enum yourself and you can define an
EDataType to wrap it. So if someone wants absolute purity they have to
write their own enums by hand rather than making use of EMF's EEnum.
Scott Lewis wrote:
> In response to an improperly directed posting to emf-dev (below), Ed's
> response was:
> GenModel properties like Suppress EMF Types set to true and Root
> Extends Interface set to blank will hide EMF from the public APIs,
> though of course they'll still be lurking behind the implementations.
>
> [Scott]
>
> Hi Ed. Follow up: The Suppress EMF Types and Root Extends are set
> as you describe, but it seems that the Enumerator type reference is
> still being added (no others are added...just the Enumerator ref).
> I'm trying to verify the EMF version from my colleagues...in case it
> might be a bug.
>
> Is there something else/additional needed for enumeration types?
>
> Thanksinadvance,
>
> Scott
>
> ---- Scott's original question below -----
>
> Scott Lewis wrote:
>> Hi Folks,
>>
>> My apologies in advance if this is in the faq...I'm asking this on
>> behalf of another party and can't track all discussions/history on EMF.
>>
>> What my colleague wants to do is to have EMF generate *interface*
>> classes that do not reference or extend EMF.
>> They are doing this now, for the most part (e.g. wrt EObject, etc),
>> but they have some enumerator types (i.e. extends
>> org.eclipse.emf.common.util.Enumerator). Is there an easy way to
>> prevent this reference from being generated?
>>
>> Thanksinadvance,
>>
>> Scott
>>
>> _______________________________________________
>> emf-dev mailing list
>> mailto:emf-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/emf-dev
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02939 seconds
] 
Search
Help
Register
Login
Home
