Re: [e4-dev] Suggestion to restructure UIEvents to increase clarity and

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

If we do this in 4.2 we're OK since
none of the API and been cast in concrete yet (all 4.1 API is considered
provisional). If we agree that this is something that makes the API easier
to consume then now  is the time to do it, after 4.2 ships
it'll be too late. We should of course also try to mitigate the impact
of folks already using the current mechanism through blogs...

I'll also try to directly contact Simon
Chemouil, the other brave soul that built a commercial offering on Eclipse
4.1...;-), just to make sure he understands the change and can synch up
once we're done.

My personal opinion is that this sounds
like a good thing to me. A few quick searches shows that most folks use
the specific version of the buildTopic call which specifies the topic all
the way down to the attribute level. In a few cases we use the general
one; this is mostly used for handling UILabel so that one listener can
be used to keep the Label, Icon and Tooltip up-to-date (the other one isn't
used at all).

I think that 

         
      eventBroker.subscribe(UIEvents.Dirtyable.DIRTY,
dirtyUpdater);

         
      eventBroker.subscribe(UIEvents.UILabel.ALL,
itemUpdater);

scan better than

         
      eventBroker.subscribe(UIEvents.buildTopic(UIEvents.Dirtyable.TOPIC,
         
               
      UIEvents.Dirtyable.DIRTY),
dirtyUpdater);

         
      eventBroker.subscribe(UIEvents.buildTopic(UIEvents.UILabel.TOPIC),
         
               
      itemUpdater);

(The use of the new 'ALL' constant rather
than the existing 'TOPIC' is my initial lame attempt to make its name more
reflective of its intent...;-).

Dean has already done the initial version
of the experiment, changing the generator and the builldTopic implementations
but there appear to be a few cases where we're building the topic string
directly which we'd have to track down. Other than that the refactoring
to get rid of the current uses of buildTopic is straightforward. 

Whether or not we leave deprecated versions
of buildTopic in the UIEvents class would depend on how widely they're
used outside of our implementation. For my money I'd deprecate them in
M4 (to give Simon et al time to catch up) and then *remove* them in M5
(which would still give us time to put them back if there's a heavy push
from the community).

Eric

From:	Markus Keller <markus_keller@xxxxxxxxxx>
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date:	11/10/2011 12:17 PM
Subject:	Re: [e4-dev] Suggestion to restructure UIEvents to increase clarity and performance (Evolving Java-based APIs)
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

Brian de Alwis <briandealwis@xxxxxxxxx> wrote
on 2011-11-10 17:39:44:

> On 10-Nov-2011, at 10:55 AM, Dean Roberts wrote:
> > Do we have to be compatible with previously compiled .class files
> ... I'm assuming the answer is going to be yes here. 
> 
> So it really hinges on: are we guaranteed that all existing compiled
> classes that referenced the previous version of 
> UIEvents.UIElement.VISIBLE would have had the string inlined?
> 
> I believe the Java compilers inline static final string references.
> But I don't know if they *have* to, nor as to whether there are any
> that don't.  Anybody know the applicable part of the JLS?

Every Eclipse committer should read 
http://wiki.eclipse.org/Evolving_Java-based_APIs
every once in a while. 
That document tells the whole story about API compatibility in an 
easy-to-digest form.

This concrete case is described here:
http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_classes_-_API_fields
> Change value of API field     If field is compile-time constant
Breaks 
compatibility (2)

http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.4.9
has the full story.

Note that we only guarantee compatibility for APIs that have already been
released. If this constant has only been added in the 4.2 cycle, then you
can still change the value.

HTH,
Markus
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev