Removing name from Object

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing name from Object

stepharo
Hi guys

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

Stef

Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

Sven Van Caekenberghe-2

> 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


Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

CyrilFerlicot
In reply to this post by stepharo
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


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

Hannes Hirzel
In reply to this post by stepharo
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

Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

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

2015-09-02 7:06 GMT+02:00 H. Hirzel <[hidden email]>:
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


Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

stepharo
In reply to this post by Sven Van Caekenberghe-2
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 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
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

Peter Uhnak
In reply to this post by Nicolai Hess
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)

Peter
Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

EstebanLM

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

Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

Guillermo Polito
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

Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

Sven Van Caekenberghe-2

> 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

;-)

> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

EstebanLM
In reply to this post by Guillermo Polito
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


Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

Sean P. DeNigris
Administrator
In reply to this post by Hannes Hirzel
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

Sean P. DeNigris
Administrator
In reply to this post by EstebanLM
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 :)
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

Peter Uhnak
In reply to this post by Sean P. DeNigris
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

Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

Sven Van Caekenberghe-2
In reply to this post by Sean P. DeNigris
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

> On 02 Sep 2015, at 13:53, Sean P. DeNigris <[hidden email]> wrote:
>
> 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 :)
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Removing-name-from-Object-tp4847514p4847641.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

stepharo
In reply to this post by Guillermo Polito

> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

stepharo
In reply to this post by EstebanLM
Yes we know but first we should just make sure that the system is still working without this $#%^^&*^(&)*%^& method.

Le 2/9/15 10:29, Esteban Lorenzano a écrit :
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



Reply | Threaded
Open this post in threaded view
|

Re: Removing name from Object

stepharo
In reply to this post by Peter Uhnak
yes but first name out :)

Le 2/9/15 14:08, Peter Uhnák a écrit :
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