This content has been marked as final. Show 3 replies
Personally, I would have named the class ChoiceEvent rather than ChoiceMade. Then your event would be ChoiceEvent.CHOICE_MADE.
Since the constants are part of the class, repeating 'CHOICE' as part of the constant is redundant and adds little value.
For example, there is no ambiguity in :
Very good point Bart, that's what I was looking for.
So I would just add constants for the other events, as in:
public static const MADE:String = "choiceMade";
public static const NEGATIVE:String = "choiceNegative";
Yes... but. ( There's always a but! )
You certainly can, and often times should, have Event constants for specific 'events'.
But other times you should have a more generic 'transport' event. i.e. ChoiceEvent.MADE which as a custom event also accepts a parameter and passes it along. This way the event 'transports' some vital piece of info.
See example code below.
This custom event allows you to (optionally) pass the answer/choice made along with the event. You can then put your logic on either side of the event... either deciding the choice was right/wrong/other and dispatching a right/wrong/other event... or dispatching a MADE event, and including the answer in that event so that whomever is listening can do whatever they need to/with the answer.