Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Feature IDs in generated code(Custom code generation for VCS friendly code )
Feature IDs in generated code [message #1835085] Tue, 24 November 2020 13:28 Go to next message
Janik S is currently offline Janik SFriend
Messages: 12
Registered: November 2017
Junior Member
Hi,

we are facing issues with maintaining checked in emf generated code across multiple branches. The main problem is that the generated code for the package class is containing enumerated feature ids. If the model is changed by multiple developers, it is very hard to do out of order merges. The only safe way to achieve this, would be a manual integrate with regenerating the code on the target branch. Right now we are considering to avoid checking in the generated code but instead generating it on the fly in our build process. I think both approaches have advantages and disadvantages, so far our preference would still be to have the generated code checked in (e.g. because of customized edit code, easier understanding of code history in revision control).

Are there any tips how we could solve this problem?

We thought of customizing the code generation to generate more merge friendly code. If this is possible, we think that the following changes could simplify the merging process:

a) In the ModelPackageImpl the index based feature access could use the static feature ids defined on the interface instead of duplicating the index hardcoded.
E.g:

public EAttribute getModel_Version() {
        return (EAttribute)getModel().getEStructuralFeatures().get(10);
}

//change to

public EAttribute getModel_Version() {
        return (EAttribute)getModel().getEStructuralFeatures().get(CorePackage.MODEL__VERSION);
}


b) Don't hardcode the ids on the interface, but instead generate them with some static helper. Needs to provide global counters and sub-counters for offset feature ids.

int NAMED_MODEL_ELEMENT = 16;
//change to 
int NAMED_MODEL_ELEMENT = CoreIdGenerator.metaObjectId().incrementAndGet()

int NAMED_MODEL_ELEMENT__NAME = MODEL_ELEMENT_FEATURE_COUNT + 0;
//change to
int NAMED_MODEL_ELEMENT__NAME = MODEL_ELEMENT_FEATURE_COUNT + CoreIdGenerator.featureId(NAMED_MODEL_ELEMENT).incrementAndGet();

int NAMED_MODEL_ELEMENT_FEATURE_COUNT = MODEL_ELEMENT_FEATURE_COUNT + 1;
//change to
int NAMED_MODEL_ELEMENT_FEATURE_COUNT = MODEL_ELEMENT_FEATURE_COUNT + CoreIdGenerator.featureId(NAMED_MODEL_ELEMENT).get();



This is just a rough idea how it could work without thinking much about details like thread safety (static initialization is done once per class loader?). Have there already been some thoughts about something like this? Or can you give any other recommendation for avoiding the merge problems?

If this is a valid approach, what would be the best way to customize the generation? Is it required to mirror the code and hack the changes into it, or are there any other possible hooks for modifications like this?

I think the relevant pointers for the JET template / model are here:

https://github.com/eclipse/emf/blob/master/plugins/org.eclipse.emf.codegen.ecore/templates/model/PackageClass.javajet#L200

https://github.com/eclipse/emf/blob/8b4397688e71b577c5c9b1f915da1769bab8ade0/plugins/org.eclipse.emf.codegen.ecore/src/org/eclipse/emf/codegen/ecore/genmodel/impl/GenClassImpl.java#L1043


Thanks
Janik
Re: Feature IDs in generated code [message #1835088 is a reply to message #1835085] Tue, 24 November 2020 15:29 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
I think it sounds like a misguided activity. The only things that change in a meaningful way typically are the *.ecore and the *.genmodel. To try to merge anything downstream from those doesn't seem generally sensible (except to pick up hand modified changes). But I doubt it's even possible in general to achieve your goal. One must merge the *.ecore and *.genmodel and then regenerate a single consistent result. Even if you try to merge things (because there are hand written changes), you should still regenerate to ensure that the final result is correct and consistent.

Why do I say all that? Because, if you think about what happens, if developer A adds feature foo to class X and developer B adds feature bar also to class X. Both features will use the same feature ID and which ID is "correct" in the final merged result will be determined by whether you as the merger decide to merge foo before bar or bar before foo. Merging generated downstream code will never end up with the correct ID nor the correct ID computation.

Also, I don't think you've considered yet all the places that the ID constants are used downstream, e.g., in the eGet/eSet/eIsSet/eUnset methods. They're used in a switch and must be a static compile time constant...


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Feature IDs in generated code [message #1835106 is a reply to message #1835088] Tue, 24 November 2020 19:30 Go to previous messageGo to next message
Janik S is currently offline Janik SFriend
Messages: 12
Registered: November 2017
Junior Member
Hey Ed,

thanks for the very quick answer. Hmm I think my point is, that the final id as integer number should be irrelevant, if all references are always going through the package class API. It turns out to be something like an enum. The eGet/eSet/eIsSet/eUnset methods which you have mentioned are such examples, e.g.:
public Object eGet(int featureID, boolean resolve, boolean coreType) {
		switch (featureID) {
			case CorePackage.MODEL__NAME: //I don't care if it is 0 or 57 and it is subject to change anyways
				return getName();
			case CorePackage.MODEL__FILE_VERSION:
				return getFileVersion();
        [...]


I would say that at least in java code, the features should never be accessed via a hardcoded integer, but rather by using the static field on the package interface. Whether this field has the value 57 or 58 becomes irrelevant. That is what I recommend as change a) in the package impl class. eGet/eSet/eIsSet/eUnset are already doing this correctly.

Thinking of your example now, if the ids are not hard coded but statically uniquely assigned, the order would also not matter - or am I msissing something?

[...]
int X_Foo = CoreIdGenerator.featureId(X).incrementAndGet(); //might be 57
int X_Bar = CoreIdGenerator.featureId(X).incrementAndGet(); //might be 58
[...]
or 
[...]
int X_Bar = CoreIdGenerator.featureId(X).incrementAndGet(); //might be 57
int X_Foo = CoreIdGenerator.featureId(X).incrementAndGet(); //might be 58
[...]


Referencing via the interface (CorePackage.X_Bar) would always be correct. Referencing via the integer value would today already be dangerous or even wrong?!

So far I can only imagine some problems, if we are leaving java and want to carry some feature id (e.g. serialize a feature value update: set "feature 57" to "foo" and apply it later on on a loaded model where feature 57 became a different feature). This would neither work with today's hardcoded approach.

Of course regenerating the code on the target branch is the safest approach, but this is not realistic in our case, as we have multiple release branches with staging branches. In our case we are also not trying to solve the problem of merging two separately evolved models, but we can assume that the model is changed only on one branch. We just want to relax developer dependencies and allow for out of order merges. So the target branch(es) will always follow the source branch.
Getting back to your example:

1. Developer A adds feature Foo to class X on branch Develop. Regenerate.
-> some methods will be added in several places, new feature id will be generated (and unfortunately other ids change)
2. Developer B adds feature Bar to class X on bnanch Develop.
-> some methods will be added in several places, new feature id will be generated (and unfortunately other ids change)
[state on branch Develop now: 2x several methods added -> ok to merge, easy diff in the model file -> ok to merge, some fixed ids as result of both changes -> not ok to out of order merge]

Our goal is to eventually have both changes on the Release branch. Today, it is already "ok" to first merge Developer A's changes and then Developer B's changes. In the end the Develop and Release branch will be in the same state.
With my limited knowledge about the EMF details, I'm currently only seeing the fixed ids from preventing us to merge the two changes in a different order.

I can see a problem when the generated changes are in two neighboring lines, then the code can be out of sync after a merge, but should be still functionaly correct. Of course this should be a corner case and we should take care when manually merging that the target branch should always try to get into sync with the source branch.
Can you see any other problems, which I might have overlooked?

Sorry for the long explanation, but I hope that I could better explain the idea and you can give it a second thought with the assumption that IDs should never be directly used in generated code but always accessed via the static indirection.

If you still say, this is fundamentally not possible, is the best approach for us to NOT check the generated code in but generate it on the fly?

Thanks for your help! :)
Re: Feature IDs in generated code [message #1835107 is a reply to message #1835088] Tue, 24 November 2020 19:35 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

For different reasons related to redundant API 'changes' /org.eclipse.ocl.examples.codegen/templates/model/README.txt describes revised templates that arrange for all interface ints to migrate from the one Package to the many ClassImpl.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=471114 for the development history. The usage has been in OCL and QVTd since March 2019 without untoward issues showing up.

You should be able to browse down from https://git.eclipse.org/r/plugins/gitiles/ocl/org.eclipse.ocl/+/refs/heads/master/examples/org.eclipse.ocl.examples.codegen/ to see how much has been removed from CGModelPackage and added to CGNamedElementImpl where most integer constants are inlined. Unfortunately when I try to browse down I get a Security violation. Maybe your browser / the Eclipse server will be in a better mood if you try.

Regards

Ed Willink
Re: Feature IDs in generated code [message #1835118 is a reply to message #1835107] Wed, 25 November 2020 05:57 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
It's seems that OCL has a solution sample to almost every problem, but I can't personally vouch for that.

As for your long details, I can only say that the value of a case in a switch must be a compile time constant, so FOO declared as "private static final int FOO = new Integer(10).intValue();" cannot be used as "case FOO" without an error. So I don't see how "CoreIdGenerator.featureId(X).incrementAndGet()" can provide a compile-time constant.

So no, I don't think that what you're generally trying to do is feasible and if your problem cannot be solved except by solving a generally unsolvable problem then yes, you should generate the code as part of the build not check it in.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Feature IDs in generated code [message #1835132 is a reply to message #1835118] Wed, 25 November 2020 11:26 Go to previous messageGo to next message
Janik S is currently offline Janik SFriend
Messages: 12
Registered: November 2017
Junior Member
Thanks Ed and Ed :)

Ed Merks,

sorry I made some wrong assumption, now I see the problem and you are totally right, what I proposed is not possible in Java:

public class CompileTimeConstantTest {

	public final static class CoreIds {

		private final static AtomicInteger globalIds = new AtomicInteger(0);
		private final static Map<Integer, AtomicInteger> subIds = new HashMap<>();

		public static int metaObjectId_GetAndIncrement() {
			return globalIds.getAndIncrement();
		}

		public static int featureId_GetAndIncrement(int base) {
			AtomicInteger subId = subIds.computeIfAbsent(base, b -> new AtomicInteger(0));
			return subId.incrementAndGet();
		}

	}

	public static interface CorePackageFail {
		final int MODEL = CoreIds.metaObjectId_GetAndIncrement();
		int MODEL_NAME = CoreIds.featureId_GetAndIncrement(MODEL);
		int MODEL_FOO = CoreIds.featureId_GetAndIncrement(MODEL);
		int MEMORY = CoreIds.metaObjectId_GetAndIncrement();
		int MEMORY_NAME = CoreIds.featureId_GetAndIncrement(MEMORY);
		int MEMORY_BAR = CoreIds.featureId_GetAndIncrement(MEMORY);
	}

	@Test
	public void testCompileTimeConstantsError() {
		assertEquals(0, CorePackageFail.MODEL);
		switch (0) {
		case CorePackageFail.MODEL: //Error: Case expression must be constant expression
			break;
		default:
			fail();
		}
	}

	public static interface CorePackage {
		final int MODEL = 0;
		int MODEL_NAME = 0;
		int MODEL_FOO = MODEL_NAME + 1;
		int MODEL_BAR = MODEL_FOO + 1;
		int MEMORY = 1;
		int MEMORY_NAME = 0;
		int MEMORY_BAR = MEMORY_NAME + 1;
	}

	@Test
	public void testCompileTimeConstants() {
		assertEquals(0, CorePackage.MODEL);
		switch (0) {
		case CorePackage.MODEL:
			break;
		default:
			fail();
		}
	}

}


Nevertheless, maybe there are other similar possibilities to minimize the effect of a model change on the generated code. You already have expressions in the assignments today, so some increment expression could be used to reduce the number of changes (see unit test above). Alternatively maybe Enums could be used in some way, as the positioning alone already defines some kind of uniquiness - but maybe not ideal, as we would need multiple enums?!

Ed Willink, I had a quick look at your discussion and solution and this is an interesting point - are the ids public API or not?! First I was thinking, maybe it is not even required, as the real features (and object identity) are API enough. On the second look though, I see that they are also referred to in e.g. notifications, hence they should be publicly available. So I would say, yes, the IDs serving as "unique identifiers" is public API, but the real "integer values" themselves are an implementation detail and should never be directly written in generated code except for the definition. Like this all references remain stable. (this is problem 'a)' I was mentioning)
I see that you have moved the feature ids from the package into the class. I could not see how they are used in the notification infrastructure, on the package they are completely removed right? Are they still exposed in the Class interfaces or you could you eliminate them completely from the API?
Re: Feature IDs in generated code [message #1835136 is a reply to message #1835132] Wed, 25 November 2020 13:01 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Well, the whole point of the IDs is to make reflective lookup super faster. This is why an EObject.eGet is faster than a HashMap.get. The assigning of IDs is complicated by things like multiple inheritance. And then there's org.eclipse.emf.ecore.EClass.getFeatureID(EStructuralFeature) for which these ID values need to be consistent.

Your goal of wanting to be able to merge generated code easily for multiple independent model changes, and in all cases, is simply at odds with wanting to generate the highest performing result. To my thinking, there will always be corner cases that don't work. Hence I see the effort you are investing as effort that would be better invested in generating code as part of a build.

In the project on which I currently working, the models are expressed in Xcore and Tycho build generates source automatically, so the only thing than needs merging is the one *.xcore model file. The IDs just don't matter, other than that they produce high performance results.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Feature IDs in generated code [message #1835146 is a reply to message #1835136] Wed, 25 November 2020 15:40 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

On those rare occasions when you need the integer values, the prevailing (not frozen API) value is available via the getters in the Literals interface.

Regards

Ed Willink
Re: Feature IDs in generated code [message #1835165 is a reply to message #1835146] Thu, 26 November 2020 09:23 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

The more general problem of stabilizing order might benefit from a change of merger philosophy. Currently the merger endeavours to preserve existing ordering, which is sensible for a single linear development. However I find that if I develop a change that ultimately involves changes A, B, C where A,B,C are in the order of the Ecore file declarations, but incrementally I developed it as B then C then A, the incremental merge accommodates B,C,A and is inconveniently different to the start again with A,B,C at the end of the incremental experiment/research. You are probably seeing similar issues with concurrent developments.

If rather than preserving prevailing order, the merger imposed a sensible (typically alphabetical) order there would be far fewer merge conflicts as the results of changes A,B,C are accommodated in distinct orders. The merger could therefore read old/new files as a hierarchy of 'paragraphs' such as package/class/nested-class/operation/field taking care to aggregate all comments to the nearest 'paragraph'. The hierarchies can then be sorted and interleaved with merge conflicts left distinctively marked to force user attention. A similar functionality would be helpful in GIT, except that would then make GIT Java-language aware.

Regards

Ed Willink

Re: Feature IDs in generated code [message #1835167 is a reply to message #1835165] Thu, 26 November 2020 09:35 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
I really can't make any concrete sense of what you abstractly describe here. I'm not even sure which "merger" you're referring to. The one used by the compare tool or the one used by EMF when you regenerate?

It's probably not important for me to understand because if it's the former, I don't control that, while if it's the latter, I don't plan to change my philosophy about its implementation.

I feel this problem is a rat hole.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Feature IDs in generated code [message #1835188 is a reply to message #1835167] Thu, 26 November 2020 16:12 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Ed Merks wrote on Thu, 26 November 2020 04:35
I feel this problem is a rat hole.


I couldn't agree more. I'm just identifying some directions that Janik might consider if he really needs to address the problem. Any change to the post-JET merger will hit myriad legacy issues.

Regards

Ed Willink
Re: Feature IDs in generated code [message #1835191 is a reply to message #1835188] Thu, 26 November 2020 17:10 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
I can only advise people not to go down a rat hole. The fundamental rat hole problem here is that the final code that one needs from the final merge does not exist in the any of the sources that one can try to merge. Hence one must recast the problem domain such that one generates different code where that is not a fact. So if one is going to recast the problem domain, surely then it's better to recast it such that you are not merging generating code in the first place instead of focusing on making the generated code "merge" friendly, with the underlying assumption that it is even feasible.

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Feature IDs in generated code [message #1835197 is a reply to message #1835191] Thu, 26 November 2020 21:57 Go to previous messageGo to next message
Janik S is currently offline Janik SFriend
Messages: 12
Registered: November 2017
Junior Member
Hey guys,

thanks for your opinions and help, we are now trying the "don't check the generated code in" approach. We are indeed also using xcore and now incorporated the generation into our build by using maven (after some starting problems ;)) - Good opportunity to get into touch with maven, as the product build itself is still done with ant :/
We still have the edit code checked in, since this code is more stable with regards to an evolving model and it might simplify customizations (e.g. getText, getImage). Or Ed would you recommend to also always regenerate those and customize them via subclassing or any other mechanism?

After some time we will see how the whole thing goes. Right now it feels like the better approach :)

Thanks
Janik

PS: I still think that any generated direct id references not accessing the static fields exposed on the package API are not ideal and should be fixed - if possible ;)
Re: Feature IDs in generated code [message #1835201 is a reply to message #1835197] Fri, 27 November 2020 03:49 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
The item providers are much simpler to merge and indeed are typically hand modified, so unless you use some type of "generation gap" approach (which is not directly supported by EMF but used "others"), keeping that checked in likely makes sense. Even if you were to use subclasses, you'd end up with very similar issues merging the hand-written subclasses.

Given that there is no funding for EMF, don't expect too much to happen, especially not things that involve changing a bunch of templates to design and maintain forever yet another "generation pattern"...


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Feature IDs in generated code [message #1835212 is a reply to message #1835201] Fri, 27 November 2020 08:23 Go to previous messageGo to next message
Janik S is currently offline Janik SFriend
Messages: 12
Registered: November 2017
Junior Member
I thought subclassing + an item provider factory returning the specialized item providers is the generation gap pattern. But yes, if it is not required, then we go for the simpler approach.

I was not considerung this change to be a fundamentally different "generation pattern", more a cleanup of the existing "generation pattern". I also thought that it should not be too complicated, as it is done "correctly" in most other places already. So I was more just interested in whether you agree with the point, or if there is a concrete reason, why in certain places the numbers are hardcoded and in other places the indirection via the API is done? If you say this makes sense, I could also try to come up with some proposal, but of course it doesn't make sense to look into it, if you don't agree. :)
Re: Feature IDs in generated code [message #1835221 is a reply to message #1835212] Fri, 27 November 2020 10:58 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
It's not entirely clear to me what you want to see differently, which things you consider correct, and which you consider incorrect and should be fixed/improved. At this point, I don't believe anything is incorrect and I see nothing that needs improving in this regard. All the classifier constants are assigned a literal int based on the classifier's position in the EPackage.eClassifiers list. The feature IDs use constant expressions or int literals, but whatever they use, if it is the correct value, then I'm not sure why it would need to be changed to something else...

You might not consider changes to templates a different generation pattern, but any changes to templates that change what's generated will generally need to be conditional because consumers are not used to EMF changing the generated results regularly/arbitrarily...


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Feature IDs in generated code [message #1835229 is a reply to message #1835221] Fri, 27 November 2020 13:24 Go to previous messageGo to next message
Janik S is currently offline Janik SFriend
Messages: 12
Registered: November 2017
Junior Member
What I meant was e.g. this:

interface CorePackage extends EPackage {
[...]
	int MODEL__AUTO_INCLUDE_IP_LIBRARIES = 59;
[...]
}

public class CorePackageImpl extends EPackageImpl implements CorePackage {
[...]
        public EAttribute getModel_AutoIncludeIpLibraries() {
              //return (EAttribute)getModel().getEStructuralFeatures().get(59); //generated
              return (EAttribute)getModel().getEStructuralFeatures().get(CorePackage.MODEL__AUTO_INCLUDE_IP_LIBRARIES); //in my opinion better
        }
[...]
}


Unless there is a concrete reason to not use the feature ids assigned on the interface, I think the cleaner generated code would be the second (i.e. the int literals / const expressions are only written in one single place - where the ids are declared)

You are right in saying, that there is no functional difference. Probably the next argument will be, the code is generated, so nobody needs to care .. ;)
Consumers may not be used to EMF changes, but I have seen it in the past (e.g. usage of StringBuilder, ..) - so switching the emf versions does not guarantee you the same generation output. Btw, we even observed different emf output in exactly the same eclipse (different users) - so there must be some user code-formatting preferences affecting the generation output - but this is a different story.
Re: Feature IDs in generated code [message #1835232 is a reply to message #1835229] Fri, 27 November 2020 14:04 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Janik S wrote on Fri, 27 November 2020 14:24
[...]Btw, we even observed different emf output in exactly the same eclipse (different users) - so there must be some user code-formatting preferences affecting the generation output - but this is a different story.


Yes, you can, for example, execute the source code formatter as part of the generation procedure. If you do that in multiple workspaces you better make sure that you store the formatter profile in the project-specific settings - not in the global workspace preferences - and commit it to your source code repository along with your sources.


Re: Feature IDs in generated code [message #1835237 is a reply to message #1835232] Fri, 27 November 2020 14:56 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

You latest suggestion contradicts your desire for source stability. When you add a new feature, currently the int assignments change but the mnemonic references are stable. With your suggestion, all references will change so you trade off one change for "FEATURE = 61" to "FEATURE = 62" against perhaps 5 changes in each of the autogenerated switch cases such as "case 61" to "case 62" rather than a stable "case FEATURE".

The OCL approach has this trade-off, but since a new feature is class-plus-derived-class localized rather than every change anywhere affecting the EPackage, the changes although line-by-line more costly are overall more proportionate.

Regards

Ed Willink.
Re: Feature IDs in generated code [message #1835239 is a reply to message #1835237] Fri, 27 November 2020 16:04 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Okay, we really are going down the rat hole and then down into the side tunnels of the rat hole... :-(

Firstly as for the StringBuilder/StringBuffer, it seemed unlikely to me that anyone would want an option to keep generating StringBuilder. I could be wrong, but no one complained. I actually only did this because the Platform, which uses EMF, went on a StringBuffer witch hunt, and were whining about this, otherwise who really cares? It's not a performance issue! But it's simply impossible to keep everyone happy...

As for the hard coded numbers in methods like this:
  public EReference getEClass_EAllSuperTypes()
  {
    return (EReference)eClassEClass.getEStructuralFeatures().get(11);
  }
You should note that feature IDs from the package interface are indexes in eClass.getEAllStructureFeatures(), but in this code we are accessing eClass.getEStructuralFeatures(), This is a different list (the features declared local to this class as opposed to all feature available via inheritance). For this there are no constants in the interface for the things at each index. So your suggested change is actually wrong, and generating yet more constant seems overkill because they'd not be used outside of this initialization code.

Soon it will be time to send a invoice for my 1 hour of time!! :-P


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Feature IDs in generated code [message #1835240 is a reply to message #1835237] Fri, 27 November 2020 16:18 Go to previous messageGo to next message
Janik S is currently offline Janik SFriend
Messages: 12
Registered: November 2017
Junior Member
Sorry Ed, seems like there is some misunderstanding on my or your side.
My point is that 62 should only be used in ONE single place, the place where the id is declared: FEATURE = 62. It should NOT be used in any switch case statement .. NEITHER in the place which I mentioned in my last post :
return (EAttribute)getModel().getEStructuralFeatures().get(62);

In this place it should rather be
return (EAttribute)getModel().getEStructuralFeatures().get(CorePackage.FEATURE);
... which is not the case today

There is only one argument I could imagine: if the feature name changes, the static field name changes, hence all references change - if the int value was used instead for references, only the field name changes and all references (via the int) are stable. This is not a strong argument in my eyes.

Eike, thanks for the recommendation, maybe we should fixate the auto formating for those particular projects then. An option in the gen model for an eclipse preference independant generation would be good - or maybe already exist?


EDIT:
After reading Ed Merks last post it makes sense now. I was checking our diffs and it looked very much like duplicated ids. If this is not the case, please forget about it. Thanks for the explanations and sorry for wasting your time. :)

EDIT2:
I'm not complaining about the StringBuilder change, this is totally fine - it just popped into my mind first, when you said EMF users are not used to generator changes.

[Updated on: Sat, 28 November 2020 09:35]

Report message to a moderator

Re: Feature IDs in generated code [message #1835349 is a reply to message #1835240] Tue, 01 December 2020 11:02 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Janik S wrote on Fri, 27 November 2020 17:18
Eike, thanks for the recommendation, maybe we should fixate the auto formating for those particular projects then. An option in the gen model for an eclipse preference independant generation would be good - or maybe already exist?


No, you just enable source code formatting in the Genmodel, and then configure your project(s) accordingly.


Previous Topic:Element matching
Next Topic:Two different XML custom serializations for the same model
Goto Forum:
  


Current Time: Fri Mar 29 08:04:55 GMT 2024

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

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

Back to the top