I recently made a number of updates to my collections API which include some minor changes to the existing code as well as a few additional classes and interfaces which have been added.
The most significant updates involve three additional operations which have been added to the IMap interface which are as follows:
Allows an Object or Dictionary instance of key / value pairs to be added to an IMap implementation.
Serves as a pseudo-overloaded implementation of the put(key:*, value:*); method in order to allow Strongly typed key / value implementations to be added to a map.
Returns an IList of HashMapEntry objects based on all key/value pairs
I have also added two new additional IMap implementations to the collections API; LocalPersistenceMap, which can be utilized to provide an IMap implementation into a local SharedObject and ResourceMap which allows developers to work with a ResourceBundles via an IMap implementation. All IMap implementations; HashMap, ResourceMap and LocalPersistenceMap have been updated to implement the new operations.
The IIterator interface has been renamed to Iterator. In addition the remove() operation has been omitted in order to enforce that a concrete implementations can not modify an aggregate. Additionally, ICollectionViewSortHelper has been renamed to CollectionSortUtil.
Some design decisions worth mentioning involve the inclusion of multiple IMap implementations; HashMap, ResouceMap and LocalPersistanceMap. Initially I identified an AbstractMap from which these classes would extend, however I realize some developers may want to minimize dependencies as much as possible therefore I decided to simply have each concrete map implement the IMap interface rather than extend an abstract map implementation.
The source, binary and ASDocs for the new Collections API can be downloaded here.
The Collections API is published under the MIT license.
Thanks for the job Eric, those are the kind of things you wonder why they are not included in the framework…
{Maz}
Hey Maz,
I agree, for the most part these are common APIs one would expect to be included in the framework. The only reason I can think of as to why they are not included is to allow ActionScript 3 to align with the ECMA-262 edition 4 standard – which in many ways is very limiting.
– Eric
One problem with:
getEntries() : IList;
(and the ArrayCollection) is that it introduces a dependency on the Flex framework, preventing the use of you HashMap in plain AS3 projects 🙁
Any chance of changing it to an Array?
hi Eric,
and thanks for sharing your work. Could be nice to see all your code in a repository indeed, much easier to update for us.
Thanks.
I have an entire codebase which contains all of my Open Source APIs as well as numerous other APIs which are not open source. This is entirely under version control and provides source access and distributions. If you are interested in the licensed version you can contact me directly
Thanks,
Eric
HashMap utility is very helpful. Thanks!
Thanks very much for these – saved me a lot of typing.
Small problem…
If I do something like mymap.put(“hello”, null) and then mymap.contains(“hello”), it returns false. This is because for “contains()” you implemented it by checking the value in the dictionary. Is it possible to change this so that contains() tests for the existing of the key rather than the null-ness of the value???
Would hasOwnProperty() do this???
One more thing – looking inside the HashMap class, I could not see any kind of hashing going on – or is that something built into Actionscript’s property lookup mechanism?
Hmmm. In my code I got HashMap object and put it as a value inside another HashMap. Looks like this: HashMapA(key, HashMapB value).
Then i do:
var iList:IList = HashMapA.getEntries();
var iListLen:int = iList.length;
var mapEntry:HashMapEntry = null;
var tmpList:IList = null;
var HashMapB:HashMap = null;
var tmpListLen:int = 0;
for (var i:int=0; i ” + i + ” ” + mapEntry.key + ” ” + tmpListLen);
}
If you run this code repeatedly, you will notice that tmpListLen yields inconsistent results.
Sorry, this should be the content of the for-loop:
for (var i:int=0; i ” + i + ” ” + mapEntry.key + ” ” + tmpListLen);
}
mapEntry = iList.getItemAt(i) as HashMapEntry;
HashMapB = mapEntry.value;
tmpList = HashMapB.getEntries();
tmpListLen = tmpList.length;
trace(“i -> ” + i + ” ” + mapEntry.key + ” ” + tmpListLen);
errr, i can’t post my for-loop properly 🙁
Hey Charisma,
You will get inconsistent results because internally, the HashMap utilizes a Dictionary object, thus when you invoke HashMapA.getEntries(); the underlying algorithm uses a “for in” loop, which when used to iterate over an Object or Dictionary the order of the results returned are not guaranteed.
Best,
Eric
Hi Eric,
Does HashMap suport data binding? I want to bind a hashmap value to a textinput component.
Thanks,
Alan