If I have a function called from a few places, and it requires some condition to be met for anything it does to execute, where should that condition be checked? In my case, it's for drawing - if the mouse button is held down, then execute the drawing logic (this is being done in the mouse movement handler for when you drag.)
Option one says put it in the function so that it's guaranteed to be checked. Abstracted, if you will.
public function Foo() {
DoThing();
}
private function DoThing() {
if (!condition) return;
// do stuff
}
The problem I have with this is that when reading the code of Foo, which may be far away from DoThing, it looks like a bug. The first thought is that the condition isn't being checked.
Option two, then, is to check before calling.
public function Foo() {
if (condition) DoThing();
}
This reads better, but now you have to worry about checking from everywhere you call it.
Option three is to rename the function to be more descriptive.
public function Foo() {
DoThingOnlyIfCondition();
}
private function DoThingOnlyIfCondition() {
if (!condition) return;
// do stuff
}
Is this the "correct" solution? Or is this going a bit too far? I feel like if everything were like this function names would start to duplicate their code.
About this being subjective: of course it is, and there may not be a right answer, but I think it's still perfectly at home here. Getting advice from better programmers than I is the second best way to learn. Subjective questions are exactly the kind of thing Google can't answer.
According to DRY, I'd go with the first one.
public function Foo() {
DoThing();
}
private function DoThing() {
if (!condition) return;
// do stuff
}
Once you get used to the pattern, it's not so unnerving seeing a lone DoThing() in your code. You'll start to read it like a EnsureThingDone().
Option four, wrap the predicate and the actual call in a 3rd function.
function DoThing() {
// do stuff
}
function DoThingOnlyIfCondition() {
if (!condition) return;
DoThing();
}
function Foo() {
DoThingOnlyIfCondition();
}
// Foo version 2
function FooBar() {
DoThing();
}
Now Foo, or whatever function, can use the most appropriate DoXXX() version.
I like to check preconditions inside the function,
public function DoThing()
{
ValidatePreconditions();
DoWork();
}
private function DoWork()
{
//Do the actual work;
}
This way i'm certain all the proper preconditions are met before the execution of my function and there's no need for a consumer to add unnecesary code every time my function is called.
You could use the type system. Make the parameter to DoThing an object that you can only instantiate if the preconditions are passed.
A neat-ish way to do this would be to make DoThing an instance method on that object.
Related
I posted a question last night that after reading back sounded awful, so I deleted it and have come back to try again, this time properly.
I have a Flex Mobile App, that uses Parsley, everything works as expected but I am trying to do use a decoupled result handler in my controller, but it is not firing when I expect it to, so would like a pointer as to why.
The command look like this:
public function execute():void
{
var asyncToken:AsyncToken = Db.Instance.ViewChildren(mainModel.loggedInUser.userId);
asyncToken.addResponder(new Responder(result, error));
}
public function result(result:ResultEvent):void
{
callback(result.result);
}
public function error(event:FaultEvent):void
{
callback(event.fault);
}
Which works as expected, the command is executed and the result handler handles the result, the problem comes when I try to put a message handler in the controller for the view.
[CommandResult]
public function handleResult(result:AsyncToken):void
{
trace("result in the controller");
}
[CommandError]
public function handleError(fault:AsyncToken):void
{
trace('error: ' + fault.fault.faultDetail);
}
Neither of these listeners fire when a result arrives, so I did the obvious thing and changed the code to:
[CommandResult]
public function handleResult():void
{
trace("result in the controller");
}
[CommandError]
public function handleError():void
{
trace('fault in controller);
}
Now it fires, but I have no data handle.
I did think of changing the commands execute method to
public function execute():AsyncToken
{
return Db.Instance.ViewChildren(mainModel.loggedInUser.userId);
}
as after all it does return an AsyncToken, but then the command doesn't fire at all (it is part of a 2 command sequence that is mapped to an event called ChildEvent, this is the second and last event in the chain.
So in summary, I want the above to work, but want to be able to manage the result in the decoupled result handler, but I can't work out how, the parsley manual is great for getting to this point (http://www.spicefactory.org/parsley/docs/3.0/manual/?page=commands§ion=intro), but the finer details are a little sketchy.
Thanks
With a small tweak to the Controller code, we end up with this:
[CommandResult(type="view.user.UserEvent", selector="loadUser")]
public function handleResult(result:Object):void
{
trace("this is the command result");
}
OR
[CommandResult(selector="loadUser")]
public function handleResult(result:Object, trigger:UserEvent):void
{
trace("this is the command result");
}
Now this fires, I get an Object with my data in, resolved.
It would be useful to note that the manual for Parsley 3.0 misses out the section that explains how this actually works. I eventually found it in the Parsley 2.2 manual (the equivalent section in the 3.0 manual has been removed!) But if you ever need it http://www.spicefactory.org/parsley/docs/2.2/manual/messaging.php#command_methods
Thanks everyone!
I have been dealing with this problem for days already. I am at my wits' end!
I can't seem to find a definitive answer anywhere on any of the forums, documentation, etc.
Everything looks fine at first run, or when I load a next level for the user to play. But if the user hits the ESC key to load a different level, the ENTER FRAME listener does not get removed and it duplicates all the triggers in it, showing the player going really fast, and all funky, because it builds on top of the previously instantiated ENTER FRAME listener.
I don't know if I have a problem of an anonymous function, or an unknown instance being referenced in my removeEvent... command... Bottom line, I give up and I need this working HELP!!!
Here's the code:
function initPlay():void
{
//code here determining what display object to add to the list and assign it to the currentLevel variable (a movieclip)
if(userIsLoadingOtherLevel){
removeEnterFrameListener();
addChild(currentLevel);
}
if(userIsGointToNextLevel)
addChild(currentLevel);
currentLevel.addEventListener(Event.ENTER_FRAME, onEnterFrame);
function onEnterFrame(event:Event):void
{
//collision detection, parallax scrolling, etc, etc is done here.
if(allCoinsCollected)
loadNextLevel();
if(ESCKeyPressed)
ESCKeyPressHandler();
}
function loadNextLevel():void
{
removeChild(currentLevel);
newLevelToLoad++
removeEnterFrameListener();
initPlay();
}
function ESCKeyPressHandler():void
{
removeChild(currentLevel);
initPlay();
}
function removeEnterFrameListener();
{
currentLevel.removeEventListener(Event.ENTER_FRAME,onEnterFrame)
trace("currentLevel.hasEventListener(Event.ENTER_FRAME) = "+currentLevel.hasEventListener(Event.ENTER_FRAME)); //outputs TRUE if called from loadNextLevel but FALSE if called from initPlay() !!!
}
}
I also tried to add and remove the eventListener to stage, MovieClip(Root), or nothing at all and the result is always the same.
I know that there may be other ways to design such a process, but please note I am not really flexible at the moment on doing this because the project is very long (about 4000 lines of code) and removing the ENTER FRAME this way, crazy or not should still work!!
THANK YOU in advance for anyone willing to help.
The problem appears to be the nested functions inside the initPlay() method.
Each time you call initPlay() you are defining new functions. Some of these nested functions call initPlay() themselves.
Functions are objects (memory references). So each time you call initPlay() you are making new references to new functions. So when you try to remove an event listener, you're only able to remove one of these event handlers (the one in the current scope of execution).
I'm not sure if I'm explaining this clearly, perhaps this example will help. I'll use numbers to represent the references to each function, and a simple scenario that is similar to yours:
function example():void
{
addEventListener(MouseEvent.CLICK, mouseClickHandler);
function mouseClickHandler(event:Event):void
{
if (someCondition)
{
example();
}
else
{
removeEventListener(MouseEvent.CLICK, mouseClickHandler);
}
}
}
When we run this function the first time, a new function is defined within the scope of the example() function. Lets use the number 1 to represent the reference to this nested function. someCondition is true on the first time around, and so the example() function is called again.
On the second execution of the example() function, a new reference to the mouse event handler is created (#2). We also add the event listener again. At this point, there are two event handling functions in memory, and both will be executed when the event is dispatched.
Let's say that in the second invocation of example() that someCondition is false and now we want to remove the listener. When we call:
removeEventListener(MouseEvent.CLICK, mouseClickHandler);
It's referring to event handler #2. Event handler #1 still exists, and because it's hidden in the scope of the first invocation of example() it can't be removed here.
My simple example breaks down after this... but I hope it makes it clear why your event handlers shouldn't be nested inside a function. Admittedly, this is difficult to describe and even more so in a real world example like yours. But I'm pretty confident that this is the source of most, if not all, of the issues you describe.
Here's how I was able to get around this without changing the scope of the nested functions (although I agree that would be the preferred solution) by creating a boolean variable called "loadingNewGame" and changing it to true from outside the onEnterFrame (in fact, this assignment was done from initPlay() and then from onEnterframe I called removeEnterFrameListener() function. This did the trick.
here's the code in case anybody is interested:
// package, and other code here.
var loadingNewGame:Boolean = new Boolean(false);
function initPlay():void
{
//code here determining what display object to add to the list and assign
//it to the currentLevel variable (a movieclip)
if(userIsLoadingOtherLevel)
{
loadingNewGame = true;
removeEnterFrameListener();
addChild(currentLevel);
}
if(userIsGointToNextLevel)
addChild(currentLevel);
loadingNewGame:Boolean = false;
currentLevel.addEventListener(Event.ENTER_FRAME, onEnterFrame);
function onEnterFrame(event:Event):void
{
if(loadingNewGame)
removeChild(currentLevel);
//collision detection, parallax scrolling, etc, etc is done here.
if(allCoinsCollected)
loadNextLevel();
if(ESCKeyPressed)
ESCKeyPressHandler();
}
function loadNextLevel():void
{
removeChild(currentLevel);
newLevelToLoad++
removeEnterFrameListener();
initPlay();
}
function ESCKeyPressHandler():void
{
initPlay();
}
function removeEnterFrameListener();
{
currentLevel.removeEventListener(Event.ENTER_FRAME,onEnterFrame)
trace("currentLevel.hasEventListener(Event.ENTER_FRAME) = "+currentLevel.hasEventListener(Event.ENTER_FRAME));
//outputs true
}
I have two function on my AS3 program, one fires when the width and height changes:
stage.addEventListener(Event.RESIZE, resizeListener);
function resizeListener (e:Event):void {
//some commands
}
And the second one fires one a number of milliseconds pass:
var myTimer:Timer = new Timer(clockUpdate, 0);
myTimer.addEventListener(TimerEvent.TIMER, updateData);
myTimer.start();
function updateData(e:TimerEvent):void {
trace("AUTOUPDATE");
trace(e);
}
I need to fires those function also manually, lets say when the user press a button, but i don't know what parameters i have to send them when they are called manually.
I tried just resizeListener() and updateData() but of course it fails asking me for the parameter.
You can make parameters in a function optional by providing a default value. This is an example by taking your two functions above and making the event parameters optional:
function resizeListener(e:Event = null):void {
//some commands
}
and
function updateData(e:TimerEvent = null):void {
trace("AUTOUPDATE");
trace(e);
}
Calling, for example, resizeListener() will now execute the function and the value of e will default to null.
Making the Event parameter optional, resizeListener(e:Event=null), as in walkietokyo's answer, is a perfectly valid and often convenient solution. Another alternative is to put the stuff you want to be able to do without the event being triggered in a separate function, that can be called by the event handler and from anywhere else.
So assuming for example that what you want to do on resize is to rearrange the layout, and you also want to do that same layout setup at initialization, or at the click of a button, or anytime really, you could do something like this:
stage.addEventListener(Event.RESIZE, resizeListener);
function resizeListener(e:Event):void {
rearrangeLayout();
}
function rearrangeLayout():void {
// The actual rearrangement goes here, instead of in resizeListener. This can be called from anywhere.
}
Which way to do it is probably a matter of taste or can vary from case to case, really, both works fine.
A benefit of separating things in an event handler and another function is that there will not arise a situation where you would have to check if the e:Event parameter is null or not. In other words, you would have code that is dependent on the Event, if any, in the event handler, and code that is independent of the Event in a more general function (not an event handler).
So in a more general and schematic case, the structure would be something like this:
addEventListener(Event.SOME_EVENT, eventListener);
function eventListener(e:Event):void {
// Code that needs the Event parameter goes here (if any).
// Call other function(s), for the stuff that needs to be done when the event happens.
otherFunction();
}
function otherFunction():void {
// Stuff that is not dependent on the Event object goes here, an can be called from anywhere.
}
This is my code in Flash/AS3, in main class.
addEventListener(Event.ENTER_FRAME,function(e:Event){
if(findObject == true){
// I want to remove this ENTER FRAME
}
});
try this:
e.currentTarget.removeEventListener(e.type, arguments.callee)
You shouldn't be doing what you do in the code above.
The mgraph's code has a tiny chance of failing to work as advertised if the currentTarget of the event doesn't have a removeEventListener() method (possible, but very unlikely). From the compiler standpoint though you will be trying to dynamically resolve the method on a generic object which is error prone and should be handled with care. This is hazardous because it shows that the programmer "did not know" what kind of object was she expecting to handle and worked by assumption. Assumptions are great for finding a solution but are equally bad for implementing one.
If you thought of optimizing something in the way you did it, then, just FYI this actually creates a unique (redundant) name in the symbol table (in the compiled SWF file) which causes worse compression of the SWF.
If you are doing this as a matter of experiment, this is fine, but you should avoid such code in real life projects.
One more thing to be aware of: comparison to true constant is 100% useless. If such comparison makes any sense at all (i.e. findObject may evaluate to false any time), then if (findObject) { ... } is equivalent but shorter version of your code.
Last thing, hopefully, the anonymous function is missing return type declaration. It won't really change much in your example, except that you will get compiler warning. Omitting type declaration is, in general, a bad style.
EDIT
public function addEventListener(type:String, listener:Function ...):void
{
this._listeners[type].push(listener);
}
public function dispatchEvent(event:Event):void
{
for each (var listener:Function in this._listeners[event.type])
listener(event);
}
public function removeEventListener(type:String, listener:Function, ...):void
{
delete this._listeners[type][listener];
}
Suppose you actually want to implement IEventDispatcher (instead of using another EventDispatcher - you may have your reasons to do so, one such reason is that native EventDispatcher generates insane amounts of short-lived objects - events, and you may want to reduce that.) But there is no way you can replicate event.target or event.currentTurget in your code because you can't access the object owning the method, so, you would leave that out.
Another example:
public class SomeEvent extends Event
{
private var _target:NotEventDispatcher;
public function SomeEvent(type:String, someTarget:NotEventDispatcher)
{
super(type);
this._target = someTarget;
}
public override function get target():Object
{
return this._target;
}
}
This is something that I actually saw in real world, this was used in either Mate or similar framework to sort of "anonymously" connect all event dispatchers to a single static instance of some "mothership event dispatcher".
I don't necessarily justify this approach, but, technically, nothing stops you from doing either one of these. What I was saying in my post above is that in certain situations the language promises you things, like, if you did:
var dispatcher:IEventDispatcher;
try
{
dispatcher = IEventDispatcher(event.currentTarget);
// now you can be sure this object has removeEventListener
dispatcher.removeEventListener(event.type, arguments.callee);
}
catch (error:Error)
{
// but what are you going to do here?
}
But the most common case would be you subscribing to a bubbling event, in which case, you don't know whether you want to unsubscribe from event.target or event.currentTtarget - because you don't know which one is that you are listening to.
I agree with wvxvw.
Another way to approach your problem is to have a variable to control the "state" of your ENTER_FRAME event:
private var _state:String;
private function init(e:Event):void {
addEventListener(Event.ENTER_FRAME, loop, false, 0, true);
}
private function loop(e:Event):void {
switch(_state) {
case "play":
// do play stuff
// when you want to pause
// goToPause();
break;
}
}
// you can call the method below from a button or whatever you want
private function goToPause():void {
_state = "pause";
// do some stuff here
// when you are done, switch "_state" back to "play"
}
In this example, you keep listening for ENTER_FRAME, but it only does things when the _state variable is set to "play". You can also remove the event listener in the goToPause method:
private function goToPause():void {
_state = "pause";
removeEventListener(Event.ENTER_FRAME, loop);
}
However, the nice thing about using the "_state" to switch things is that you don't end up having a mess of addEventListeners and removeEventListeners (which is what can happen depending on how complicated your loop gets) that you have to keep track of.
You should not use anonymous function call if you would like to remove listener some time later.
public function main():void
{
//...
//some method, where you add event listener
//...
//adding enterFrame event listener
this.addEventListener(Event.ENTER_FRAME,enterFrameHandler);
//...
}
private function enterFrameHandler(e:Event)
{
if(findObject) // " == true" is not really necessary here.
{
// removing enterFrame listener:
this.removeEventlistener(Event.ENTER_FRAME,enterFrameHandler);
}
}
Just for a completeness with the other techniques mentioned here, the function you are creating is a unbound closure, so you can also leverage that concept to reference both your function and dispatcher.
var callback:Function;
var dispacher:IEventDispatcher = this;
addEventListener(Event.ENTER_FRAME, callback = function(e:Event){
if(findObject == true){
dispacher.removeEventListener(Event.ENTER_FRAME, callback);
}
});
Normal closed-over variable rules apply.
A simple piece of code that should trace :
rien
test
done!
and I get something completely far away from that,
scenario A :
var __functions_to_execute:Array;
function start():void {
__functions_to_execute =[];
__functions_to_execute.push(futile_trace());
__functions_to_execute.push(futile_trace('test'));
execute_functions();
}
function execute_functions():void {
if(__functions_to_execute.length){
//where shift on this Array remove the first element and returns it
var exec:Function =__functions_to_execute.shift();
exec;
//I tried this too, just in case
//__functions_to_execute[0];
//__functions_to_execute.shift();
} else trace("done!");
}
function futile_trace(_value:String ='rien'):void {
trace(_value);
execute_functions();
}
start();
pretty simple. but the result is :
rien
done!
test
lets add a deprecated function to this and lets change the futile_trace function to :
function futile_trace(_value:String ='rien'):void {
trace(_value);
setTimeout(execute_functions, 0);
}
and then the result is :
rien
test
done!
Ok then, I said to myself, why not, lets change the scope when I call execute_functions, so I tried :
function futile_trace(_value:String ='rien'):void {
trace(_value);
extra_step();
}
function extra_step():void {
execute_functions();
}
guess what was the result?! yeah :
rien
done!
test
so?! Is the trace function that bad? that slow? is it the fact that passing an argument to the function take so much time compare to the other one? I mean... wow!
is there something I can do to avoid this type of weirdness ?
(For the record, my project is not to trace {rien, done and test}... I have 15k lines of codes that react completely differently if I compile them with "Omit trace statements" or not.
Thanks for your input guys.
You are executing the functions and adding their return values to the __functions_to_execute array, not the functions themselves.
Your function execute_functions doesn't actually do anything. I've tried to explain the sequence in-line:
function start():void {
__functions_to_execute =[];
// 1. traces 'rien' first because futile_trace() is called with no args
// 2. 'done!' will be traced inside execute_functions because the array is still empty
// 3.undefined will be pushed into the array next
__functions_to_execute.push(futile_trace());
// 4. traces 'test'
// execute_functions does not trace anything because __functions_to_execute is non-empty
// but it also doesn't do anything because it is just removing the `undefined` value from the start of the array.
__functions_to_execute.push(futile_trace('test'));
execute_functions();
}
Something more like this should behave how you expect. It's storing in the array function references, along with the arguments that should be passed when the function is called.
var __functions_to_execute:Array;
function start():void {
__functions_to_execute = [];
__functions_to_execute.push({func:futile_trace, args:[]});
__functions_to_execute.push({func:futile_trace, args:['test']});
execute_functions();
}
function execute_functions():void {
if(__functions_to_execute.length){
var obj:Object = __functions_to_execute.shift();
obj.func.apply(null, obj.args);
} else trace("done!");
}
function futile_trace(_value:String ='rien'):void {
trace(_value);
execute_functions();
}
start();
For scenario A, you're not actually ever pushing futile_trace to the array - you're calling it (notice the () after the function name), and then pushing the result of that call to the array.
In other words:
You call futile_trace()
futile_trace traces 'rien', because you passed no value.
futile_trace calls _execute_functions
At this point, nothing has been pushed yet, so _execute_functions traces 'done!'
_execute_functions returns.
_futile_trace returns.
The result of futile_trace() (void) is pushed.
You call futile_trace('test')
futile_trace() outputs 'test'.
futile_trace calls _execute_functions
_execute_functions shifts void from the array.
_execute_functions executes void; (which does nothing)
etc. etc.
If you need to pass a function to another function or store a reference to it in a variable, make sure you're not calling it.
__functions_to_execute.push(futile_trace);
// Use an anonymous function to pass with arguments without executing:
__functions_to_execute.push(function() { futile_trace('test'); });
... and in _execute_functions do remember the parantheses:
exec();