Bugzilla – Full Text Bug Listing
| Summary: | [codegen] Code generation broken when parameters share EClass name | ||
|---|---|---|---|
| Product: | [Modeling] EEF | Reporter: | Miles Parker <milesparker> |
| Component: | General | Assignee: | EEF Inbox <emft.eef-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | goulwen.lefur, rom1.bernard, stephane.begaudeau |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
I have a similar problem with an EClass named Context...
Context ''''''context''''' = (Context)semanticObject;
if (ContextViewsRepository.Context_.Properties.ownedElement == event.getAffectedEditor()) {
if (event.getKind() == PropertiesEditionEvent.ADD) {
EReferencePropertiesEditionContext '''''''context'''''''''' = new EReferencePropertiesEditionContext(editingContext, this, ownedElementSettings, editingContext.getAdapterFactory());
An idea would be to prefix or suffix variables in generated code to avoid these naming collisions ?
We have fixed the Miles' issue, but this one could be still present. The only way to fix it for you is to rename your EClass I wonder if there is a good generic solution for this, short of (ugh) fully qualifying all of the framework class references. Perhaps it might make sense to do something like FEvent FConext, though that's ugly as well. I'm wondering how EMF handles this? No one is likely to name a class IItemProvider, but what would happen if for example someone created say a ResourceSet class.. I'm not sure there is a good generic solution. I'm agree with you the "prefix" solution is very ugly. I tried to analyze how EMF do. I can't remember its solution but I think it wasn't appliant for EEF :( Personnally, I would not be shocked by a '_context' variable, instead of 'context'... It would be very surpising if someone had an EClass named '_Context'... And the places where these naming collisions can occur are finite... (In reply to comment #5) > Personnally, I would not be shocked by a '_context' variable, instead of > 'context'... It would be very surpising if someone had an EClass named > '_Context'... > And the places where these naming collisions can occur are finite... Yes, I think at least the variable names should follow some such naming convention. In that case even something like componentContext would work. I know this would only be possible with a major version change but it might make sense to simply use more detailed / less generic class names, such as EditingContext (I'm not sue what would be appropriate here.) The Eclipse EEF team has worked over the past few months on a brand new runtime using a reflective approach which can be used more easily with Eclipse Sirius. Since we do not plan to continue to work on the old runtime and its code generation approach, I will close this issue for now. If you want to contribute, you can reopen this issue and submit a contribution to the project thanks to our Gerrit: https://git.eclipse.org/r/#/admin/projects/eef/org.eclipse.eef |
The following code: /** * {@inheritDoc} * @see org.eclipse.emf.eef.runtime.impl.components.StandardPropertiesEditionComponent#updateSemanticModel(org.eclipse.emf.eef.runtime.api.notify.IPropertiesEditionEvent) * */ public void updateSemanticModel(final IPropertiesEditionEvent event) { Event event = (Event)semanticObject; if (ButterflyzerViewsRepository.Event.Properties.label == event.getAffectedEditor()) { breaks for me because Event is also the name of one of my EClasses. (Trust me to discover this one!)