max why not subclassing OrderedCollections?
I’ve written an implementation of lazily initialized expandable collections (for
OrderedCollection and subclasses only for now), inspired by Alexandre’s talk at
ESUG
(http://www.youtube.com/watch?v=x0YJ2dsZdKg&list=UUO-vBhaKVZf0al-ISMMPvRw). The
implementation is pretty much straight forward
you initialize to nil first?
but there are a couple of culprits I want to point out in case anybody else
wants to do this:
- my implementation requires an extra instance variable in OrderedCollection to
store the requested size. This extra instance variable will break Monticello
(and possibly other tools) because Monticello uses OrderedCollections to load
code and the particular way it uses them makes it impossible to change the
number of instance variables on OrderedCollection. Also, all .mcz files written
after the change will not be loadable by images without the new instance
variable (same reason).
- the above means that you have to modify the code in the image manually and save a
new “base image"
- read only messages should obviously not initialize the array. The
‘firstIndex’ and ‘lastIndex’ variables are quite handy for that. I initialize
those variables to 1 and 0 respectively which makes most things work already
(e.g. #size, #isEmpty etc.).
- when trying to implement the same for HashedCollection I couldn’t. The image
didn’t just stop working, there was no output at all on the console, not even
when using a debug VM. The problem seems to be MethodDictionary, at least
that’s the only subclass of Dictionary for which adding an instance variable
doesn’t work.
I’ll share some memory monitoring as soon as I have something significant (only
just rolled it out).
Big thanks to Alex for his talk and the cool work he and his students did!
Cheers,
Max
