org.apache.pivot.util.MessageBus

[Chris Bartlett <cb...@gmail.com>]

Does anyone have a problem with me changing the internal
'messageTopics' Map to protected from private?
http://svn.apache.org/repos/asf/pivot/trunk/core/src/org/apache/pivot/util/MessageBus.java

The class isn't final, but perhaps it was intended to be?  In which
case I can make it final.

Chris

Re: org.apache.pivot.util.MessageBus

[Greg Brown <gk...@verizon.net>]

> Is MessageBus used by Pivot internally itself, or is it just a convenience to users?

It is not used internally at all, actually. It is a feature.

G

Re: org.apache.pivot.util.MessageBus

[Chris Bartlett <cb...@gmail.com>]

(I'll copy your BXMLSerializer question into that thread, and reply there)


On 8 July 2011 22:04, SYSE | Edvin <es...@syse.no> wrote:
> Is MessageBus used by Pivot internally itself, or is it just a convenience
> to users?

Just a convenience for users as far as I know.
There is a small test program, but I don't think it is used in any of
the 'larger' demos, because they are still relatively small.

Re: org.apache.pivot.util.MessageBus

[SYSE | Edvin <es...@syse.no>]

Den 08.07.2011 16:55, skrev Chris Bartlett:
> And I was not referring to the BXMLSerializer/Transformable proposal
> in particular, but rather my general experience.
>
>
> Anyway - any thoughts on the original topic?
> final/non-final?
> private/protected?
> Leave as is?

I've followed this thread and I have some questions.

Is MessageBus used by Pivot internally itself, or is it just a 
convenience to users?

As for BXMLSerializer, it looks like it is used mainly in 
demos/tutorials, some skin/internal stuff etc, but quite frankly - 
couldn't you just fork BXMLSerializer in your project and add all your 
goodies to it, and use it on your .ebxml (extended bxml :) files without 
problems? :)

No Pivot internal code would try to read your ebxml files anyway right?

-- Edvin

Re: org.apache.pivot.util.MessageBus

[SYSE | Edvin <es...@syse.no>]

Den 08.07.2011 18:20, skrev Greg Brown:
> Actually, MessageBus is sort of meant to be a singleton. It isn't currently implemented that way, but, functionally, that is how it is designed. Maybe it should be a singleton.

Maybe it could use the ServiceLoader architechture :)

-- Edvin

Re: org.apache.pivot.util.MessageBus

[Greg Brown <gk...@verizon.net>]

Actually, MessageBus is sort of meant to be a singleton. It isn't currently implemented that way, but, functionally, that is how it is designed. Maybe it should be a singleton.

If you don't mind sharing, I'd like to understand more about your use case. That might shed some light on ways MessageBus could be improved.

G

On Jul 8, 2011, at 12:10 PM, Chris Bartlett wrote:

> On 8 July 2011 22:18, Greg Brown <gk...@verizon.net> wrote:
>>> Pivot evolved perfectly well before I discovered it and I'm sure will
>>> continue to do so in the future.
>> 
>> Not without input and involvement from the community (yourself included). I'd strongly encourage you to continue proposing changes and enhancements. I understand that it can be difficult sometimes, but try not to be put off if they are not all accepted right away. Most aren't (historically, even my own).
> 
> I don't intend to withdraw my involvement in any way from Pivot.  I am
> saying that I can't afford to spend hours suggesting simple changes
> that I can just change locally and maintain.  Having to justify the
> benefits of even a simple change to others is sometimes just not worth
> it, especially when there are not too many voices on the mailing list.
> It can easily end up being a matter of 2 differing personal opinions
> that will not produce a useful outcome.  Thankfully, the members of
> the mailing list have handled themselves gracefully at all times, but
> I am aware that to outsiders or newcomers, a long thread with 2
> opposing views simply looks pointless.
> 
> 
>>> Anyway - any thoughts on the original topic?
>>> final/non-final?
>>> private/protected?
>>> Leave as is?
>> 
>> In keeping with the above, I'd suggest that you share your suggested improvements with the list, or prototype them and submit a patch to JIRA.
>> 
> 
> The two methods I that I needed to add to MessageBus might be useful
> to others, but are really an edge case that might possibly even be
> considered the result of a hack by some.  The key thing was the
> visibility of the Map.
> 
> Hence my question about the history of MessageBus and whether it was
> intended to be final, or was intended to be subclassed.  There have
> been prior mailing list discussions about final (inner) classes but I
> am not aware of a comprehensive review having taken place.  Therefore
> it is hard to know if a class was accidentally left 'unlocked' or not.
> Just knowing this and possibly making a change (make the class
> final/make the field protected) helps demonstrate that the class
> either is, or is not meant for extension.  The methods themselves are
> trivial and tend to be the things that have been rejected in the past
> as not worthy of the (albeit minimal) bloat they would add to the
> jars.
> 
> In many discussions (unrelated to finality) the 'original intent'
> surfaces.  This might be a justification for why something was done,
> was not done, should be done, or shouldn't be done.  If this is not
> documented in Javadocs, asking on the mailing list is the only way to
> try to find it out.
> 
> Chris

Re: org.apache.pivot.util.MessageBus

[Chris Bartlett <cb...@gmail.com>]

On 8 July 2011 22:18, Greg Brown <gk...@verizon.net> wrote:
>> Pivot evolved perfectly well before I discovered it and I'm sure will
>> continue to do so in the future.
>
> Not without input and involvement from the community (yourself included). I'd strongly encourage you to continue proposing changes and enhancements. I understand that it can be difficult sometimes, but try not to be put off if they are not all accepted right away. Most aren't (historically, even my own).

I don't intend to withdraw my involvement in any way from Pivot.  I am
saying that I can't afford to spend hours suggesting simple changes
that I can just change locally and maintain.  Having to justify the
benefits of even a simple change to others is sometimes just not worth
it, especially when there are not too many voices on the mailing list.
 It can easily end up being a matter of 2 differing personal opinions
that will not produce a useful outcome.  Thankfully, the members of
the mailing list have handled themselves gracefully at all times, but
I am aware that to outsiders or newcomers, a long thread with 2
opposing views simply looks pointless.


>> Anyway - any thoughts on the original topic?
>> final/non-final?
>> private/protected?
>> Leave as is?
>
> In keeping with the above, I'd suggest that you share your suggested improvements with the list, or prototype them and submit a patch to JIRA.
>

The two methods I that I needed to add to MessageBus might be useful
to others, but are really an edge case that might possibly even be
considered the result of a hack by some.  The key thing was the
visibility of the Map.

Hence my question about the history of MessageBus and whether it was
intended to be final, or was intended to be subclassed.  There have
been prior mailing list discussions about final (inner) classes but I
am not aware of a comprehensive review having taken place.  Therefore
it is hard to know if a class was accidentally left 'unlocked' or not.
 Just knowing this and possibly making a change (make the class
final/make the field protected) helps demonstrate that the class
either is, or is not meant for extension.  The methods themselves are
trivial and tend to be the things that have been rejected in the past
as not worthy of the (albeit minimal) bloat they would add to the
jars.

In many discussions (unrelated to finality) the 'original intent'
surfaces.  This might be a justification for why something was done,
was not done, should be done, or shouldn't be done.  If this is not
documented in Javadocs, asking on the mailing list is the only way to
try to find it out.

Chris

Re: org.apache.pivot.util.MessageBus

[Greg Brown <gk...@verizon.net>]

> Pivot evolved perfectly well before I discovered it and I'm sure will
> continue to do so in the future.  

Not without input and involvement from the community (yourself included). I'd strongly encourage you to continue proposing changes and enhancements. I understand that it can be difficult sometimes, but try not to be put off if they are not all accepted right away. Most aren't (historically, even my own).

> Anyway - any thoughts on the original topic?
> final/non-final?
> private/protected?
> Leave as is?

In keeping with the above, I'd suggest that you share your suggested improvements with the list, or prototype them and submit a patch to JIRA.

G

Re: org.apache.pivot.util.MessageBus

[Chris Bartlett <cb...@gmail.com>]

It is not a big deal, but obviously shapes the amount of time I spend
on the Pivot Project compared to my own personal projects that happen
to use Pivot.

Pivot evolved perfectly well before I discovered it and I'm sure will
continue to do so in the future.  That is in no small part due to the
stewardship provided by yourself and others.  Such stewardship is
extremely beneficial in a project with multiple contributors, as it
enables it to stay on a course and not veer off at tangents.

And I was not referring to the BXMLSerializer/Transformable proposal
in particular, but rather my general experience.


Anyway - any thoughts on the original topic?
final/non-final?
private/protected?
Leave as is?

Chris

On 8 July 2011 21:36, Greg Brown <gk...@verizon.net> wrote:
>>> If you have some suggestions on how to improve the class, why not propose them?
>> Because based on recent experiences, that can be very hard work, and
>> just not worth the effort.
>
> Sorry you feel that way. Though there is definitely a difference between proposing changes of the scale you suggested to BXMLSerializer and proposing (what I imagine are) minor modifications to a class like MessageBus. Some changes just require more scrutiny than others.
>
>

Re: org.apache.pivot.util.MessageBus

[Greg Brown <gk...@verizon.net>]

>> If you have some suggestions on how to improve the class, why not propose them?
> Because based on recent experiences, that can be very hard work, and
> just not worth the effort.

Sorry you feel that way. Though there is definitely a difference between proposing changes of the scale you suggested to BXMLSerializer and proposing (what I imagine are) minor modifications to a class like MessageBus. Some changes just require more scrutiny than others.

Re: org.apache.pivot.util.MessageBus

[Chris Bartlett <cb...@gmail.com>]

On 8 July 2011 20:58, Greg Brown <gk...@verizon.net> wrote:
>> So I can extend it and have access to the map.
>
> I thought you said you were going to make it final?
My original email said that the class could be made final now, if that
was the original intent, but was overlooked somehow.

Conversely if the class was not meant to be final, then making the
only field protected makes sub-classing easier.  (Getting access to
the only thing of value that the class contains).

> If you have some suggestions on how to improve the class, why not propose them?
Because based on recent experiences, that can be very hard work, and
just not worth the effort.
On top of that, I simply don't have the time at the moment anyway.

Chris

Re: org.apache.pivot.util.MessageBus

[Greg Brown <gk...@verizon.net>]

> So I can extend it and have access to the map.

I thought you said you were going to make it final?
> 
> Just a couple of simple methods for now that would be handy for
> something I am working on
> boolean isSubscribed(...)
> void subscribeIfRequired(...)
> 
> Making keeping it private and making it final is cool too.  I can just
> make a copy for my own purposes and tweak where desired.

If you have some suggestions on how to improve the class, why not propose them?

G

Re: org.apache.pivot.util.MessageBus

[Chris Bartlett <cb...@gmail.com>]

So I can extend it and have access to the map.

Just a couple of simple methods for now that would be handy for
something I am working on
boolean isSubscribed(...)
void subscribeIfRequired(...)

Making keeping it private and making it final is cool too.  I can just
make a copy for my own purposes and tweak where desired.

Chris

On 8 July 2011 20:29, Greg Brown <gk...@verizon.net> wrote:
> Read it too fast. Why make it protected?
>
> On Jul 8, 2011, at 9:26 AM, Chris Bartlett wrote:
>
>> Was that a typo?  It is currently private, but I was proposing
>> changing to protected.
>>
>> Or did you mean that it *should* be private and the class should be final.
>>
>> On 8 July 2011 20:21, Greg Brown <gk...@verizon.net> wrote:
>>> Seems fine. I don't remember why it is protected.
>>>
>>> On Jul 8, 2011, at 9:11 AM, Chris Bartlett wrote:
>>>
>>>> Does anyone have a problem with me changing the internal
>>>> 'messageTopics' Map to protected from private?
>>>> http://svn.apache.org/repos/asf/pivot/trunk/core/src/org/apache/pivot/util/MessageBus.java
>>>>
>>>> The class isn't final, but perhaps it was intended to be?  In which
>>>> case I can make it final.
>>>>
>>>> Chris
>>>
>>>
>
>

Re: org.apache.pivot.util.MessageBus

[Greg Brown <gk...@verizon.net>]

Read it too fast. Why make it protected?

On Jul 8, 2011, at 9:26 AM, Chris Bartlett wrote:

> Was that a typo?  It is currently private, but I was proposing
> changing to protected.
> 
> Or did you mean that it *should* be private and the class should be final.
> 
> On 8 July 2011 20:21, Greg Brown <gk...@verizon.net> wrote:
>> Seems fine. I don't remember why it is protected.
>> 
>> On Jul 8, 2011, at 9:11 AM, Chris Bartlett wrote:
>> 
>>> Does anyone have a problem with me changing the internal
>>> 'messageTopics' Map to protected from private?
>>> http://svn.apache.org/repos/asf/pivot/trunk/core/src/org/apache/pivot/util/MessageBus.java
>>> 
>>> The class isn't final, but perhaps it was intended to be?  In which
>>> case I can make it final.
>>> 
>>> Chris
>> 
>> 

Re: org.apache.pivot.util.MessageBus

[Chris Bartlett <cb...@gmail.com>]

Was that a typo?  It is currently private, but I was proposing
changing to protected.

Or did you mean that it *should* be private and the class should be final.

On 8 July 2011 20:21, Greg Brown <gk...@verizon.net> wrote:
> Seems fine. I don't remember why it is protected.
>
> On Jul 8, 2011, at 9:11 AM, Chris Bartlett wrote:
>
>> Does anyone have a problem with me changing the internal
>> 'messageTopics' Map to protected from private?
>> http://svn.apache.org/repos/asf/pivot/trunk/core/src/org/apache/pivot/util/MessageBus.java
>>
>> The class isn't final, but perhaps it was intended to be?  In which
>> case I can make it final.
>>
>> Chris
>
>

Re: org.apache.pivot.util.MessageBus

[Greg Brown <gk...@verizon.net>]

Seems fine. I don't remember why it is protected.

On Jul 8, 2011, at 9:11 AM, Chris Bartlett wrote:

> Does anyone have a problem with me changing the internal
> 'messageTopics' Map to protected from private?
> http://svn.apache.org/repos/asf/pivot/trunk/core/src/org/apache/pivot/util/MessageBus.java
> 
> The class isn't final, but perhaps it was intended to be?  In which
> case I can make it final.
> 
> Chris