This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: A Timely Collection
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
This was supposed to be out Wednesday, but I had to put some time in on my attic fan project.
How Blogging Improved My Work
I get to do "trending" widgets often. For these, you have to accrue data and associate it with the time it was gathered. And there's usually some amount of time, after which the data is no longer relevant. For example, a real time Stock graph would really like this kind of data model. Whether done in the widget or as a domain model, the problem is still pretty much the same. In these cases, I end up writing an addData: method. I've implemented this a number of different ways, two parallel collections of the data and timestamps, a single collection with associations, a single collection with Points, a collection of TimestampedValue objects. And after the meat of the addData: method, there's always some sort of "trim" method, which expires old elements that are outside.
Today (actually Yesterday now) I was concocting another such widget, replete with the addData: method and all the instance variables that go along with it, and my mind casting about for what kind of new collection I should blog about next, said "ya know, this is really stupid. I should've made a collection out of this pattern a long time ago, I guess I need to blog to do my job right."
Timeline
I'm not sure if it's the best name, but that's what I called it for now. I won't blog all the code as I have with some of the others. It's pretty mundane stuff. I decided to just package it up (along with my failed Treap attempt and the GenericDictionary) and put it in the Open Repository: ExtraCollections (original name, huh?).
Basically, Timeline is a collection object that has a duration in seconds (you can create one via either 'Timeline duration: someSeconds' or 'Timeline new duration: someSeconds'). You can add: objects to a timeline; as you add them, it keeps track of when it was added. The keys of the collection are the microsecond times of the adds. So you can do all of the normal key related methods (e.g. keysAndValuesDo:, keys, etc). The timeline is self managed as far as element expiry goes. Every access is always relative to the current time. Elements that were added longer than the duration ago or automatically removed.
Some Interesting Implementation Details
One of the properties of the Timeline, is that it always appears to be "trimmed". As I thought about the wealth of collection api's, this seemed daunting. I worried I would have to override a significant amount of methods which were basically implemented as 'self trim. super doTheAPI'. Such turned out not to be the case.
After a bit of collection class hierarchy exploration, I decided that KeyedCollection was the super for Timeline. It turns out that KeyedCollection derives a significant amount of behavior from keysAndValuesDo:. So I overrode that and put the trim hook in there. Once you've done keysAndValuesDo:, you get do:, anySatisfy:, allSatisfy: asWhatever, keys, keysDo:, values:, ad-many. You even get size for free (though, I chose to actually override it for a quicker implementation)!
One tricky party was the *ect: messages. collect:/select:/detect: all create a new collection of the same type, and then use add: to put the new/filtered elements on the return value. For Timeline, this is a problem, because time keys go with the data. A collect: would return the transformed values, but all marked as occuring at the time of the collect:. So I had to do my own implementations of select: and collect:. IF the KeyedCollection implementations of select: and collect: were ANSI compliant, I would not have had to (OTOH, I would have to actually implement an at:put:).
Previous Topic
