[
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
|
Kevin,
Yes. The only interesting wrinkle EMF adds (or perhaps it's more like a
wrinkle it removes) is that you can work with all the instances uniformly
using EMF reflection (EObject) which is at a higher level of abstraction
than Java reflection. This becomes important if you want to work with
dynamic models. I.e., models for which there is no generated API or
implementation classes.
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
Kevin
McGuire/Ottawa/IB
M@IBMCA To
Sent by: E4 developer list
eclipse-incubator <eclipse-incubator-e4-dev@eclipse.o
-e4-dev-bounces@e rg>
clipse.org cc
Subject
04/08/2008 05:22 Re: [eclipse-incubator-e4-dev]
PM Initial discussion on the
'modelled' workbench UI
Please respond to
E4 developer list
<eclipse-incubato
r-e4-dev@eclipse.
org>
Hi Tom,
Yeah, I wasn't worried about Java<->Javascript so much as we've already
done some successful investigation into that. But I guess my confusion was
that I forgot that EMF isn't special in this regard... if you can cross
call from one language to another (dealing with the types in whatever
manner) then you can do so in EMF because it just gens to the target
language in each case. Is that right? (Newby EMF guy here).
Kevin
Tom Schindl
<tom.schindl@xxxxxxxxxxxxxxx
> To
Sent by: E4 developer list
eclipse-incubator-e4-dev-bou <eclipse-incubator-e4-dev@xxxxxxxxxx
nces@xxxxxxxxxxx g>
cc
04/07/2008 03:57 PM Subject
Re: [eclipse-incubator-e4-dev]
Initial discussion on the 'modelled'
Please respond to workbench UI
E4 developer list
<eclipse-incubator-e4-dev@e
clipse.org>
Kevin McGuire schrieb:
>
> >>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.... 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'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. Your response below Ed suggests that EMF is
> flexible in this regard, right? But is that just in the definition of
> the model or in consumption too? How do we say access a strongly typed
> EMF model from a language like Javascript?
>
Are we talking about JavaScript in the browser or JavaScript as part of
the JVM?
If we talk about Scripting inside the VM, they have access to all
Java-Types you give it access to via imports or using fully qualified
names.
So far I only used Groovy where you could simply pass this script to the
engine and it knows what to do.
---------8<---------
"
import org.eclipse.e4.AddressBook;
AddressBook addressbook = new AddressBook();
addressbook.addPerson(new org.eclipse.e4.Person("Kevin"));
"
---------8<---------
I haven't used Rhino but I think it works a bit different because Eric
is somehow wrapping it in a ScritableObject where the conversion has to
happen in the put-method in case the given parameter doesn't match the
one coming from the client.
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
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
