Woe unto thee who assigns to class-side #name!
Issue 16947: Class-side Inst Var "#name" Allowed, But Breaks System https://pharo.fogbugz.com/f/cases/16947/Class-side-Inst-Var-name-Allowed-But... If you like adventure, try the following: class := Object subclass: #MyClass instanceVariableNames: '' classVariableNames: '' category: 'MyBug'. class class compile: 'break name := 1'. class break. MyClass browse "Emergency evaluator :/" To restore the system: class instVarNamed: #name put: #MyClass. Now here's the kicker - there doesn't seem to a class-side instVarNamed: #name! It's not defined in Object or ProtoObject. NB. Also a bug in Pharo 4.0 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp4859734... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Le 07/11/2015 18:21, Sean P. DeNigris a écrit :
Issue 16947: Class-side Inst Var "#name" Allowed, But Breaks System https://pharo.fogbugz.com/f/cases/16947/Class-side-Inst-Var-name-Allowed-But...
If you like adventure, try the following: class := Object subclass: #MyClass instanceVariableNames: '' classVariableNames: '' category: 'MyBug'. class class compile: 'break name := 1'. class break. MyClass browse
"Emergency evaluator :/"
To restore the system: class instVarNamed: #name put: #MyClass.
Now here's the kicker - there doesn't seem to a class-side instVarNamed: #name! It's not defined in Object or ProtoObject.
When I try that, I can avoid the emergency evaluator if I try to browse with an already opened system browser -> I get a red window instead with a Metaclass>>#name problem. Thierry
NB. Also a bug in Pharo 4.0
----- Cheers, Sean -- View this message in context: http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp4859734... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Sun, Nov 8, 2015 at 1:21 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Issue 16947: Class-side Inst Var "#name" Allowed, But Breaks System https://pharo.fogbugz.com/f/cases/16947/Class-side-Inst-Var-name-Allowed-But...
If you like adventure, try the following: class := Object subclass: #MyClass instanceVariableNames: '' classVariableNames: '' category: 'MyBug'. class class compile: 'break name := 1'. class break. MyClass browse
"Emergency evaluator :/"
To restore the system: class instVarNamed: #name put: #MyClass.
Now here's the kicker - there doesn't seem to a class-side instVarNamed: #name! It's not defined in Object or ProtoObject.
NB. Also a bug in Pharo 4.0
But Class has an instance variable 'name', and Class subclasses --> {ProtoObject class} Following on from past discussions about making the generic 'name' identifier available to applications, should that instance variable and accessors be renamed to 'classname' ? I don't know at all whether that would be a good idea, I just raise the question. cheers -ben
Ben Coman wrote
But Class has an instance variable 'name', and Class subclasses --> {ProtoObject class}
He he, of course. Thanks for the clarification! Ben Coman wrote
should that instance variable and accessors be renamed to 'classname'?
YES to a rename! Let's remove all mysterious gotchas for newbies (and me ha ha). This is an obscure and scary bug, because it prevents all operations on the package, so one can not even commit or file out the package. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp4859734... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2015-11-09 13:05 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
Ben Coman wrote
But Class has an instance variable 'name', and Class subclasses --> {ProtoObject class}
He he, of course. Thanks for the clarification!
Ben Coman wrote
should that instance variable and accessors be renamed to 'classname'?
YES to a rename! Let's remove all mysterious gotchas for newbies (and me ha ha). This is an obscure and scary bug, because it prevents all operations on the package, so one can not even commit or file out the package.
Are you sure it would eliminate the gotcha? Can't you trigger it again with self classname: 1? I'd feel a bit safer with some defensive programming (an assert: in class>>#name?). And I like the elegance of AClass name. Thierry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp4859734... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Thierry Goubier wrote
Are you sure it would eliminate the gotcha? Can't you trigger it again with self classname: 1?
By "gotcha" I mean specifically doing something that seems normal that unknowningly breaks the system, added by the extra pain in this case that you might not find out until much later and not be able to connect the cause. If someone sends #classname:, or even assigns to #classname, they deserve a broken system ;) Thierry Goubier wrote
I like the elegance of AClass name.
Yes it's nice, but IMHO as a tremendous price. This is a constant pain point for newbies. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp4859734... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2015-11-09 13:37 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
Thierry Goubier wrote
Are you sure it would eliminate the gotcha? Can't you trigger it again with self classname: 1?
By "gotcha" I mean specifically doing something that seems normal that unknowningly breaks the system, added by the extra pain in this case that you might not find out until much later and not be able to connect the cause.
If someone sends #classname:, or even assigns to #classname, they deserve a broken system ;)
Thierry Goubier wrote
I like the elegance of AClass name.
Yes it's nice, but IMHO as a tremendous price. This is a constant pain point for newbies.
Come on; just an assert: aString isString in #name: would certainly stop the student doing any harm. We're talking of classes here, that is well predefined entities with a large API that one should not override... Now, about name in Object... Thierry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp4859734... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Mon, Nov 9, 2015 at 8:59 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-11-09 13:37 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
Thierry Goubier wrote
Are you sure it would eliminate the gotcha? Can't you trigger it again with self classname: 1?
By "gotcha" I mean specifically doing something that seems normal that unknowningly breaks the system, added by the extra pain in this case that you might not find out until much later and not be able to connect the cause.
If someone sends #classname:, or even assigns to #classname, they deserve a broken system ;)
Thierry Goubier wrote
I like the elegance of AClass name.
Yes it's nice, but IMHO as a tremendous price. This is a constant pain point for newbies.
Come on; just an assert: aString isString in #name: would certainly stop the student doing any harm.
The fix was given as...
To restore the system: class instVarNamed: #name put: #MyClass.
So should the assert be isSymbol? or are symbol/string interchangeable in this context? Also, before restoring the system... (Smalltalk at: #MyClass) name --> 1 so do we want to ensure the Smalltalk collection is synchronised? Perhaps this is a slots use case for a First Class Relationship [1] ? [1] https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayout... cheers -ben
On 09 Nov 2015, at 09:29, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-11-09 13:05 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>: Ben Coman wrote
But Class has an instance variable 'name', and Class subclasses --> {ProtoObject class}
He he, of course. Thanks for the clarification!
Ben Coman wrote
should that instance variable and accessors be renamed to 'classname'?
YES to a rename! Let's remove all mysterious gotchas for newbies (and me ha ha). This is an obscure and scary bug, because it prevents all operations on the package, so one can not even commit or file out the package.
Are you sure it would eliminate the gotcha? Can't you trigger it again with self classname: 1?
I'd feel a bit safer with some defensive programming (an assert: in class>>#name?). And I like the elegance of AClass name.
Yes, I feel the same. We should check for these cases but we should not make the APIs horrible. Marcus
I would start to remove for real name from Object :) Stef Le 9/11/15 13:05, Sean P. DeNigris a écrit :
Ben Coman wrote
But Class has an instance variable 'name', and Class subclasses --> {ProtoObject class} He he, of course. Thanks for the clarification!
Ben Coman wrote
should that instance variable and accessors be renamed to 'classname'? YES to a rename! Let's remove all mysterious gotchas for newbies (and me ha ha). This is an obscure and scary bug, because it prevents all operations on the package, so one can not even commit or file out the package.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp4859734... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Yes please!! . I hate Object>>#name. Let me know if you need help. On Nov 9, 2015 15:22, "stepharo" <stepharo@free.fr> wrote:
I would start to remove for real name from Object :)
Stef
Le 9/11/15 13:05, Sean P. DeNigris a écrit :
Ben Coman wrote
But Class has an instance variable 'name', and Class subclasses --> {ProtoObject class}
He he, of course. Thanks for the clarification!
Ben Coman wrote
should that instance variable and accessors be renamed to 'classname'?
YES to a rename! Let's remove all mysterious gotchas for newbies (and me ha ha). This is an obscure and scary bug, because it prevents all operations on the package, so one can not even commit or file out the package.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp4859734... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi gabriel Le 9/11/15 20:22, Gabriel Cotelli a écrit :
Yes please!! . I hate Object>>#name. Let me know if you need help.
Me too :) Guille sharpened his axe :) Stef
On Nov 9, 2015 15:22, "stepharo" <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
I would start to remove for real name from Object :)
Stef
Le 9/11/15 13:05, Sean P. DeNigris a écrit :
Ben Coman wrote
But Class has an instance variable 'name', and Class subclasses --> {ProtoObject class}
He he, of course. Thanks for the clarification!
Ben Coman wrote
should that instance variable and accessors be renamed to 'classname'?
YES to a rename! Let's remove all mysterious gotchas for newbies (and me ha ha). This is an obscure and scary bug, because it prevents all operations on the package, so one can not even commit or file out the package.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp4859734... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (6)
-
Ben Coman -
Gabriel Cotelli -
Marcus Denker -
Sean P. DeNigris -
stepharo -
Thierry Goubier