TweenEvent.COMPLETE conflict with Event.COMPLETE

[prometh]

Both of them have a text value of "complete". If you have listeners for both events in a single class, you'll have problems.

 

I push for a notion to have TweenEvent.COMPLETE officially changed to "tweenComplete". Would probably be a good idea to change "init" and the others too. I have made these changes in my current project.

[GreenSock]

Hmm, I'm not sure I follow why this would be a problem. Lots of classes use the Event.COMPLETE type - would you say that every class that dispatches it should have its own renamed type as well? If you're trying to reuse an event handler and employ conditional logic to discover what type of event it is, wouldn't it be just as simple to see if (event.target is TweenLite) or something? I may be missing something obvious here, but I just don't see why it would be necessary or beneficial to rename the constant.

[prometh]

I have custom dispatched events in a class:

 

dispatchEvent( new Event(Event.COMPLETE) );

dispatchEvent( new TweenEvent(TweenEvent.COMPLETE) );

 

Since both have a value of "complete", it's causing problems. Adding an event.type check is, to me, unnecessary code. Just to be clear, I'm not saying change the "COMPLETE", but the "complete".

[prometh]

If you aren't going to make this change, lemme know, cuz I'd rather not find out later when I overwrite my files with a new version.

[GreenSock]

Oh, I see. For that type of usage, I think it's generally a much better practice to use your own Event class anyway because it gives you much better control. Even if I did change "complete" to "tweenComplete", it wouldn't fix your dilemma because what if you have a Loader and a Sound and a URLLoader - they all dispatch a "complete" event as well so how would you distinguish between them? But if you create your own custom event class (I'll call it CustomEvent), you could use CustomEvent.TWEEN_COMPLETE, CustomEvent.SOUND_COMPLETE, CustomEvent.LOADER_COMPLETE, etc.

 

See what I mean?

 

To be consistent with the standard way of naming events in AS3, I'd need to either keep TweenEvent.COMPLETE as "complete" or change the whole thing to TweenEvent.TWEEN_COMPLETE with "tweenComplete" as the value. Doing that would be very risky because a LOT of people are using these classes and it would suddenly break for them when they update. See my dilemma? I'm not trying to be unhelpful here - I just believe it would be a much better practice for you to structure your event handling differently.

[prometh]

Loader and URLLoader both make use of Event.COMPLETE, however there is TimerEvent.TIMER_COMPLETE, so I think you're right about TWEEN_COMPLETE. What would you think about officially adding such events to the class and deprecating the old ones? Much like what you've done with setDestination() and updateTo()

[GreenSock]

Loader and URLLoader both make use of Event.COMPLETE, however there is TimerEvent.TIMER_COMPLETE, so I think you're right about TWEEN_COMPLETE. What would you think about officially adding such events to the class and deprecating the old ones? Much like what you've done with setDestination() and updateTo()

I don't think that's a good solution for two reasons:

 

1) I'd have to dispatch 2 events (COMPLETE and TWEEN_COMPLETE) after every tween which is wasteful and degrades performance slightly. It's pretty confusing from an API standpoint too.

 

2) Even if I made that change, it wouldn't solve the problem you're facing. Sure, it gives you a short-term fix for this particular scenario but it seems very shallow because you're still using a technique that is generally considered a poor practice.

 

Is there a reason you're resisting the concept of using a custom Event class for your application/class? I do that for almost every project (at least ones that require event notifications other than the very basics that are already provided by the standard Event class) and I think it's pretty common for other developers as well.

[prometh]

Well, I've always used a custom events class for things like this, but this time I figured it'd be better to use the standard ones. But, I just noticed VideoEvent.COMPLETE as well, so... meh, heh... I still think my idea is better, but it would've had to have been applied across the board in AS3

 

Thanks for your thoughts, and thanks for TweenMax!