Lowering the pain of newbies

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
>

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.

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