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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, August 13, 2011 9:39 AM To: Pharo-project@lists.gforge.inria.fr 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.