In my experience in supporting users of the EventBus, in both the open
source world and in professional teams, weak references are not something to
be feared. This is because:
1) Weak references fail fast.
2) Weak reference semantics can be documented. Make the API's clear, make
the doc clear, ma
I think that's fair to do.
-Original Message-
From: Greg Brown [mailto:gkbr...@mac.com]
Sent: Monday, June 21, 2010 2:11 PM
To: dev@pivot.apache.org
Subject: Re: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation
and an annotation processor for application context message lis
It doesn't necessarily need to be used by other parts of the framework to go in
pivot-core. It just needs to be generally useful and not have any dependencies
on the other libraries.
I'm not sure what else, if anything, I would want it to do - it is really only
meant to provide simple intra-app
Yes. But I would leave it there for now. For simple messaging it is
sufficient. More thought is needed. My current thinking is that unless it
used by pivot internally, and hence drives need & evolution, it could be
better to use something else.
-Original Message-
From: Greg Brown [mailto:
> One thing I am finding is for annotations and auto-registering, that the
> machinery dominates the actual messaging code in ApplicationContext.
ApplicationContext is large, but the message handling code itself is pretty
small - it is just a few methods:
subscribe()
unsubscribe()
sendMessage(
Agreed on your points which are very thoughtful.
Strong references do not automatically lead to bloat, but like weak
references, issues arise if things are done un-thoughtfully. Let me play
around with it. I am not advocating using weak references when using the
message API at all. Its possible t
There are a number of issues with weak references that, IMO, make them
unsuitable for event registration. As Noel noted, they can easily disappear,
causing developer confusion. This is true even for non-anonymous listener
classes:
something.addListener(new ConcreteListener());
If the registe
> OK, but that means that when a paragraph has multiple styles, we end up
> with the following structure:
>
>
>
>some styled text
>
> unstyled text
>
>more styled text
>
>
Right. This is similar to how it would work in HTML:
some styled text
unstyled text
more styled te
OK, but that means that when a paragraph has multiple styles, we end up
with the following structure:
some styled text
unstyled text
more styled text
And we don't currently support Span in TextAreaSkin.
I'm trying to implement it, but it's turning out pretty complicated,
b
