[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled' workbench UI
|
Tom,
I personally like EObject being in the API for exactly this type of reason.
I.e. it provides a very small set of extremely useful methods to access the
adapters (for receiving notifications), the container, the contained
children, the metadata, and so on as well as making it easy to apply any
reflection-based utilities to the instance. But some folks are purists and
don't want any method other than the ones they've provided visible. (Those
same people aren't the least bit bothered by all the methods that
java.lang.Object introduces into their class hierarchy.) Other folks are
pseudo purists and want to define their own facade API instead. For these
reasons, I try to make EMF be more like plastic, so that it can be molded
to best suit other people's ideals rather than just my own...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
Tom Schindl
<tom.schindl@best
solution.at> To
Sent by: E4 developer list
eclipse-incubator <eclipse-incubator-e4-dev@eclipse.o
-e4-dev-bounces@e rg>
clipse.org cc
Subject
04/04/2008 08:08 Re: [eclipse-incubator-e4-dev]
AM Initial discussion on the
'modelled' workbench UI
Please respond to
E4 developer list
<eclipse-incubato
r-e4-dev@eclipse.
org>
Ed Merks schrieb:
> Kevin,
>
> Comments below.
>
>
> Ed Merks/Toronto/IBM@IBMCA
> mailto: merks@xxxxxxxxxx
> 905-413-3265 (t/l 313)
>
>
>
> eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 04/03/2008 06:40:36
> PM:
>
>> I believe there's going to be a lot of reluctance to introducing EMF
>> into the platform.
>
> Really, I wonder why you believe that? So far there seems to be mostly
> support in favor of reusing long established technology and experience.
>
>> Although maybe not for good reason.
>
> I suppose we can dismiss the bad reasons pretty quickly and then focus on
> the good reason.
>
>> The problem
>> with these kinds of discussions is that they're so abstract that its
>> easy for personal preferences or ignorance (in this case, mine) to
>> get in the way.
>
> Yes, human nature will always be what it is. Just as the neighbour's
grass
> always looks greener, your own baby always seems cuter. (I've figured
the
> greener grass thing out though. It's because grass from an angle looks
> greener than if you look straight down at it. So the neighbours grass
> looking greener is perspective thing than changes as soon as you walk
over
> and look closely to notice the bare earth and the infiltrating weeds.)
>
>
>> I've not done any in-depth EMF work, I'd say I've
>> more been acquainted with an EMF model or two but, well you know,
>> never really gotten to know them. I'm sure their really wonderful
>> once you take the time, I'm embarrased to say that I've not.
>
> Given that you can completely suppress EMF (EObject, EList, and so on)
from
> the model's API, you might even have met a few "closet" EMF models. :-P
>
Well there are things we can't hide from the API because we need a
possibility to attach-listeners to our model so what we need to expose
are the things coming from EMF-Common (Adapter, Notification) if I'm not
completely mistaken.
I'm going to study Eric's code on the weekend to understand how his
model works :-)
Tom
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl leiter softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
