Eclipse Community Forums: B3 » status report Jan 16 2010

Help

Home

Home » Archived » B3 » status report Jan 16 2010

Show: Today's Messages :: Show Polls :: Message Navigator

status report Jan 16 2010 [message #508113]

Sat, 16 January 2010 00:33

Henrik Lindberg

Messages: 2509
Registered: July 2009

Senior Member

Hi,
I have been quiet on this forum/newsgroup for a while, but that does not
mean there has been no activity, there has just not been all that much
to report.

I had to rethink one area of the b3 language after looking more deeply
into the implementation alternatives - and this blocked me for a while
until I came up with a workable solution. The issues are regarding
advice, concurrency, and working with a model that is mutating.

To make a long story short, the end result will work as follows:
- all build models are kept unchanged (they are what they are at the
point they are either discovered or read from a b3 resource).
- when advice is applied to a model element, a proxy/wrapper is added to
the execution context
- effective values are obtained by getting the model elements from the
execution context rather than by navigating the model.

The earlier idea of "just navigate the model and make changes" does not
work as the mechanism for advise for several reasons:
- technically it would be a challenge to let the model mutate in
different ways on different threads. (Maybe some neat support in CDO
could help with this, but such support is not there now and this is a
major implementation effort. Also looked into using change sets, but
this proved very difficult as some changes to the model (typically
transient/cached values etc.) should remain in effect even if changes
were rolled back - and this approach would only work if running single
threaded anyway)
- some advise affects resolution, and thus, free navigation (in
combination with "any expression" make it very complex to handle.

Instead, concrete syntax is required in the DSL. This has several
advantages:
- more feedback is given to the user during construction, and the user
does not have to understand as much about the underlying model.
- since the advice is concrete/explicit (as opposed to general logic),
it is much easier to apply when performing resolution.

The drawback is naturally that a lot more syntax was required as there
are quite a few things where it makes sense to allow advise to be
applied, and getting this right required quite a lot of experiments (and
hence me being quiet on this list). But I am now on a track that looks
promising, and I am making good progress with both the grammar and the
implementation.

Regards
- henrik

Report message to a moderator

Re: status report Jan 16 2010 [message #508123 is a reply to message #508113]

Sat, 16 January 2010 02:50

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Hi Henrik,

Comments below...

Henrik Lindberg schrieb:
> Hi,
> I have been quiet on this forum/newsgroup for a while, but that does
> not mean there has been no activity, there has just not been all that
> much to report.
>
> I had to rethink one area of the b3 language after looking more deeply
> into the implementation alternatives - and this blocked me for a while
> until I came up with a workable solution. The issues are regarding
> advice, concurrency, and working with a model that is mutating.
>
> To make a long story short, the end result will work as follows:
> - all build models are kept unchanged (they are what they are at the
> point they are either discovered or read from a b3 resource).
> - when advice is applied to a model element, a proxy/wrapper is added
> to the execution context
> - effective values are obtained by getting the model elements from the
> execution context rather than by navigating the model.
>
> The earlier idea of "just navigate the model and make changes" does
> not work as the mechanism for advise for several reasons:
> - technically it would be a challenge to let the model mutate in
> different ways on different threads. (Maybe some neat support in CDO
> could help with this,
Yes, with CDO you could run multiple transactions on the same model and
commit them separartely. But that would still introduce a potential for
conflicts. You'd just move them from the modification time to the commit
time. With certain CDOConflictResolvers you could possibly resolve some
of these conflicts but generally there can be conflicts that are only
resolveable interactively. See 299114: Implement Interactive
CDOConflictResolver with EMF Compare
https://bugs.eclipse.org/bugs/show_bug.cgi?id=299114

Let me know if you want to know more about this.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

> but such support is not there now and this is a major implementation
> effort. Also looked into using change sets, but this proved very
> difficult as some changes to the model (typically transient/cached
> values etc.) should remain in effect even if changes were rolled back
> - and this approach would only work if running single threaded anyway)
> - some advise affects resolution, and thus, free navigation (in
> combination with "any expression" make it very complex to handle.
>
> Instead, concrete syntax is required in the DSL. This has several
> advantages:
> - more feedback is given to the user during construction, and the user
> does not have to understand as much about the underlying model.
> - since the advice is concrete/explicit (as opposed to general logic),
> it is much easier to apply when performing resolution.
>
> The drawback is naturally that a lot more syntax was required as there
> are quite a few things where it makes sense to allow advise to be
> applied, and getting this right required quite a lot of experiments
> (and hence me being quiet on this list). But I am now on a track that
> looks promising, and I am making good progress with both the grammar
> and the implementation.
>
> Regards
> - henrik
>

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator