I looked at this early on, and decided that since Object>>name is defined in terns of #printString, there couldn't be anything terribly important happening with the result, because #printSring is not under the system's control. I have freely added name as an instance variable in many classes.
Process>>name and #name: are interesting. I didn't do the hash part, but I advocated for adding the name aspect to Process, and was very much surprised to see it adopted. This was in the days when most requests for changes prompted a reply something like "Do you realize that YOU can do that to YOUR image?" - emphasis added, but it was always clearly present. However, it has apparently been there since 2002. If there were going to be problems, I think we would have seen them by now :) That of course does nothing to fix the real problem, but I think it does provide evidence that one can safely ignore Object>>name. Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Stéphane Ducasse [[email protected]] Sent: Saturday, August 13, 2011 9:39 AM To: [email protected] Subject: Re: [Pharo-project] #name On Aug 12, 2011, at 5:35 PM, Sean P. DeNigris wrote: > How is #name used by the system? I often want to use it in my classes, but I > don't want to mess with whatever Object is doing with it. There are +++ > senders. Yes name is object is quite a bad smell to me. This is on my radar to nule setname: and friends. Since this is only used to give name to part in etoyish morphic If I remember also pay attention for class methods too. > On the flip side, should the system use a different, more specific, > intention-revealing selector to avoid this confusion? > > Thanks. > Sean > > -- > View this message in context: > http://forum.world.st/name-tp3739677p3739677.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
