My colleagues probably think of me as the "ivar nazi." If I can find a way to reduce instance variable count, I won't hesitate. I chuckled when I saw a class in a 3rd party package with a lot of instance variables yesterday. I was curious. How many did it really have? And what other treasures lay hidden in the image?
So I threw together this workspace snippent:
((Class rootsOfTheWorld collect: #withAllSubclasses) fold: [:a :b | a, b]) groupedBy: [:each | each instVarNames size]
Just one line. Pretty cool I think. This snippet groups classes by their own inst var account. It does not take inheritance into account. To get that, you just replace instVarNames with allInstVarNames. In truth, it didn't make much difference for what I was looking for. Here's the top 10 I found:
instVarNames size
Class(es)
21
Glorp.StoreReplicator, DataSetColumnSpec
22
RasterOp, GraphicsContext, PostScriptFile
23
MemoryPolicy, Store.PublishPundleDialog
25
DataSetView
26
ScarcityTrackingModel
29
JPEGImageWriter
38
CodeWriter
58
Code Reader
62
ObjectMemory
72
InverseColorMapInitializer
Some I expected. For example, I knew ObjectMemory was big, but not THAT big. InverseColorMapInitializer blew me away. 72 instance variables. Whoah. We even managed to get one of our own classes (ScarcityTrackingModel is not something you'll find in your image) in there.
So... how's your code do? Can anyone else get anything in this range (21 ivars+)? Were you surprised?
Previous Topic
