Re: dependency info

["ian (i.r.) woollard" <wolfe@bnr.ca>]

I ran up self to have a look around. I noticed a few things that would
affect it as a scheme...

I took list as an example. It has: traits list, collection, ordered
clonable, ordering, lobby, globals, default behaviour as parents
objects.

If you choose groups at random that would make 4-7 of the groups full
already (you might choose to be smarter than that, by putting the
parents of lobby in the same group...) Still you are looking at
7/32*15 seconds ~ 3 seconds with a naive implementation.

Hey, here's an idea. If you add a second, differently randomised 32
bit tag bit field and you say that the method must match both, then
the number of likely overlaps goes down in a square law, so if you
have 1/4 filled to start with then you get 1/16 with two 1/64 with 3
etc.

A problem with the idea as a whole is that a method doesn't only
search self, it also searches other object's parent hierarchy... If
the method references 4 other objects most of the groups will fill
up. Might not be a killing problem, you need to find out how often
this kind of thing happens. Most sends *are* to self, it *might* not
matter.

One other thing that you might consider is baseing tagging on the
senders of slot names instead. Like the object dependency scheme, it
will work most of the time, but might run slowly for some popular
slots like 'add:'. Still, the object dependency scheme runs slowly for
globals... When adding a parent slot, at worst you may have to
recompile everything.

Disclaimer: I don't *really* understand this stuff... ;-) Chris
Chambers idea of baseing it on message lookup dependencies looks the
best idea to me...