Rename PubSubEvents to PrismEvent?

[brianlagunas]

We need the community's input on this issue. We are considering changing the name of the event aggregator's PubSubEvent to PrismEvent to better align with Prism as a product. What are the community's thoughts on this? Should we make the change? Prism 6 for WPF will contain breaking changes in terms of namespaces. So, since we are breaking apps, now would be the time to do it.

What are your thoughts?

[keozx]

I agree! 👍

[llewelynrex]

Sure. Out with the old and in with the new!

[bartlannoeye]

Moving the namespace from Microsoft.Practices.Prism.PubSubEvents to Prism.Events certainly aligns it with the rest of (the new) Prism. That's a clear choice I'd say.

Changing the class name from PubSubEvent to PrismEvent is (in my opinion) a harder nut to crack. It would fit more in the branding of the Prism product. On the other hand the PubSubEvent class hints we're using a publisher-subscriber pattern, which is also clearly stated by the Publish and Subscribe methods. But then you could bring up as argument that nobody will use Prism without reading at least some documentation (which would state the publisher-subscriber pattern).

[ashokgelal]

I'm kind of torn on this. On one hand I personally don't like the name PubSubEventbut on the other hand I don't like the idea of tying it up too much with Prism. Prism is too close to be a pure Windows+WPF only library. Unless we plan to make Prism a true cross platform library, I don't want to give an impression that this awesome library has anything to do with Windows+WPF. As a matter of fact, we are using PubSubEvents package in our Xamarin.Mac apps.

[brianlagunas]

If you look at the new structure, Prism is now headed towards a true cross platform library. Commanding, Logging, and Even Aggregation (PubSubEvents) have moved into a single PCL. We also recently started adding support for Xamarin.Forms. Soon we will be adding Windows 10 support.

[ashokgelal]

I noticed that and if that's where we are heading then I'm all up for it. Let's do it! I like the name way better then PubSubEvent anyway.

[akoken]

It would be great 👍

[sgrassie]

👍

[Mike-E-angelo]

Anything other than PubSubEvent would be an improvement in my book. I like PrismEvent from a branding perspective. Although, personally, I would try to get away with just Event<>, if possible (since Prism is already in the namespace), but PrismEvent is better than the previous version. Prism is just a cool/good name. 👍

[roy-t]

I would vote against this. Including the brand name in the class name does not make it more clear what the class does and since the class is already included in a branded name space it does not convey any extra information. I would not be against changing the name, but as bartlannoeye already said the name covers the class's functionality pretty good.

Extreme example, I don't think anybody thinks its a good idea to add "Prism" in front of all classes in the prism library. So why is it a good idea to add it in front of one class?

/me is not looking forward to typing
var nav = new PrismRegionNavigationSerivce(new PrismServiceLocator(), new PrismRegionNavigationContentLoader(), new PrismRegionNavigationJournal());

[brianlagunas]

Well technically, the class doesn't really do anything special. PubSubEvent is not the concern that is doing the publishing or subscribing. The IEventAggregator is doing the pub/sub action. So the PubSubEvent name doesn't fit well with the class. The PubSubEvent is just an event used by the IEventAggregator. The reason to prefix with "Prism" is to eliminate any collisions with any .NET Event class, since it is an event specifically for use in Prism with the event aggregator.

[powerdude]

EventAggregatorEvent?

[brianlagunas]

So I was looking into this some more and it appears that there is no Event class in .NET. There is an "event" keyword, but no Event class. So, what if we just called it Event?

public class SaveEvent : Event < string > { }

Thoughts?

[Mike-E-angelo]

👍 👍 👍

[brianlagunas]

It's been brought up that Event < string > may be too ambigious, and I tend to agree.

And, it turns out that I was wrong when I said the IEventAggregator does the pub/sub action. It is actually the event. I don't know what I was thinking!

Anyways, knowing that the event does actually perform the pub/sub actions, should we just keep it PubSubEvent?

I am leaning towards keeping it that way.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.