Smalltalk › Pharo › Pharo Smalltalk Developers

Woe unto thee who assigns to class-side #name!

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

Sean P. DeNigris

Woe unto thee who assigns to class-side #name!

Administrator

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

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

Thierry Goubier

Re: Woe unto thee who assigns to class-side #name!

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-Breaks-System
>
> 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.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>
>

Ben Coman

Re: Woe unto thee who assigns to class-side #name!

In reply to this post by Sean P. DeNigris

On Sun, Nov 8, 2015 at 1:21 AM, Sean P. DeNigris <[hidden email]> wrote:

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

Sean P. DeNigris

Re: Woe unto thee who assigns to class-side #name!

Administrator

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

Thierry Goubier

Re: Woe unto thee who assigns to class-side #name!

2015-11-09 13:05 GMT+01:00 Sean P. DeNigris <[hidden email]>:

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

Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sean P. DeNigris

Re: Woe unto thee who assigns to class-side #name!

Administrator

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

Marcus Denker-4

Re: Woe unto thee who assigns to class-side #name!

In reply to this post by Thierry Goubier

On 09 Nov 2015, at 09:29, Thierry Goubier <[hidden email]> wrote:

2015-11-09 13:05 GMT+01:00 Sean P. DeNigris <[hidden email]>:
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

Thierry Goubier

Re: Woe unto thee who assigns to class-side #name!

In reply to this post by Sean P. DeNigris

2015-11-09 13:37 GMT+01:00 Sean P. DeNigris <[hidden email]>:

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

Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Ben Coman

Re: Woe unto thee who assigns to class-side #name!

On Mon, Nov 9, 2015 at 8:59 PM, Thierry Goubier
<[hidden email]> wrote:

>
>
> 2015-11-09 13:37 GMT+01:00 Sean P. DeNigris <[hidden email]>:
>>
>> 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-FlexibleObjectLayouts.pdf

cheers -ben

stepharo

Re: Woe unto thee who assigns to class-side #name!

In reply to this post by Sean P. DeNigris

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-tp4859734p4859900.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>
>

gcotelli

Re: Woe unto thee who assigns to class-side #name!

Yes please!! . I hate Object>>#name. Let me know if you need help.

On Nov 9, 2015 15:22, "stepharo" <[hidden email]> 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-tp4859734p4859900.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

stepharo

Re: Woe unto thee who assigns to class-side #name!

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" <[hidden email]> 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-tp4859734p4859900.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.