Re: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled' work

[Ed Merks <merks@xxxxxxxxxx>]

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/07/2008 02:58:47
PM:

>
> >>I think the contrary is the case.  A weakly typed with almost no
metadata
> >>leaves the user with code that's right only if it behaves right after
> >>extensive testing.
>
> Just to get ahead of things, I'd like to avoid discussions that
> reduce down to the merits of a static typing vs. weak typing vs....

When someone says something is easier (a blanket statement) without stating
a reason, and I think the opposite is the case, giving the reason why I
think that's so, that seems to be a good thing not to avoid.   I know from
past experience that folks often assume that static typing == strong typing
and that weak typing is the alternative/opposite of this.  What gets lost
in the picture is dynamic typing which can be just as strong without being
static.  It's very helpful for catching failures early, i.e,. typically at
the point of creation, rather than later, at the point of consumption...

> Not that I thought you were doing this Ed, just making a blanket
> statement early in.  You know, there's more than a few former
> Smalltalk programmers here (sniff) and I'd love to live in a world
> where our Java doesn't require extensive testing.  At this point,
> everyone's picked sides, the arguments have been played out, and
> beliefs border on the religious without much chance of converting
someone.

I know there are all kinds of personal preferences involved in life, but I
also like to think there is a fundamental technical basis underlying the
important technical issues that have nothing to do with religion or liking
blue better than green.  Most technical designs are so difficult because
they involve a balance between extremes.  If we could just make some
foundational piece trivially simple, the hard problems don't just go away,
they just end up somewhere else.  If we make the foundational piece
incredibly rich and complex, the simplest things might suddenly seem quite
involved.  So somehow things need to be simple while still being rich and
expressive and in becoming the latter, without also becoming too complex.
Constraints are generally good, as long as they don't make things too
rigid.  It's all a balancing act and there in the opinions begin to hold
sway.

>
> I'm completely with you in the value of first class metadata support.
>
> What's clear is that we'll need to drive the model from languages
> which run the gammut of typing.

I would imagine that a weakly typed language can always subsume a strongly
typed one, though the results of changes might not be well formed anymore.
I also imagine that a strongly typed language with sufficiently weak
constraints (every feature is of type java.lang.Object) can subsume a
weakly typed one.  It's kind of the Turing completeness thing in
disguise...

> Your response below Ed suggests
> that EMF is flexible in this regard, right?

I think so.  It's up to the user do define a constrained model or a wide
open one...

> But is that just in the
> definition of the model or in consumption too?

Generally EMF can serialize an instance to XML and generally XML is such
that it can be consumed by any other language, so in that sense I suppose
so.

> How do we say access
> a strongly typed EMF model from a language like Javascript?

I imagine you could quite easily convert any instance to JSON.  But JSON is
more of a map of properties type of thing, so it wasn't so clear to me how
to convert JSON back into typed objects.  I imagine we'd need to solve this
issue with ModelElement as well (and might be as easy as marking things
with a property representing the type).

Is saying "the same way as we do a Java Bean" a good answer?  Not that I
know how that's done...  :-P

>
> Kevin
>
>
>
>

>
> Ed Merks/Toronto/IBM@IBMCA
> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> 04/06/2008 04:04 PM
>
> Please respond to
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>
> To
>
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>
> cc
>
> "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>, eclipse-
> incubator-e4-dev-bounces@xxxxxxxxxxx
>
> Subject
>
> Re: [eclipse-incubator-e4-dev] Initial        discussion
> onthe'modelled'workbench UI
>
>
>
>
> Comment below.
>
>
> Ed Merks/Toronto/IBM@IBMCA
> mailto: merks@xxxxxxxxxx
> 905-413-3265  (t/l 313)
>
>
>
> eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 04/06/2008 01:35:15
> PM:
>
> >
> > Tom, have no fear..I'm not at all closed on discussions about the
> > API. I was just going to start them -independently- of whether or
> > not EMF is a suitable candidate as 'Model Server' (we should likely
> > start a different thread for this)...the question remains; can EMF
> > emulate the current API and, if so, at what cost?
>
> Another important question, which I think Tom is raising, seems to be:
> what's the basis for the current API?  Why is it the way it is? Why is it
> the benchmark?  I can see it's very minimal, but the design motivations
> aren't so clear.
>
> >
> > Your comment "Eric's model is perfectly suited for scripting guys"
> > is true.
>
> I think the same is true for EMF.  In fact, I think it's even more
true...
>
> > Given that this is a design requirement I don't think that
> > it's inappropriate. I realize that there's a trade-off between an
> > unbounded and untyped 'bag of properties' and a formalized full on
> > completely meta-modeled structure. The main problem I see with the
> > fully modeled approach is that I fear that it'll make our users life
> > more difficult.
>
> I think the contrary is the case.  A weakly typed with almost no metadata
> leaves the user with code that's right only if it behaves right after
> extensive testing.  What aspect of full modeling do you think will make
the
> user's life more difficult?  Something like DOM is very flexible yet most
> folks don't consider DOM to be a good API for general purpose data
> manipulation...
>
> > If they want to use ModelElement as the basis for -
> > their- domain object will they be required to get into writing an
> > ECore extension to the ETreeModel metamodel (or whatever the EMF
> > equivalent is) n order to use the JFace viewer ?
>
> EObject is just like ModelElement, only richer in that it is strongly
> typed.  And don't confuse strong typing with static verse dynamic typing.
> EMF supports all these things.  It's often the case that any model can be
> rendered in a variety of different ways, so I'm a bit curious about the
> fact that you seem to be implying that there is kind of a direct
one-to-one
> correspondence between model and view...
>
> > I'd be more than
> > glad to find out that this is YAGF (Yet Another Groundless Fear...;-).
>
> Anyone can define a model independant of all other models, and the
model's
> API need not reveal it's basis in EMF in the API.  I.e., there's no need
to
> extend EObject in the interfaces.  So users just design a model using
> annotated Java, XML Schema, Ecore, UML, or anything else folks might
dream
> up as a nice way of describing a model.  Similarly I would imagine it
> should not be necessary to see ModelElement in any client-defined API; it
> would just be an implementation detail.
>
> >
> > The 'loose' approach is based on a concept of 'common properties'; -
> > any- ModelElement that contains a GUI_LABEL and/or a GUI_IMAGE
> > property can be hosted in a tree (or a menu, toolbar or CTabItem)
> > making it very simple for clients to use for -their- work.
>
> EMF is able to show a default tree view for any model already.  The more
I
> read, the more I get the impression that ModelElement is almost like a
view
> element.  I don't imagine that folks would generally want to "pollute"
> their data model with information about how it's viewed/rendered in any
one
> particular viewing/rendering technology...
>
> >
> > My bet is that we're going to end up in the middle somewhere,
> > completely untyped/bounded is -too- loose. Perhaps one approach is
> > to provide meta-information on a 'per property' basis (i.e. a
> > property would have to be 'registered' (including meta info) against
> > a 'type' before it can be set in that type.
>
> Wouldn't it be good to fully understand EMF before placing bets?  Are you
> so sure it doesn't provide everything you need already without being
overly
> restrictive?
>
> > I was expecting to do
> > this using an 'exemplar' model; you'd 'register' a ModelElement
> > whose current structure (its properties and their data types)
> > represent the valid properties (and their defaults?) but API might
> > be ok as well (I'm not really anti-api, I just think if should be
> > generated from the model...;-).
>
> So if someone make a mistake in their instance, it would become explary?
I
> consider API and model to be effectively equivalent because, given a
model,
> I can generate an API, and given that API, I can reconstruct the model.
> Besides, being anti-API seems like being against motherhood.  It's the
> basis for all things.  You know that XML Schema has things like wildcards
> to deal wtih open content; there are all kinds of good comprimises
between
> being suitably well constrained to find errors quickly and early as well
as
> being suitably flexible to accomodate the unexpected later on.  I get the
> feeling that a lot of useful knowledge that would come from looking
clostly
> at XML Schema, UML, and Ecore is simply being overlooked.  Even if there
is
> a good reason for doing that, nevertheless, if you don't learn from the
> mistakes of others, your most likely doomed to repeat them...
>
> >
> > This remains a primary concern of mine; the end result must be
> > easily consumable downstream, both to understand and to extend.
>
> This is the central mantra behind the model driven development vision.
>
>
> >  I
> > found it interesting when initially looking at JSON that it's rate
> > of acceptance is high because it's -simpler- than other
> > infrastructures that it was competing against..perhaps they're onto
> something.
>
> As I undertand JSON, it's a reflection of JavaScipts type system.  If
this
> was really such a great thing, we'd all have switched to JavaScipt
because
> it's so simple and flexible, unlike Java, which is complex and rigid.
> Designs decisions are such that the things at the extremes are usually
> optimal...
>
> >
> > One thing that nobody's mentioned yet are the CSS requirements; if
> > we get this right (and we must) then almost all of the 'properties'
> > we're talking about modeling here (tab style, min/max buttons,
> > colors/fonts...perhaps even the SWT widget to render with) will be
> > coming from the styler and won't even -be- a part of the ModelElement's
> data.
>
> Ofthen in modeling there are patterns you might think of as decorator
> patterns.  This seems like one of them.  You have an underlying model
that
> can be decorated to render it in different ways.  Things like adapters an
> item providers, which interact with content providers serve this type of
> role as well.  This outline by Jim van Dam seems related to this styling
> issue.
>
> (See attached file: StUIML Management Summary.pdf)
>
> >
> > Whatever we end up using (both as API and as implementation) the
> > only two things that someone's going to have to use a big stick to
> > beat me off of are:
> >
> > 1) -All- GUI changes take place as responses to an observable model.
> > Otherwise it's not MVC
>
> This was one of the central design goals of EMF.  Notifications must
> produce enough information that you can use them to update your views.
> Consider that EMF's change model provide a change recorder that lets you
> record all changes you make to a model, cover it to a change description,
> which you can them apply to undo and redo all the changes.  The change
> description itself is a model, so you could sent it somewhere else
> (serialize it) and apply the same changes to a different copy of the
> objects...
>
> >
> > 2) The protocol currently enforced in the ControlFactory's
> > 'createGUI' and 'disposeGUI' methods be the -only- path through with
> > rendering elements are managed.
>
> Not sure I understand this one.  Model instances definitely are created
by
> a factory.  Viewing is typically done by using adapters that interact
with
> content/label providers.  Those adapters can indeed be disposed when the
> view is disposed...
>
>
> >  This is needed to enforce the CSS
> > styling (as well as a way to maintain sanity in the world...;-).
> > Tom, the reason that the 'clientArea' gets added to the 'contents'
> > as well as being its own property is to get the rendering for take
> > place in the ControlFactory's 'processContents' part of the protocol).
>
> I think Tom will understand this better than I.  I kind of always imagine
> models being focused just on the data they represent and that views act
as
> decorators around such things.  It's of course highly likely that we're
> using the world model to mean slightly different things.  I'm sure when
we
> meet in the middle, we'll both be like: ah, I see now what you meant. ;-)
>
>
> >
> > time for lunch,
> > Eric
> >
> >
>
> > On Sat, Apr 5, 2008 at 11:09 AM, Boris Bokowski
> <Boris_Bokowski@xxxxxxxxxx
> > > wrote:
> > Kevin wrote:
> > > At the risk of killing momentum, I'd like to suggest that this
> > > investigation would work best if someone on the platform team (yes,
> > > I'm looking at you Eric <g>) were involved to whatever degree it
> > > made sense.
>
> > I am a little surprised - Kevin did you realize that Tom is *already* a
> > member of the Platform team, as a Platform UI committer?
> >
> > Yes, Eric should be involved in this, but I also think that Tom should
be
> > allowed to do the same thing Eric has done - produce some experimental
> code
> > to be used in the discussion (code speaks!) - and I have therefore
> > nominated Tom as an e4 committer.
> >
> > For higher-bandwidth communication, we can use the #eclipse-dev channel
> > (see http://wiki.eclipse.org/IRC). I know that both Eric and Tom can be
> > found there regularly. Please remember to post occasional updates to
the
> > mailing list as well...
> >
> > Boris
> >
> > _______________________________________________
> > eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> > _______________________________________________
> > eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-
> dev_______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> [attachment "StUIML Management Summary.pdf" deleted by Ed
Merks/Toronto/IBM]
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev