[chuck-users] implementing a set (was object / class hacking)

[Michael Heuer]

Robert Poor wrote:

> To clarify: I'd like to implement a set for storing a collection of
> homogenous objects.  Specifically, I need to be able to test for the
> presence of an object in the set, add an object to the set (if not already
> present), delete a object from the set, and iterate over all the objects in
> the set.  This last requirements, sadly, eliminates Chuck's "associative
> arrays".
>
> It's worth pointing out that:
>
>        arbitraryobject.toString()
>
> will generate a string of the form "ClassName:hexLocation".  Assuming that
> Chuck NEVER (ever) relocates a live object in memory (Chuck has a reference
> counting GC, not a copying GC, true?), that string could be useful as a
> unique ID.  But Chuck lacks the string operations to reduce a string into a
> hash key.
>
> So what I'll probably end up doing is to create a unique ID for each of my
> objects (either via toString() or some other construction-time device), and
> keeping the objects sorted in an array using the ID for a binary search
> function.  It's not as fast as a hashmap, but it's faster than linear
> search.

ChucK desperately needs int hashCode() and Object (or Class)
getClass() made available on its top-level Object.  Any takers?

I'm willing to write java-style HashMap, ArraySet, and HashSet classes
in LiCK, if you are ok with that style.  There would be first class
iterators and inner iterator methods (e.g. forEach) similar to the
List and ArrayList classes.

   michael