Page 1 of 1

Situations for heterogeneous containers

Posted: Mon Sep 21, 2015 3:19 pm
by Pixel_Outlaw
One thing that seems to be popular among some programmers is that "you're doing it wrong" if you even think about heterogeneous collections.
However I often find use for them.

I think a lot of the opposition comes from languages that are statically typed and provide no clean way to check for user defined types.
Heck, look at the CLOS we get a type predicate for our user defined classes so it can be very safe to allow unlike things to be stored together.

Now one use case I've found is making a queue of unlike functions that need to be delayed and executed at a later time.
It is quite handy to just shove them all in a container and execute them later when needed.
You can think of this as something akin to behavior scripting. (Imagine how easily you can give a video game object unique actions with a list of actions and execution tick time)

Another use case I've done is storing GUI elements easily.
Instead of having to subclass each GUI element through a long tree of polymorphism, you may simply store all items on a menu container in the same container and update them all at once. The active widget is simply an index value you work on. A menu of different widgets that cycles with a single index value is very powerful. You can still use polymorphism to get the behavior you need from parent widget classes but your are not FORCING polymorphism to trick them into fitting into the same menu.

A third case is when you want to write a function that may evolve at runtime.
In a user interaction system where routines are built, it is especially helpful to be able to change the order and types of functions called while maintaining the toplevel function name.
I can see some AI systems that use machine learning being able to rewrite their functions closer and closer to the goal all while editing and storing a function under the same name.

A lot of languages seem to be grown from big pieces fit together at a high level so complexity arises from that while leaving gaps between the big chunks. Lisp was grown from the simple CONS cell and lambda and I think you get a flexible clean language from that as a natural side effect (even if it is hell to implement that abstraction from a low level language). You get high level flexibility because the most basic of the pieces themselves started as flexible. You can see this as CONS cells as building blocks for lists rather than a "list of Int" etc.

Pardon the rant.
I'm just a bit tired of the ghastly looks I keep getting for liking the flexibility of Lisp's/Scheme's lists.
I think heterogeneous containers are great, as long as we the programmers carefully document our code.

What do you use heterogeneous containers for? ;)