Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Suggestion to "as YXZProxy" casting  (Read 9136 times)
mikih
Newbie
*
Posts: 4


View Profile Email
« on: February 16, 2010, 10:07:22 »

Hi there,

I've got a suggestion for the usage of the "as" casting in the as3 port. It's not really useful to do so. It makes it worst to debug the code.

Using this:

:
var userProxy:UserProxy = facade.retrieveProxy(UserProxy.NAME) as UserProxy;

and getting a NULL return of any reason will effect your code at another position in the code. That makes it harder to debug while the debugger jumps to the wrong position in the Code.


I would rather recommend using this:

:
var userProxy:UserProxy = UserProxy(facade.retrieveProxy(UserProxy.NAME));

then the player is immediately throwing an exception at the right position in the stack and not when the userProxy is used later in the code.


Cheers
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: February 16, 2010, 11:36:47 »

Certainly a good point. It's not an issue usually if you've already registered your Proxies at startup, as most PureMVC apps do.

-=Cliff>
Logged
mikih
Newbie
*
Posts: 4


View Profile Email
« Reply #2 on: February 16, 2010, 12:58:48 »

Just in Case of code improvment. Last project we had Somerset issues with piping where I followed the paradigm ;) good insane while debugging. Sometimes you don't think about those compiler stuff


Flo 
Logged
mikih
Newbie
*
Posts: 4


View Profile Email
« Reply #3 on: March 02, 2010, 03:52:44 »

Performance wise "Class()" casting is a lot faster then "as Class". Are you planning to change that in the next rlz?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: March 02, 2010, 11:27:49 »

There are only two places in the entire Standard version framework where an 'as Class' cast is used, and that is in the View.notifyObservers and View.removeObserver methods. In both cases, they are getting the observer list for a given notification like this:

 
:
var observers:Array = observerMap[ notificationName ] as Array;
Since the execution of these calls only happens once in the method (the real work is subsequently visiting each of the observers in the list), I don't see a reason to optimize it. UPDATE: Actually, it can't be changed, as Array and Date are the two types that must be cast with 'as'. For arrays, a call to Array(xxx) will create an Array with one element: xxx.

Really, the best practices need to change in programs using PureMVC. And I've already taken a step in that direction. Just the other day I updated the Flex EmployeeAdmin demo to reflect best practices, and I made all the casts of retrieved Proxies and such use the 'Class()' casting instead of 'as Class'.

-=Cliff>
« Last Edit: March 04, 2010, 09:25:30 by puremvc » Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #5 on: March 02, 2010, 07:42:16 »

Really, the best practices need to change in programs using PureMVC. And I've already taken a step in that direction. Just the other day I updated the Flex EmployeeAdmin demo to reflect best practices, and I made all the casts of retrieved Proxies and such use the 'Class()' casting instead of 'as Class'.

I'm really glad to hear that!  A lot of programmers on my team have been using "as" for regular casting now because they saw it in some PureMVC demo or another and I've been having to convince them that regular casting is correct despite whatever online tutorials they may have seen.  You pull a lot of weight!
Logged
philipSe
Sr. Member
****
Posts: 139


View Profile Email
« Reply #6 on: March 03, 2010, 03:52:53 »

Useful reference on this topic:
http://stackoverflow.com/questions/996478/actionscript-is-there-ever-a-good-reason-to-use-as-casting
Logged
Pages: [1]
Print