[Feature Request] Having Typed Notification

[Flapflap]

Hi there,

With the INotification's getBody() Object return type. We can not override the getBody() method to have a typed object handled in our Notification.
Sad, beacause having typed Notification can be very usefull and errorless.

Maybe in 1.7.
I'm ready to write the code if needed.

Thanks

[pedr]

Why not subclass Notification and add your own getter / setters much as you would when building a new Event class?

The getBody() is there as an easy, untyped way of passing data, but if you need  strict typing, just add it to your subclass.

Happy to send you an example if needed.

[Kristopher Schultz]

pedr,

If one were to create a subclass for a particular type of Notification - say a notification which carried a User object as it's payload and had a getUser() method - how would you get PureMVC to use that subclass? The method signature of sendNotification() doesn't allow you to specify which INotification implementation to use.

Kris

[Jason MacDonald]

Use notifyObservers.

[puremvc]

Typed notifications are exactly what the framework was trying to avoid. Believe me, I'm sold on the power of strong typing, but in this case, I wanted simplicity.

IMHO, Custom Events are such a pain to have to create if you want to throw a piece of data over to another actor. The actor has to be listening for the specific type and you have to create the class. Once you start making custom Events (or Notifications) its like the 'bet you cant eat just one' commercial; you end up with a plethora of them to manage. If you have a team and a codebase in flux, often code gets refactored not to use an existing custom event but the class remains, since other parts of the code use it, and no one knows when to get rid of it. You have to figure out what to name them, etc. In short it can become a hairball that is not even remotely worth the hassle.

In a system like Flash where you get a reference to an EventBroadcaster subclass and tell it to create a listener pointing to your method (which has a typed Event argument), typed Events make sense, in that the IDE can tell you something about the problem before you compile. The trade off (at least in flash.events.Event) is that you can't send arbitrary data with an Event. It just says something happened and here's the name of what it was and where it came from.

In the PureMVC implementation of the Observer pattern we trade that compile time knowledge of the type being sent and received for the decoupling of the actors (the observer doesn't need to know or have a reference to the subject, in fact the subject doesn't even need to exist at the time the observer is registered) and because of that we have a single inbound notification method that the notified parties receive their notifications on.

As Jason mentioned you can use facade.notifyObservers to send custom notifications, and feel free to do so, but I don't see the benefit. If you cast a received note body to the type you expect it to be, you still need to see if its null before making assumptions about it, do you not? Could you not have as easily as having got the type wrong, not loaded the body at all? Even if that body was typed, it could still be null. You can't catch everything at compile time, and this is one of those things that, again, IMHO, isn't worth trying.

-=Cliff>