Removing name from Object

Hi guys

I would love to see name removed from Object. It brings more problems
than anything else.
Any taker?

Stef

> On 01 Sep 2015, at 21:44, stepharo <[hidden email]> wrote:
>
> Hi guys
>
> I would love to see name removed from Object. It brings more problems than anything else.
> Any taker?
>
> Stef

I tried it in the past. I just tried again on the latest #50297.

I did put a 'self haltOnce' in Object>>#name and with 'Halt enableHaltOnce' I can still browse and run all Zinc-Tests so we might be closer than we thought.

In any case, almost any code that needs Object>>#name could probably we rewritten to send #printString (being lazy).

Sven

Le 01/09/2015 21:44, stepharo a écrit :
> Hi guys
>
> I would love to see name removed from Object. It brings more problems
> than anything else.
> Any taker?
>
> Stef
>


That would be cool ! Sometimes I really needed a method "name" and that
was really boring to have to think again and again to find another name
for the method…

--
Cheers
Cyril

On 9/1/15, stepharo <[hidden email]> wrote:
> Hi guys
>
> I would love to see name removed from Object. It brings more problems
> than anything else.
> Any taker?
>
> Stef
>
>



Hi Stef

About

Object>>
name
        "Answer a name for the receiver.  This is used generically in the
title of certain inspectors, such as the referred-to inspector, and
specificially by various subsystems.  By default, we let the object
just print itself out..  "

        ^ self printString


Are you refering to this

http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.user/21476?

Which other kinds of problems do you see with this method?

Could you elaborate a bit please why you want to remove Object>>name?

Regards

Hannes

Good idea I will try when I have a moment to relax.
I'm in a little focused hacking sprint then admin sprint :)

Le 1/9/15 22:02, Sven Van Caekenberghe a écrit :

> On 02 Sep 2015, at 10:21, Guillermo Polito <[hidden email]> wrote:
>
> The problem is if (like in the past) name is extensively used by some library we depend upon (like... let's say morphic), a deprecation that raises an exception may turn the system unusable. It's not that it is not doable, but we should do it gently and with love.

You mean

(Object>>#name) removeFromSystem

;-)

but if we deprecate, that means we need to remove it from the system. 

Hannes Hirzel wrote

Which other kinds of problems do you see with this method?
Could you elaborate a bit please why you want to remove Object>>name?

Off the top of my head, in the worst case implementing #name on the class-side can be fatal. Less seriously one can get confusing result if e.g. you create a #name instVar and expect something to fail because you haven't created the getter yet, but instead it surprises you by using the unkown default implementation. At minimum, it creates confusion by using an overly generic name deep in the system. There should be as few reserved words like #class as possible, and only with very good reason, as it makes the system harder to understand.

For more info, see:
http://forum.world.st/name-tt3739677.html
http://forum.world.st/name-selector-tt4760402.html

EstebanLM wrote

deprecate it like any other method change or removal? (And then remove it in Pharo 6)

+1
that’s the way to do it :)

+1. I'm glad we're finally getting around to this :)

I am reviving the following (old) case:

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

I will add some more comments there.

Sven

> The problem is if (like in the past) name is extensively used by some
> library we depend upon (like... let's say morphic), a deprecation that
> raises an exception may turn the system unusable. It's not that it is
> not doable, but we should do it gently and with love.

The devil is in the details... they say.

Yes we know but first we should just make sure that the system is still working without this $#%^^&*^(&)*%^& method.

but if we deprecate, that means we need to remove it from the system. 

deprecated is for external users, not for Pharo it self. 

Esteban

ps: We *can not* remove #name from the system just like that. It is too widely use, we need to give users time to adapt. Doing otherwise is not professional and expect a lot of people yelling (and with reason, in this case). 

On 02 Sep 2015, at 10:21, Guillermo Polito <[hidden email]> wrote:

The problem is if (like in the past) name is extensively used by some library we depend upon (like... let's say morphic), a deprecation that raises an exception may turn the system unusable. It's not that it is not doable, but we should do it gently and with love. 

El mié., 2 de sept. de 2015 a la(s) 9:30 a. m., Esteban Lorenzano <[hidden email]> escribió:

On 02 Sep 2015, at 09:25, Peter Uhnák <[hidden email]> wrote:

On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <[hidden email]> wrote:

How can we find out, which external projects depend on this?

Is #name in any way special? Why not just deprecate it like any other method change or removal? (And then remove it in Pharo 6)

+1

that’s the way to do it :)

Peter

yes but first name out :)

Off the top of my head, in the worst case implementing #name on the
class-side can be fatal.

TBH using generic names (for both variables and methods) on class side is like running through a mine field.
I blew up my image more than once.

From UX perspective the system should warn the user if he is trying to override some system method or variable, but that is perhaps issue of its own.

Peter