Eclipse Community Forums: Eclipse 4

Home » Eclipse Projects » Eclipse 4 » Typed event topics(Why does E4 use string-based event topics instead of typed ones?)

Typed event topics [message #1137004]

Mon, 14 October 2013 03:46

Eclipse User

Hi,

I wonder why event topics are strings. I see the flexibility of this approach, but were typed event topics ever considered? At first sight, using typed event topic classes and subclasses seems more robust than the "TOPIC/SUBTOPIC/*" mechanism.

Thanks,
Uwe

Re: Typed event topics [message #1137012 is a reply to message #1137004]

Mon, 14 October 2013 03:52

Eclipse User

Why is typed more robust?

Re: Typed event topics [message #1137041 is a reply to message #1137012]

Mon, 14 October 2013 04:16

Eclipse User

The event topics are String based AND typed! You could send different types of objects for the same topic String and it would be handled correctly (type based) at injection time.

Using the String based approach you are able to create a hierarchy using the sub-topic approach, which makes it a lot more flexible than the typed approach.

Surely there are some more reasons, possibly related to performance as using Generics in Java you are only type safe at compile time, at runtime you need to check the type manually. This is not as fast as checking Strings and if the String fits perform a type check.

Re: Typed event topics [message #1137049 is a reply to message #1137041]

Mon, 14 October 2013 04:23

Eclipse User

Dirk Fauth wrote on Mon, 14 October 2013 10:16

The event topics are String based AND typed!

Well yeah but that's a different thing. The *topics* are not typed. The injection is type sensitive in the sense that it is sensitive to the type of the payload of the event, not the topic.

Re: Typed event topics [message #1137050 is a reply to message #1137041]

Mon, 14 October 2013 04:24

Eclipse User

I think typed can be more robust because you can't have spelling mistakes in strings. This play a role when you concatenate strings to manage event topics with subtopics:

public static final String TOPIC_ALL = "org/eclipse/e4/ui/model/ui/UILabel/*";
public static final String TOPIC_ICONURI = "org/eclipse/e4/ui/model/ui/UILable/iconURI/*";

Note that it's "UILabel" in the first string and "UILable" in the second. These little mistakes happen and they can be quite annoying. You can use constants for every sublevel, of course, but you'll still need to take care of the slashes that separate the levels. This type of string management is error-prone.

In addition to that, it may happen in a large application that the same string is used for two different event topics (constants). This would not be possible when there were event classes.

Dirk Fauth wrote on Mon, 14 October 2013 04:16

Using the String based approach you are able to create a hierarchy using the sub-topic approach, which makes it a lot more flexible than the typed approach.

Wouldn't a typed system with event classes and subclasses be equally flexible?

Re: Typed event topics [message #1137056 is a reply to message #1137050]

Mon, 14 October 2013 04:29

Eclipse User

On 14.10.13 10:24, Uwe San wrote:
> I think typed can be more robust because you can't have spelling
> mistakes in strings. This play a role when you concatenate strings to
> manage event topics with subtopics:
>
>
> public static final String TOPIC_ALL =
> "org/eclipse/e4/ui/model/ui/UILabel/*";
> public static final String TOPIC_ICONURI =
> "org/eclipse/e4/ui/model/ui/UILable/iconURI/*";
>
>
> Note that it's "UILabel" in the first string and "UILable" in the
> second. These little mistakes happen and they can be quite annoying. You

This clearly is a bug!

Stuff you put into the annotations has to be final so you can only put
immuntable types there (primitives, String) there.

Tom

Re: Typed event topics [message #1137067 is a reply to message #1137056]

Mon, 14 October 2013 04:36

Eclipse User

Thomas Schindl wrote on Mon, 14 October 2013 04:29

This clearly is a bug!

I'm afraid you lost me a little. Could you explain what exactly is the bug?

When you can put only immutable types into annotations, then that's the end for any mechanism with classes and subclasses, indeed. Thank you for clarifying this.

Re: Typed event topics [message #1137073 is a reply to message #1137049]

Mon, 14 October 2013 04:41

Eclipse User

Sopot Cela wrote on Mon, 14 October 2013 10:23

Well yeah but that's a different thing. The *topics* are not typed. The injection is type sensitive in the sense that it is sensitive to the type of the payload of the event, not the topic.

Thank's for correcting my wrong explanation. Smile

Uwe San wrote on Mon, 14 October 2013 10:24

Wouldn't a typed system with event classes and subclasses be equally flexible?

That's discussable. Would you like to create new event classes for every event in your system? Would you like to create huge hierarchies of event classes to build your event system? What happens if you want to create a subtopic of an event of another plugin, but the one who build the plugin you want to listen to forgot to add the package that contains the event classes to the exported packages?

IMHO this discussion will end up in having personal flavours. Both approaches have advantages and disadvantages. But if you compare it with other event bus systems out there, you will mostly find the String based approach for topics.

Re: Typed event topics [message #1137075 is a reply to message #1137067]

Mon, 14 October 2013 04:40

Eclipse User

On 14.10.13 10:36, Uwe San wrote:
> Thomas Schindl wrote on Mon, 14 October 2013 04:29
>> This clearly is a bug!
>
>
> I'm afraid you lost me a little. Could you explain what exactly is the bug?

public static final String TOPIC_ALL =
"org/eclipse/e4/ui/model/ui/UILabel/*";
public static final String TOPIC_ICONURI =
"org/eclipse/e4/ui/model/ui/UILable/iconURI/*";

so if there's really "UILable" then this is a bug, the problem is that
we probably can't fix it without breaking exisiting customers because
they need to recompile their sources!

Tom

Re: Typed event topics [message #1137088 is a reply to message #1137075]

Mon, 14 October 2013 04:51

Eclipse User

Thomas Schindl wrote on Mon, 14 October 2013 04:40

so if there's really "UILable" then this is a bug, the problem is that
we probably can't fix it without breaking exisiting customers because
they need to recompile their sources!

Fortunately, this is just a hypothetical example I made up. Sorry about the confusion. Wink

Uwe

Re: Typed event topics [message #1137089 is a reply to message #1137088]

Mon, 14 October 2013 04:53

Eclipse User

On 14.10.13 10:51, Uwe San wrote:
> Thomas Schindl wrote on Mon, 14 October 2013 04:40
>> so if there's really "UILable" then this is a bug, the problem is that
>> we probably can't fix it without breaking exisiting customers because
>> they need to recompile their sources!
>
>
> Fortunately, this is just a hypothetical example I made up. Sorry about
> the confusion. ;)

I was wondering because the file is generated!

Tom

Re: Typed event topics [message #1137240 is a reply to message #1137073]

Mon, 14 October 2013 06:59

Eclipse User

Dirk Fauth wrote on Mon, 14 October 2013 04:41

That's discussable. Would you like to create new event classes for every event in your system? Would you like to create huge hierarchies of event classes to build your event system? What happens if you want to create a subtopic of an event of another plugin, but the one who build the plugin you want to listen to forgot to add the package that contains the event classes to the exported packages?

IMHO this discussion will end up in having personal flavours. Both approaches have advantages and disadvantages. But if you compare it with other event bus systems out there, you will mostly find the String based approach for topics.

These are all good questions that need to be considered. Thanks for your feedback, Dirk.

Re: Typed event topics [message #1139396 is a reply to message #1137240]

Tue, 15 October 2013 14:52

Eclipse User

The 'real' reason is because that's how the EventAdmin (our currnet eventing backbone) wants them. However I'm heartily in favor of the style because of its inherent flexibility (i.e. no need to make my package depend on a bunch of other things...).

Also, the possibility of typos is what lead me to create the UIEVents class; it specifically provides access to the complete model through a set of constants. This also has the added bonus of allowing me to search for listeners on a particular topic.

Previous Topic:	Launching p2 UI from application model
Next Topic:	Contribute new project wizard for kepler/luna ide ?

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 19 20:24:30 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter