Community
Participate
Working Groups
Eclipse-Projects but also other companies have codeing guidelines where e.g. the interface name always starts with an "I" and the real implementation doesn't contain an "Impl" but is simply the name of the class.
I'll mark it as an enhancement request.
Created attachment 101878 [details] patch
I'd really like to do this in EMF 2.5. I'm not a big fan of the "I" pattern, but I do think we should support it for those who are. Notice that we don't treat all classes equally. Many, such as the item provider implementations don't get the "Impl" suffix, since there's no type-specific interface that they're implementing. I think I like Tom's approach, which doesn't affect those ones, but it would be more general and flexible if we provided another attribute for them. The patch doesn't apply the class name pattern to the resource and resource factory implementation. I haven't checked exhaustively to ensure everything else is correct.
I can't stand the I naming convention. I think it's ridiculous that we deal with things like IFile everywhere and never see a File. The human readable name is internal and the butchered name is the API. But hey, that's just my opinion. This is clearly an API change and needs to wait. I know Kenn generates resource interfaces but we don't, so we should coordinate that properly. I don't really want to anticipate yet more ways that folks might want to butcher their names. Someone who wants that can help provide it the way Tom has.
*** Bug 147380 has been marked as a duplicate of this bug. ***
Dave is there something I can do to bring this forward the earlier in the release cycle we get this in the better we can test and make 100% sure nothing gets broken. If you instruct me where to look at for things that you think have to be changed I can work on it.
Tom, I think it just needs for me to look carefully. I can't conjure a list of things off the top of my head, unfortunately. That's more Ed's style. ;-) Given that we'll be building M1 tomorrow, are you comfortable with it being in M2?
Dave, M2 is fine for me. Maybe we need this feature for e4 where the workbench model is created with EMF and then we can ensure that the interfaces start with an I (though I'm also not a favorite) if we still want that to happen. I've CC'ed Boris and Eric who are working with me on this e4 topic.
Created attachment 110877 [details] My first cut at improving the patch Here's a first cut at improving the patch, just so you can see that I'm working on this. ;-) I started with Tom's patch and found and addressed a bunch of issues. 1. Fixed problems with supppressed interfaces and/or metadata. For example, suppresing interfaces caused some names to go back to the basic, unaltered names, but others not. I made it consistent: the patterns are only used when interfaces aren't suppressed. 2. Introduced some new API to get at the basic names, unaltered by an interface name pattern: GenBaseImpl.getInterfaceName(), GenPackage.getFactoryName(), and GenPackage.getBasicPackageName(). 3. Included resource and resource factory. They also use the class naming pattern. I think it would be nicer if they also switched to the basic name when interfaces are suppressed, but I think it's too late for that kind of change. 4. Added the new GenModel attributes to GenModelImpl.reconcileSettings() so they'll carry over when a model is reloaded. 5. Changed category for the attributes (Model Feature -> Model) and improved (hopefully?) their descriptions. 6. Fixed a previously existing problem with GenPackageImpl.getQualifiedEFactoryInstanceAccessor() and getQualifiedEFactoryInternalInstanceAccessor(). I noticed that the former was doing unneccessary casting when both interfaces and metadata are suppressed. I've done some more hunting to catch more uses of interface names inside other names (e.g. <Interface>StackFrame, get<PackageInterface>Package, etc.), which don't really work so nicely with non-default interface names, and replacing them by the basic name (using the new APIs mentioned above). I'm still testing that and should have a new patch tomorrow morning. I'm still not thrilled with the descriptions, so any input there would be appreciated. Also, I wish the properties appeared next to each other, but alas, alphabetical ordering strikes again. I really don't like the name getBasicPackageName(), but unfortunately getPackageName() is already taken...and it does exactly the same thing as getName(). Rage! So, again, better ideas would be appreciated. My other ideas, which I liked even less, were getSimplePackageName(), getPackageUnsplitName() (as in, when the interface/implementation split is disabled).
Created attachment 110884 [details] Patch take 2 Here's my second take. I've switched all the questionable uses of GenPackage.getPackageInterfaceName() and getFactoryInterfaceName() that I could find to getBasicPackageName() and getFactoryName(). I also introduced getUncapPackageName() and getUncapFactoryName() and deprecated getUncapPackageInterfaceName() and getUncapFactoryInterfaceName(), switching all uses of them over to the new ones. This definitely seems better to me. In addition to the name/description issues I mentioned in the previous comment, there's still another thing I'm considering. One more patch to come...
Created attachment 110885 [details] Patch take 3 Here's one last refinement tonight. It's just a small change: I cleared the default values for interfaceNamePattern and classNamePattern (they were "{0}" and "{0}Impl"), and made GenBaseImpl.getInterfaceName() and getClassName() use those patterns by default if none are specified. I think this approach makes things a little nicer looking, initially, and a little more resilliant. I prefer not to have weird patterns like that staring new users in the face. Also, if someone clears these properties (and doesn't know about the magic reset button), they can still generate working code, which is nice. The other approach is a little more straightforward, though, so if someone prefers it, I'm not totally committed.
Oh, for people who don't like to read lots of comments, just go ahead and look at my last patch, and take note of the last two paragraphs of comment 9. ;-)
Dave, It looks good.
Ed, Thanks, but any comments on my naming/description questions (comment 9)? Any preference regarding the default values for interfaceNamePattern and classNamePattern (comment 11)?
Based on feedback I received from Ed, I'm planning to change the descriptions to these: Pattern for deriving interface names from model element names ("{0}" by default) Pattern for deriving class names from model element names ("{0}Impl" by default) Also, I'm going to change the method name getBasicPackageName() to getEffectivePackageName(). I'll commit this before the end of the week. I'm going to be away for the next two weeks, and I promised this would be in M2. Any comments, Tom?
I didn't had time to take a look because I'm so loaded with work, sorry.
No problem Tom! We all know how that feels. I think I'll go ahead and commit the patch this week and if you find any issues when you try to start using it, we can address them then.
+1, I'll give it a spin when the changes are in
The enhancement is in CVS for EMF 2.5. In the end, I decided to stick with getBasicPackageName(), since the existing "effective" methods all seem to refer to what's in effect when taking GenModel properties into consideration, and this is the *opposite* of that. The basic package name is just the package prefix with "Package" appended. Depending on GenModel.suppressInterfaces, GenModel.suppressEMFMetaData, and GenModel.interfaceNamePattern, it might be changed to something else.
Fix available in HEAD: 2.5.0.I200809021800.
Fix available in HEAD: 2.5.0 (R200906151043).
