-----Original Message-----
From: Thomas Schuessler [mailto:Thomas.Schuessler@bwservices.de]
Sent: Tuesday, December 11, 2007 12:06 PM
To: cliff@puremvc.org
Subject: One more question...
Hi Cliff,
It is probably too late to make such a change and maybe I am a little paranoid, but what about using Enum-classes instead of strings to identify notifications? This would avoid the need to have naming conventions in larger projects.
br...tgs
Thomas,
I'm not completely against enums, as you can see in the Arch101 demo, I find a variation on it very useful for dealing with combo box population where we have an enumeration of possible settings:
http://puremvc.org/pages/demos/arch101demo/srcview/source/org/puremvc/arch_101/unit_03/lab_02/model/enum/DeptEnum.as.htmlBut it seems to me that Enums are still a little involved for a core activity like notification constant naming. I think a lot of people would be put off by it. Of course middleware would help, but...
However, this really falls into the area of idiom. You could do it either way.
I would suggest doing demos that use both approaches. One that will be more understandable to people using other versions of PureMVC where constants are used, and another that shows using enums for those who prefer it.
The advantage of enums over constants are that you get all the possible values in one spot, even ordered. But we don't really ever have a need for that in PureMVC. Nothing is ever passing over all possible Notification names. At least not now. If there were utilities for analyzing and interacting with arbitrary PureMVC apps, then it might be nice to expose the notificaiton names supported by the app to such a tool...
-=Cliff>