On 14 Dec 2013, at 22:13, Stéphane Ducasse <[email protected]> wrote:
> Hi
>
> I do not understand why we deprecate methodDictionary and not methodDict
> (What a really bad name)
> I hate this inconsistent and lame name like methodDict and
>
> Marcus you mention on the bug entry
>
> nobody should access methodDict directly
> -> so why have a "nice" accessor for something not to be used?
>
> but I have 103 send of methodDict in my image
>
Yes, I am slowly removing them, but that takes time (I removed quite a lot over
the last months! A *lot*!)
I even added a lint rule detecting calls to #methodDict.
> So I do not get it and personally I would not deprecate methodDictionary and
> I would remove
> methodDict because it sucks!
methodDict should *never* be used from the outside. It’s far too easy to get
problems because you modify the dictionary
without e.g. invalidating the VM cache or telling the system.
And it gets *much* easier to read:
methodDict values —> methods
methodDict keys —> selectors
methodDict size > 0 —> #hasMethods
and so on… it’s amazing how much more readable code gets.
So why do we provide a “nice” selector “methodDictionary” if this is a private
accessor for internal state?
If we do that it communicates “use me”! And you should not. If you want to use
it, you know what you are doing
and you know #methodDict.
And if people use it, the #methodDict is so deep in the brain of people that
they never used #methoDictionary
(there where maybe 5 senders…).
Marcus
