Collections API update
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.
April 2nd, 2008 at 6:50 am
Thanks for the job Eric, those are the kind of things you wonder why they are not included in the framework…
{Maz}
April 3rd, 2008 at 10:00 am
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
April 23rd, 2008 at 1:43 am
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?
July 5th, 2008 at 1:51 am
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.
July 6th, 2008 at 7:41 am
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