AS3: Why are all maps used by PureMVC Arrays (commandMap, proxyMap etc.) ?

[wez]

Can anyone explain to me why commandMap (in Command.as), proxyMap (in Model.as) and mediatorMap & observerMap (in View.as) are all Arrays, even if their variable names accurately describe them as Maps?
e.g. commandMap = new Array();

Arrays in ActionScript are numerical and not associative.

And the ActionScript reference states:

Do not use the Array class to create associative arrays (also called hashes), which are data structures that contain named elements instead of numbered elements. To create associative arrays, use the Object class. Although ActionScript permits you to create associative arrays using the Array class, you cannot use any of the Array class methods or properties with associative arrays.

Therefore i would propose to change them into Objects.
This is not a performance or functionality issue, but as everything in PureMVC builds upon logic, this seems very logical to me.
Using Arrays will add functionality to the Maps, that is never used.

[gencha]

There is also flash.utils.Dictionary.

[wez]

That's true. This is also an AS3 implementation of a map.
But it also provides functionality, i.e. not used by PureMVC.

The Dictionary class...

... lets you create a dynamic collection of properties, which uses strict equality (===) for key comparison

So if you need to use objects as keys for your map, the Dictionary class would be the right choice.
But as PureMVC maps use simple Strings as keys, the Object class would be the right choice.

[puremvc]

Dictionary is a flash class. PureMVC was intentionally written to not have any Flash, Flex or AIR dependencies to remain portable. At the time that was to shoot for a framework that would work with Tamarin. In the end it lead to portability to all these other platforms.

As for using objects instead of arrays, it was a decision that came from habit.

On a Flash project I worked on sometime back, I discovered that arrays as maps performed better than objects as maps for large numbers of key value pairs. I don't know if it was the internal implementation of arrays as opposed to objects when it comes to adding a member to a prototype or what, but the results of my tests at the time lead me to choose arrays as maps over objects. Now this may have changed over time, AS3 brought about a complete rewrite of the VM.

But at this point, switching over the internals would really require a good reason. It works well, and as they say 'if it aint broke don't fix it.'
-=Cliff>

[wez]

I would bet that Array builds upon Object in the VM and they share exactly the same functionality concerning their functionality as maps. So i won't believe to detect performance differences in any case. You could even use any other class and declare it dynamic.

My issue was something different.
When talking about PureMVC, we are talking about design patterns.
The aim of design patterns is to provide the most simple and most logical way possible to structure a given complex task.
So my thought was, that the framework implementation itself should also use the most simple and logical structures.
Of course 'if it aint broke don't fix it.', but it won't break in either case.
I just thought it would fit in better from a logical standpoint.

But hey, it was just a proposal and in the end has no effect on the functionality and performance of PureMVC.
So of course there is no need to change it at all.

[puremvc]

Wez,

I absolutely agree about making it as simple as possible - but no simpler. In this case, I don't think that Object fits the bill. You can have problems if properties are ActionScript reserved words. I'm not sure you'd want to pass that along as a constraint on Notification names, which are just supposed to be the key in a key value pair.

Try this:

:

public var {this:'that'};

You get several markers but the killer is:

:

Error 1078: Label must be simple identifier.

-=Cliff>

[wez]

I don't know if i get the point.
Of course there can be trouble if reserved words are used.
But that's the case for both arrays and objects.

If you instanciate an object in this JASON-like fashion:

:

var obj = {this:'that'};there will of course be problems.

But in this JASON-like fashion it is not even possible to instanciate Arrays with key value pairs.
An Array would look like this and would be numerical anyway.

:

var arr = ['this', 'that'];
But the following will work in both cases:

:

var obj = new Object();
var arr = new Array();
obj['this'] = 'that';
arr['this'] = 'that';
trace(obj['this'], arr['this']);Although it still remains a bad idea to use reserved words, it will work with both, Arrays and Objects.
And that's exactly the way PureMVC makes use of the Maps.

So for me there is actually no point for using Arrays instead of Objects.
Using Arrays is not really worse than using Objects, but it's also not better.
There is only a difference from a logical standpoint, as i mentioned above.

But as i said, this is only a very marginal issue and nothing of big worth compared to the benefits of PureMVC.
So, even if i don't really understand why you prefer Arrays, the simple notion that you do should suffice in the end.
And i will use this framework anyway, even with Arrays !!