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 <stepharo@free.fr> 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
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 <stepharo@free.fr> 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 <stepharo@free.fr> 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
How can we find out, which external projects depend on this? 2015-09-02 7:06 GMT+02:00 H. Hirzel <hannes.hirzel@gmail.com>:
On 9/1/15, stepharo <stepharo@free.fr> 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
On 02 Sep 2015, at 09:25, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> 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
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 < estebanlm@gmail.com> escribió:
On 02 Sep 2015, at 09:25, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <nicolaihess@web.de> 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
On 02 Sep 2015, at 10:21, Guillermo Polito <guillermopolito@gmail.com> 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 <estebanlm@gmail.com> escribió:
On 02 Sep 2015, at 09:25, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <nicolaihess@web.de> 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
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 <guillermopolito@gmail.com> 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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> escribió:
On 02 Sep 2015, at 09:25, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> 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 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 <guillermopolito@gmail.com <mailto:guillermopolito@gmail.com>> 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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> escribió:
On 02 Sep 2015, at 09:25, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> 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
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.
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.
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 <sean@clipperadams.com> 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.
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 -- View this message in context: http://forum.world.st/Removing-name-from-Object-tp4847514p4847640.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
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
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
participants (9)
-
Esteban Lorenzano -
Ferlicot D. Cyril -
Guillermo Polito -
H. Hirzel -
Nicolai Hess -
Peter Uhnák -
Sean P. DeNigris -
stepharo -
Sven Van Caekenberghe