|
| Re: ECoreSwitch design [message #431018 is a reply to message #431016] |
Wed, 24 June 2009 12:48  |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
David Michonneau wrote:
> Hi,
>
> Is there a reason why the EcoreSwitch implementation of the visitor pattern
> chooses to implement calls to caseEXxx (X) from most specific type to least
> specific type by testing its result against null?
>
Yes, so that the most specific case can make the decision.
> For instance the following code in EcoreSwitch for enums types:
>
> case EcorePackage.EENUM:
> {
> EEnum eEnum = (EEnum)theEObject;
> T result = caseEEnum(eEnum);
> if (result == null) result = caseEDataType(eEnum);
> if (result == null) result = caseEClassifier(eEnum);
> if (result == null) result = caseENamedElement(eEnum);
> if (result == null) result = caseEModelElement(eEnum);
> if (result == null) result = defaultCase(theEObject);
> return result;
> }
>
> The default implementations of caseEXxx all return null:
> public T caseEEnum(EEnum object)
> {
> return null;
> }
>
> The typical implementation as described in the GoF book would rather be:
> public T caseEEnum(EEnum object)
> {
> return caseEDataType(object);
> }
>
With multiple inheritance will visit some cases more than once though,
at least for the ones that return null.
> This may seem unimportant, however I've tried to implement a visitor
> performing side effects by subclassing ECoreSwitch<Object> and always
> returning null; of course it did not work because all caseEXxx functions
> were being called.
Though fortunately none are called more than once, but then you'd not
notice that with Ecore itself because it doesn't use multiple inheritance.
> This would not happen in the classic visitor
> implementation.
>
Design involves trade-offs.
> Thanks,
>
> David
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02835 seconds
] 
Search
Help
Register
Login
Home
