Ok, so now I repeated what Sven did some time ago, logging each time #name was accessed. As soon as I found some sender to #name, I removed it. Except from GT and versionner, as they are external projects that I could not add in my slice. So I prepared and committed a slice for issue 7241. This slice removes the method #name from object and fixes several senders. The ones that I did not fix are the following: ====== GT and Glamour ========= gtDisplaySummaryOn: aStream. self label isEmptyOrNil ifFalse: [ ^ aStream nextPutAll: self label ]. self description isEmptyOrNil ifFalse: [ ^ aStream nextPutAll: self description ]. aStream nextPutAll: self method name configurationBlockForProcessorsCreatedBy: aMethod ^ configurationBlocks at: aMethod name ifAbsent: [ self nullConfigurationBlock ] allowProcessorsFrom: aMethod configuredWith: aBlock self allowProcessorsFrom: aMethod. configurationBlocks at: aMethod name put: aBlock. portName ^self port name ====== Versionner ======= remove "search if I am present in other groups and remove myself from these groups, then remove myself from project dependencies" (self project groups select: [ :aGroup | aGroup dependencies includes: name ]) do: [ :aGroup | aGroup removeDependency: name]. self project dependencies: (self project dependencies reject: [ :dep | dep = self]). self project announcer announce: (MTProjectModelChanged project: self) MBGroupInfo>>name ^ self spec name Guille

On 10 nov 2015, at 4:05 p.m., stepharo <stepharo@free.fr> wrote:

Thanks you both. I love your attitude :)

Stef

Le 10/11/15 11:35, Sven Van Caekenberghe a écrit :

...

Hi Guillermo et al,

...

On 10 Nov 2015, at 11:31, Guillermo Polito <guillermopolito@gmail.com> wrote:

Hey,

I was following the discussion about Class>>#name and Object>>#name so I checked what happened if I removed #name from Object.

1) The system did not blew up. I could open a browser and a test runner.

2) I could use spotter, look for a class, dive in, look for methods… Same for the inspector.

3) I ran all the tests in the image. - I saw some failures in GT* and Glamour. I ran them in a new image and they are not failing so maybe they are broken because of the change or some side effect of the tests? - Then I saw some failures of OpenToolTest and MBGroupInfoTest that *do look related*

4) I created a Package and it worked

5) I tried to create a class and it exploded with RBBrowserEnvironment DNU #includesKey:. This however explodes also in a clean image so I do not think it is related.

6) I could however create new methods...

Of course integrating such a little change is still scary :). But I can propose a slice… Votes in favor? :)

Guille Some months ago I did some more experiments, like you, please see this old thread (at the end):

https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed

I am certainly willing to help.

Sven

On 10 Nov 2015, at 17:41, Guillermo Polito <guillermopolito@gmail.com> wrote:

Ok, so now I repeated what Sven did some time ago, logging each time #name was accessed. As soon as I found some sender to #name, I removed it. Except from GT and versionner, as they are external projects that I could not add in my slice.

So I prepared and committed a slice for issue 7241. This slice removes the method #name from object and fixes several senders.

I can't find your slice in 5.0's inbox. What is its exact name ?

The ones that I did not fix are the following:

====== GT and Glamour =========

gtDisplaySummaryOn: aStream. self label isEmptyOrNil ifFalse: [ ^ aStream nextPutAll: self label ]. self description isEmptyOrNil ifFalse: [ ^ aStream nextPutAll: self description ]. aStream nextPutAll: self method name

configurationBlockForProcessorsCreatedBy: aMethod

^ configurationBlocks at: aMethod name ifAbsent: [ self nullConfigurationBlock ]

allowProcessorsFrom: aMethod configuredWith: aBlock

self allowProcessorsFrom: aMethod. configurationBlocks at: aMethod name put: aBlock.

portName

^self port name

====== Versionner =======

remove "search if I am present in other groups and remove myself from these groups, then remove myself from project dependencies" (self project groups select: [ :aGroup | aGroup dependencies includes: name ]) do: [ :aGroup | aGroup removeDependency: name]. self project dependencies: (self project dependencies reject: [ :dep | dep = self]). self project announcer announce: (MTProjectModelChanged project: self)

MBGroupInfo>>name ^ self spec name

Guille

...

On 10 nov 2015, at 4:05 p.m., stepharo <stepharo@free.fr> wrote:

Thanks you both. I love your attitude :)

Stef

Le 10/11/15 11:35, Sven Van Caekenberghe a écrit :

...

Hi Guillermo et al,

...

On 10 Nov 2015, at 11:31, Guillermo Polito <guillermopolito@gmail.com> wrote:

Hey,

I was following the discussion about Class>>#name and Object>>#name so I checked what happened if I removed #name from Object.

1) The system did not blew up. I could open a browser and a test runner.

2) I could use spotter, look for a class, dive in, look for methods… Same for the inspector.

3) I ran all the tests in the image. - I saw some failures in GT* and Glamour. I ran them in a new image and they are not failing so maybe they are broken because of the change or some side effect of the tests? - Then I saw some failures of OpenToolTest and MBGroupInfoTest that *do look related*

4) I created a Package and it worked

5) I tried to create a class and it exploded with RBBrowserEnvironment DNU #includesKey:. This however explodes also in a clean image so I do not think it is related.

6) I could however create new methods...

Of course integrating such a little change is still scary :). But I can propose a slice… Votes in favor? :)

Guille Some months ago I did some more experiments, like you, please see this old thread (at the end):

https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed

I am certainly willing to help.

Sven