Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [emf-dev] ESetting/EOperation Delegate

On Jun 29, 2009, at 1:53 PM, Achim Demelt wrote:

I personally would prefer one general hook (like in over the several
special ones.
I'd like to specify guarding behavior for common (non-derived)
features as well.

In the spirit of separation of concerns, I tend to prefer specialized
hooks/adapters for each distinct purpose over a "one-size-fits-all" solution.
In this particular case, I'd also argue that the scope of the extensions is a
different one. The computational behavior of derived properties and operations
is rooted at the (meta)model level, i.e. every instance of the model obeys the
same computational rules. The adapter pattern, however, and especially the one
discussed in bug 247130, applies to the instance level. IMHO, this warrants to
separate concepts.

I'm not saying that the adapter pattern should be limited to that.
I'm only saying that one might be able to implement the computation of derived properties with that hook.
But you're right that it belongs to the Ecore model not to the actual instances.
On the other hand this would make it possible to hold internal, transient and private state (like e.g. caches).

Anyway, what I originally had in mind is that I would like to be able to write behavior for non-derived features as well as for derived ones.
One often wants to derive/compute default values if a features has not been set. Maybe it would be sufficient to allow expressions in the default literal field, but I generally prefer less and more powerful hooks as opposed to many little limited ones.


Back to the top