Lowering the pain of newbies

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

Lowering the pain of newbies

Stephane Ducasse-3
Hi guys

my son coded in Pharo 60

testGuessUrlPart

      |dg8|
      dg8 := GameItem new;
                  name: 'Dragon Quest VIII : Journey Of The Cursed King';
                  console: 'PS2'.
       self assert: dg8 guessUrlPart equals:
'dragonquestviiijourneyofthecursedking'

and guess what he broke the system.

We should not accept such kind of behavior.
name: should not change the name of the class.

I do not know the solution but I fear when I will teach 160 students this fall.
We should make sure that Pharo is not a system only for experts!

any idea is welcome

https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-automatically-rename-and-destroy-the-class

Stef

Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

CyrilFerlicot

On jeu. 17 août 2017 at 21:53, Stephane Ducasse <[hidden email]> wrote:
Hi guys

my son coded in Pharo 60

testGuessUrlPart

      |dg8|
      dg8 := GameItem new;
                  name: 'Dragon Quest VIII : Journey Of The Cursed King';
                  console: 'PS2'.
       self assert: dg8 guessUrlPart equals:
'dragonquestviiijourneyofthecursedking'

and guess what he broke the system.

We should not accept such kind of behavior.
name: should not change the name of the class.

I do not know the solution but I fear when I will teach 160 students this fall.
We should make sure that Pharo is not a system only for experts!

any idea is welcome

https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-automatically-rename-and-destroy-the-class

Stef

Fast answer: 

Some month (year?) ago I proposed to get pre-compilation rules that could show warnings in interactive mode. 

Maybe this can be a path to dig. 

:)


--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Esteban A. Maringolo
In reply to this post by Stephane Ducasse-3
What are the odds?

The ability to break a system in a few steps seems to be an inherited trait.

My daughter (2 years old) was randomly punching my keyboard and caused
a segfault that I couldn't reproduce afterwards.

Regards!


Esteban A. Maringolo


2017-08-17 16:52 GMT-03:00 Stephane Ducasse <[hidden email]>:

> Hi guys
>
> my son coded in Pharo 60
>
> testGuessUrlPart
>
>       |dg8|
>       dg8 := GameItem new;
>                   name: 'Dragon Quest VIII : Journey Of The Cursed King';
>                   console: 'PS2'.
>        self assert: dg8 guessUrlPart equals:
> 'dragonquestviiijourneyofthecursedking'
>
> and guess what he broke the system.
>
> We should not accept such kind of behavior.
> name: should not change the name of the class.
>
> I do not know the solution but I fear when I will teach 160 students this fall.
> We should make sure that Pharo is not a system only for experts!
>
> any idea is welcome
>
> https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-automatically-rename-and-destroy-the-class
>
> Stef
>

Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Peter Uhnak
On Thu, Aug 17, 2017 at 05:23:28PM -0300, Esteban A. Maringolo wrote:
> What are the odds?

100%, this _always_ happens to some student. (You just need to omit a single semicolon and you've just broke it.)

Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Tim Mackinnon
In reply to this post by Stephane Ducasse-3
Is this a goal we can all share for 7.0?

Sort out the expert tools (like git etc), but equally enable that simplicity you expect for a child/newbie/expert...

I'm in!

Tim

Sent from my iPhone

> On 17 Aug 2017, at 20:52, Stephane Ducasse <[hidden email]> wrote:
>
> Hi guys
>
> my son coded in Pharo 60
>
> testGuessUrlPart
>
>      |dg8|
>      dg8 := GameItem new;
>                  name: 'Dragon Quest VIII : Journey Of The Cursed King';
>                  console: 'PS2'.
>       self assert: dg8 guessUrlPart equals:
> 'dragonquestviiijourneyofthecursedking'
>
> and guess what he broke the system.
>
> We should not accept such kind of behavior.
> name: should not change the name of the class.
>
> I do not know the solution but I fear when I will teach 160 students this fall.
> We should make sure that Pharo is not a system only for experts!
>
> any idea is welcome
>
> https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-automatically-rename-and-destroy-the-class
>
> Stef
>


Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Denis Kudriashov
Hi

I wrote proposal in issue

2017-08-18 0:52 GMT+02:00 Tim Mackinnon <[hidden email]>:
Is this a goal we can all share for 7.0?

Sort out the expert tools (like git etc), but equally enable that simplicity you expect for a child/newbie/expert...

I'm in!

Tim

Sent from my iPhone

> On 17 Aug 2017, at 20:52, Stephane Ducasse <[hidden email]> wrote:
>
> Hi guys
>
> my son coded in Pharo 60
>
> testGuessUrlPart
>
>      |dg8|
>      dg8 := GameItem new;
>                  name: 'Dragon Quest VIII : Journey Of The Cursed King';
>                  console: 'PS2'.
>       self assert: dg8 guessUrlPart equals:
> 'dragonquestviiijourneyofthecursedking'
>
> and guess what he broke the system.
>
> We should not accept such kind of behavior.
> name: should not change the name of the class.
>
> I do not know the solution but I fear when I will teach 160 students this fall.
> We should make sure that Pharo is not a system only for experts!
>
> any idea is welcome
>
> https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-automatically-rename-and-destroy-the-class
>
> Stef
>



Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Stephane Ducasse-3
I have the impression that we should rethink the meta interface of
classes and reflective calls.

On Fri, Aug 18, 2017 at 10:44 AM, Denis Kudriashov <[hidden email]> wrote:

> Hi
>
> I wrote proposal in issue
>
> 2017-08-18 0:52 GMT+02:00 Tim Mackinnon <[hidden email]>:
>>
>> Is this a goal we can all share for 7.0?
>>
>> Sort out the expert tools (like git etc), but equally enable that
>> simplicity you expect for a child/newbie/expert...
>>
>> I'm in!
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> > On 17 Aug 2017, at 20:52, Stephane Ducasse <[hidden email]>
>> > wrote:
>> >
>> > Hi guys
>> >
>> > my son coded in Pharo 60
>> >
>> > testGuessUrlPart
>> >
>> >      |dg8|
>> >      dg8 := GameItem new;
>> >                  name: 'Dragon Quest VIII : Journey Of The Cursed King';
>> >                  console: 'PS2'.
>> >       self assert: dg8 guessUrlPart equals:
>> > 'dragonquestviiijourneyofthecursedking'
>> >
>> > and guess what he broke the system.
>> >
>> > We should not accept such kind of behavior.
>> > name: should not change the name of the class.
>> >
>> > I do not know the solution but I fear when I will teach 160 students
>> > this fall.
>> > We should make sure that Pharo is not a system only for experts!
>> >
>> > any idea is welcome
>> >
>> >
>> > https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-automatically-rename-and-destroy-the-class
>> >
>> > Stef
>> >
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Sean P. DeNigris
Administrator
In reply to this post by Stephane Ducasse-3
Stephane Ducasse-3 wrote
any idea is welcome
From http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-td4859734.html :
    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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Nicolas Cellier
The irony is that there is no such bug in Squeak.
Class does not require such selector.
But it "inherits" it in Pharo because of Trait implementation (via TClass).

Why Trait itself requires #name: is another question...
IMO it does not.
If I replace the two local send in Trait by direct i.var. access in Squeak, then the TraitsTests-Kernel all pass...

Class has #setName:, though which is used in ClassBuilder, #obsolete and ImageSegment.
So the same problem exists if you replace name: by setName: but it's a bit less likely.

2017-08-19 23:19 GMT+02:00 Sean P. DeNigris <[hidden email]>:
Stephane Ducasse-3 wrote
> any idea is welcome

From
http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-td4859734.html
:
    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



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Lowering-the-pain-of-newbies-tp4961937p4962584.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Luke Gorrie
In reply to this post by Stephane Ducasse-3
On 17 August 2017 at 21:52, Stephane Ducasse <[hidden email]> wrote:
We should not accept such kind of behavior.
name: should not change the name of the class.

I had exactly such a problem a couple of weeks ago :).

I write MyClass on: foo; name: x; yourself'but I forgot the ^ return in MyClass class>>on: and so called name: on the class instead of the instance. Hilarity ensued :).


Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Stephane Ducasse-3
Thanks for all the information. In Pharo 70 Object does not understand
name so it will already be a step in the right direction.

I think that we should do two things.
- Address simply this problem for example using setName: or
setClassName: instead of name:
- start to prototype for a future a solution where the reflective
calls are clearly identified.

Stef

On Sun, Aug 20, 2017 at 11:19 AM, Luke Gorrie <[hidden email]> wrote:

> On 17 August 2017 at 21:52, Stephane Ducasse <[hidden email]>
> wrote:
>>
>> We should not accept such kind of behavior.
>> name: should not change the name of the class.
>
>
> I had exactly such a problem a couple of weeks ago :).
>
> I write MyClass on: foo; name: x; yourself'but I forgot the ^ return in
> MyClass class>>on: and so called name: on the class instead of the instance.
> Hilarity ensued :).
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Brad Selfridge
I vote for setClassName:

Brad Selfridge


> On Aug 20, 2017, at 5:30 AM, Stephane Ducasse <[hidden email]> wrote:
>
> Thanks for all the information. In Pharo 70 Object does not understand
> name so it will already be a step in the right direction.
>
> I think that we should do two things.
> - Address simply this problem for example using setName: or
> setClassName: instead of name:
> - start to prototype for a future a solution where the reflective
> calls are clearly identified.
>
> Stef
>
>> On Sun, Aug 20, 2017 at 11:19 AM, Luke Gorrie <[hidden email]> wrote:
>> On 17 August 2017 at 21:52, Stephane Ducasse <[hidden email]>
>> wrote:
>>>
>>> We should not accept such kind of behavior.
>>> name: should not change the name of the class.
>>
>>
>> I had exactly such a problem a couple of weeks ago :).
>>
>> I write MyClass on: foo; name: x; yourself'but I forgot the ^ return in
>> MyClass class>>on: and so called name: on the class instead of the instance.
>> Hilarity ensued :).
>>
>>
>

Brad Selfridge
Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Marcus Denker-4

> On 20 Aug 2017, at 23:48, Brad <[hidden email]> wrote:
>
> I vote for setClassName:
>

setName: is better because this is what is there since many many years… and by just using it
we must need to deprecate one method, not two.

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

kilon.alios
its inconsistent to start using (set) in front of the name of methods and unnecessary

className: 

makes more sense to me

Another way to do this instead have something like classMetaData which can be a dictionary containing all the data like name of the class, method dictionary etc this way we ensure that what happened with name does not happen with other methods too that may find themselves in a name conflict by an unaware user. 

Or we can provide both ways or something else. 

Class name has caused me pain too and I am no newbie , when I was making an API for Blender it clashed with the name of the 3d objects. So this is definitely not newbie orientated problem , its a fundamental problem.

I dont mind which solution you guys follow , afterall its easy to solve cause its easy to override any solution I don't like. The beauty of Smalltalk :) 

On Mon, Aug 21, 2017 at 11:05 AM Marcus Denker <[hidden email]> wrote:

> On 20 Aug 2017, at 23:48, Brad <[hidden email]> wrote:
>
> I vote for setClassName:
>

setName: is better because this is what is there since many many years… and by just using it
we must need to deprecate one method, not two.

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Esteban A. Maringolo
I avoid get/set prefixes in method selectors, however it is a "good
practice pattern" the use of the "set" prefix as a private accessor.

I use it to build initialized instances,

MyClass class>>#attribute: anObject
  ^self new setAttribute: aString

In some cases MyClass doesn't have the `#attribute:` setter because
it's not meant to be modified externally.

In the case of the `name` setter for a class, adding the `class`
prefix is redundant, so I think that `setName:` is the right selector
to use.

It's like the Clipboard class, that has the `clipboardText:` selector
instead of `text:` or something similar, but without the redundant
`clipboard` prefix.

But without diverting from the main topic, I think that the `name`
accessor is one of the things that causes a lot of trouble because of
unanticipated side effects. It indirectly becomes some sort of
"reserved word" of the language.

Also `name` is a common property in many domain objects, and creating
the accessors will create name:/name1 selectors, which is confusing
for newcomers as well, because they'd expect the #name getter instead
of #name1.

Regards,

Esteban A. Maringolo


2017-08-21 9:42 GMT-03:00 Dimitris Chloupis <[hidden email]>:

> its inconsistent to start using (set) in front of the name of methods and
> unnecessary
>
> className:
>
> makes more sense to me
>
> Another way to do this instead have something like classMetaData which can
> be a dictionary containing all the data like name of the class, method
> dictionary etc this way we ensure that what happened with name does not
> happen with other methods too that may find themselves in a name conflict by
> an unaware user.
>
> Or we can provide both ways or something else.
>
> Class name has caused me pain too and I am no newbie , when I was making an
> API for Blender it clashed with the name of the 3d objects. So this is
> definitely not newbie orientated problem , its a fundamental problem.
>
> I dont mind which solution you guys follow , afterall its easy to solve
> cause its easy to override any solution I don't like. The beauty of
> Smalltalk :)
>
> On Mon, Aug 21, 2017 at 11:05 AM Marcus Denker <[hidden email]>
> wrote:
>>
>>
>> > On 20 Aug 2017, at 23:48, Brad <[hidden email]> wrote:
>> >
>> > I vote for setClassName:
>> >
>>
>> setName: is better because this is what is there since many many years…
>> and by just using it
>> we must need to deprecate one method, not two.
>>
>>         Marcus

Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Peter Uhnak
I'd prefer to not use `setName:` nor `setClassName:` as `setX:`/`setX:Y:` is often used as a constructor initialization pattern (as per Kent Beck's Smalltalk book).

Using `className:` could be confusing, as it could be unclear whether you are changing the name of the class itself, or the name of the class of the class (the "Class class" class :)).
Maybe `changeNameTo:` to explicitly state the intent?

> It indirectly becomes some sort of "reserved word" of the language.

Class has many such methods (and I've destroyed my image many times before I subconsciously learned to avoid them), but only name tends to be problematic so introducing "special" methods for meta methods seems pointless, as a person doing metaprogramming would (must) take the care anyway to distinguish on which side they are working on.

Peter

On Mon, Aug 21, 2017 at 3:08 PM, Esteban A. Maringolo <[hidden email]> wrote:
I avoid get/set prefixes in method selectors, however it is a "good
practice pattern" the use of the "set" prefix as a private accessor.

I use it to build initialized instances,

MyClass class>>#attribute: anObject
  ^self new setAttribute: aString

In some cases MyClass doesn't have the `#attribute:` setter because
it's not meant to be modified externally.

In the case of the `name` setter for a class, adding the `class`
prefix is redundant, so I think that `setName:` is the right selector
to use.

It's like the Clipboard class, that has the `clipboardText:` selector
instead of `text:` or something similar, but without the redundant
`clipboard` prefix.

But without diverting from the main topic, I think that the `name`
accessor is one of the things that causes a lot of trouble because of
unanticipated side effects. It indirectly becomes some sort of
"reserved word" of the language.

Also `name` is a common property in many domain objects, and creating
the accessors will create name:/name1 selectors, which is confusing
for newcomers as well, because they'd expect the #name getter instead
of #name1.

Regards,

Esteban A. Maringolo


2017-08-21 9:42 GMT-03:00 Dimitris Chloupis <[hidden email]>:
> its inconsistent to start using (set) in front of the name of methods and
> unnecessary
>
> className:
>
> makes more sense to me
>
> Another way to do this instead have something like classMetaData which can
> be a dictionary containing all the data like name of the class, method
> dictionary etc this way we ensure that what happened with name does not
> happen with other methods too that may find themselves in a name conflict by
> an unaware user.
>
> Or we can provide both ways or something else.
>
> Class name has caused me pain too and I am no newbie , when I was making an
> API for Blender it clashed with the name of the 3d objects. So this is
> definitely not newbie orientated problem , its a fundamental problem.
>
> I dont mind which solution you guys follow , afterall its easy to solve
> cause its easy to override any solution I don't like. The beauty of
> Smalltalk :)
>
> On Mon, Aug 21, 2017 at 11:05 AM Marcus Denker <[hidden email]>
> wrote:
>>
>>
>> > On 20 Aug 2017, at 23:48, Brad <[hidden email]> wrote:
>> >
>> > I vote for setClassName:
>> >
>>
>> setName: is better because this is what is there since many many years…
>> and by just using it
>> we must need to deprecate one method, not two.
>>
>>         Marcus


Reply | Threaded
Open this post in threaded view
|

Re: Lowering the pain of newbies

Esteban A. Maringolo
2017-08-21 15:39 GMT-03:00 Peter Uhnák <[hidden email]>:
> I'd prefer to not use `setName:` nor `setClassName:` as `setX:`/`setX:Y:` is
> often used as a constructor initialization pattern (as per Kent Beck's
> Smalltalk book).

I use setX: with the same purpose, as per the same book recommendation.

But isn't #name: (or #setName:) in Class used in the context of
initialization only?

> Maybe `changeNameTo:` to explicitly state the intent?

Although I don't like the "change" prefix when it's a one way
operation, that selector is unambiguous as it gets.

>> It indirectly becomes some sort of "reserved word" of the language.
>
> Class has many such methods (and I've destroyed my image many times before I
> subconsciously learned to avoid them), but only name tends to be problematic
> so introducing "special" methods for meta methods seems pointless, as a
> person doing metaprogramming would (must) take the care anyway to
> distinguish on which side they are working on.

+1


Esteban A. Maringolo