Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Giving some love to org.eclipse.core.databinding.observable

Hi Stefan,

sounds good. AFAIK we do not yet have a bug for the generics migration.

Best regards, Lars

On Fri, May 29, 2015 at 7:54 PM, Stefan Xenos <sxenos@xxxxxxxxxx> wrote:
I may be able to look at it before then. If I defer the work on the notifications plugin (bug 229823), I could do the generification in mid-june. Do we already have a bug for the generification of databinding?

Regarding the other two items (improving the propagation algorithm and fixing the flicker due to asyncExec), the improved propagation algorithm may need to wait a bit and I think the asyncExec fix should probably go in SWT rather than databinding.

While looking at the code, I also noticed a lot of incorrect comparisons -- there's a lot of checks intended to prevent redundant change events that incorrectly uses identity (==) rather than value (Object.equals). That allows a lot of redundant changes through and results in incorrect list and set diffs.

I believe this is a workaround for the incorrect implementation of equals that AbstractObservableList inherits from AbstractList. This should also be fixed.

  - Stefan

On Fri, May 29, 2015 at 12:51 AM Lars Vogel <lars.vogel@xxxxxxxxxxx> wrote:
Hi Stefan,

I plan to work on the JFace generification in early Neon and would also be interested in working on the generics part of Databinding. Looking at my calendar, it is also work to find a sufficient time slot for this work. How is beginning of August looking for you? 

I talked to Simon and he is also interested in working on this but currently very busy.

Best regards, Lars

On Tue, May 19, 2015 at 6:08 AM, Stefan Xenos <sxenos@xxxxxxxxxx> wrote:
Simon, based on my current bug inbox, I should be able to look at this in 3-4 weeks.

I think we should start by pulling in just the generification from the e4 repository, without the other refactorings... then we can look at the other refactorings on a case-by-case basis.

I also notice that this repository doesn't seem to be a clone of the main repository -- it looks as though it contains a different set of plugins. That will make it really awkward to cherry-pick changes. Anyone know why this was done (and if there's any git tricks to make the cherry-picks less awful)?


On Mon, May 18, 2015 at 12:36 AM Daniel Megert <daniel_megert@xxxxxxxxxx> wrote:
Hi Stefan

There were lengthy discussions about the generification of all JFace(not just Databinding) and there were (and still are) doubts whether doing this for all JFace makes sense and there was no proof of concept i.e. adoption in some upper layers. I suggest to read the following thread: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10861.html.

Having said that, it might make sense to generify Databinding. We've done that in other parts of Platform UI already.

See also https://wiki.eclipse.org/Generify_A_Java_Project.

Dani



From:        Stefan Xenos <sxenos@xxxxxxxxxx>
To:        "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
Date:        16.05.2015 00:10
Subject:        Re: [platform-ui-dev] Giving some love to        org.eclipse.core.databinding.observable
Sent by:        platform-ui-dev-bounces@xxxxxxxxxxx




So it looks like most of the work to convert to generics has already been done in that repository. How come it was never pushed to the main repository?

FYI, that repository contains some dangerous code -- particularly the fix for bug 425704. That bit definitely shouldn't go to the main repo, but most of the rest looks pretty good.

Is there something that's still incomplete or broken?

On Fri, May 15, 2015 at 2:37 PM Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx> wrote:
http://git.eclipse.org/c/e4/org.eclipse.e4.databinding.git/

On my doubts on realm i reply later on.

Tom

Von meinem iPhone gesendet


Am 15.05.2015 um 23:29 schrieb Stefan Xenos <
sxenos@xxxxxxxxxx>:

Do you have the repo/branch name for the e4 git repo where people tried to add generics to the databinding project?

Regarding realms: a realm is essentially the same thing as an actor in http://www.ponylang.org/ -- AFAIK, it's a standard primitive for lock-free multithreading. When you say it's broken, what specifically do you mean?


On Fri, May 15, 2015 at 2:24 PM Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx> wrote:
On generics - there is a version in the e4 git repo where people tried to add generics - at least you could get inspired by that.

On reactive: very welcome having this added 

On thread sync: if you ask me the realm concept is totally broken and i don't think the databinding lib should be dealing with it

Tom

Von meinem iPhone gesendet


Am 15.05.2015 um 23:05 schrieb Stefan Xenos <
sxenos@xxxxxxxxxx>:

I'm starting to use the org.eclipse.core.databinding.observable plugin for one of my projects, but I see it hasn't had any love for about 5 years. I was thinking of updating the plugin but figured I'd discuss the changes here first, since they'd be fairly sweeping.

1. I notice the plugin has been updated to java 1.7, but the code is still written in 1.4 style.
- Most of the IObservable implementations were designed to be generics but they haven't been converted to actually use generics yet.
- Many of the methods are supposed to be annotated with @TrackedGetter, but the annotation is currently in comments rather than actual code.

2. It hasn't been updated to use modern algorithms for reactive programming frameworks. The whole library still uses listeners for change propogation, which are subject to event storms and degenerate in the repeated diamond shape.

Reference:
http://en.wikipedia.org/wiki/Reactive_programming#Evaluation_models_of_reactive_programming

I know a good algorithm that addresses this quite efficiently and can deep-dive on it if anyone wants details.

3. Each async event currently gets executed as a separate asyncExec. This allows paints to get interleaved with the events, possibly causing flicker and triggering multiple layouts. I plan to put all pending updates in a queue and process them as a batch, ensuring that only one paint or layout pass occurs at the end.

Thoughts?

  - Stefan
_______________________________________________
platform-ui-dev mailing list

platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list

platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list

platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list

platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/platform-ui-dev_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev



--
Geschäftsführer

vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (032) 221739404, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev



--
Geschäftsführer

vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (032) 221739404, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com

Back to the top