Maps for Flash (part II)

I made a post a few days ago about using a Map type object in Flash rather than associative arrays or objects, and I got some interesting comments. One person pointed out a bug in the code that I posted that keeps track of the size of the map, which was a good catch. Someone else wanted to know why I preferred a map API over objects and arrays. There are three reasons:

  1. The map interface offers more functionality. The keys and values functions return keys and values as arrays. The size function returns the number of items in the map (something that the length attribute obviously gets you with an array, but not on object). I can, and probably will, add functions like clear, containsKey, containsValue, equals, isEmpty, etc.
  2. A map object is a great base class for other types of specific maps which add even more functionality. It’s even tempting to use the map object as a base class for any data type that needs put and get type functionally, though there are many who would argue for composition as opposed to inheritance in such a case, I say do what works (as long as you know what you are doing).
  3. I like to use my own data types when I can because they offer me flexibility and hooks for features and functionality I might want later. They also offer a central place where I can put common code where many parts of my applications can immediately benefit.

The three points above sound good in theory, however I must admit, I have learned recently that in practice, many times arrays and object are simply easier and more appropriate for the following reasons:

  1. Fewer dependancies. With the sophistication of a language comes dependancies and with dependancies comes complexity. The more a language supports customization and extensibility, the more powerful the language becomes in many ways, but also the complex your projects can become. My advice would be keep your simple apps simple. If you don’t need a more complex data type, there’s no reason to use it.
  2. They aren’t serializable. I learned this the hard way. I am working on an app which requires persistence through shared objects, so I created all kinds of data models to make the API more intuitive and easier to use. It was all working great until it actually become time to save the data, and I realized that all the functions were being stripped out of my objects. I experimented with “casting” the objects back into their original data types (using something like Object.registerClass, but smarter), but as far as I know, there’s no really good way to do it (with custom data types that have references to other custom data types — it gets ugly). I re-factored my code so that it now uses arrays and objects, and it works great.

What’s the bottom line? Use what works best for you, and use what’s most appropriate. For as logical and methodical as programming is, there are surprisingly few absolutes.

One Response to Maps for Flash (part II)

  1. This is a great blog