On Tue, 11 Dec 2001, Henrik Gedenryd wrote:

> Scott A Crosby wrote:
>
> > I am subscribing to the motto: fix it once, fix it in the right place.
>
>
> In this case, I think it is "fix it at least twice, in all the right
> places". Consider
>
> Interpreter>>lookupMethodInDictionary: dictionary
> <rest snipped>
>
> One might think that 4096 is a helluva lotta methods for one class, but hey,
> any day now Morph will be there. I it was at 1007 methods and counting when

Agreed. You'd not want more than 2048-3072 method/class, at least looked
up in this fashion. I do not consider this a serious problem. First,
dictionaries with 3000 keys are a lot more likely to occur than classes
with 3000 methods.

Second, if there is some particular case where do genuinely want 3072
methods/class. (I can't really envision one, but...) If we don't expect to
these methods to be performance-critical, A valid workaround would be to
overload #doesNotUndstatand and use a better dictionary internally.

Third, fixing the problem on MethodDictionary would be far harder and
would require an incompatible image change. This is beyond my skill.

Yaw, it is the right fix, (Except in this case, we can use a smaller
prime. 17 would work nicely.) But its a lot harder to get into the system,
and very unlikely that we'd get any advantages.

I'd make a claim that if there's 3000 methods in one class, somone has
made a mistake. (As a corrolary, any class with 1000 methods probably
needs to be refactored.)


> I last checked, one of which is "makeAllTilesGreen". Now consider the
> corresponding ones for the other 700 hues that someone posted
> yesterday--surely they should be defined too. They would clearly be
> generally useful.

Wouldn't it be smarter to have: 'makeAllTilesColor: aColor'?

and have 'Color green' 'Color xxxx' to make all the other hues? Or, have:
   'Color fromName: aSymbol' which looks the colors up in a dictionary?

>
> Anyway, my point is that the algorithm to scan (Method)Dictionaries is built
> into the vm code, which needs to be considered when making changes.
>

Which is why I have not touched that code.

Scott



--
No DVD movie will ever enter the public domain, nor will any CD. The last CD
and the last DVD will have moldered away decades before they leave copyright.
This is not encouraging the creation of knowledge in the public domain.