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: Persistent commands?  (Read 5464 times)
Deril
Full Member
***
Posts: 22


View Profile Email
« on: August 06, 2011, 10:04:55 »

Hi,

 If I understand correctly - commands are created then they respond to notification, and garbage collected after job is done. Both actions are expensive.

 as long as you read and listen to what everybody tells : commands must be stateless! there should not be a problem to create command once, and keep it in memory for future uses.

 Also keeping one object with execute instruction in memory should not be a problem. It will take couple of bytes.. not more.

 Object creation and destruction could be avoided?

 Apart of danger of creating the state and fail with it, is there any other problems?



-------------------


while I am at it... :) do you think this command is valid, I mean.. it kind of... sort of.. has a state for very short time until file is selected and ether fails or is loaded. (state in dynamic memory... but still)

:
package com.mindscriptact.mapExplorer.controller.fileHandling {

public class LoadZoneFileCommand extends SimpleCommand {

override public function execute(note:INotification):void {
var fileReference:FileReference = new FileReference();
fileReference.browse([new FileFilter("map3d.xml Files", "*.xml")]);
fileReference.addEventListener(Event.SELECT, handleFileSelect);
}

private function handleFileSelect(event:Event):void {
var fileReference:FileReference = event.currentTarget as FileReference;
fileReference.removeEventListener(Event.SELECT, handleFileSelect);
//
fileReference.addEventListener(Event.COMPLETE, handleFileLoadComplete);
fileReference.addEventListener(IOErrorEvent.IO_ERROR, handleIOError);
//
fileReference.load();
}

private function handleFileLoadComplete(event:Event):void {
var fileReference:FileReference = event.currentTarget as FileReference;
fileReference.removeEventListener(Event.COMPLETE, handleFileLoadComplete);
fileReference.removeEventListener(IOErrorEvent.IO_ERROR, handleIOError);

sendNotification(Note.PARSE_MAP_DATA, fileReference.data);
}

private function handleIOError(event:IOErrorEvent):void {
var fileReference:FileReference = event.currentTarget as FileReference;
fileReference.removeEventListener(Event.COMPLETE, handleFileLoadComplete);
fileReference.removeEventListener(IOErrorEvent.IO_ERROR, handleIOError);

sendNotification(Note.ERROR_REPORT, " ERRROR: file error " + fileReference.name + " " + event.text);
}

}
}

 would you implement it differently?


Thanks for time.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: August 08, 2011, 10:49:47 »

If I understand correctly - commands are created then they respond to notification, and garbage collected after job is done. Both actions are expensive.
Yes, the creation and GC of a Command has an expense associated with it. But consider a system that has literally hundreds of commands. Creating them all at startup just so they would be available when you need them would be extremely expensive. And engineering a 'phased instantiation' where you only create and register the ones you need at first and then create and register them when you first need them, would impose a lot of hassle on the developer.

as long as you read and listen to what everybody tells : commands must be stateless! there should not be a problem to create command once, and keep it in memory for future uses.
Yes, commands are meant to be stateless, and this is why they are created when needed and GCd later. The framework does this on purpose.

Give me a real-world scenario where the a time to create and destroy a lightweight command (such as the one you included in your post) multiple times would have an actual *perceptually measurable* effect on an app. There really aren't any I can think of.

do you think this command is valid, I mean.. it kind of... sort of.. has a state for very short time until file is selected and ether fails or is loaded. (state in dynamic memory... but still)
This is OK. No other actor can access the command, so its internal state is meaningless from all other perspectives. Note that you could always implement this as a Proxy if you only wanted to instantiate it and its FileReference class once.

-=Cliff>
Logged
Pages: [1]
Print