Home » Modeling » EMF » EMF Java generation : interfaces packages versus implementation ones
| EMF Java generation : interfaces packages versus implementation ones [message #419470] |
Fri, 23 May 2008 12:30  |
 Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi,
Right now for a given Ecore model and it's associated genmodel the Java code
will get generated this way :
basepackage.ecorepackage for Interfaces
basepackage.ecorepackage.util for factory and package
basepackage.ecorepackage.impl for implementation classes
Setting values in the genmodel I can change the package suffix but not the
package prefix independently for Interfaces and implementations, what I
would like to achieve is something like that:
basepackage.api.ecorepackage for Interfaces
basepackage.api.ecorepackage.util for factory and package
basepackage.internal.ecorepackage for Java class implementation
What would be the best way to customize the generated path, dynamic
templates ? specific extension point ?
Thanks in advance !
Cédric
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
| |
| Re: EMF Java generation : interfaces packages versus implementation ones [message #419494 is a reply to message #419483] |
Sat, 24 May 2008 20:39  |
Rafael Chaves
Messages: 362
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> I think this naming pattern is bad. It's api unless it's internal. I
> think the internal details of "ecorepackage" should be nested under
> "ecorepackage", not above it. I have considered supporting substitution
> within the "suffix" properties so that "abc" is implicitly "{0}.abc",
> but I feel very strongly that the internals for a model should be nested
> under the namespace of the model's API. What good arguments can you
> make that some other alternative is better? Keep in mind that I think
> api is horrible and redundant. :-P
Ed, that is similar to the package organization used by all plug-ins in
the Eclipse Project itself, which is considered the ultimate exemplary
code by the plug-in development community. It would be great if EMF
could support that style out-of-the-box. The same is true for using
'IName' style for API interfaces and 'Name' for implementation classes,
which last time I looked was not supported. The way it is right now, one
cannot use the Eclipse Modeling Framework for generating Eclipse-style
API and package structure. Isn't that weird?
We are already off a tangent here (sorry, Cedric!), but my point is that
dictating a particular API style or package structure should not be
EMF's business. This lack of flexibility results in generated API that
won't fit into an organization's existing style, and in the worst case
might result in EMF being deemed unsuitable.
BTW, I don't like the 'api' segment either, but that really was not the
point of Cedric's post anyway (he just wanted to know how to do it, not
whether he should do it).
Cheers,
Rafael
|
|
|
| Re: EMF Java generation : interfaces packages versus implementation ones [message #419495 is a reply to message #419494] |
Sat, 24 May 2008 22:08 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Rafael,
Comments below.
Rafael Chaves wrote:
> Ed Merks wrote:
>
>> I think this naming pattern is bad. It's api unless it's internal.
>> I think the internal details of "ecorepackage" should be nested under
>> "ecorepackage", not above it. I have considered supporting
>> substitution within the "suffix" properties so that "abc" is
>> implicitly "{0}.abc", but I feel very strongly that the internals for
>> a model should be nested under the namespace of the model's API.
>> What good arguments can you make that some other alternative is
>> better? Keep in mind that I think api is horrible and redundant. :-P
>
> Ed, that is similar to the package organization used by all plug-ins
> in the Eclipse Project itself, which is considered the ultimate
> exemplary code by the plug-in development community.
It seems to me if you read the guidelines carefully that what I'm
suggesting conforms exactly to the guidelines. I.e. it's
org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
> It would be great if EMF could support that style out-of-the-box.
I'd still like to see a strong argument that says all things associated
with org.eclipse.xyz should be in a package other than org.eclipse.xyz.*...
> The same is true for using 'IName' style for API interfaces and 'Name'
> for implementation classes, which last time I looked was not supported.
Should SWT change its design to suit this style? I personally feel very
strongly that butchering the API names and keeping the "nice" names for
the internal implementation classes is a very bad approach. Of course
those who feel strongly enough about the issue can do more than just
talk about it, i.e., they can provide the code changes needed to support
what they want and in that way can have significant influence. I assume
that given that the implementation classes are internal, most people
ultimately don't care that it's IAbcImpl verses AbcImpl since no one
sees these classes anyway. I could be wrong, but it's been a lot of
years...
> The way it is right now, one cannot use the Eclipse Modeling Framework
> for generating Eclipse-style API and package structure. Isn't that weird?
I don't agree. Firstly, it's no more weird than the fact that SWT
doesn't follow this style. Did you ever wonder about that? Nor is it
anymore weird than the fact that no one cared enough to put their coding
efforts where their mouth is. As I mentioned above, living with
IAbcImpl doesn't seem the least bit tragic, especially if you hide it in
you *.internal package.
>
> We are already off a tangent here (sorry, Cedric!), but my point is
> that dictating a particular API style or package structure should not
> be EMF's business.
Certainly it's reasonable to argue that I should not impose my choices
on the community. It's important to consider that relative to the fact
that perhaps Eclipse's uses of "I" ought not to be imposed on me
either. In any event, given that my resources are limited, a community
that cares enough about the issue will put their resources where there
mouth is. I've not noticed that happen yet.
> This lack of flexibility results in generated API that won't fit into
> an organization's existing style, and in the worst case might result
> in EMF being deemed unsuitable.
I can live with that. The alternatives to EMF are few. I.e., write it
yourself by hand, provide patches for EMF to suit your needs, or accept
that no one sees IAbcImpl anyway...
>
> BTW, I don't like the 'api' segment either, but that really was not
> the point of Cedric's post anyway (he just wanted to know how to do
> it, not whether he should do it).
I understand fully the point of Cedric's post. I will continue to argue
strongly that given I have org.eclipse.xyz as my API, that
org.eclipse.xyz.internal ought to be where the internals for xyz
appear. That's what JDT does. I'm certainly open to hear an argument
to the contrary. But so far, I've not seen one yet.
>
> Cheers,
>
> Rafael
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF Java generation : interfaces packages versus implementation ones [message #419496 is a reply to message #419495] |
Sat, 24 May 2008 23:00 |
Rafael Chaves
Messages: 362
Registered: July 2009 |
Senior Member |
|
|
Ed, that is because you are considering the base namespace as the API
package, and that is incorrect.
For example, for the Core team, org.eclipse.core is the base package.
For each subsystem (resources, runtime, filesystem, etc), the API is at
org.eclipse.core.<subsystem> and the implementation is under
org.eclipse.core.internal.<subsystem>. There is no API in the
org.eclipse.core package.
You are right, SWT is an exception (the only one I know of). SWT is a
totally different beast that happens to be shipped as a plug-in (Steve
Northover says himself, "SWT is not Eclipse"), it is not an Eclipse
plug-in per se. They don't use the interface/implementation separation
either.
But you are wrong about JDT, as these guidelines apply to JDT too: the
base package is org.eclipse.jdt, and then the JDT Core API are under
org.eclipse.jdt.core whereas the implementation classes are under
org.eclipse.jdt.internal.core. The JDT UI API is under
org.eclipse.jdt.ui whereas the implementation is under
org.eclipse.jdt.internal.ui. There is no API in the org.eclipse.jdt
package itself.
That is no coincidence. That is a guideline, and plug-ins in the Eclipse
Project that deviated from that guideline in the past had to be
refactored to comply with it (I remember that that happened to Ant UI,
that had to refactor org.eclipse.ant.ui.internal to
org.eclipse.ant.internal.ui). I am not making this stuff up, I was in
the Eclipse Project when that happened.
Re: putting your money where your mouth is - totally agree. You sure
don't have any obligation of actually implementing this feature and
those who care strongly enough should do something about it. But that
does not change the fact that more flexibility is warranted. Your
willingness to acknowledge that the flexibility is lacking would mean a
lot to encourage the community to contribute with improvements in that area.
Cheers,
Rafael
Ed Merks wrote:
> Rafael,
>
> Comments below.
>
> Rafael Chaves wrote:
>> Ed Merks wrote:
>>
>>> I think this naming pattern is bad. It's api unless it's internal.
>>> I think the internal details of "ecorepackage" should be nested under
>>> "ecorepackage", not above it. I have considered supporting
>>> substitution within the "suffix" properties so that "abc" is
>>> implicitly "{0}.abc", but I feel very strongly that the internals for
>>> a model should be nested under the namespace of the model's API.
>>> What good arguments can you make that some other alternative is
>>> better? Keep in mind that I think api is horrible and redundant. :-P
>>
>> Ed, that is similar to the package organization used by all plug-ins
>> in the Eclipse Project itself, which is considered the ultimate
>> exemplary code by the plug-in development community.
> It seems to me if you read the guidelines carefully that what I'm
> suggesting conforms exactly to the guidelines. I.e. it's
> org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
>> It would be great if EMF could support that style out-of-the-box.
> I'd still like to see a strong argument that says all things associated
> with org.eclipse.xyz should be in a package other than org.eclipse.xyz.*...
>> The same is true for using 'IName' style for API interfaces and 'Name'
>> for implementation classes, which last time I looked was not supported.
> Should SWT change its design to suit this style? I personally feel very
> strongly that butchering the API names and keeping the "nice" names for
> the internal implementation classes is a very bad approach. Of course
> those who feel strongly enough about the issue can do more than just
> talk about it, i.e., they can provide the code changes needed to support
> what they want and in that way can have significant influence. I assume
> that given that the implementation classes are internal, most people
> ultimately don't care that it's IAbcImpl verses AbcImpl since no one
> sees these classes anyway. I could be wrong, but it's been a lot of
> years...
>> The way it is right now, one cannot use the Eclipse Modeling Framework
>> for generating Eclipse-style API and package structure. Isn't that weird?
> I don't agree. Firstly, it's no more weird than the fact that SWT
> doesn't follow this style. Did you ever wonder about that? Nor is it
> anymore weird than the fact that no one cared enough to put their coding
> efforts where their mouth is. As I mentioned above, living with
> IAbcImpl doesn't seem the least bit tragic, especially if you hide it in
> you *.internal package.
>>
>> We are already off a tangent here (sorry, Cedric!), but my point is
>> that dictating a particular API style or package structure should not
>> be EMF's business.
> Certainly it's reasonable to argue that I should not impose my choices
> on the community. It's important to consider that relative to the fact
> that perhaps Eclipse's uses of "I" ought not to be imposed on me
> either. In any event, given that my resources are limited, a community
> that cares enough about the issue will put their resources where there
> mouth is. I've not noticed that happen yet.
>> This lack of flexibility results in generated API that won't fit into
>> an organization's existing style, and in the worst case might result
>> in EMF being deemed unsuitable.
> I can live with that. The alternatives to EMF are few. I.e., write it
> yourself by hand, provide patches for EMF to suit your needs, or accept
> that no one sees IAbcImpl anyway...
>>
>> BTW, I don't like the 'api' segment either, but that really was not
>> the point of Cedric's post anyway (he just wanted to know how to do
>> it, not whether he should do it).
> I understand fully the point of Cedric's post. I will continue to argue
> strongly that given I have org.eclipse.xyz as my API, that
> org.eclipse.xyz.internal ought to be where the internals for xyz
> appear. That's what JDT does. I'm certainly open to hear an argument
> to the contrary. But so far, I've not seen one yet.
>>
>> Cheers,
>>
>> Rafael
|
|
|
| Re: EMF Java generation : interfaces packages versus implementation ones [message #419497 is a reply to message #419496] |
Sat, 24 May 2008 23:24 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Rafael,
Comments below.
Rafael Chaves wrote:
> Ed, that is because you are considering the base namespace as the API
> package, and that is incorrect.
I think there are many valid ways of looking at this. Not one correct
one and many incorrect ones.
>
> For example, for the Core team, org.eclipse.core is the base package.
> For each subsystem (resources, runtime, filesystem, etc), the API is
> at org.eclipse.core.<subsystem> and the implementation is under
> org.eclipse.core.internal.<subsystem>. There is no API in the
> org.eclipse.core package.
It's all a matter of perspective. The guidelines (note that's it's a
guideline, not a rule) only state that internal is somewhere in the
qualified name, not that it must be in a specific location within the
qualified name.
>
> You are right, SWT is an exception (the only one I know of). SWT is a
> totally different beast that happens to be shipped as a plug-in (Steve
> Northover says himself, "SWT is not Eclipse"), it is not an Eclipse
> plug-in per se. They don't use the interface/implementation separation
> either.
They have listeners that are interfaces so the convention would
certainly apply there. I think Steve just doesn't like the "I" naming
convention and couldn't be convinced. Just a theory... In any case, one
can always argue "my thing is a totally different beast". One can also
argue that guidelines are just that, or they would be called rules.
>
> But you are wrong about JDT, as these guidelines apply to JDT too: the
> base package is org.eclipse.jdt, and then the JDT Core API are under
> org.eclipse.jdt.core whereas the implementation classes are under
> org.eclipse.jdt.internal.core.
Note that this pattern is achievable by specifying "core" for the
interface and "internal.core" for the implementation classes.
> The JDT UI API is under org.eclipse.jdt.ui whereas the implementation
> is under org.eclipse.jdt.internal.ui. There is no API in the
> org.eclipse.jdt package itself.
But there could be. There is no guideline that says use "core" is there?
>
> That is no coincidence.
It' more of a choice than a coincidence.
> That is a guideline, and plug-ins in the Eclipse Project that deviated
> from that guideline in the past had to be refactored to comply with it
> (I remember that that happened to Ant UI, that had to refactor
> org.eclipse.ant.ui.internal to org.eclipse.ant.internal.ui). I am not
> making this stuff up, I was in the Eclipse Project when that happened.
Sometimes you have to wonder about where the guidelines came from and
who was involved in making up the guidelines. I don't recall being
consulted... Can any one explain what makes this conventional so good?
>
> Re: putting your money where your mouth is - totally agree. You sure
> don't have any obligation of actually implementing this feature and
> those who care strongly enough should do something about it.
As I said, I can imagine using substitutions to insert the package name
somewhere other than in front. I can also imagine a property that uses
substitutions so that you could specify I{0} as the interface name and
{o}Impl as the class name. Some folks have already asked for property
to specify an arbitrary per-EClass implementation class name. It's kind
of an endless set of "want to haves"...
> But that does not change the fact that more flexibility is warranted.
Of course folks will also complain about the plethora of options. :-P
> Your willingness to acknowledge that the flexibility is lacking would
> mean a lot to encourage the community to contribute with improvements
> in that area.
Go community go! Contributions are more than welcome. If this is
important to you, I don't really think it's all that hard to provide it.
>
> Cheers,
>
> Rafael
>
> Ed Merks wrote:
>> Rafael,
>>
>> Comments below.
>>
>> Rafael Chaves wrote:
>>> Ed Merks wrote:
>>>
>>>> I think this naming pattern is bad. It's api unless it's
>>>> internal. I think the internal details of "ecorepackage" should be
>>>> nested under "ecorepackage", not above it. I have considered
>>>> supporting substitution within the "suffix" properties so that
>>>> "abc" is implicitly "{0}.abc", but I feel very strongly that the
>>>> internals for a model should be nested under the namespace of the
>>>> model's API. What good arguments can you make that some other
>>>> alternative is better? Keep in mind that I think api is horrible
>>>> and redundant. :-P
>>>
>>> Ed, that is similar to the package organization used by all plug-ins
>>> in the Eclipse Project itself, which is considered the ultimate
>>> exemplary code by the plug-in development community.
>> It seems to me if you read the guidelines carefully that what I'm
>> suggesting conforms exactly to the guidelines. I.e. it's
>> org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
>>> It would be great if EMF could support that style out-of-the-box.
>> I'd still like to see a strong argument that says all things
>> associated with org.eclipse.xyz should be in a package other than
>> org.eclipse.xyz.*...
>>> The same is true for using 'IName' style for API interfaces and
>>> 'Name' for implementation classes, which last time I looked was not
>>> supported.
>> Should SWT change its design to suit this style? I personally feel
>> very strongly that butchering the API names and keeping the "nice"
>> names for the internal implementation classes is a very bad approach.
>> Of course those who feel strongly enough about the issue can do more
>> than just talk about it, i.e., they can provide the code changes
>> needed to support what they want and in that way can have significant
>> influence. I assume that given that the implementation classes are
>> internal, most people ultimately don't care that it's IAbcImpl verses
>> AbcImpl since no one sees these classes anyway. I could be wrong,
>> but it's been a lot of years...
>>> The way it is right now, one cannot use the Eclipse Modeling
>>> Framework for generating Eclipse-style API and package structure.
>>> Isn't that weird?
>> I don't agree. Firstly, it's no more weird than the fact that SWT
>> doesn't follow this style. Did you ever wonder about that? Nor is
>> it anymore weird than the fact that no one cared enough to put their
>> coding efforts where their mouth is. As I mentioned above, living
>> with IAbcImpl doesn't seem the least bit tragic, especially if you
>> hide it in you *.internal package.
>>>
>>> We are already off a tangent here (sorry, Cedric!), but my point is
>>> that dictating a particular API style or package structure should
>>> not be EMF's business.
>> Certainly it's reasonable to argue that I should not impose my
>> choices on the community. It's important to consider that relative
>> to the fact that perhaps Eclipse's uses of "I" ought not to be
>> imposed on me either. In any event, given that my resources are
>> limited, a community that cares enough about the issue will put their
>> resources where there mouth is. I've not noticed that happen yet.
>>> This lack of flexibility results in generated API that won't fit
>>> into an organization's existing style, and in the worst case might
>>> result in EMF being deemed unsuitable.
>> I can live with that. The alternatives to EMF are few. I.e., write it
>> yourself by hand, provide patches for EMF to suit your needs, or
>> accept that no one sees IAbcImpl anyway...
>>>
>>> BTW, I don't like the 'api' segment either, but that really was not
>>> the point of Cedric's post anyway (he just wanted to know how to do
>>> it, not whether he should do it).
>> I understand fully the point of Cedric's post. I will continue to
>> argue strongly that given I have org.eclipse.xyz as my API, that
>> org.eclipse.xyz.internal ought to be where the internals for xyz
>> appear. That's what JDT does. I'm certainly open to hear an
>> argument to the contrary. But so far, I've not seen one yet.
>>>
>>> Cheers,
>>>
>>> Rafael
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF Java generation : interfaces packages versus implementation ones [message #419498 is a reply to message #419497] |
Sun, 25 May 2008 09:45 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Is there a bug already filed for this? I am in the same situation
writing a library for a customer whose codeing guidelines state that an
interface has to start with an I. So I have the same problem: I'm not
making the rules I have to follow them.
In my situation it's not a problem because not even the interfaces are
public API and only an implementation detail inside the plugin and
that's why I'm sure I can convince my customer that I don't have to
follow the rules here.
Any pointers to code that could make this possible (I'm only interested
in the I-prefix would be fine because then I could take a look.) Ed how
hard is that to implement? Is this something an EMF-internals newbie
like me could solve?
Tom
Ed Merks schrieb:
> Rafael,
>
> Comments below.
>
> Rafael Chaves wrote:
>> Ed, that is because you are considering the base namespace as the API
>> package, and that is incorrect.
> I think there are many valid ways of looking at this. Not one correct
> one and many incorrect ones.
>>
>> For example, for the Core team, org.eclipse.core is the base package.
>> For each subsystem (resources, runtime, filesystem, etc), the API is
>> at org.eclipse.core.<subsystem> and the implementation is under
>> org.eclipse.core.internal.<subsystem>. There is no API in the
>> org.eclipse.core package.
> It's all a matter of perspective. The guidelines (note that's it's a
> guideline, not a rule) only state that internal is somewhere in the
> qualified name, not that it must be in a specific location within the
> qualified name.
>>
>> You are right, SWT is an exception (the only one I know of). SWT is a
>> totally different beast that happens to be shipped as a plug-in (Steve
>> Northover says himself, "SWT is not Eclipse"), it is not an Eclipse
>> plug-in per se. They don't use the interface/implementation separation
>> either.
> They have listeners that are interfaces so the convention would
> certainly apply there. I think Steve just doesn't like the "I" naming
> convention and couldn't be convinced. Just a theory... In any case, one
> can always argue "my thing is a totally different beast". One can also
> argue that guidelines are just that, or they would be called rules.
>>
>> But you are wrong about JDT, as these guidelines apply to JDT too: the
>> base package is org.eclipse.jdt, and then the JDT Core API are under
>> org.eclipse.jdt.core whereas the implementation classes are under
>> org.eclipse.jdt.internal.core.
> Note that this pattern is achievable by specifying "core" for the
> interface and "internal.core" for the implementation classes.
>> The JDT UI API is under org.eclipse.jdt.ui whereas the implementation
>> is under org.eclipse.jdt.internal.ui. There is no API in the
>> org.eclipse.jdt package itself.
> But there could be. There is no guideline that says use "core" is there?
>>
>> That is no coincidence.
> It' more of a choice than a coincidence.
>> That is a guideline, and plug-ins in the Eclipse Project that deviated
>> from that guideline in the past had to be refactored to comply with it
>> (I remember that that happened to Ant UI, that had to refactor
>> org.eclipse.ant.ui.internal to org.eclipse.ant.internal.ui). I am not
>> making this stuff up, I was in the Eclipse Project when that happened.
> Sometimes you have to wonder about where the guidelines came from and
> who was involved in making up the guidelines. I don't recall being
> consulted... Can any one explain what makes this conventional so good?
>>
>> Re: putting your money where your mouth is - totally agree. You sure
>> don't have any obligation of actually implementing this feature and
>> those who care strongly enough should do something about it.
> As I said, I can imagine using substitutions to insert the package name
> somewhere other than in front. I can also imagine a property that uses
> substitutions so that you could specify I{0} as the interface name and
> {o}Impl as the class name. Some folks have already asked for property
> to specify an arbitrary per-EClass implementation class name. It's kind
> of an endless set of "want to haves"...
>> But that does not change the fact that more flexibility is warranted.
> Of course folks will also complain about the plethora of options. :-P
>> Your willingness to acknowledge that the flexibility is lacking would
>> mean a lot to encourage the community to contribute with improvements
>> in that area.
> Go community go! Contributions are more than welcome. If this is
> important to you, I don't really think it's all that hard to provide it.
>>
>> Cheers,
>>
>> Rafael
>>
>> Ed Merks wrote:
>>> Rafael,
>>>
>>> Comments below.
>>>
>>> Rafael Chaves wrote:
>>>> Ed Merks wrote:
>>>>
>>>>> I think this naming pattern is bad. It's api unless it's
>>>>> internal. I think the internal details of "ecorepackage" should be
>>>>> nested under "ecorepackage", not above it. I have considered
>>>>> supporting substitution within the "suffix" properties so that
>>>>> "abc" is implicitly "{0}.abc", but I feel very strongly that the
>>>>> internals for a model should be nested under the namespace of the
>>>>> model's API. What good arguments can you make that some other
>>>>> alternative is better? Keep in mind that I think api is horrible
>>>>> and redundant. :-P
>>>>
>>>> Ed, that is similar to the package organization used by all plug-ins
>>>> in the Eclipse Project itself, which is considered the ultimate
>>>> exemplary code by the plug-in development community.
>>> It seems to me if you read the guidelines carefully that what I'm
>>> suggesting conforms exactly to the guidelines. I.e. it's
>>> org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
>>>> It would be great if EMF could support that style out-of-the-box.
>>> I'd still like to see a strong argument that says all things
>>> associated with org.eclipse.xyz should be in a package other than
>>> org.eclipse.xyz.*...
>>>> The same is true for using 'IName' style for API interfaces and
>>>> 'Name' for implementation classes, which last time I looked was not
>>>> supported.
>>> Should SWT change its design to suit this style? I personally feel
>>> very strongly that butchering the API names and keeping the "nice"
>>> names for the internal implementation classes is a very bad approach.
>>> Of course those who feel strongly enough about the issue can do more
>>> than just talk about it, i.e., they can provide the code changes
>>> needed to support what they want and in that way can have significant
>>> influence. I assume that given that the implementation classes are
>>> internal, most people ultimately don't care that it's IAbcImpl verses
>>> AbcImpl since no one sees these classes anyway. I could be wrong,
>>> but it's been a lot of years...
>>>> The way it is right now, one cannot use the Eclipse Modeling
>>>> Framework for generating Eclipse-style API and package structure.
>>>> Isn't that weird?
>>> I don't agree. Firstly, it's no more weird than the fact that SWT
>>> doesn't follow this style. Did you ever wonder about that? Nor is
>>> it anymore weird than the fact that no one cared enough to put their
>>> coding efforts where their mouth is. As I mentioned above, living
>>> with IAbcImpl doesn't seem the least bit tragic, especially if you
>>> hide it in you *.internal package.
>>>>
>>>> We are already off a tangent here (sorry, Cedric!), but my point is
>>>> that dictating a particular API style or package structure should
>>>> not be EMF's business.
>>> Certainly it's reasonable to argue that I should not impose my
>>> choices on the community. It's important to consider that relative
>>> to the fact that perhaps Eclipse's uses of "I" ought not to be
>>> imposed on me either. In any event, given that my resources are
>>> limited, a community that cares enough about the issue will put their
>>> resources where there mouth is. I've not noticed that happen yet.
>>>> This lack of flexibility results in generated API that won't fit
>>>> into an organization's existing style, and in the worst case might
>>>> result in EMF being deemed unsuitable.
>>> I can live with that. The alternatives to EMF are few. I.e., write it
>>> yourself by hand, provide patches for EMF to suit your needs, or
>>> accept that no one sees IAbcImpl anyway...
>>>>
>>>> BTW, I don't like the 'api' segment either, but that really was not
>>>> the point of Cedric's post anyway (he just wanted to know how to do
>>>> it, not whether he should do it).
>>> I understand fully the point of Cedric's post. I will continue to
>>> argue strongly that given I have org.eclipse.xyz as my API, that
>>> org.eclipse.xyz.internal ought to be where the internals for xyz
>>> appear. That's what JDT does. I'm certainly open to hear an
>>> argument to the contrary. But so far, I've not seen one yet.
>>>>
>>>> Cheers,
>>>>
>>>> Rafael
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: EMF Java generation : interfaces packages versus implementation ones [message #419499 is a reply to message #419497] |
Sun, 25 May 2008 10:11 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Woa ! I should have guess that any question related to naming convention
would start such a debate. Let's just say we are trying to conform to
legacy code organization and keep the "guidelines" debate out of it.
Ed, what approach would you think as the best for customizing the
generation, genmodel annotations ? The problem is that the package name is
retrieved with the getPackageName() (or something like that) in the JET
template and we can't easily re-define this with a dynamic template. One
thing I often see in the Acceleo community is a "names" generator template
for such needs, even if it's only calling a "getPackageName() method. Then
the client may easily re-define the way the path and names are computed in
the generator without copy/pasting the generator content.
What do you think about such an generator organization, would it be
something you would integrate in EMF (I guess, considering the freeze and
RC status of EMF it would only be integrated in 2.5)
I tend to prefer such a solution instead of genmodel annotations or change,
or as with these solution you ends up with many cimplicated settings in the
genmodel. With the dynamic template you can define any rule you want.
Cheers,
Cédric
Ed Merks wrote:
> Rafael,
>
> Comments below.
>
> Rafael Chaves wrote:
>> Ed, that is because you are considering the base namespace as the API
>> package, and that is incorrect.
> I think there are many valid ways of looking at this. Not one correct
> one and many incorrect ones.
>>
>> For example, for the Core team, org.eclipse.core is the base package.
>> For each subsystem (resources, runtime, filesystem, etc), the API is
>> at org.eclipse.core.<subsystem> and the implementation is under
>> org.eclipse.core.internal.<subsystem>. There is no API in the
>> org.eclipse.core package.
> It's all a matter of perspective. The guidelines (note that's it's a
> guideline, not a rule) only state that internal is somewhere in the
> qualified name, not that it must be in a specific location within the
> qualified name.
>>
>> You are right, SWT is an exception (the only one I know of). SWT is a
>> totally different beast that happens to be shipped as a plug-in (Steve
>> Northover says himself, "SWT is not Eclipse"), it is not an Eclipse
>> plug-in per se. They don't use the interface/implementation separation
>> either.
> They have listeners that are interfaces so the convention would
> certainly apply there. I think Steve just doesn't like the "I" naming
> convention and couldn't be convinced. Just a theory... In any case, one
> can always argue "my thing is a totally different beast". One can also
> argue that guidelines are just that, or they would be called rules.
>>
>> But you are wrong about JDT, as these guidelines apply to JDT too: the
>> base package is org.eclipse.jdt, and then the JDT Core API are under
>> org.eclipse.jdt.core whereas the implementation classes are under
>> org.eclipse.jdt.internal.core.
> Note that this pattern is achievable by specifying "core" for the
> interface and "internal.core" for the implementation classes.
>> The JDT UI API is under org.eclipse.jdt.ui whereas the implementation
>> is under org.eclipse.jdt.internal.ui. There is no API in the
>> org.eclipse.jdt package itself.
> But there could be. There is no guideline that says use "core" is there?
>>
>> That is no coincidence.
> It' more of a choice than a coincidence.
>> That is a guideline, and plug-ins in the Eclipse Project that deviated
>> from that guideline in the past had to be refactored to comply with it
>> (I remember that that happened to Ant UI, that had to refactor
>> org.eclipse.ant.ui.internal to org.eclipse.ant.internal.ui). I am not
>> making this stuff up, I was in the Eclipse Project when that happened.
> Sometimes you have to wonder about where the guidelines came from and
> who was involved in making up the guidelines. I don't recall being
> consulted... Can any one explain what makes this conventional so good?
>>
>> Re: putting your money where your mouth is - totally agree. You sure
>> don't have any obligation of actually implementing this feature and
>> those who care strongly enough should do something about it.
> As I said, I can imagine using substitutions to insert the package name
> somewhere other than in front. I can also imagine a property that uses
> substitutions so that you could specify I{0} as the interface name and
> {o}Impl as the class name. Some folks have already asked for property
> to specify an arbitrary per-EClass implementation class name. It's kind
> of an endless set of "want to haves"...
>> But that does not change the fact that more flexibility is warranted.
> Of course folks will also complain about the plethora of options. :-P
>> Your willingness to acknowledge that the flexibility is lacking would
>> mean a lot to encourage the community to contribute with improvements
>> in that area.
> Go community go! Contributions are more than welcome. If this is
> important to you, I don't really think it's all that hard to provide it.
>>
>> Cheers,
>>
>> Rafael
>>
>> Ed Merks wrote:
>>> Rafael,
>>>
>>> Comments below.
>>>
>>> Rafael Chaves wrote:
>>>> Ed Merks wrote:
>>>>
>>>>> I think this naming pattern is bad. It's api unless it's
>>>>> internal. I think the internal details of "ecorepackage" should be
>>>>> nested under "ecorepackage", not above it. I have considered
>>>>> supporting substitution within the "suffix" properties so that
>>>>> "abc" is implicitly "{0}.abc", but I feel very strongly that the
>>>>> internals for a model should be nested under the namespace of the
>>>>> model's API. What good arguments can you make that some other
>>>>> alternative is better? Keep in mind that I think api is horrible
>>>>> and redundant. :-P
>>>>
>>>> Ed, that is similar to the package organization used by all plug-ins
>>>> in the Eclipse Project itself, which is considered the ultimate
>>>> exemplary code by the plug-in development community.
>>> It seems to me if you read the guidelines carefully that what I'm
>>> suggesting conforms exactly to the guidelines. I.e. it's
>>> org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
>>>> It would be great if EMF could support that style out-of-the-box.
>>> I'd still like to see a strong argument that says all things
>>> associated with org.eclipse.xyz should be in a package other than
>>> org.eclipse.xyz.*...
>>>> The same is true for using 'IName' style for API interfaces and
>>>> 'Name' for implementation classes, which last time I looked was not
>>>> supported.
>>> Should SWT change its design to suit this style? I personally feel
>>> very strongly that butchering the API names and keeping the "nice"
>>> names for the internal implementation classes is a very bad approach.
>>> Of course those who feel strongly enough about the issue can do more
>>> than just talk about it, i.e., they can provide the code changes
>>> needed to support what they want and in that way can have significant
>>> influence. I assume that given that the implementation classes are
>>> internal, most people ultimately don't care that it's IAbcImpl verses
>>> AbcImpl since no one sees these classes anyway. I could be wrong,
>>> but it's been a lot of years...
>>>> The way it is right now, one cannot use the Eclipse Modeling
>>>> Framework for generating Eclipse-style API and package structure.
>>>> Isn't that weird?
>>> I don't agree. Firstly, it's no more weird than the fact that SWT
>>> doesn't follow this style. Did you ever wonder about that? Nor is
>>> it anymore weird than the fact that no one cared enough to put their
>>> coding efforts where their mouth is. As I mentioned above, living
>>> with IAbcImpl doesn't seem the least bit tragic, especially if you
>>> hide it in you *.internal package.
>>>>
>>>> We are already off a tangent here (sorry, Cedric!), but my point is
>>>> that dictating a particular API style or package structure should
>>>> not be EMF's business.
>>> Certainly it's reasonable to argue that I should not impose my
>>> choices on the community. It's important to consider that relative
>>> to the fact that perhaps Eclipse's uses of "I" ought not to be
>>> imposed on me either. In any event, given that my resources are
>>> limited, a community that cares enough about the issue will put their
>>> resources where there mouth is. I've not noticed that happen yet.
>>>> This lack of flexibility results in generated API that won't fit
>>>> into an organization's existing style, and in the worst case might
>>>> result in EMF being deemed unsuitable.
>>> I can live with that. The alternatives to EMF are few. I.e., write it
>>> yourself by hand, provide patches for EMF to suit your needs, or
>>> accept that no one sees IAbcImpl anyway...
>>>>
>>>> BTW, I don't like the 'api' segment either, but that really was not
>>>> the point of Cedric's post anyway (he just wanted to know how to do
>>>> it, not whether he should do it).
>>> I understand fully the point of Cedric's post. I will continue to
>>> argue strongly that given I have org.eclipse.xyz as my API, that
>>> org.eclipse.xyz.internal ought to be where the internals for xyz
>>> appear. That's what JDT does. I'm certainly open to hear an
>>> argument to the contrary. But so far, I've not seen one yet.
>>>>
>>>> Cheers,
>>>>
>>>> Rafael
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: EMF Java generation : interfaces packages versus implementation ones [message #419500 is a reply to message #419498] |
Sun, 25 May 2008 11:26 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050307070405060805050506
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Tom,
Comments below.
Tom Schindl wrote:
> Is there a bug already filed for this?
Nope.
> I am in the same situation writing a library for a customer whose
> codeing guidelines state that an interface has to start with an I. So
> I have the same problem: I'm not making the rules I have to follow them.
Don't you hate those kind of rules. :-P I like to be consulted about
rules. Of course the "I" thing wasn't the original issue in the posting.
>
> In my situation it's not a problem because not even the interfaces are
> public API and only an implementation detail inside the plugin and
> that's why I'm sure I can convince my customer that I don't have to
> follow the rules here.
You could point at SWT as an example.
>
> Any pointers to code that could make this possible (I'm only
> interested in the I-prefix would be fine because then I could take a
> look.) Ed how hard is that to implement? Is this something an
> EMF-internals newbie like me could solve?
This method in GenClassImpl computes the name of the interface:
public String getInterfaceName()
{
return getName();
}
This method computes the class name
public String getClassName()
{
String result = getInterfaceName();
if (!getGenModel().isSuppressInterfaces())
{
result = getImplClassName(result);
}
return result;
}
and uses this method from GenBaseImpl
protected String getImplClassName(String interfaceName)
{
return interfaceName + "Impl";
}
To tackle this issue, the approach I'd likely take is to define two new
properties on GenModel, "interfaceNamePattern" and "classNamePattern"
which would default to "{0}" and "{0}Impl" so that one could change them
to "I{0}" and "{0}" if desired. GenBaseImpl already has a getGenModel
method for accessing the containing GenModel, so the properties would be
easy to access. That's probably pretty much sufficient, although it's
possible that a few other things would need to use getInterfaceName name
that might be pulling the information directly from the Ecore model. Oh
yeah, and because the pattern should apply for the factory and the
package interface/impl, you should probably look at where
getImplClassName is called to be sure you call the new
getInterfaceClassName method for the factory and the package interface
names...
And of course because you are one of Eclipse's most helpful people, if
not the most helpful person, you have direct access to me should you
need any help. (Not many folks take advantage of IRC's #eclipse-modeling.)
>
> Tom
>
> Ed Merks schrieb:
>> Rafael,
>>
>> Comments below.
>>
>> Rafael Chaves wrote:
>>> Ed, that is because you are considering the base namespace as the
>>> API package, and that is incorrect.
>> I think there are many valid ways of looking at this. Not one
>> correct one and many incorrect ones.
>>>
>>> For example, for the Core team, org.eclipse.core is the base
>>> package. For each subsystem (resources, runtime, filesystem, etc),
>>> the API is at org.eclipse.core.<subsystem> and the implementation is
>>> under org.eclipse.core.internal.<subsystem>. There is no API in the
>>> org.eclipse.core package.
>> It's all a matter of perspective. The guidelines (note that's it's a
>> guideline, not a rule) only state that internal is somewhere in the
>> qualified name, not that it must be in a specific location within the
>> qualified name.
>>>
>>> You are right, SWT is an exception (the only one I know of). SWT is
>>> a totally different beast that happens to be shipped as a plug-in
>>> (Steve Northover says himself, "SWT is not Eclipse"), it is not an
>>> Eclipse plug-in per se. They don't use the interface/implementation
>>> separation either.
>> They have listeners that are interfaces so the convention would
>> certainly apply there. I think Steve just doesn't like the "I"
>> naming convention and couldn't be convinced. Just a theory... In any
>> case, one can always argue "my thing is a totally different beast".
>> One can also argue that guidelines are just that, or they would be
>> called rules.
>>>
>>> But you are wrong about JDT, as these guidelines apply to JDT too:
>>> the base package is org.eclipse.jdt, and then the JDT Core API are
>>> under org.eclipse.jdt.core whereas the implementation classes are
>>> under org.eclipse.jdt.internal.core.
>> Note that this pattern is achievable by specifying "core" for the
>> interface and "internal.core" for the implementation classes.
>>> The JDT UI API is under org.eclipse.jdt.ui whereas the
>>> implementation is under org.eclipse.jdt.internal.ui. There is no API
>>> in the org.eclipse.jdt package itself.
>> But there could be. There is no guideline that says use "core" is
>> there?
>>>
>>> That is no coincidence.
>> It' more of a choice than a coincidence.
>>> That is a guideline, and plug-ins in the Eclipse Project that
>>> deviated from that guideline in the past had to be refactored to
>>> comply with it (I remember that that happened to Ant UI, that had to
>>> refactor org.eclipse.ant.ui.internal to
>>> org.eclipse.ant.internal.ui). I am not making this stuff up, I was
>>> in the Eclipse Project when that happened.
>> Sometimes you have to wonder about where the guidelines came from and
>> who was involved in making up the guidelines. I don't recall being
>> consulted... Can any one explain what makes this conventional so good?
>>>
>>> Re: putting your money where your mouth is - totally agree. You sure
>>> don't have any obligation of actually implementing this feature and
>>> those who care strongly enough should do something about it.
>> As I said, I can imagine using substitutions to insert the package
>> name somewhere other than in front. I can also imagine a property
>> that uses substitutions so that you could specify I{0} as the
>> interface name and {o}Impl as the class name. Some folks have
>> already asked for property to specify an arbitrary per-EClass
>> implementation class name. It's kind of an endless set of "want to
>> haves"...
>>> But that does not change the fact that more flexibility is warranted.
>> Of course folks will also complain about the plethora of options. :-P
>>> Your willingness to acknowledge that the flexibility is lacking
>>> would mean a lot to encourage the community to contribute with
>>> improvements in that area.
>> Go community go! Contributions are more than welcome. If this is
>> important to you, I don't really think it's all that hard to provide it.
>>>
>>> Cheers,
>>>
>>> Rafael
>>>
>>> Ed Merks wrote:
>>>> Rafael,
>>>>
>>>> Comments below.
>>>>
>>>> Rafael Chaves wrote:
>>>>> Ed Merks wrote:
>>>>>
>>>>>> I think this naming pattern is bad. It's api unless it's
>>>>>> internal. I think the internal details of "ecorepackage" should
>>>>>> be nested under "ecorepackage", not above it. I have considered
>>>>>> supporting substitution within the "suffix" properties so that
>>>>>> "abc" is implicitly "{0}.abc", but I feel very strongly that the
>>>>>> internals for a model should be nested under the namespace of the
>>>>>> model's API. What good arguments can you make that some other
>>>>>> alternative is better? Keep in mind that I think api is horrible
>>>>>> and redundant. :-P
>>>>>
>>>>> Ed, that is similar to the package organization used by all
>>>>> plug-ins in the Eclipse Project itself, which is considered the
>>>>> ultimate exemplary code by the plug-in development community.
>>>> It seems to me if you read the guidelines carefully that what I'm
>>>> suggesting conforms exactly to the guidelines. I.e. it's
>>>> org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
>>>>> It would be great if EMF could support that style out-of-the-box.
>>>> I'd still like to see a strong argument that says all things
>>>> associated with org.eclipse.xyz should be in a package other than
>>>> org.eclipse.xyz.*...
>>>>> The same is true for using 'IName' style for API interfaces and
>>>>> 'Name' for implementation classes, which last time I looked was
>>>>> not supported.
>>>> Should SWT change its design to suit this style? I personally feel
>>>> very strongly that butchering the API names and keeping the "nice"
>>>> names for the internal implementation classes is a very bad
>>>> approach. Of course those who feel strongly enough about the issue
>>>> can do more than just talk about it, i.e., they can provide the
>>>> code changes needed to support what they want and in that way can
>>>> have significant influence. I assume that given that the
>>>> implementation classes are internal, most people ultimately don't
>>>> care that it's IAbcImpl verses AbcImpl since no one sees these
>>>> classes anyway. I could be wrong, but it's been a lot of years...
>>>>> The way it is right now, one cannot use the Eclipse Modeling
>>>>> Framework for generating Eclipse-style API and package structure.
>>>>> Isn't that weird?
>>>> I don't agree. Firstly, it's no more weird than the fact that SWT
>>>> doesn't follow this style. Did you ever wonder about that? Nor is
>>>> it anymore weird than the fact that no one cared enough to put
>>>> their coding efforts where their mouth is. As I mentioned above,
>>>> living with IAbcImpl doesn't seem the least bit tragic, especially
>>>> if you hide it in you *.internal package.
>>>>>
>>>>> We are already off a tangent here (sorry, Cedric!), but my point
>>>>> is that dictating a particular API style or package structure
>>>>> should not be EMF's business.
>>>> Certainly it's reasonable to argue that I should not impose my
>>>> choices on the community. It's important to consider that relative
>>>> to the fact that perhaps Eclipse's uses of "I" ought not to be
>>>> imposed on me either. In any event, given that my resources are
>>>> limited, a community that cares enough about the issue will put
>>>> their resources where there mouth is. I've not noticed that happen
>>>> yet.
>>>>> This lack of flexibility results in generated API that won't fit
>>>>> into an organization's existing style, and in the worst case might
>>>>> result in EMF being deemed unsuitable.
>>>> I can live with that. The alternatives to EMF are few. I.e., write
>>>> it yourself by hand, provide patches for EMF to suit your needs, or
>>>> accept that no one sees IAbcImpl anyway...
>>>>>
>>>>> BTW, I don't like the 'api' segment either, but that really was
>>>>> not the point of Cedric's post anyway (he just wanted to know how
>>>>> to do it, not whether he should do it).
>>>> I understand fully the point of Cedric's post. I will continue to
>>>> argue strongly that given I have org.eclipse.xyz as my API, that
>>>> org.eclipse.xyz.internal ought to be where the internals for xyz
>>>> appear. That's what JDT does. I'm certainly open to hear an
>>>> argument to the contrary. But so far, I've not seen one yet.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Rafael
>
>
--------------050307070405060805050506
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tom,<br>
<br>
Comments below.<br>
<br>
Tom Schindl wrote:
<blockquote cite="mid:g1bcgm$8ec$1@build.eclipse.org" type="cite">Is
there a bug already filed for this? </blockquote>
Nope.<br>
<blockquote cite="mid:g1bcgm$8ec$1@build.eclipse.org" type="cite">I am
in the same situation writing a library for a customer whose codeing
guidelines state that an interface has to start with an I. So I have
the same problem: I'm not making the rules I have to follow them.
<br>
</blockquote>
Don't you hate those kind of rules. :-P I like to be consulted about
rules. Of course the "I" thing wasn't the original issue in the
posting.<br>
<blockquote cite="mid:g1bcgm$8ec$1@build.eclipse.org" type="cite"><br>
In my situation it's not a problem because not even the interfaces are
public API and only an implementation detail inside the plugin and
that's why I'm sure I can convince my customer that I don't have to
follow the rules here.
<br>
</blockquote>
You could point at SWT as an example.<br>
<blockquote cite="mid:g1bcgm$8ec$1@build.eclipse.org" type="cite"><br>
Any pointers to code that could make this possible (I'm only interested
in the I-prefix would be fine because then I could take a look.) Ed how
hard is that to implement? Is this something an EMF-internals newbie
like me could solve?
<br>
</blockquote>
This method in GenClassImpl computes the name of the interface:<br>
<blockquote> public String getInterfaceName()<br>
{<br>
return getName();<br>
}<br>
</blockquote>
This method computes the class name<br>
<blockquote> public String getClassName()<br>
{<br>
String result = getInterfaceName();<br>
if (!getGenModel().isSuppressInterfaces())<br>
{<br>
result = getImplClassName(result);<br>
}<br>
return result;<br>
}<br>
</blockquote>
and uses this method from GenBaseImpl<br>
<blockquote> protected String getImplClassName(String interfaceName)<br>
{<br>
return interfaceName + "Impl";<br>
}<br>
</blockquote>
To tackle this issue, the approach I'd likely take is to define two new
properties on GenModel, "interfaceNamePattern" and "classNamePattern"
which would default to "{0}" and "{0}Impl" so that one could change
them to "I{0}" and "{0}" if desired. GenBaseImpl already has a
getGenModel method for accessing the containing GenModel, so the
properties would be easy to access. That's probably pretty much
sufficient, although it's possible that a few other things would need
to use getInterfaceName name that might be pulling the information
directly from the Ecore model. Oh yeah, and because the pattern should
apply for the factory and the package interface/impl, you should
probably look at where getImplClassName is called to be sure you call
the new getInterfaceClassName method for the factory and the package
interface names...<br>
<br>
And of course because you are one of Eclipse's most helpful people, if
not the most helpful person, you have direct access to me should you
need any help. (Not many folks take advantage of IRC's
#eclipse-modeling.)<br>
<br>
<blockquote cite="mid:g1bcgm$8ec$1@build.eclipse.org" type="cite"><br>
Tom
<br>
<br>
Ed Merks schrieb:
<br>
<blockquote type="cite">Rafael,
<br>
<br>
Comments below.
<br>
<br>
Rafael Chaves wrote:
<br>
<blockquote type="cite">Ed, that is because you are considering the
base namespace as the API package, and that is incorrect.
<br>
</blockquote>
I think there are many valid ways of looking at this. Not one correct
one and many incorrect ones.
<br>
<blockquote type="cite"><br>
For example, for the Core team, org.eclipse.core is the base package.
For each subsystem (resources, runtime, filesystem, etc), the API is at
org.eclipse.core.<subsystem> and the implementation is under
org.eclipse.core.internal.<subsystem>. There is no API in the
org.eclipse.core package.
<br>
</blockquote>
It's all a matter of perspective. The guidelines (note that's it's a
guideline, not a rule) only state that internal is somewhere in the
qualified name, not that it must be in a specific location within the
qualified name.
<br>
<blockquote type="cite"><br>
You are right, SWT is an exception (the only one I know of). SWT is a
totally different beast that happens to be shipped as a plug-in (Steve
Northover says himself, "SWT is not Eclipse"), it is not an Eclipse
plug-in per se. They don't use the interface/implementation separation
either.
<br>
</blockquote>
They have listeners that are interfaces so the convention would
certainly apply there. I think Steve just doesn't like the "I" naming
convention and couldn't be convinced. Just a theory... In any case,
one can always argue "my thing is a totally different beast". One can
also argue that guidelines are just that, or they would be called
rules.
<br>
<blockquote type="cite"><br>
But you are wrong about JDT, as these guidelines apply to JDT too: the
base package is org.eclipse.jdt, and then the JDT Core API are under
org.eclipse.jdt.core whereas the implementation classes are under
org.eclipse.jdt.internal.core. </blockquote>
Note that this pattern is achievable by specifying "core" for the
interface and "internal.core" for the implementation classes.
<br>
<blockquote type="cite">The JDT UI API is under org.eclipse.jdt.ui
whereas the implementation is under org.eclipse.jdt.internal.ui. There
is no API in the org.eclipse.jdt package itself.
<br>
</blockquote>
But there could be. There is no guideline that says use "core" is
there?
<br>
<blockquote type="cite"><br>
That is no coincidence. </blockquote>
It' more of a choice than a coincidence.
<br>
<blockquote type="cite">That is a guideline, and plug-ins in the
Eclipse Project that deviated from that guideline in the past had to be
refactored to comply with it (I remember that that happened to Ant UI,
that had to refactor org.eclipse.ant.ui.internal to
org.eclipse.ant.internal.ui). I am not making this stuff up, I was in
the Eclipse Project when that happened.
<br>
</blockquote>
Sometimes you have to wonder about where the guidelines came from and
who was involved in making up the guidelines. I don't recall being
consulted... Can any one explain what makes this conventional so good?
<br>
<blockquote type="cite"><br>
Re: putting your money where your mouth is - totally agree. You sure
don't have any obligation of actually implementing this feature and
those who care strongly enough should do something about it.
<br>
</blockquote>
As I said, I can imagine using substitutions to insert the package name
somewhere other than in front. I can also imagine a property that uses
substitutions so that you could specify I{0} as the interface name and
{o}Impl as the class name. Some folks have already asked for property
to specify an arbitrary per-EClass implementation class name. It's
kind of an endless set of "want to haves"...
<br>
<blockquote type="cite">But that does not change the fact that more
flexibility is warranted. </blockquote>
Of course folks will also complain about the plethora of options. :-P
<br>
<blockquote type="cite">Your willingness to acknowledge that the
flexibility is lacking would mean a lot to encourage the community to
contribute with improvements in that area.
<br>
</blockquote>
Go community go! Contributions are more than welcome. If this is
important to you, I don't really think it's all that hard to provide
it.
<br>
<blockquote type="cite"><br>
Cheers,
<br>
<br>
Rafael
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Rafael,
<br>
<br>
Comments below.
<br>
<br>
Rafael Chaves wrote:
<br>
<blockquote type="cite">Ed Merks wrote:
<br>
<br>
<blockquote type="cite">I think this naming pattern is bad.
It's api unless it's internal. I think the internal details of
"ecorepackage" should be nested under "ecorepackage", not above it. I
have considered supporting substitution within the "suffix" properties
so that "abc" is implicitly "{0}.abc", but I feel very strongly that
the internals for a model should be nested under the namespace of the
model's API. What good arguments can you make that some other
alternative is better? Keep in mind that I think api is horrible and
redundant. :-P
<br>
</blockquote>
<br>
Ed, that is similar to the package organization used by all plug-ins in
the Eclipse Project itself, which is considered the ultimate exemplary
code by the plug-in development community. </blockquote>
It seems to me if you read the guidelines carefully that what I'm
suggesting conforms exactly to the guidelines. I.e. it's
org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
<br>
<blockquote type="cite">It would be great if EMF could support
that style out-of-the-box. </blockquote>
I'd still like to see a strong argument that says all things associated
with org.eclipse.xyz should be in a package other than
org.eclipse.xyz.*...
<br>
<blockquote type="cite">The same is true for using 'IName'
style for API interfaces and 'Name' for implementation classes, which
last time I looked was not supported. </blockquote>
Should SWT change its design to suit this style? I personally feel
very strongly that butchering the API names and keeping the "nice"
names for the internal implementation classes is a very bad approach.
Of course those who feel strongly enough about the issue can do more
than just talk about it, i.e., they can provide the code changes needed
to support what they want and in that way can have significant
influence. I assume that given that the implementation classes are
internal, most people ultimately don't care that it's IAbcImpl verses
AbcImpl since no one sees these classes anyway. I could be wrong, but
it's been a lot of years...
<br>
<blockquote type="cite">The way it is right now, one cannot use
the Eclipse Modeling Framework for generating Eclipse-style API and
package structure. Isn't that weird?
<br>
</blockquote>
I don't agree. Firstly, it's no more weird than the fact that SWT
doesn't follow this style. Did you ever wonder about that? Nor is it
anymore weird than the fact that no one cared enough to put their
coding efforts where their mouth is. As I mentioned above, living with
IAbcImpl doesn't seem the least bit tragic, especially if you hide it
in you *.internal package.
<br>
<blockquote type="cite"><br>
We are already off a tangent here (sorry, Cedric!), but my point is
that dictating a particular API style or package structure should not
be EMF's business.
<br>
</blockquote>
Certainly it's reasonable to argue that I should not impose my choices
on the community. It's important to consider that relative to the fact
that perhaps Eclipse's uses of "I" ought not to be imposed on me
either. In any event, given that my resources are limited, a community
that cares enough about the issue will put their resources where there
mouth is. I've not noticed that happen yet.
<br>
<blockquote type="cite">This lack of flexibility results in
generated API that won't fit into an organization's existing style, and
in the worst case might result in EMF being deemed unsuitable.
<br>
</blockquote>
I can live with that. The alternatives to EMF are few. I.e., write it
yourself by hand, provide patches for EMF to suit your needs, or accept
that no one sees IAbcImpl anyway...
<br>
<blockquote type="cite"><br>
BTW, I don't like the 'api' segment either, but that really was not the
point of Cedric's post anyway (he just wanted to know how to do it, not
whether he should do it).
<br>
</blockquote>
I understand fully the point of Cedric's post. I will continue to
argue strongly that given I have org.eclipse.xyz as my API, that
org.eclipse.xyz.internal ought to be where the internals for xyz
appear. That's what JDT does. I'm certainly open to hear an argument
to the contrary. But so far, I've not seen one yet.
<br>
<blockquote type="cite"><br>
Cheers,
<br>
<br>
Rafael
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------050307070405060805050506--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF Java generation : interfaces packages versus implementation ones [message #419501 is a reply to message #419499] |
Sun, 25 May 2008 11:44 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090905030306020109020102
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cédric,
Comments below.
Cédric brun wrote:
> Woa ! I should have guess that any question related to naming convention
> would start such a debate. Let's just say we are trying to conform to
> legacy code organization and keep the "guidelines" debate out of it.
>
I would have guessed. Rafael doesn't like it when folks have to follow
my personal choices. No doubt he considers it an example of me stifling
the community. He might even be right about that! But don't tell him I
said so!! He'll just be back to say I told you so, and I really don't
like that. I prefer to think I'm right all the time. In any case, being
human, I'm not always keen on having to do every last thing the
community thinks I should do for them.
It's good to know that the naming conventions being used weren't by your
choice...
> Ed, what approach would you think as the best for customizing the
> generation, genmodel annotations ? The problem is that the package name is
> retrieved with the getPackageName() (or something like that) in the JET
> template and we can't easily re-define this with a dynamic template. One
> thing I often see in the Acceleo community is a "names" generator template
> for such needs, even if it's only calling a "getPackageName() method. Then
> the client may easily re-define the way the path and names are computed in
> the generator without copy/pasting the generator content.
>
The GenModel itself serves that purpose. Of course the GenModel isn't
trivial to extend either. GenPackage has these methods:
String getInterfacePackageName();
String getReflectionPackageName();
String getReflectionClassPackageName();
String getClassPackageName();
String getUtilitiesPackageName();
String getTestsPackageName();
There are methods like this:
public String getClassPackageName()
{
return
getQualifiedPackageName(getGenModel().isSuppressInterfaces() ?
getInterfacePackageSuffix() : getClassPackageSuffix());
}
With helper methods like this:
protected String getQualifiedPackageName(String suffix)
{
String name = getQualifiedPackageName();
return isBlank(suffix) ? name : name + "." + suffix;
}
I could imagine checking for {0} in the "suffix" and if it's there,
substituting the name at that point in the suffix. This would make it
more flexible without impacting the existing GenModel or existing clients.
> What do you think about such an generator organization, would it be
> something you would integrate in EMF (I guess, considering the freeze and
> RC status of EMF it would only be integrated in 2.5)
>
Yes, it's too late to make any changes to APIs or that affect the
generated results. Of course I expect this change could be done in a
way that affects neither.
> I tend to prefer such a solution instead of genmodel annotations or change,
> or as with these solution you ends up with many cimplicated settings in the
> genmodel. With the dynamic template you can define any rule you want.
>
We already have the settings. We could just make their use more
flexible. The problem with the solution you outline is that JET is not
so powerful for defining reusable utilities in the templates
themselves. The choice of names needs to be used uniformly across all
templates and even downstream clients of your model that might want to
reuse your model in their model will need to ensure that the choices of
names in your model are known in their model code...
Of course another approach you could take is to make "basepackage" your
package name and use suffixes to get all the rest of the full qualified
name. That requires no changes. Of course I think it would be quite
easy to change the GenPackageImpl code to support something more
flexible, easier than what Tom wants to do, so I'm interested to see how
badly you want this. :-P
> Cheers,
>
> Cédric
>
>
> Ed Merks wrote:
>
>
>> Rafael,
>>
>> Comments below.
>>
>> Rafael Chaves wrote:
>>
>>> Ed, that is because you are considering the base namespace as the API
>>> package, and that is incorrect.
>>>
>> I think there are many valid ways of looking at this. Not one correct
>> one and many incorrect ones.
>>
>>> For example, for the Core team, org.eclipse.core is the base package.
>>> For each subsystem (resources, runtime, filesystem, etc), the API is
>>> at org.eclipse.core.<subsystem> and the implementation is under
>>> org.eclipse.core.internal.<subsystem>. There is no API in the
>>> org.eclipse.core package.
>>>
>> It's all a matter of perspective. The guidelines (note that's it's a
>> guideline, not a rule) only state that internal is somewhere in the
>> qualified name, not that it must be in a specific location within the
>> qualified name.
>>
>>> You are right, SWT is an exception (the only one I know of). SWT is a
>>> totally different beast that happens to be shipped as a plug-in (Steve
>>> Northover says himself, "SWT is not Eclipse"), it is not an Eclipse
>>> plug-in per se. They don't use the interface/implementation separation
>>> either.
>>>
>> They have listeners that are interfaces so the convention would
>> certainly apply there. I think Steve just doesn't like the "I" naming
>> convention and couldn't be convinced. Just a theory... In any case, one
>> can always argue "my thing is a totally different beast". One can also
>> argue that guidelines are just that, or they would be called rules.
>>
>>> But you are wrong about JDT, as these guidelines apply to JDT too: the
>>> base package is org.eclipse.jdt, and then the JDT Core API are under
>>> org.eclipse.jdt.core whereas the implementation classes are under
>>> org.eclipse.jdt.internal.core.
>>>
>> Note that this pattern is achievable by specifying "core" for the
>> interface and "internal.core" for the implementation classes.
>>
>>> The JDT UI API is under org.eclipse.jdt.ui whereas the implementation
>>> is under org.eclipse.jdt.internal.ui. There is no API in the
>>> org.eclipse.jdt package itself.
>>>
>> But there could be. There is no guideline that says use "core" is there?
>>
>>> That is no coincidence.
>>>
>> It' more of a choice than a coincidence.
>>
>>> That is a guideline, and plug-ins in the Eclipse Project that deviated
>>> from that guideline in the past had to be refactored to comply with it
>>> (I remember that that happened to Ant UI, that had to refactor
>>> org.eclipse.ant.ui.internal to org.eclipse.ant.internal.ui). I am not
>>> making this stuff up, I was in the Eclipse Project when that happened.
>>>
>> Sometimes you have to wonder about where the guidelines came from and
>> who was involved in making up the guidelines. I don't recall being
>> consulted... Can any one explain what makes this conventional so good?
>>
>>> Re: putting your money where your mouth is - totally agree. You sure
>>> don't have any obligation of actually implementing this feature and
>>> those who care strongly enough should do something about it.
>>>
>> As I said, I can imagine using substitutions to insert the package name
>> somewhere other than in front. I can also imagine a property that uses
>> substitutions so that you could specify I{0} as the interface name and
>> {o}Impl as the class name. Some folks have already asked for property
>> to specify an arbitrary per-EClass implementation class name. It's kind
>> of an endless set of "want to haves"...
>>
>>> But that does not change the fact that more flexibility is warranted.
>>>
>> Of course folks will also complain about the plethora of options. :-P
>>
>>> Your willingness to acknowledge that the flexibility is lacking would
>>> mean a lot to encourage the community to contribute with improvements
>>> in that area.
>>>
>> Go community go! Contributions are more than welcome. If this is
>> important to you, I don't really think it's all that hard to provide it.
>>
>>> Cheers,
>>>
>>> Rafael
>>>
>>> Ed Merks wrote:
>>>
>>>> Rafael,
>>>>
>>>> Comments below.
>>>>
>>>> Rafael Chaves wrote:
>>>>
>>>>> Ed Merks wrote:
>>>>>
>>>>>
>>>>>> I think this naming pattern is bad. It's api unless it's
>>>>>> internal. I think the internal details of "ecorepackage" should be
>>>>>> nested under "ecorepackage", not above it. I have considered
>>>>>> supporting substitution within the "suffix" properties so that
>>>>>> "abc" is implicitly "{0}.abc", but I feel very strongly that the
>>>>>> internals for a model should be nested under the namespace of the
>>>>>> model's API. What good arguments can you make that some other
>>>>>> alternative is better? Keep in mind that I think api is horrible
>>>>>> and redundant. :-P
>>>>>>
>>>>> Ed, that is similar to the package organization used by all plug-ins
>>>>> in the Eclipse Project itself, which is considered the ultimate
>>>>> exemplary code by the plug-in development community.
>>>>>
>>>> It seems to me if you read the guidelines carefully that what I'm
>>>> suggesting conforms exactly to the guidelines. I.e. it's
>>>> org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
>>>>
>>>>> It would be great if EMF could support that style out-of-the-box.
>>>>>
>>>> I'd still like to see a strong argument that says all things
>>>> associated with org.eclipse.xyz should be in a package other than
>>>> org.eclipse.xyz.*...
>>>>
>>>>> The same is true for using 'IName' style for API interfaces and
>>>>> 'Name' for implementation classes, which last time I looked was not
>>>>> supported.
>>>>>
>>>> Should SWT change its design to suit this style? I personally feel
>>>> very strongly that butchering the API names and keeping the "nice"
>>>> names for the internal implementation classes is a very bad approach.
>>>> Of course those who feel strongly enough about the issue can do more
>>>> than just talk about it, i.e., they can provide the code changes
>>>> needed to support what they want and in that way can have significant
>>>> influence. I assume that given that the implementation classes are
>>>> internal, most people ultimately don't care that it's IAbcImpl verses
>>>> AbcImpl since no one sees these classes anyway. I could be wrong,
>>>> but it's been a lot of years...
>>>>
>>>>> The way it is right now, one cannot use the Eclipse Modeling
>>>>> Framework for generating Eclipse-style API and package structure.
>>>>> Isn't that weird?
>>>>>
>>>> I don't agree. Firstly, it's no more weird than the fact that SWT
>>>> doesn't follow this style. Did you ever wonder about that? Nor is
>>>> it anymore weird than the fact that no one cared enough to put their
>>>> coding efforts where their mouth is. As I mentioned above, living
>>>> with IAbcImpl doesn't seem the least bit tragic, especially if you
>>>> hide it in you *.internal package.
>>>>
>>>>> We are already off a tangent here (sorry, Cedric!), but my point is
>>>>> that dictating a particular API style or package structure should
>>>>> not be EMF's business.
>>>>>
>>>> Certainly it's reasonable to argue that I should not impose my
>>>> choices on the community. It's important to consider that relative
>>>> to the fact that perhaps Eclipse's uses of "I" ought not to be
>>>> imposed on me either. In any event, given that my resources are
>>>> limited, a community that cares enough about the issue will put their
>>>> resources where there mouth is. I've not noticed that happen yet.
>>>>
>>>>> This lack of flexibility results in generated API that won't fit
>>>>> into an organization's existing style, and in the worst case might
>>>>> result in EMF being deemed unsuitable.
>>>>>
>>>> I can live with that. The alternatives to EMF are few. I.e., write it
>>>> yourself by hand, provide patches for EMF to suit your needs, or
>>>> accept that no one sees IAbcImpl anyway...
>>>>
>>>>> BTW, I don't like the 'api' segment either, but that really was not
>>>>> the point of Cedric's post anyway (he just wanted to know how to do
>>>>> it, not whether he should do it).
>>>>>
>>>> I understand fully the point of Cedric's post. I will continue to
>>>> argue strongly that given I have org.eclipse.xyz as my API, that
>>>> org.eclipse.xyz.internal ought to be where the internals for xyz
>>>> appear. That's what JDT does. I'm certainly open to hear an
>>>> argument to the contrary. But so far, I've not seen one yet.
>>>>
>>>>> Cheers,
>>>>>
>>>>> Rafael
>>>>>
>
>
--------------090905030306020109020102
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Cédric,<br>
<br>
Comments below.<br>
<br>
Cédric brun wrote:
<blockquote cite="mid:g1bdng$c11$1@build.eclipse.org" type="cite">
<pre wrap="">Woa ! I should have guess that any question related to naming convention
would start such a debate. Let's just say we are trying to conform to
legacy code organization and keep the "guidelines" debate out of it.
</pre>
</blockquote>
I would have guessed. Rafael doesn't like it when folks have to follow
my personal choices. No doubt he considers it an example of me stifling
the community. He might even be right about that! But don't tell him
I said so!! He'll just be back to say I told you so, and I really
don't like that. I prefer to think I'm right all the time. In any
case, being human, I'm not always keen on having to do every last thing
the community thinks I should do for them. <br>
<br>
It's good to know that the naming conventions being used weren't by
your choice...<br>
<blockquote cite="mid:g1bdng$c11$1@build.eclipse.org" type="cite">
<pre wrap="">
Ed, what approach would you think as the best for customizing the
generation, genmodel annotations ? The problem is that the package name is
retrieved with the getPackageName() (or something like that) in the JET
template and we can't easily re-define this with a dynamic template. One
thing I often see in the Acceleo community is a "names" generator template
for such needs, even if it's only calling a "getPackageName() method. Then
the client may easily re-define the way the path and names are computed in
the generator without copy/pasting the generator content.
</pre>
</blockquote>
The GenModel itself serves that purpose. Of course the GenModel isn't
trivial to extend either. GenPackage has these methods:<br>
<blockquote> String getInterfacePackageName();<br>
String getReflectionPackageName();<br>
String getReflectionClassPackageName();<br>
String getClassPackageName();<br>
String getUtilitiesPackageName();<br>
String getTestsPackageName();<br>
</blockquote>
There are methods like this:<br>
<blockquote> public String getClassPackageName()<br>
{<br>
return getQualifiedPackageName(getGenModel().isSuppressInterfaces()
? getInterfacePackageSuffix() : getClassPackageSuffix());<br>
}<br>
</blockquote>
With helper methods like this:<br>
<blockquote> protected String getQualifiedPackageName(String suffix)<br>
{<br>
String name = getQualifiedPackageName();<br>
return isBlank(suffix) ? name : name + "." + suffix;<br>
}<br>
</blockquote>
I could imagine checking for {0} in the "suffix" and if it's there,
substituting the name at that point in the suffix. This would make it
more flexible without impacting the existing GenModel or existing
clients.<br>
<br>
<blockquote cite="mid:g1bdng$c11$1@build.eclipse.org" type="cite">
<pre wrap="">
What do you think about such an generator organization, would it be
something you would integrate in EMF (I guess, considering the freeze and
RC status of EMF it would only be integrated in 2.5)
</pre>
</blockquote>
Yes, it's too late to make any changes to APIs or that affect the
generated results. Of course I expect this change could be done in a
way that affects neither.<br>
<blockquote cite="mid:g1bdng$c11$1@build.eclipse.org" type="cite">
<pre wrap="">
I tend to prefer such a solution instead of genmodel annotations or change,
or as with these solution you ends up with many cimplicated settings in the
genmodel. With the dynamic template you can define any rule you want.
</pre>
</blockquote>
We already have the settings. We could just make their use more
flexible. The problem with the solution you outline is that JET is
not so powerful for defining reusable utilities in the templates
themselves. The choice of names needs to be used uniformly across all
templates and even downstream clients of your model that might want to
reuse your model in their model will need to ensure that the choices of
names in your model are known in their model code...<br>
<br>
Of course another approach you could take is to make "basepackage" your
package name and use suffixes to get all the rest of the full qualified
name. That requires no changes. Of course I think it would be quite
easy to change the GenPackageImpl code to support something more
flexible, easier than what Tom wants to do, so I'm interested to see
how badly you want this. :-P<br>
<blockquote cite="mid:g1bdng$c11$1@build.eclipse.org" type="cite">
<pre wrap="">
Cheers,
Cédric
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Rafael,
Comments below.
Rafael Chaves wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ed, that is because you are considering the base namespace as the API
package, and that is incorrect.
</pre>
</blockquote>
<pre wrap="">I think there are many valid ways of looking at this. Not one correct
one and many incorrect ones.
</pre>
<blockquote type="cite">
<pre wrap="">For example, for the Core team, org.eclipse.core is the base package.
For each subsystem (resources, runtime, filesystem, etc), the API is
at org.eclipse.core.<subsystem> and the implementation is under
org.eclipse.core.internal.<subsystem>. There is no API in the
org.eclipse.core package.
</pre>
</blockquote>
<pre wrap="">It's all a matter of perspective. The guidelines (note that's it's a
guideline, not a rule) only state that internal is somewhere in the
qualified name, not that it must be in a specific location within the
qualified name.
</pre>
<blockquote type="cite">
<pre wrap="">You are right, SWT is an exception (the only one I know of). SWT is a
totally different beast that happens to be shipped as a plug-in (Steve
Northover says himself, "SWT is not Eclipse"), it is not an Eclipse
plug-in per se. They don't use the interface/implementation separation
either.
</pre>
</blockquote>
<pre wrap="">They have listeners that are interfaces so the convention would
certainly apply there. I think Steve just doesn't like the "I" naming
convention and couldn't be convinced. Just a theory... In any case, one
can always argue "my thing is a totally different beast". One can also
argue that guidelines are just that, or they would be called rules.
</pre>
<blockquote type="cite">
<pre wrap="">But you are wrong about JDT, as these guidelines apply to JDT too: the
base package is org.eclipse.jdt, and then the JDT Core API are under
org.eclipse.jdt.core whereas the implementation classes are under
org.eclipse.jdt.internal.core.
</pre>
</blockquote>
<pre wrap="">Note that this pattern is achievable by specifying "core" for the
interface and "internal.core" for the implementation classes.
</pre>
<blockquote type="cite">
<pre wrap="">The JDT UI API is under org.eclipse.jdt.ui whereas the implementation
is under org.eclipse.jdt.internal.ui. There is no API in the
org.eclipse.jdt package itself.
</pre>
</blockquote>
<pre wrap="">But there could be. There is no guideline that says use "core" is there?
</pre>
<blockquote type="cite">
<pre wrap="">That is no coincidence.
</pre>
</blockquote>
<pre wrap="">It' more of a choice than a coincidence.
</pre>
<blockquote type="cite">
<pre wrap="">That is a guideline, and plug-ins in the Eclipse Project that deviated
from that guideline in the past had to be refactored to comply with it
(I remember that that happened to Ant UI, that had to refactor
org.eclipse.ant.ui.internal to org.eclipse.ant.internal.ui). I am not
making this stuff up, I was in the Eclipse Project when that happened.
</pre>
</blockquote>
<pre wrap="">Sometimes you have to wonder about where the guidelines came from and
who was involved in making up the guidelines. I don't recall being
consulted... Can any one explain what makes this conventional so good?
</pre>
<blockquote type="cite">
<pre wrap="">Re: putting your money where your mouth is - totally agree. You sure
don't have any obligation of actually implementing this feature and
those who care strongly enough should do something about it.
</pre>
</blockquote>
<pre wrap="">As I said, I can imagine using substitutions to insert the package name
somewhere other than in front. I can also imagine a property that uses
substitutions so that you could specify I{0} as the interface name and
{o}Impl as the class name. Some folks have already asked for property
to specify an arbitrary per-EClass implementation class name. It's kind
of an endless set of "want to haves"...
</pre>
<blockquote type="cite">
<pre wrap="">But that does not change the fact that more flexibility is warranted.
</pre>
</blockquote>
<pre wrap="">Of course folks will also complain about the plethora of options. :-P
</pre>
<blockquote type="cite">
<pre wrap="">Your willingness to acknowledge that the flexibility is lacking would
mean a lot to encourage the community to contribute with improvements
in that area.
</pre>
</blockquote>
<pre wrap="">Go community go! Contributions are more than welcome. If this is
important to you, I don't really think it's all that hard to provide it.
</pre>
<blockquote type="cite">
<pre wrap="">Cheers,
Rafael
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Rafael,
Comments below.
Rafael Chaves wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I think this naming pattern is bad. It's api unless it's
internal. I think the internal details of "ecorepackage" should be
nested under "ecorepackage", not above it. I have considered
supporting substitution within the "suffix" properties so that
"abc" is implicitly "{0}.abc", but I feel very strongly that the
internals for a model should be nested under the namespace of the
model's API. What good arguments can you make that some other
alternative is better? Keep in mind that I think api is horrible
and redundant. :-P
</pre>
</blockquote>
<pre wrap="">Ed, that is similar to the package organization used by all plug-ins
in the Eclipse Project itself, which is considered the ultimate
exemplary code by the plug-in development community.
</pre>
</blockquote>
<pre wrap="">It seems to me if you read the guidelines carefully that what I'm
suggesting conforms exactly to the guidelines. I.e. it's
org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
</pre>
<blockquote type="cite">
<pre wrap="">It would be great if EMF could support that style out-of-the-box.
</pre>
</blockquote>
<pre wrap="">I'd still like to see a strong argument that says all things
associated with org.eclipse.xyz should be in a package other than
org.eclipse.xyz.*...
</pre>
<blockquote type="cite">
<pre wrap="">The same is true for using 'IName' style for API interfaces and
'Name' for implementation classes, which last time I looked was not
supported.
</pre>
</blockquote>
<pre wrap="">Should SWT change its design to suit this style? I personally feel
very strongly that butchering the API names and keeping the "nice"
names for the internal implementation classes is a very bad approach.
Of course those who feel strongly enough about the issue can do more
than just talk about it, i.e., they can provide the code changes
needed to support what they want and in that way can have significant
influence. I assume that given that the implementation classes are
internal, most people ultimately don't care that it's IAbcImpl verses
AbcImpl since no one sees these classes anyway. I could be wrong,
but it's been a lot of years...
</pre>
<blockquote type="cite">
<pre wrap="">The way it is right now, one cannot use the Eclipse Modeling
Framework for generating Eclipse-style API and package structure.
Isn't that weird?
</pre>
</blockquote>
<pre wrap="">I don't agree. Firstly, it's no more weird than the fact that SWT
doesn't follow this style. Did you ever wonder about that? Nor is
it anymore weird than the fact that no one cared enough to put their
coding efforts where their mouth is. As I mentioned above, living
with IAbcImpl doesn't seem the least bit tragic, especially if you
hide it in you *.internal package.
</pre>
<blockquote type="cite">
<pre wrap="">We are already off a tangent here (sorry, Cedric!), but my point is
that dictating a particular API style or package structure should
not be EMF's business.
</pre>
</blockquote>
<pre wrap="">Certainly it's reasonable to argue that I should not impose my
choices on the community. It's important to consider that relative
to the fact that perhaps Eclipse's uses of "I" ought not to be
imposed on me either. In any event, given that my resources are
limited, a community that cares enough about the issue will put their
resources where there mouth is. I've not noticed that happen yet.
</pre>
<blockquote type="cite">
<pre wrap="">This lack of flexibility results in generated API that won't fit
into an organization's existing style, and in the worst case might
result in EMF being deemed unsuitable.
</pre>
</blockquote>
<pre wrap="">I can live with that. The alternatives to EMF are few. I.e., write it
yourself by hand, provide patches for EMF to suit your needs, or
accept that no one sees IAbcImpl anyway...
</pre>
<blockquote type="cite">
<pre wrap="">BTW, I don't like the 'api' segment either, but that really was not
the point of Cedric's post anyway (he just wanted to know how to do
it, not whether he should do it).
</pre>
</blockquote>
<pre wrap="">I understand fully the point of Cedric's post. I will continue to
argue strongly that given I have org.eclipse.xyz as my API, that
org.eclipse.xyz.internal ought to be where the internals for xyz
appear. That's what JDT does. I'm certainly open to hear an
argument to the contrary. But so far, I've not seen one yet.
</pre>
<blockquote type="cite">
<pre wrap="">Cheers,
Rafael
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------090905030306020109020102--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF Java generation : interfaces packages versus implementation ones [message #419502 is a reply to message #419500] |
Sun, 25 May 2008 11:42 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Ed,
Bug is filed [1]. Thanks for the pointers I'll take a look at it later
today.
Tom
[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=233843
Ed Merks schrieb:
> Tom,
>
> Comments below.
>
> Tom Schindl wrote:
>> Is there a bug already filed for this?
> Nope.
>> I am in the same situation writing a library for a customer whose
>> codeing guidelines state that an interface has to start with an I. So
>> I have the same problem: I'm not making the rules I have to follow them.
> Don't you hate those kind of rules. :-P I like to be consulted about
> rules. Of course the "I" thing wasn't the original issue in the posting.
>>
>> In my situation it's not a problem because not even the interfaces are
>> public API and only an implementation detail inside the plugin and
>> that's why I'm sure I can convince my customer that I don't have to
>> follow the rules here.
> You could point at SWT as an example.
>>
>> Any pointers to code that could make this possible (I'm only
>> interested in the I-prefix would be fine because then I could take a
>> look.) Ed how hard is that to implement? Is this something an
>> EMF-internals newbie like me could solve?
> This method in GenClassImpl computes the name of the interface:
>
> public String getInterfaceName()
> {
> return getName();
> }
>
> This method computes the class name
>
> public String getClassName()
> {
> String result = getInterfaceName();
> if (!getGenModel().isSuppressInterfaces())
> {
> result = getImplClassName(result);
> }
> return result;
> }
>
> and uses this method from GenBaseImpl
>
> protected String getImplClassName(String interfaceName)
> {
> return interfaceName + "Impl";
> }
>
> To tackle this issue, the approach I'd likely take is to define two new
> properties on GenModel, "interfaceNamePattern" and "classNamePattern"
> which would default to "{0}" and "{0}Impl" so that one could change them
> to "I{0}" and "{0}" if desired. GenBaseImpl already has a getGenModel
> method for accessing the containing GenModel, so the properties would be
> easy to access. That's probably pretty much sufficient, although it's
> possible that a few other things would need to use getInterfaceName name
> that might be pulling the information directly from the Ecore model. Oh
> yeah, and because the pattern should apply for the factory and the
> package interface/impl, you should probably look at where
> getImplClassName is called to be sure you call the new
> getInterfaceClassName method for the factory and the package interface
> names...
>
> And of course because you are one of Eclipse's most helpful people, if
> not the most helpful person, you have direct access to me should you
> need any help. (Not many folks take advantage of IRC's #eclipse-modeling.)
>
>>
>> Tom
>>
>> Ed Merks schrieb:
>>> Rafael,
>>>
>>> Comments below.
>>>
>>> Rafael Chaves wrote:
>>>> Ed, that is because you are considering the base namespace as the
>>>> API package, and that is incorrect.
>>> I think there are many valid ways of looking at this. Not one
>>> correct one and many incorrect ones.
>>>>
>>>> For example, for the Core team, org.eclipse.core is the base
>>>> package. For each subsystem (resources, runtime, filesystem, etc),
>>>> the API is at org.eclipse.core.<subsystem> and the implementation is
>>>> under org.eclipse.core.internal.<subsystem>. There is no API in the
>>>> org.eclipse.core package.
>>> It's all a matter of perspective. The guidelines (note that's it's a
>>> guideline, not a rule) only state that internal is somewhere in the
>>> qualified name, not that it must be in a specific location within the
>>> qualified name.
>>>>
>>>> You are right, SWT is an exception (the only one I know of). SWT is
>>>> a totally different beast that happens to be shipped as a plug-in
>>>> (Steve Northover says himself, "SWT is not Eclipse"), it is not an
>>>> Eclipse plug-in per se. They don't use the interface/implementation
>>>> separation either.
>>> They have listeners that are interfaces so the convention would
>>> certainly apply there. I think Steve just doesn't like the "I"
>>> naming convention and couldn't be convinced. Just a theory... In any
>>> case, one can always argue "my thing is a totally different beast".
>>> One can also argue that guidelines are just that, or they would be
>>> called rules.
>>>>
>>>> But you are wrong about JDT, as these guidelines apply to JDT too:
>>>> the base package is org.eclipse.jdt, and then the JDT Core API are
>>>> under org.eclipse.jdt.core whereas the implementation classes are
>>>> under org.eclipse.jdt.internal.core.
>>> Note that this pattern is achievable by specifying "core" for the
>>> interface and "internal.core" for the implementation classes.
>>>> The JDT UI API is under org.eclipse.jdt.ui whereas the
>>>> implementation is under org.eclipse.jdt.internal.ui. There is no API
>>>> in the org.eclipse.jdt package itself.
>>> But there could be. There is no guideline that says use "core" is
>>> there?
>>>>
>>>> That is no coincidence.
>>> It' more of a choice than a coincidence.
>>>> That is a guideline, and plug-ins in the Eclipse Project that
>>>> deviated from that guideline in the past had to be refactored to
>>>> comply with it (I remember that that happened to Ant UI, that had to
>>>> refactor org.eclipse.ant.ui.internal to
>>>> org.eclipse.ant.internal.ui). I am not making this stuff up, I was
>>>> in the Eclipse Project when that happened.
>>> Sometimes you have to wonder about where the guidelines came from and
>>> who was involved in making up the guidelines. I don't recall being
>>> consulted... Can any one explain what makes this conventional so good?
>>>>
>>>> Re: putting your money where your mouth is - totally agree. You sure
>>>> don't have any obligation of actually implementing this feature and
>>>> those who care strongly enough should do something about it.
>>> As I said, I can imagine using substitutions to insert the package
>>> name somewhere other than in front. I can also imagine a property
>>> that uses substitutions so that you could specify I{0} as the
>>> interface name and {o}Impl as the class name. Some folks have
>>> already asked for property to specify an arbitrary per-EClass
>>> implementation class name. It's kind of an endless set of "want to
>>> haves"...
>>>> But that does not change the fact that more flexibility is warranted.
>>> Of course folks will also complain about the plethora of options. :-P
>>>> Your willingness to acknowledge that the flexibility is lacking
>>>> would mean a lot to encourage the community to contribute with
>>>> improvements in that area.
>>> Go community go! Contributions are more than welcome. If this is
>>> important to you, I don't really think it's all that hard to provide it.
>>>>
>>>> Cheers,
>>>>
>>>> Rafael
>>>>
>>>> Ed Merks wrote:
>>>>> Rafael,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Rafael Chaves wrote:
>>>>>> Ed Merks wrote:
>>>>>>
>>>>>>> I think this naming pattern is bad. It's api unless it's
>>>>>>> internal. I think the internal details of "ecorepackage" should
>>>>>>> be nested under "ecorepackage", not above it. I have considered
>>>>>>> supporting substitution within the "suffix" properties so that
>>>>>>> "abc" is implicitly "{0}.abc", but I feel very strongly that the
>>>>>>> internals for a model should be nested under the namespace of the
>>>>>>> model's API. What good arguments can you make that some other
>>>>>>> alternative is better? Keep in mind that I think api is horrible
>>>>>>> and redundant. :-P
>>>>>>
>>>>>> Ed, that is similar to the package organization used by all
>>>>>> plug-ins in the Eclipse Project itself, which is considered the
>>>>>> ultimate exemplary code by the plug-in development community.
>>>>> It seems to me if you read the guidelines carefully that what I'm
>>>>> suggesting conforms exactly to the guidelines. I.e. it's
>>>>> org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
>>>>>> It would be great if EMF could support that style out-of-the-box.
>>>>> I'd still like to see a strong argument that says all things
>>>>> associated with org.eclipse.xyz should be in a package other than
>>>>> org.eclipse.xyz.*...
>>>>>> The same is true for using 'IName' style for API interfaces and
>>>>>> 'Name' for implementation classes, which last time I looked was
>>>>>> not supported.
>>>>> Should SWT change its design to suit this style? I personally feel
>>>>> very strongly that butchering the API names and keeping the "nice"
>>>>> names for the internal implementation classes is a very bad
>>>>> approach. Of course those who feel strongly enough about the issue
>>>>> can do more than just talk about it, i.e., they can provide the
>>>>> code changes needed to support what they want and in that way can
>>>>> have significant influence. I assume that given that the
>>>>> implementation classes are internal, most people ultimately don't
>>>>> care that it's IAbcImpl verses AbcImpl since no one sees these
>>>>> classes anyway. I could be wrong, but it's been a lot of years...
>>>>>> The way it is right now, one cannot use the Eclipse Modeling
>>>>>> Framework for generating Eclipse-style API and package structure.
>>>>>> Isn't that weird?
>>>>> I don't agree. Firstly, it's no more weird than the fact that SWT
>>>>> doesn't follow this style. Did you ever wonder about that? Nor is
>>>>> it anymore weird than the fact that no one cared enough to put
>>>>> their coding efforts where their mouth is. As I mentioned above,
>>>>> living with IAbcImpl doesn't seem the least bit tragic, especially
>>>>> if you hide it in you *.internal package.
>>>>>>
>>>>>> We are already off a tangent here (sorry, Cedric!), but my point
>>>>>> is that dictating a particular API style or package structure
>>>>>> should not be EMF's business.
>>>>> Certainly it's reasonable to argue that I should not impose my
>>>>> choices on the community. It's important to consider that relative
>>>>> to the fact that perhaps Eclipse's uses of "I" ought not to be
>>>>> imposed on me either. In any event, given that my resources are
>>>>> limited, a community that cares enough about the issue will put
>>>>> their resources where there mouth is. I've not noticed that happen
>>>>> yet.
>>>>>> This lack of flexibility results in generated API that won't fit
>>>>>> into an organization's existing style, and in the worst case might
>>>>>> result in EMF being deemed unsuitable.
>>>>> I can live with that. The alternatives to EMF are few. I.e., write
>>>>> it yourself by hand, provide patches for EMF to suit your needs, or
>>>>> accept that no one sees IAbcImpl anyway...
>>>>>>
>>>>>> BTW, I don't like the 'api' segment either, but that really was
>>>>>> not the point of Cedric's post anyway (he just wanted to know how
>>>>>> to do it, not whether he should do it).
>>>>> I understand fully the point of Cedric's post. I will continue to
>>>>> argue strongly that given I have org.eclipse.xyz as my API, that
>>>>> org.eclipse.xyz.internal ought to be where the internals for xyz
>>>>> appear. That's what JDT does. I'm certainly open to hear an
>>>>> argument to the contrary. But so far, I've not seen one yet.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Rafael
>>
>>
>
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: EMF Java generation : interfaces packages versus implementation ones [message #419553 is a reply to message #419501] |
Tue, 27 May 2008 10:21 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
bug #234105 [1] is in the wild, with a patch created against the EMF2.3
maintenance stream and the corresponding unit test.
I also created the same patch for the HEAD branch as the first one would not
apply correctly.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=234105
Ed Merks wrote:
> Cédric,
>
> Comments below.
>
> Cédric brun wrote:
>> Woa ! I should have guess that any question related to naming convention
>> would start such a debate. Let's just say we are trying to conform to
>> legacy code organization and keep the "guidelines" debate out of it.
>>
> I would have guessed. Rafael doesn't like it when folks have to follow
> my personal choices. No doubt he considers it an example of me stifling
> the community. He might even be right about that! But don't tell him I
> said so!! He'll just be back to say I told you so, and I really don't
> like that. I prefer to think I'm right all the time. In any case, being
> human, I'm not always keen on having to do every last thing the
> community thinks I should do for them.
>
> It's good to know that the naming conventions being used weren't by your
> choice...
>> Ed, what approach would you think as the best for customizing the
>> generation, genmodel annotations ? The problem is that the package name
>> is retrieved with the getPackageName() (or something like that) in the
>> JET template and we can't easily re-define this with a dynamic template.
>> One thing I often see in the Acceleo community is a "names" generator
>> template for such needs, even if it's only calling a "getPackageName()
>> method. Then the client may easily re-define the way the path and names
>> are computed in the generator without copy/pasting the generator content.
>>
> The GenModel itself serves that purpose. Of course the GenModel isn't
> trivial to extend either. GenPackage has these methods:
>
> String getInterfacePackageName();
> String getReflectionPackageName();
> String getReflectionClassPackageName();
> String getClassPackageName();
> String getUtilitiesPackageName();
> String getTestsPackageName();
>
> There are methods like this:
>
> public String getClassPackageName()
> {
> return
> getQualifiedPackageName(getGenModel().isSuppressInterfaces() ?
> getInterfacePackageSuffix() : getClassPackageSuffix());
> }
>
> With helper methods like this:
>
> protected String getQualifiedPackageName(String suffix)
> {
> String name = getQualifiedPackageName();
> return isBlank(suffix) ? name : name + "." + suffix;
> }
>
> I could imagine checking for {0} in the "suffix" and if it's there,
> substituting the name at that point in the suffix. This would make it
> more flexible without impacting the existing GenModel or existing clients.
>
>> What do you think about such an generator organization, would it be
>> something you would integrate in EMF (I guess, considering the freeze and
>> RC status of EMF it would only be integrated in 2.5)
>>
> Yes, it's too late to make any changes to APIs or that affect the
> generated results. Of course I expect this change could be done in a
> way that affects neither.
>> I tend to prefer such a solution instead of genmodel annotations or
>> change, or as with these solution you ends up with many cimplicated
>> settings in the genmodel. With the dynamic template you can define any
>> rule you want.
>>
> We already have the settings. We could just make their use more
> flexible. The problem with the solution you outline is that JET is not
> so powerful for defining reusable utilities in the templates
> themselves. The choice of names needs to be used uniformly across all
> templates and even downstream clients of your model that might want to
> reuse your model in their model will need to ensure that the choices of
> names in your model are known in their model code...
>
> Of course another approach you could take is to make "basepackage" your
> package name and use suffixes to get all the rest of the full qualified
> name. That requires no changes. Of course I think it would be quite
> easy to change the GenPackageImpl code to support something more
> flexible, easier than what Tom wants to do, so I'm interested to see how
> badly you want this. :-P
>> Cheers,
>>
>> Cédric
>>
>>
>> Ed Merks wrote:
>>
>>
>>> Rafael,
>>>
>>> Comments below.
>>>
>>> Rafael Chaves wrote:
>>>
>>>> Ed, that is because you are considering the base namespace as the API
>>>> package, and that is incorrect.
>>>>
>>> I think there are many valid ways of looking at this. Not one correct
>>> one and many incorrect ones.
>>>
>>>> For example, for the Core team, org.eclipse.core is the base package.
>>>> For each subsystem (resources, runtime, filesystem, etc), the API is
>>>> at org.eclipse.core.<subsystem> and the implementation is under
>>>> org.eclipse.core.internal.<subsystem>. There is no API in the
>>>> org.eclipse.core package.
>>>>
>>> It's all a matter of perspective. The guidelines (note that's it's a
>>> guideline, not a rule) only state that internal is somewhere in the
>>> qualified name, not that it must be in a specific location within the
>>> qualified name.
>>>
>>>> You are right, SWT is an exception (the only one I know of). SWT is a
>>>> totally different beast that happens to be shipped as a plug-in (Steve
>>>> Northover says himself, "SWT is not Eclipse"), it is not an Eclipse
>>>> plug-in per se. They don't use the interface/implementation separation
>>>> either.
>>>>
>>> They have listeners that are interfaces so the convention would
>>> certainly apply there. I think Steve just doesn't like the "I" naming
>>> convention and couldn't be convinced. Just a theory... In any case, one
>>> can always argue "my thing is a totally different beast". One can also
>>> argue that guidelines are just that, or they would be called rules.
>>>
>>>> But you are wrong about JDT, as these guidelines apply to JDT too: the
>>>> base package is org.eclipse.jdt, and then the JDT Core API are under
>>>> org.eclipse.jdt.core whereas the implementation classes are under
>>>> org.eclipse.jdt.internal.core.
>>>>
>>> Note that this pattern is achievable by specifying "core" for the
>>> interface and "internal.core" for the implementation classes.
>>>
>>>> The JDT UI API is under org.eclipse.jdt.ui whereas the implementation
>>>> is under org.eclipse.jdt.internal.ui. There is no API in the
>>>> org.eclipse.jdt package itself.
>>>>
>>> But there could be. There is no guideline that says use "core" is
>>> there?
>>>
>>>> That is no coincidence.
>>>>
>>> It' more of a choice than a coincidence.
>>>
>>>> That is a guideline, and plug-ins in the Eclipse Project that deviated
>>>> from that guideline in the past had to be refactored to comply with it
>>>> (I remember that that happened to Ant UI, that had to refactor
>>>> org.eclipse.ant.ui.internal to org.eclipse.ant.internal.ui). I am not
>>>> making this stuff up, I was in the Eclipse Project when that happened.
>>>>
>>> Sometimes you have to wonder about where the guidelines came from and
>>> who was involved in making up the guidelines. I don't recall being
>>> consulted... Can any one explain what makes this conventional so good?
>>>
>>>> Re: putting your money where your mouth is - totally agree. You sure
>>>> don't have any obligation of actually implementing this feature and
>>>> those who care strongly enough should do something about it.
>>>>
>>> As I said, I can imagine using substitutions to insert the package name
>>> somewhere other than in front. I can also imagine a property that uses
>>> substitutions so that you could specify I{0} as the interface name and
>>> {o}Impl as the class name. Some folks have already asked for property
>>> to specify an arbitrary per-EClass implementation class name. It's kind
>>> of an endless set of "want to haves"...
>>>
>>>> But that does not change the fact that more flexibility is warranted.
>>>>
>>> Of course folks will also complain about the plethora of options. :-P
>>>
>>>> Your willingness to acknowledge that the flexibility is lacking would
>>>> mean a lot to encourage the community to contribute with improvements
>>>> in that area.
>>>>
>>> Go community go! Contributions are more than welcome. If this is
>>> important to you, I don't really think it's all that hard to provide it.
>>>
>>>> Cheers,
>>>>
>>>> Rafael
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> Rafael,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Rafael Chaves wrote:
>>>>>
>>>>>> Ed Merks wrote:
>>>>>>
>>>>>>
>>>>>>> I think this naming pattern is bad. It's api unless it's
>>>>>>> internal. I think the internal details of "ecorepackage" should be
>>>>>>> nested under "ecorepackage", not above it. I have considered
>>>>>>> supporting substitution within the "suffix" properties so that
>>>>>>> "abc" is implicitly "{0}.abc", but I feel very strongly that the
>>>>>>> internals for a model should be nested under the namespace of the
>>>>>>> model's API. What good arguments can you make that some other
>>>>>>> alternative is better? Keep in mind that I think api is horrible
>>>>>>> and redundant. :-P
>>>>>>>
>>>>>> Ed, that is similar to the package organization used by all plug-ins
>>>>>> in the Eclipse Project itself, which is considered the ultimate
>>>>>> exemplary code by the plug-in development community.
>>>>>>
>>>>> It seems to me if you read the guidelines carefully that what I'm
>>>>> suggesting conforms exactly to the guidelines. I.e. it's
>>>>> org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
>>>>>
>>>>>> It would be great if EMF could support that style out-of-the-box.
>>>>>>
>>>>> I'd still like to see a strong argument that says all things
>>>>> associated with org.eclipse.xyz should be in a package other than
>>>>> org.eclipse.xyz.*...
>>>>>
>>>>>> The same is true for using 'IName' style for API interfaces and
>>>>>> 'Name' for implementation classes, which last time I looked was not
>>>>>> supported.
>>>>>>
>>>>> Should SWT change its design to suit this style? I personally feel
>>>>> very strongly that butchering the API names and keeping the "nice"
>>>>> names for the internal implementation classes is a very bad approach.
>>>>> Of course those who feel strongly enough about the issue can do more
>>>>> than just talk about it, i.e., they can provide the code changes
>>>>> needed to support what they want and in that way can have significant
>>>>> influence. I assume that given that the implementation classes are
>>>>> internal, most people ultimately don't care that it's IAbcImpl verses
>>>>> AbcImpl since no one sees these classes anyway. I could be wrong,
>>>>> but it's been a lot of years...
>>>>>
>>>>>> The way it is right now, one cannot use the Eclipse Modeling
>>>>>> Framework for generating Eclipse-style API and package structure.
>>>>>> Isn't that weird?
>>>>>>
>>>>> I don't agree. Firstly, it's no more weird than the fact that SWT
>>>>> doesn't follow this style. Did you ever wonder about that? Nor is
>>>>> it anymore weird than the fact that no one cared enough to put their
>>>>> coding efforts where their mouth is. As I mentioned above, living
>>>>> with IAbcImpl doesn't seem the least bit tragic, especially if you
>>>>> hide it in you *.internal package.
>>>>>
>>>>>> We are already off a tangent here (sorry, Cedric!), but my point is
>>>>>> that dictating a particular API style or package structure should
>>>>>> not be EMF's business.
>>>>>>
>>>>> Certainly it's reasonable to argue that I should not impose my
>>>>> choices on the community. It's important to consider that relative
>>>>> to the fact that perhaps Eclipse's uses of "I" ought not to be
>>>>> imposed on me either. In any event, given that my resources are
>>>>> limited, a community that cares enough about the issue will put their
>>>>> resources where there mouth is. I've not noticed that happen yet.
>>>>>
>>>>>> This lack of flexibility results in generated API that won't fit
>>>>>> into an organization's existing style, and in the worst case might
>>>>>> result in EMF being deemed unsuitable.
>>>>>>
>>>>> I can live with that. The alternatives to EMF are few. I.e., write it
>>>>> yourself by hand, provide patches for EMF to suit your needs, or
>>>>> accept that no one sees IAbcImpl anyway...
>>>>>
>>>>>> BTW, I don't like the 'api' segment either, but that really was not
>>>>>> the point of Cedric's post anyway (he just wanted to know how to do
>>>>>> it, not whether he should do it).
>>>>>>
>>>>> I understand fully the point of Cedric's post. I will continue to
>>>>> argue strongly that given I have org.eclipse.xyz as my API, that
>>>>> org.eclipse.xyz.internal ought to be where the internals for xyz
>>>>> appear. That's what JDT does. I'm certainly open to hear an
>>>>> argument to the contrary. But so far, I've not seen one yet.
>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Rafael
>>>>>>
>>
>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: EMF Java generation : interfaces packages versus implementation ones [message #419556 is a reply to message #419553] |
Tue, 27 May 2008 12:54 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020508000305070507030705
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cédric,
Thanks! As I mentioned in the bugzilla, we really shouldn't be
providing new features in maintenance streams so I'd face some
uncomfortable scrutiny if I did that. I suppose we might be able to
justify it for 2.4, but even that is a bit questionable...
I'll have to take this hard line "do it yourself approach" more often.
That worked really well. :-P
Cédric Brun wrote:
> Hi Ed,
>
> bug #234105 [1] is in the wild, with a patch created against the EMF2.3
> maintenance stream and the corresponding unit test.
>
> I also created the same patch for the HEAD branch as the first one would not
> apply correctly.
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=234105
>
> Ed Merks wrote:
>
>
>> Cédric,
>>
>> Comments below.
>>
>> Cédric brun wrote:
>>
>>> Woa ! I should have guess that any question related to naming convention
>>> would start such a debate. Let's just say we are trying to conform to
>>> legacy code organization and keep the "guidelines" debate out of it.
>>>
>>>
>> I would have guessed. Rafael doesn't like it when folks have to follow
>> my personal choices. No doubt he considers it an example of me stifling
>> the community. He might even be right about that! But don't tell him I
>> said so!! He'll just be back to say I told you so, and I really don't
>> like that. I prefer to think I'm right all the time. In any case, being
>> human, I'm not always keen on having to do every last thing the
>> community thinks I should do for them.
>>
>> It's good to know that the naming conventions being used weren't by your
>> choice...
>>
>>> Ed, what approach would you think as the best for customizing the
>>> generation, genmodel annotations ? The problem is that the package name
>>> is retrieved with the getPackageName() (or something like that) in the
>>> JET template and we can't easily re-define this with a dynamic template.
>>> One thing I often see in the Acceleo community is a "names" generator
>>> template for such needs, even if it's only calling a "getPackageName()
>>> method. Then the client may easily re-define the way the path and names
>>> are computed in the generator without copy/pasting the generator content.
>>>
>>>
>> The GenModel itself serves that purpose. Of course the GenModel isn't
>> trivial to extend either. GenPackage has these methods:
>>
>> String getInterfacePackageName();
>> String getReflectionPackageName();
>> String getReflectionClassPackageName();
>> String getClassPackageName();
>> String getUtilitiesPackageName();
>> String getTestsPackageName();
>>
>> There are methods like this:
>>
>> public String getClassPackageName()
>> {
>> return
>> getQualifiedPackageName(getGenModel().isSuppressInterfaces() ?
>> getInterfacePackageSuffix() : getClassPackageSuffix());
>> }
>>
>> With helper methods like this:
>>
>> protected String getQualifiedPackageName(String suffix)
>> {
>> String name = getQualifiedPackageName();
>> return isBlank(suffix) ? name : name + "." + suffix;
>> }
>>
>> I could imagine checking for {0} in the "suffix" and if it's there,
>> substituting the name at that point in the suffix. This would make it
>> more flexible without impacting the existing GenModel or existing clients.
>>
>>
>>> What do you think about such an generator organization, would it be
>>> something you would integrate in EMF (I guess, considering the freeze and
>>> RC status of EMF it would only be integrated in 2.5)
>>>
>>>
>> Yes, it's too late to make any changes to APIs or that affect the
>> generated results. Of course I expect this change could be done in a
>> way that affects neither.
>>
>>> I tend to prefer such a solution instead of genmodel annotations or
>>> change, or as with these solution you ends up with many cimplicated
>>> settings in the genmodel. With the dynamic template you can define any
>>> rule you want.
>>>
>>>
>> We already have the settings. We could just make their use more
>> flexible. The problem with the solution you outline is that JET is not
>> so powerful for defining reusable utilities in the templates
>> themselves. The choice of names needs to be used uniformly across all
>> templates and even downstream clients of your model that might want to
>> reuse your model in their model will need to ensure that the choices of
>> names in your model are known in their model code...
>>
>> Of course another approach you could take is to make "basepackage" your
>> package name and use suffixes to get all the rest of the full qualified
>> name. That requires no changes. Of course I think it would be quite
>> easy to change the GenPackageImpl code to support something more
>> flexible, easier than what Tom wants to do, so I'm interested to see how
>> badly you want this. :-P
>>
>>> Cheers,
>>>
>>> Cédric
>>>
>>>
>>> Ed Merks wrote:
>>>
>>>
>>>
>>>> Rafael,
>>>>
>>>> Comments below.
>>>>
>>>> Rafael Chaves wrote:
>>>>
>>>>
>>>>> Ed, that is because you are considering the base namespace as the API
>>>>> package, and that is incorrect.
>>>>>
>>>>>
>>>> I think there are many valid ways of looking at this. Not one correct
>>>> one and many incorrect ones.
>>>>
>>>>
>>>>> For example, for the Core team, org.eclipse.core is the base package.
>>>>> For each subsystem (resources, runtime, filesystem, etc), the API is
>>>>> at org.eclipse.core.<subsystem> and the implementation is under
>>>>> org.eclipse.core.internal.<subsystem>. There is no API in the
>>>>> org.eclipse.core package.
>>>>>
>>>>>
>>>> It's all a matter of perspective. The guidelines (note that's it's a
>>>> guideline, not a rule) only state that internal is somewhere in the
>>>> qualified name, not that it must be in a specific location within the
>>>> qualified name.
>>>>
>>>>
>>>>> You are right, SWT is an exception (the only one I know of). SWT is a
>>>>> totally different beast that happens to be shipped as a plug-in (Steve
>>>>> Northover says himself, "SWT is not Eclipse"), it is not an Eclipse
>>>>> plug-in per se. They don't use the interface/implementation separation
>>>>> either.
>>>>>
>>>>>
>>>> They have listeners that are interfaces so the convention would
>>>> certainly apply there. I think Steve just doesn't like the "I" naming
>>>> convention and couldn't be convinced. Just a theory... In any case, one
>>>> can always argue "my thing is a totally different beast". One can also
>>>> argue that guidelines are just that, or they would be called rules.
>>>>
>>>>
>>>>> But you are wrong about JDT, as these guidelines apply to JDT too: the
>>>>> base package is org.eclipse.jdt, and then the JDT Core API are under
>>>>> org.eclipse.jdt.core whereas the implementation classes are under
>>>>> org.eclipse.jdt.internal.core.
>>>>>
>>>>>
>>>> Note that this pattern is achievable by specifying "core" for the
>>>> interface and "internal.core" for the implementation classes.
>>>>
>>>>
>>>>> The JDT UI API is under org.eclipse.jdt.ui whereas the implementation
>>>>> is under org.eclipse.jdt.internal.ui. There is no API in the
>>>>> org.eclipse.jdt package itself.
>>>>>
>>>>>
>>>> But there could be. There is no guideline that says use "core" is
>>>> there?
>>>>
>>>>
>>>>> That is no coincidence.
>>>>>
>>>>>
>>>> It' more of a choice than a coincidence.
>>>>
>>>>
>>>>> That is a guideline, and plug-ins in the Eclipse Project that deviated
>>>>> from that guideline in the past had to be refactored to comply with it
>>>>> (I remember that that happened to Ant UI, that had to refactor
>>>>> org.eclipse.ant.ui.internal to org.eclipse.ant.internal.ui). I am not
>>>>> making this stuff up, I was in the Eclipse Project when that happened.
>>>>>
>>>>>
>>>> Sometimes you have to wonder about where the guidelines came from and
>>>> who was involved in making up the guidelines. I don't recall being
>>>> consulted... Can any one explain what makes this conventional so good?
>>>>
>>>>
>>>>> Re: putting your money where your mouth is - totally agree. You sure
>>>>> don't have any obligation of actually implementing this feature and
>>>>> those who care strongly enough should do something about it.
>>>>>
>>>>>
>>>> As I said, I can imagine using substitutions to insert the package name
>>>> somewhere other than in front. I can also imagine a property that uses
>>>> substitutions so that you could specify I{0} as the interface name and
>>>> {o}Impl as the class name. Some folks have already asked for property
>>>> to specify an arbitrary per-EClass implementation class name. It's kind
>>>> of an endless set of "want to haves"...
>>>>
>>>>
>>>>> But that does not change the fact that more flexibility is warranted.
>>>>>
>>>>>
>>>> Of course folks will also complain about the plethora of options. :-P
>>>>
>>>>
>>>>> Your willingness to acknowledge that the flexibility is lacking would
>>>>> mean a lot to encourage the community to contribute with improvements
>>>>> in that area.
>>>>>
>>>>>
>>>> Go community go! Contributions are more than welcome. If this is
>>>> important to you, I don't really think it's all that hard to provide it.
>>>>
>>>>
>>>>> Cheers,
>>>>>
>>>>> Rafael
>>>>>
>>>>> Ed Merks wrote:
>>>>>
>>>>>
>>>>>> Rafael,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Rafael Chaves wrote:
>>>>>>
>>>>>>
>>>>>>> Ed Merks wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I think this naming pattern is bad. It's api unless it's
>>>>>>>> internal. I think the internal details of "ecorepackage" should be
>>>>>>>> nested under "ecorepackage", not above it. I have considered
>>>>>>>> supporting substitution within the "suffix" properties so that
>>>>>>>> "abc" is implicitly "{0}.abc", but I feel very strongly that the
>>>>>>>> internals for a model should be nested under the namespace of the
>>>>>>>> model's API. What good arguments can you make that some other
>>>>>>>> alternative is better? Keep in mind that I think api is horrible
>>>>>>>> and redundant. :-P
>>>>>>>>
>>>>>>>>
>>>>>>> Ed, that is similar to the package organization used by all plug-ins
>>>>>>> in the Eclipse Project itself, which is considered the ultimate
>>>>>>> exemplary code by the plug-in development community.
>>>>>>>
>>>>>>>
>>>>>> It seems to me if you read the guidelines carefully that what I'm
>>>>>> suggesting conforms exactly to the guidelines. I.e. it's
>>>>>> org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
>>>>>>
>>>>>>
>>>>>>> It would be great if EMF could support that style out-of-the-box.
>>>>>>>
>>>>>>>
>>>>>> I'd still like to see a strong argument that says all things
>>>>>> associated with org.eclipse.xyz should be in a package other than
>>>>>> org.eclipse.xyz.*...
>>>>>>
>>>>>>
>>>>>>> The same is true for using 'IName' style for API interfaces and
>>>>>>> 'Name' for implementation classes, which last time I looked was not
>>>>>>> supported.
>>>>>>>
>>>>>>>
>>>>>> Should SWT change its design to suit this style? I personally feel
>>>>>> very strongly that butchering the API names and keeping the "nice"
>>>>>> names for the internal implementation classes is a very bad approach.
>>>>>> Of course those who feel strongly enough about the issue can do more
>>>>>> than just talk about it, i.e., they can provide the code changes
>>>>>> needed to support what they want and in that way can have significant
>>>>>> influence. I assume that given that the implementation classes are
>>>>>> internal, most people ultimately don't care that it's IAbcImpl verses
>>>>>> AbcImpl since no one sees these classes anyway. I could be wrong,
>>>>>> but it's been a lot of years...
>>>>>>
>>>>>>
>>>>>>> The way it is right now, one cannot use the Eclipse Modeling
>>>>>>> Framework for generating Eclipse-style API and package structure.
>>>>>>> Isn't that weird?
>>>>>>>
>>>>>>>
>>>>>> I don't agree. Firstly, it's no more weird than the fact that SWT
>>>>>> doesn't follow this style. Did you ever wonder about that? Nor is
>>>>>> it anymore weird than the fact that no one cared enough to put their
>>>>>> coding efforts where their mouth is. As I mentioned above, living
>>>>>> with IAbcImpl doesn't seem the least bit tragic, especially if you
>>>>>> hide it in you *.internal package.
>>>>>>
>>>>>>
>>>>>>> We are already off a tangent here (sorry, Cedric!), but my point is
>>>>>>> that dictating a particular API style or package structure should
>>>>>>> not be EMF's business.
>>>>>>>
>>>>>>>
>>>>>> Certainly it's reasonable to argue that I should not impose my
>>>>>> choices on the community. It's important to consider that relative
>>>>>> to the fact that perhaps Eclipse's uses of "I" ought not to be
>>>>>> imposed on me either. In any event, given that my resources are
>>>>>> limited, a community that cares enough about the issue will put their
>>>>>> resources where there mouth is. I've not noticed that happen yet.
>>>>>>
>>>>>>
>>>>>>> This lack of flexibility results in generated API that won't fit
>>>>>>> into an organization's existing style, and in the worst case might
>>>>>>> result in EMF being deemed unsuitable.
>>>>>>>
>>>>>>>
>>>>>> I can live with that. The alternatives to EMF are few. I.e., write it
>>>>>> yourself by hand, provide patches for EMF to suit your needs, or
>>>>>> accept that no one sees IAbcImpl anyway...
>>>>>>
>>>>>>
>>>>>>> BTW, I don't like the 'api' segment either, but that really was not
>>>>>>> the point of Cedric's post anyway (he just wanted to know how to do
>>>>>>> it, not whether he should do it).
>>>>>>>
>>>>>>>
>>>>>> I understand fully the point of Cedric's post. I will continue to
>>>>>> argue strongly that given I have org.eclipse.xyz as my API, that
>>>>>> org.eclipse.xyz.internal ought to be where the internals for xyz
>>>>>> appear. That's what JDT does. I'm certainly open to hear an
>>>>>> argument to the contrary. But so far, I've not seen one yet.
>>>>>>
>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Rafael
>>>>>>>
>>>>>>>
>>>
>
>
--------------020508000305070507030705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Cédric,<br>
<br>
Thanks! As I mentioned in the bugzilla, we really shouldn't be
providing new features in maintenance streams so I'd face some
uncomfortable scrutiny if I did that. I suppose we might be able to
justify it for 2.4, but even that is a bit questionable...<br>
<br>
I'll have to take this hard line "do it yourself approach" more often.
That worked really well. :-P<br>
<br>
<br>
Cédric Brun wrote:
<blockquote cite="mid:g1gmr6$1g6$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Ed,
bug #234105 [1] is in the wild, with a patch created against the EMF2.3
maintenance stream and the corresponding unit test.
I also created the same patch for the HEAD branch as the first one would not
apply correctly.
[1] <a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=234105">https://bugs.eclipse.org/bugs/show_bug.cgi?id=234105</a>
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Cédric,
Comments below.
Cédric brun wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Woa ! I should have guess that any question related to naming convention
would start such a debate. Let's just say we are trying to conform to
legacy code organization and keep the "guidelines" debate out of it.
</pre>
</blockquote>
<pre wrap="">I would have guessed. Rafael doesn't like it when folks have to follow
my personal choices. No doubt he considers it an example of me stifling
the community. He might even be right about that! But don't tell him I
said so!! He'll just be back to say I told you so, and I really don't
like that. I prefer to think I'm right all the time. In any case, being
human, I'm not always keen on having to do every last thing the
community thinks I should do for them.
It's good to know that the naming conventions being used weren't by your
choice...
</pre>
<blockquote type="cite">
<pre wrap="">Ed, what approach would you think as the best for customizing the
generation, genmodel annotations ? The problem is that the package name
is retrieved with the getPackageName() (or something like that) in the
JET template and we can't easily re-define this with a dynamic template.
One thing I often see in the Acceleo community is a "names" generator
template for such needs, even if it's only calling a "getPackageName()
method. Then the client may easily re-define the way the path and names
are computed in the generator without copy/pasting the generator content.
</pre>
</blockquote>
<pre wrap="">The GenModel itself serves that purpose. Of course the GenModel isn't
trivial to extend either. GenPackage has these methods:
String getInterfacePackageName();
String getReflectionPackageName();
String getReflectionClassPackageName();
String getClassPackageName();
String getUtilitiesPackageName();
String getTestsPackageName();
There are methods like this:
public String getClassPackageName()
{
return
getQualifiedPackageName(getGenModel().isSuppressInterfaces() ?
getInterfacePackageSuffix() : getClassPackageSuffix());
}
With helper methods like this:
protected String getQualifiedPackageName(String suffix)
{
String name = getQualifiedPackageName();
return isBlank(suffix) ? name : name + "." + suffix;
}
I could imagine checking for {0} in the "suffix" and if it's there,
substituting the name at that point in the suffix. This would make it
more flexible without impacting the existing GenModel or existing clients.
</pre>
<blockquote type="cite">
<pre wrap="">What do you think about such an generator organization, would it be
something you would integrate in EMF (I guess, considering the freeze and
RC status of EMF it would only be integrated in 2.5)
</pre>
</blockquote>
<pre wrap="">Yes, it's too late to make any changes to APIs or that affect the
generated results. Of course I expect this change could be done in a
way that affects neither.
</pre>
<blockquote type="cite">
<pre wrap="">I tend to prefer such a solution instead of genmodel annotations or
change, or as with these solution you ends up with many cimplicated
settings in the genmodel. With the dynamic template you can define any
rule you want.
</pre>
</blockquote>
<pre wrap="">We already have the settings. We could just make their use more
flexible. The problem with the solution you outline is that JET is not
so powerful for defining reusable utilities in the templates
themselves. The choice of names needs to be used uniformly across all
templates and even downstream clients of your model that might want to
reuse your model in their model will need to ensure that the choices of
names in your model are known in their model code...
Of course another approach you could take is to make "basepackage" your
package name and use suffixes to get all the rest of the full qualified
name. That requires no changes. Of course I think it would be quite
easy to change the GenPackageImpl code to support something more
flexible, easier than what Tom wants to do, so I'm interested to see how
badly you want this. :-P
</pre>
<blockquote type="cite">
<pre wrap="">Cheers,
Cédric
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Rafael,
Comments below.
Rafael Chaves wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ed, that is because you are considering the base namespace as the API
package, and that is incorrect.
</pre>
</blockquote>
<pre wrap="">I think there are many valid ways of looking at this. Not one correct
one and many incorrect ones.
</pre>
<blockquote type="cite">
<pre wrap="">For example, for the Core team, org.eclipse.core is the base package.
For each subsystem (resources, runtime, filesystem, etc), the API is
at org.eclipse.core.<subsystem> and the implementation is under
org.eclipse.core.internal.<subsystem>. There is no API in the
org.eclipse.core package.
</pre>
</blockquote>
<pre wrap="">It's all a matter of perspective. The guidelines (note that's it's a
guideline, not a rule) only state that internal is somewhere in the
qualified name, not that it must be in a specific location within the
qualified name.
</pre>
<blockquote type="cite">
<pre wrap="">You are right, SWT is an exception (the only one I know of). SWT is a
totally different beast that happens to be shipped as a plug-in (Steve
Northover says himself, "SWT is not Eclipse"), it is not an Eclipse
plug-in per se. They don't use the interface/implementation separation
either.
</pre>
</blockquote>
<pre wrap="">They have listeners that are interfaces so the convention would
certainly apply there. I think Steve just doesn't like the "I" naming
convention and couldn't be convinced. Just a theory... In any case, one
can always argue "my thing is a totally different beast". One can also
argue that guidelines are just that, or they would be called rules.
</pre>
<blockquote type="cite">
<pre wrap="">But you are wrong about JDT, as these guidelines apply to JDT too: the
base package is org.eclipse.jdt, and then the JDT Core API are under
org.eclipse.jdt.core whereas the implementation classes are under
org.eclipse.jdt.internal.core.
</pre>
</blockquote>
<pre wrap="">Note that this pattern is achievable by specifying "core" for the
interface and "internal.core" for the implementation classes.
</pre>
<blockquote type="cite">
<pre wrap="">The JDT UI API is under org.eclipse.jdt.ui whereas the implementation
is under org.eclipse.jdt.internal.ui. There is no API in the
org.eclipse.jdt package itself.
</pre>
</blockquote>
<pre wrap="">But there could be. There is no guideline that says use "core" is
there?
</pre>
<blockquote type="cite">
<pre wrap="">That is no coincidence.
</pre>
</blockquote>
<pre wrap="">It' more of a choice than a coincidence.
</pre>
<blockquote type="cite">
<pre wrap="">That is a guideline, and plug-ins in the Eclipse Project that deviated
from that guideline in the past had to be refactored to comply with it
(I remember that that happened to Ant UI, that had to refactor
org.eclipse.ant.ui.internal to org.eclipse.ant.internal.ui). I am not
making this stuff up, I was in the Eclipse Project when that happened.
</pre>
</blockquote>
<pre wrap="">Sometimes you have to wonder about where the guidelines came from and
who was involved in making up the guidelines. I don't recall being
consulted... Can any one explain what makes this conventional so good?
</pre>
<blockquote type="cite">
<pre wrap="">Re: putting your money where your mouth is - totally agree. You sure
don't have any obligation of actually implementing this feature and
those who care strongly enough should do something about it.
</pre>
</blockquote>
<pre wrap="">As I said, I can imagine using substitutions to insert the package name
somewhere other than in front. I can also imagine a property that uses
substitutions so that you could specify I{0} as the interface name and
{o}Impl as the class name. Some folks have already asked for property
to specify an arbitrary per-EClass implementation class name. It's kind
of an endless set of "want to haves"...
</pre>
<blockquote type="cite">
<pre wrap="">But that does not change the fact that more flexibility is warranted.
</pre>
</blockquote>
<pre wrap="">Of course folks will also complain about the plethora of options. :-P
</pre>
<blockquote type="cite">
<pre wrap="">Your willingness to acknowledge that the flexibility is lacking would
mean a lot to encourage the community to contribute with improvements
in that area.
</pre>
</blockquote>
<pre wrap="">Go community go! Contributions are more than welcome. If this is
important to you, I don't really think it's all that hard to provide it.
</pre>
<blockquote type="cite">
<pre wrap="">Cheers,
Rafael
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Rafael,
Comments below.
Rafael Chaves wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I think this naming pattern is bad. It's api unless it's
internal. I think the internal details of "ecorepackage" should be
nested under "ecorepackage", not above it. I have considered
supporting substitution within the "suffix" properties so that
"abc" is implicitly "{0}.abc", but I feel very strongly that the
internals for a model should be nested under the namespace of the
model's API. What good arguments can you make that some other
alternative is better? Keep in mind that I think api is horrible
and redundant. :-P
</pre>
</blockquote>
<pre wrap="">Ed, that is similar to the package organization used by all plug-ins
in the Eclipse Project itself, which is considered the ultimate
exemplary code by the plug-in development community.
</pre>
</blockquote>
<pre wrap="">It seems to me if you read the guidelines carefully that what I'm
suggesting conforms exactly to the guidelines. I.e. it's
org.eclispe.jdt.internal, not org.eclipse.internal.jdt.
</pre>
<blockquote type="cite">
<pre wrap="">It would be great if EMF could support that style out-of-the-box.
</pre>
</blockquote>
<pre wrap="">I'd still like to see a strong argument that says all things
associated with org.eclipse.xyz should be in a package other than
org.eclipse.xyz.*...
</pre>
<blockquote type="cite">
<pre wrap="">The same is true for using 'IName' style for API interfaces and
'Name' for implementation classes, which last time I looked was not
supported.
</pre>
</blockquote>
<pre wrap="">Should SWT change its design to suit this style? I personally feel
very strongly that butchering the API names and keeping the "nice"
names for the internal implementation classes is a very bad approach.
Of course those who feel strongly enough about the issue can do more
than just talk about it, i.e., they can provide the code changes
needed to support what they want and in that way can have significant
influence. I assume that given that the implementation classes are
internal, most people ultimately don't care that it's IAbcImpl verses
AbcImpl since no one sees these classes anyway. I could be wrong,
but it's been a lot of years...
</pre>
<blockquote type="cite">
<pre wrap="">The way it is right now, one cannot use the Eclipse Modeling
Framework for generating Eclipse-style API and package structure.
Isn't that weird?
</pre>
</blockquote>
<pre wrap="">I don't agree. Firstly, it's no more weird than the fact that SWT
doesn't follow this style. Did you ever wonder about that? Nor is
it anymore weird than the fact that no one cared enough to put their
coding efforts where their mouth is. As I mentioned above, living
with IAbcImpl doesn't seem the least bit tragic, especially if you
hide it in you *.internal package.
</pre>
<blockquote type="cite">
<pre wrap="">We are already off a tangent here (sorry, Cedric!), but my point is
that dictating a particular API style or package structure should
not be EMF's business.
</pre>
</blockquote>
<pre wrap="">Certainly it's reasonable to argue that I should not impose my
choices on the community. It's important to consider that relative
to the fact that perhaps Eclipse's uses of "I" ought not to be
imposed on me either. In any event, given that my resources are
limited, a community that cares enough about the issue will put their
resources where there mouth is. I've not noticed that happen yet.
</pre>
<blockquote type="cite">
<pre wrap="">This lack of flexibility results in generated API that won't fit
into an organization's existing style, and in the worst case might
result in EMF being deemed unsuitable.
</pre>
</blockquote>
<pre wrap="">I can live with that. The alternatives to EMF are few. I.e., write it
yourself by hand, provide patches for EMF to suit your needs, or
accept that no one sees IAbcImpl anyway...
</pre>
<blockquote type="cite">
<pre wrap="">BTW, I don't like the 'api' segment either, but that really was not
the point of Cedric's post anyway (he just wanted to know how to do
it, not whether he should do it).
</pre>
</blockquote>
<pre wrap="">I understand fully the point of Cedric's post. I will continue to
argue strongly that given I have org.eclipse.xyz as my API, that
org.eclipse.xyz.internal ought to be where the internals for xyz
appear. That's what JDT does. I'm certainly open to hear an
argument to the contrary. But so far, I've not seen one yet.
</pre>
<blockquote type="cite">
<pre wrap="">Cheers,
Rafael
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------020508000305070507030705--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Goto Forum:
Current Time: Thu Apr 18 17:49:43 GMT 2024
Powered by FUDForum. Page generated in 0.02827 seconds |
] 
Search
Help
Register
Login
Home
