methodDict versus methodDictionary
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 So I do not get it and personally I would not deprecate methodDictionary and I would remove methodDict because it sucks! In the same bad style instSize or instSpec looks like the guy was lazy to type instanceSize and instanceSpec So let me know because I want to understand the story behind methodDict the ugly. Stef
On 14 Dec 2013, at 22:13, Stéphane Ducasse <stephane.ducasse@inria.fr> 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
On 15 Dec 2013, at 09:32, Marcus Denker <marcus.denker@inria.fr> wrote:
On 14 Dec 2013, at 22:13, Stéphane Ducasse <stephane.ducasse@inria.fr> 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!
I actually thought about that. I did not move to #methodDictionary because - a lot of Smalltalk code used methodDict. Historically, e..g Squeak did not even have #methods on Classes⦠because that method was needed for fileIn backward compatibility with some ancient file out format. If you look, people use it a lot. You will not change that. So if we move the #methodDictionary, the system could use that in the 10 or so places where direct access is needed. But for externals, you would need to keep a non-deprecated #methodDict around (we can not remove it, no way). So therefore, just having #methodDict is better, I think. And then, itâs not that important. So going the way that take the least energy while being ok is the way to go here. (the only other alternative is to do nothing. Taking lots of pain just to have #methodDictionary instead of #methodDict⦠honestly, I think there are more important things to do) Marcus
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*!)
Ok excellent I did not know that.
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.
I disagree here. In that case we should start using vv jyv jvzxxx. We should put the method in a private category and we should add a comment.
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â¦).
Still I would rename it. Stef
participants (2)
-
Marcus Denker -
Stéphane Ducasse