Smalltalk › Pharo › Pharo Smalltalk Developers

Changing class template

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

stepharo

Changing class template

https://pharo.fogbugz.com/f/cases/16952/Change-class-template-creation

Stef

Hi guys

I think that not enough of us are teaching... we are so used to jump around
"DETAILS" that we do not have a clue how newcomers see our system.

For example I hate that I have to explain that we should enter a package name as argument of a category????

Object subclass: #NameOfSubclass
    instanceVariableNames: ’’
    classVariableNames: ’’
    category: ’PackageName’

I will change the template because I do not want to have to explain that
and that our Mooc refers to such crap. And you will have the right to complain but in that case
I will tell you: "give a lecture and come back to"

We are trapped in our way of thinking and we are trapped in the glitches of our system

We should not accept glitches and we should kill them.

Stef

Class and Method Definition Class and Method Definition

Thierry Goubier

Re: Changing class template

Stef,

I don't understand. I have never set a category in a class creation
template for the last three years.

When I teach using Pharo, I allways tell students to create a package,
select the package in the browser and add a class there.

Changing #category: for #package: (which is what the fix will be, I bet)
is useless.

Thierry

Le 08/11/2015 19:55, stepharo a écrit :

> https://pharo.fogbugz.com/f/cases/16952/Change-class-template-creation
>
> Stef
>
> Hi guys
>
> I think that not enough of us are teaching... we are so used to jump around
> "DETAILS" that we do not have a clue how newcomers see our system.
>
> For example I hate that I have to explain that we should enter a package
> name as argument of a category????
>
> Object subclass: #NameOfSubclass
> instanceVariableNames: ’’
> classVariableNames: ’’
> category: ’PackageName’
>
>
> I will change the template because I do not want to have to explain that
> and that our Mooc refers to such crap. And you will have the right to
> complain but in that case
> I will tell you: "give a lecture and come back to"
>
> We are trapped in our way of thinking and we are trapped in the glitches
> of our system
>
> We should not accept glitches and we should kill them.
>
> Stef

CyrilFerlicot

Re: Changing class template

Le 08/11/2015 20:14, Thierry Goubier a écrit :

I understand because when I explain a little Pharo to friends who only
learned Java, I like to explain the advantage to have everything as an
object and every action as a message. And one of the first message we
encounter is the class template. We can explain «We send this message to
"Object" and with this message we have arguments which are…». But when
it comes to the package we have to say «And for the category you pass
the package name and don't care about the "category" name» because this
is too much to explain the tags thing to beginners.

I think that what is easily visible should be very explicit, and more
advances feature should be in menu or things like that to help beginners.

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

signature.asc (836 bytes) Download Attachment

stepharo

Re: Changing class template

In reply to this post by Thierry Goubier

So this is good your super students will not have to worry and my super
stupid will be happy.

Le 8/11/15 20:14, Thierry Goubier a écrit :

> Stef,
>
> I don't understand. I have never set a category in a class creation
> template for the last three years.
>
> When I teach using Pharo, I allways tell students to create a package,
> select the package in the browser and add a class there.
>
> Changing #category: for #package: (which is what the fix will be, I
> bet) is useless.
>
> Thierry
>
> Le 08/11/2015 19:55, stepharo a écrit :
>> https://pharo.fogbugz.com/f/cases/16952/Change-class-template-creation
>>
>> Stef
>>
>> Hi guys
>>
>> I think that not enough of us are teaching... we are so used to jump
>> around
>> "DETAILS" that we do not have a clue how newcomers see our system.
>>
>> For example I hate that I have to explain that we should enter a package
>> name as argument of a category????
>>
>> Object subclass: #NameOfSubclass
>> instanceVariableNames: ’’
>> classVariableNames: ’’
>> category: ’PackageName’
>>
>>
>> I will change the template because I do not want to have to explain that
>> and that our Mooc refers to such crap. And you will have the right to
>> complain but in that case
>> I will tell you: "give a lecture and come back to"
>>
>> We are trapped in our way of thinking and we are trapped in the glitches
>> of our system
>>
>> We should not accept glitches and we should kill them.
>>
>> Stef
>
>
>
>

Thierry Goubier

Re: Changing class template

Le 08/11/2015 20:59, stepharo a écrit :
> So this is good your super students will not have to worry and my super
> stupid will be happy.

No, this is that you need to change deeper, no just complain about the
template, to help your and my students.

But it's good to see you notice :)

Thierry

Uko2

Re: Changing class template

In reply to this post by Thierry Goubier

> On 08 Nov 2015, at 20:14, Thierry Goubier <[hidden email]> wrote:
>
> Stef,
>
> I don't understand. I have never set a category in a class creation template for the last three years.
>
> When I teach using Pharo, I allways tell students to create a package, select the package in the browser and add a class there.
>
> Changing #category: for #package: (which is what the fix will be, I bet) is useless.

Because what written there is not a package, it’s a package + tag. So it would make sense to have

…
package: ‘PacakgeName’
tag: ’TagName’

But what I’d really enjoy is to have a dedicated UI there. Because we really use class templates as templates. 90% of a time I just change the Superclass, Class and instance variables. And 9% more I also add a tag to the package. So why we cannot have a UI with text fields for this values? Later it can be fancier e.g. classVariables are hidden by default and can be expanded on demand or if the are defined (I don’t like explaining class vars to people and I don’t like them from design point of view). Then also superclass field can have autocompletion only from the defined classes prioritizing the ones from the same package. Instance variables can be converted to slots really fast by lookup, etc…

I mean, it’s nice that we can subclass by sending a message, but we don’t develop methods in a template like:

compile: ‘methodCode’ classified: ‘protocolName’

So maybe we make use of special UI for classes instead of plain code.

Uko

>
> Thierry
>
> Le 08/11/2015 19:55, stepharo a écrit :
>> https://pharo.fogbugz.com/f/cases/16952/Change-class-template-creation
>>
>> Stef
>>
>> Hi guys
>>
>> I think that not enough of us are teaching... we are so used to jump around
>> "DETAILS" that we do not have a clue how newcomers see our system.
>>
>> For example I hate that I have to explain that we should enter a package
>> name as argument of a category????
>>
>> Object subclass: #NameOfSubclass
>> instanceVariableNames: ’’
>> classVariableNames: ’’
>> category: ’PackageName’
>>
>>
>> I will change the template because I do not want to have to explain that
>> and that our Mooc refers to such crap. And you will have the right to
>> complain but in that case
>> I will tell you: "give a lecture and come back to"
>>
>> We are trapped in our way of thinking and we are trapped in the glitches
>> of our system
>>
>> We should not accept glitches and we should kill them.
>>
>> Stef
>
>
>

Thierry Goubier

Re: Changing class template

Le 09/11/2015 01:33, Yuriy Tymchuk a écrit :

>
>> On 08 Nov 2015, at 20:14, Thierry Goubier
>> <[hidden email]> wrote:
>>
>> Stef,
>>
>> I don't understand. I have never set a category in a class creation
>> template for the last three years.
>>
>> When I teach using Pharo, I allways tell students to create a
>> package, select the package in the browser and add a class there.
>>
>> Changing #category: for #package: (which is what the fix will be, I
>> bet) is useless.
>
> Because what written there is not a package, it’s a package + tag. So
> it would make sense to have
>
> … package: ‘PacakgeName’ tag: ’TagName’

Trying to make it simpler for new students, I see :(

>
> But what I’d really enjoy is to have a dedicated UI there. Because we
> really use class templates as templates. 90% of a time I just change
> the Superclass, Class and instance variables.

As I said.

> And 9% more I also add
> a tag to the package.

What? You don't do a 'add a tag to a package' operation? You create tags
by side effect of a new class creation?

(Your numbers don't add up to 100%. What is the one percent left for
then? ;))

> So why we cannot have a UI with text fields for
> this values? Later it can be fancier e.g. classVariables are hidden
> by default and can be expanded on demand or if the are defined (I
> don’t like explaining class vars to people and I don’t like them from
> design point of view). Then also superclass field can have
> autocompletion only from the defined classes prioritizing the ones
> from the same package. Instance variables can be converted to slots
> really fast by lookup, etc…

Look, you're making even more complex everytime. But you're welcome to
try; such a GUI can be added, yes, especially behind the add Class menu
item instead of reusing the full template.

A wizard for class creation :)

Note that on current Nautilus, if you use add Class in the menu, opening
the menu will auto-select what is behind the mouse click. And the
template is prefilled, which makes it a bit more complex to create a new
clas on Object.

> I mean, it’s nice that we can subclass by sending a message, but we
> don’t develop methods in a template like:
>
> compile: ‘methodCode’ classified: ‘protocolName’

I do. When the browser is broken, it's sometime the only way left :) Or
editing Smalltalk code directly on github :)

> So maybe we make use of special UI for classes instead of plain
> code.

Note that with smart suggestions, you can have both in the same
apparently plain code.

But think of your usage, and also of the other usage: just beginner, new
student.

And the last one will show you that our toolset is geared towards the
power user. And this is not going to change anytime soon, to the contrary.

Thierry

Thierry Goubier

Re: Changing class template

In reply to this post by CyrilFerlicot

Le 08/11/2015 20:29, Ferlicot D. Cyril a écrit :

> Le 08/11/2015 20:14, Thierry Goubier a écrit :
>> Stef,
>>
>> I don't understand. I have never set a category in a class creation
>> template for the last three years.
>>
>> When I teach using Pharo, I allways tell students to create a package,
>> select the package in the browser and add a class there.
>>
>> Changing #category: for #package: (which is what the fix will be, I bet)
>> is useless.
>>
>> Thierry
>>
>>
>
> I understand because when I explain a little Pharo to friends who only
> learned Java, I like to explain the advantage to have everything as an
> object and every action as a message. And one of the first message we
> encounter is the class template. We can explain «We send this message to
> "Object" and with this message we have arguments which are…». But when
> it comes to the package we have to say «And for the category you pass
> the package name and don't care about the "category" name» because this
> is too much to explain the tags thing to beginners.

Which would mean the tags have added complexity in that regard.

> I think that what is easily visible should be very explicit, and more
> advances feature should be in menu or things like that to help beginners.

I'm not sure. Power users use the template directly (saves you one, two,
three mouse clicks and a few mouse mouvements) and I'd suggest using the
menu for beginners (you can direct them to the menu and they will
remember they are doing that 'action' of adding a class: a dialog
probably also helps them to focus on it and the questions they have to
answer when they are creating a class).

Thierry

Uko2

Re: Changing class template

In reply to this post by Thierry Goubier

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

Le 09/11/2015 01:33, Yuriy Tymchuk a écrit :

On 08 Nov 2015, at 20:14, Thierry Goubier
<[hidden email]> wrote:

Stef,

I don't understand. I have never set a category in a class creation
template for the last three years.

When I teach using Pharo, I allways tell students to create a
package, select the package in the browser and add a class there.

Changing #category: for #package: (which is what the fix will be, I
bet) is useless.

Because what written there is not a package, it’s a package + tag. So
it would make sense to have

… package: ‘PacakgeName’ tag: ’TagName’

Trying to make it simpler for new students, I see :(

Exactly, because you say: “each class has in a package and can have a tag, and here you can define that”. Otherwise you have to explain that category is actually a magical thing that splits into a package and a tag by following some rules.

But what I’d really enjoy is to have a dedicated UI there. Because we
really use class templates as templates. 90% of a time I just change
the Superclass, Class and instance variables.

As I said.

And 9% more I also add
a tag to the package.

What? You don't do a 'add a tag to a package' operation? You create tags by side effect of a new class creation?

Of course.

(Your numbers don't add up to 100%. What is the one percent left for then? ;))

I guess Traits.

So why we cannot have a UI with text fields for
this values? Later it can be fancier e.g. classVariables are hidden
by default and can be expanded on demand or if the are defined (I
don’t like explaining class vars to people and I don’t like them from
design point of view). Then also superclass field can have
autocompletion only from the defined classes prioritizing the ones
from the same package. Instance variables can be converted to slots
really fast by lookup, etc…

Look, you're making even more complex everytime. But you're welcome to try; such a GUI can be added, yes, especially behind the add Class menu item instead of reusing the full template.

A wizard for class creation :)

Note that on current Nautilus, if you use add Class in the menu, opening the menu will auto-select what is behind the mouse click. And the template is prefilled, which makes it a bit more complex to create a new clas on Object.

It’s not about creation, it’s about working with classes. #compile:classified: is not present in the method template because no one will never change it. Similarly I’ve never ever changed the `subclass:` keyword, so why should it be editable? I’ve never changed `instanceVariableNames:` keyword. Probably the only thing I’ve changed was adding `uses:` when working with traits. But again, why do I have to recall whether it’s called `uses:` or `using:` and type it between `subclass:` and `instanceVariableNames:`? Wy I cannot just press a button “use traits” and a field will appear where I have to specify traits.

I mean, it’s nice that we can subclass by sending a message, but we
don’t develop methods in a template like:

compile: ‘methodCode’ classified: ‘protocolName’

I do. When the browser is broken, it's sometime the only way left :) Or editing Smalltalk code directly on github :)

Yes, but you are not doing that in Nautilus, and there is probably a reason for that. Otherwise we can do an experiment: add #compile:classified: to the method editor and see if people like it.

So maybe we make use of special UI for classes instead of plain
code.

Note that with smart suggestions, you can have both in the same apparently plain code.

I didn’t get that one :(

But think of your usage, and also of the other usage: just beginner, new student.

I don’t know how the student thinks, but I’d prefer to have 4 input fields:

- superclass autocompleted with existing classes

- class name

- instance variables that will have visual separation for each var (eg: http://xoxco.com/projects/code/tagsinput/example.html)

- package that will be already entered as it is now (and maybe have some inactive style not to distract)

Uko

And the last one will show you that our toolset is geared towards the power user. And this is not going to change anytime soon, to the contrary.

Thierry

Peter Uhnak

Re: Changing class template

> Power users use the template directly (saves you one, two, three mouse clicks and a few mouse mouvements)

From student/beginner perspective I would argue that it is very valuable for them to see that creating class is just a regular message send and not some special syntax/magic. Adding UI would alienate them from this knowledge/revelation.

On Mon, Nov 9, 2015 at 9:47 AM, Yuriy Tymchuk <[hidden email]> wrote:

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

Le 09/11/2015 01:33, Yuriy Tymchuk a écrit :

On 08 Nov 2015, at 20:14, Thierry Goubier
<[hidden email]> wrote:

Stef,

I don't understand. I have never set a category in a class creation
template for the last three years.

When I teach using Pharo, I allways tell students to create a
package, select the package in the browser and add a class there.

Changing #category: for #package: (which is what the fix will be, I
bet) is useless.

Because what written there is not a package, it’s a package + tag. So
it would make sense to have

… package: ‘PacakgeName’ tag: ’TagName’

Trying to make it simpler for new students, I see :(

Exactly, because you say: “each class has in a package and can have a tag, and here you can define that”. Otherwise you have to explain that category is actually a magical thing that splits into a package and a tag by following some rules.

But what I’d really enjoy is to have a dedicated UI there. Because we
really use class templates as templates. 90% of a time I just change
the Superclass, Class and instance variables.

As I said.

And 9% more I also add
a tag to the package.

What? You don't do a 'add a tag to a package' operation? You create tags by side effect of a new class creation?

Of course.

(Your numbers don't add up to 100%. What is the one percent left for then? ;))

I guess Traits.

So why we cannot have a UI with text fields for
this values? Later it can be fancier e.g. classVariables are hidden
by default and can be expanded on demand or if the are defined (I
don’t like explaining class vars to people and I don’t like them from
design point of view). Then also superclass field can have
autocompletion only from the defined classes prioritizing the ones
from the same package. Instance variables can be converted to slots
really fast by lookup, etc…

Look, you're making even more complex everytime. But you're welcome to try; such a GUI can be added, yes, especially behind the add Class menu item instead of reusing the full template.

A wizard for class creation :)

Note that on current Nautilus, if you use add Class in the menu, opening the menu will auto-select what is behind the mouse click. And the template is prefilled, which makes it a bit more complex to create a new clas on Object.

It’s not about creation, it’s about working with classes. #compile:classified: is not present in the method template because no one will never change it. Similarly I’ve never ever changed the `subclass:` keyword, so why should it be editable? I’ve never changed `instanceVariableNames:` keyword. Probably the only thing I’ve changed was adding `uses:` when working with traits. But again, why do I have to recall whether it’s called `uses:` or `using:` and type it between `subclass:` and `instanceVariableNames:`? Wy I cannot just press a button “use traits” and a field will appear where I have to specify traits.

I mean, it’s nice that we can subclass by sending a message, but we
don’t develop methods in a template like:

compile: ‘methodCode’ classified: ‘protocolName’

I do. When the browser is broken, it's sometime the only way left :) Or editing Smalltalk code directly on github :)

Yes, but you are not doing that in Nautilus, and there is probably a reason for that. Otherwise we can do an experiment: add #compile:classified: to the method editor and see if people like it.

So maybe we make use of special UI for classes instead of plain
code.

Note that with smart suggestions, you can have both in the same apparently plain code.

I didn’t get that one :(

But think of your usage, and also of the other usage: just beginner, new student.

I don’t know how the student thinks, but I’d prefer to have 4 input fields:

- superclass autocompleted with existing classes
- class name
- instance variables that will have visual separation for each var (eg: http://xoxco.com/projects/code/tagsinput/example.html)
- package that will be already entered as it is now (and maybe have some inactive style not to distract)

Uko

And the last one will show you that our toolset is geared towards the power user. And this is not going to change anytime soon, to the contrary.

Thierry

Uko2

Re: Changing class template

Ok, maybe for students it’s bad, but for myself I’d like something like that :)

Uko

On 09 Nov 2015, at 10:06, Peter Uhnák <[hidden email]> wrote:

> Power users use the template directly (saves you one, two, three mouse clicks and a few mouse mouvements)

+1

From student/beginner perspective I would argue that it is very valuable for them to see that creating class is just a regular message send and not some special syntax/magic. Adding UI would alienate them from this knowledge/revelation.

On Mon, Nov 9, 2015 at 9:47 AM, Yuriy Tymchuk <[hidden email]> wrote:

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

Le 09/11/2015 01:33, Yuriy Tymchuk a écrit :

On 08 Nov 2015, at 20:14, Thierry Goubier
<[hidden email]> wrote:

Stef,

I don't understand. I have never set a category in a class creation
template for the last three years.

When I teach using Pharo, I allways tell students to create a
package, select the package in the browser and add a class there.

Changing #category: for #package: (which is what the fix will be, I
bet) is useless.

Because what written there is not a package, it’s a package + tag. So
it would make sense to have

… package: ‘PacakgeName’ tag: ’TagName’

Trying to make it simpler for new students, I see :(

Exactly, because you say: “each class has in a package and can have a tag, and here you can define that”. Otherwise you have to explain that category is actually a magical thing that splits into a package and a tag by following some rules.

But what I’d really enjoy is to have a dedicated UI there. Because we
really use class templates as templates. 90% of a time I just change
the Superclass, Class and instance variables.

As I said.

And 9% more I also add
a tag to the package.

What? You don't do a 'add a tag to a package' operation? You create tags by side effect of a new class creation?

Of course.

(Your numbers don't add up to 100%. What is the one percent left for then? ;))

I guess Traits.

So why we cannot have a UI with text fields for
this values? Later it can be fancier e.g. classVariables are hidden
by default and can be expanded on demand or if the are defined (I
don’t like explaining class vars to people and I don’t like them from
design point of view). Then also superclass field can have
autocompletion only from the defined classes prioritizing the ones
from the same package. Instance variables can be converted to slots
really fast by lookup, etc…

Look, you're making even more complex everytime. But you're welcome to try; such a GUI can be added, yes, especially behind the add Class menu item instead of reusing the full template.

A wizard for class creation :)

Note that on current Nautilus, if you use add Class in the menu, opening the menu will auto-select what is behind the mouse click. And the template is prefilled, which makes it a bit more complex to create a new clas on Object.

It’s not about creation, it’s about working with classes. #compile:classified: is not present in the method template because no one will never change it. Similarly I’ve never ever changed the `subclass:` keyword, so why should it be editable? I’ve never changed `instanceVariableNames:` keyword. Probably the only thing I’ve changed was adding `uses:` when working with traits. But again, why do I have to recall whether it’s called `uses:` or `using:` and type it between `subclass:` and `instanceVariableNames:`? Wy I cannot just press a button “use traits” and a field will appear where I have to specify traits.

I mean, it’s nice that we can subclass by sending a message, but we
don’t develop methods in a template like:

compile: ‘methodCode’ classified: ‘protocolName’

I do. When the browser is broken, it's sometime the only way left :) Or editing Smalltalk code directly on github :)

Yes, but you are not doing that in Nautilus, and there is probably a reason for that. Otherwise we can do an experiment: add #compile:classified: to the method editor and see if people like it.

So maybe we make use of special UI for classes instead of plain
code.

Note that with smart suggestions, you can have both in the same apparently plain code.

I didn’t get that one :(

But think of your usage, and also of the other usage: just beginner, new student.

I don’t know how the student thinks, but I’d prefer to have 4 input fields:

- superclass autocompleted with existing classes
- class name
- instance variables that will have visual separation for each var (eg: http://xoxco.com/projects/code/tagsinput/example.html)
- package that will be already entered as it is now (and maybe have some inactive style not to distract)

Uko

And the last one will show you that our toolset is geared towards the power user. And this is not going to change anytime soon, to the contrary.

Thierry

Thierry Goubier

Re: Changing class template

In reply to this post by Uko2

2015-11-09 9:47 GMT+01:00 Yuriy Tymchuk <[hidden email]>:

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

Le 09/11/2015 01:33, Yuriy Tymchuk a écrit :

On 08 Nov 2015, at 20:14, Thierry Goubier
<[hidden email]> wrote:

Stef,

I don't understand. I have never set a category in a class creation
template for the last three years.

When I teach using Pharo, I allways tell students to create a
package, select the package in the browser and add a class there.

Changing #category: for #package: (which is what the fix will be, I
bet) is useless.

Because what written there is not a package, it’s a package + tag. So
it would make sense to have

… package: ‘PacakgeName’ tag: ’TagName’

Trying to make it simpler for new students, I see :(

Exactly, because you say: “each class has in a package and can have a tag, and here you can define that”. Otherwise you have to explain that category is actually a magical thing that splits into a package and a tag by following some rules.

You'd better explain it that way given how it is implemented now.

I don't think the package + tags choice improved anything there compared to package + sets of packages, especially regarding categories (we could have a one to one relation between category and package, which would be way simpler to explain).

And now we need a higher abstraction than packages, the one represented for now by 'a group of packages loaded by a configuration or a baseline'.

I'd say 'missed opportunity'. Now, I'd say no to any RPackage redesign, so we'll have to live with it and repatch the rest of the system (and the documentation).

But what I’d really enjoy is to have a dedicated UI there. Because we
really use class templates as templates. 90% of a time I just change
the Superclass, Class and instance variables.

As I said.

And 9% more I also add
a tag to the package.

What? You don't do a 'add a tag to a package' operation? You create tags by side effect of a new class creation?

Of course.

Then, if you consider what you're asking for, I won't agree with it :) It clearly shows your IDE is defficient there.

(Your numbers don't add up to 100%. What is the one percent left for then? ;))

I guess Traits.

So why we cannot have a UI with text fields for
this values? Later it can be fancier e.g. classVariables are hidden
by default and can be expanded on demand or if the are defined (I
don’t like explaining class vars to people and I don’t like them from
design point of view). Then also superclass field can have
autocompletion only from the defined classes prioritizing the ones
from the same package. Instance variables can be converted to slots
really fast by lookup, etc…

Look, you're making even more complex everytime. But you're welcome to try; such a GUI can be added, yes, especially behind the add Class menu item instead of reusing the full template.

A wizard for class creation :)

Note that on current Nautilus, if you use add Class in the menu, opening the menu will auto-select what is behind the mouse click. And the template is prefilled, which makes it a bit more complex to create a new clas on Object.

It’s not about creation, it’s about working with classes. #compile:classified: is not present in the method template because no one will never change it. Similarly I’ve never ever changed the `subclass:` keyword, so why should it be editable? I’ve never changed `instanceVariableNames:` keyword. Probably the only thing I’ve changed was adding `uses:` when working with traits. But again, why do I have to recall whether it’s called `uses:` or `using:` and type it between `subclass:` and `instanceVariableNames:`? Wy I cannot just press a button “use traits” and a field will appear where I have to specify traits.

Now, why not? As I said, write a wizard behind the addClass.

Like that, it's out of the way if we don't want to use it :)

I mean, it’s nice that we can subclass by sending a message, but we
don’t develop methods in a template like:

compile: ‘methodCode’ classified: ‘protocolName’

I do. When the browser is broken, it's sometime the only way left :) Or editing Smalltalk code directly on github :)

Yes, but you are not doing that in Nautilus, and there is probably a reason for that. Otherwise we can do an experiment: add #compile:classified: to the method editor and see if people like it.

So maybe we make use of special UI for classes instead of plain
code.

Note that with smart suggestions, you can have both in the same apparently plain code.

I didn’t get that one :(

Well, take for example:

SmaCCCodeGenerator subclass: #SmaCCSmalltalkCodeGenerator

instanceVariableNames: 'isExpressions parseTreeCache category splitIndex'

classVariableNames: 'MaxJumpSize'

poolDictionaries: ''

category: 'SmaCC-Development'

If you right click on parseTreeCache, you can get as menu items:

Look: intelligent GUI, text template ;)

But think of your usage, and also of the other usage: just beginner, new student.

I don’t know how the student thinks, but I’d prefer to have 4 input fields:

- superclass autocompleted with existing classes
- class name
- instance variables that will have visual separation for each var (eg: http://xoxco.com/projects/code/tagsinput/example.html)
- package that will be already entered as it is now (and maybe have some inactive style not to distract)

But you loose the message, as Peter pointed out.

Mind you, those ideas in a class creation dialog, fine.

Thierry

Uko

And the last one will show you that our toolset is geared towards the power user. And this is not going to change anytime soon, to the contrary.

Thierry

kilon.alios

Re: Changing class template

Well from my side I must say that as a power user, (after 2 years of coding in pharo I no longer consider myself a pharo begineer) I find the class template ugly, very impractical and quite pharo and smalltalk unfriendly. After I release ChronosManager my next tool will be Cyclops a gui tool that will unite workspace , system browser , debugger , inspector and spotter under one GUI front end. Obviously its a long term project but will offer a radically diffirent workflow from the one that pharo currently offers including an alternate to the class templates amongsts many other ideas I currently have .

I agree that IDE tools can be used on a need/want to use basis , so it may be better to keep the template as it is since so many people seem to like it and just offer alternative approaches that one can install and unistall on choice easily.

There is no one ring to rule them all. Each person thinks and work differently and a great IDE must accommodate such flexibility.

On Mon, Nov 9, 2015 at 11:36 AM Thierry Goubier <[hidden email]> wrote:

2015-11-09 9:47 GMT+01:00 Yuriy Tymchuk <[hidden email]>:

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

Le 09/11/2015 01:33, Yuriy Tymchuk a écrit :

On 08 Nov 2015, at 20:14, Thierry Goubier
<[hidden email]> wrote:

Stef,

I don't understand. I have never set a category in a class creation
template for the last three years.

When I teach using Pharo, I allways tell students to create a
package, select the package in the browser and add a class there.

Changing #category: for #package: (which is what the fix will be, I
bet) is useless.

Because what written there is not a package, it’s a package + tag. So
it would make sense to have

… package: ‘PacakgeName’ tag: ’TagName’

Trying to make it simpler for new students, I see :(

Exactly, because you say: “each class has in a package and can have a tag, and here you can define that”. Otherwise you have to explain that category is actually a magical thing that splits into a package and a tag by following some rules.

You'd better explain it that way given how it is implemented now.

I don't think the package + tags choice improved anything there compared to package + sets of packages, especially regarding categories (we could have a one to one relation between category and package, which would be way simpler to explain).

And now we need a higher abstraction than packages, the one represented for now by 'a group of packages loaded by a configuration or a baseline'.

I'd say 'missed opportunity'. Now, I'd say no to any RPackage redesign, so we'll have to live with it and repatch the rest of the system (and the documentation).

But what I’d really enjoy is to have a dedicated UI there. Because we
really use class templates as templates. 90% of a time I just change
the Superclass, Class and instance variables.

As I said.

And 9% more I also add
a tag to the package.

What? You don't do a 'add a tag to a package' operation? You create tags by side effect of a new class creation?

Of course.

Then, if you consider what you're asking for, I won't agree with it :) It clearly shows your IDE is defficient there.

(Your numbers don't add up to 100%. What is the one percent left for then? ;))

I guess Traits.

:)

So why we cannot have a UI with text fields for
this values? Later it can be fancier e.g. classVariables are hidden
by default and can be expanded on demand or if the are defined (I
don’t like explaining class vars to people and I don’t like them from
design point of view). Then also superclass field can have
autocompletion only from the defined classes prioritizing the ones
from the same package. Instance variables can be converted to slots
really fast by lookup, etc…

Look, you're making even more complex everytime. But you're welcome to try; such a GUI can be added, yes, especially behind the add Class menu item instead of reusing the full template.

A wizard for class creation :)

Note that on current Nautilus, if you use add Class in the menu, opening the menu will auto-select what is behind the mouse click. And the template is prefilled, which makes it a bit more complex to create a new clas on Object.

It’s not about creation, it’s about working with classes. #compile:classified: is not present in the method template because no one will never change it. Similarly I’ve never ever changed the `subclass:` keyword, so why should it be editable? I’ve never changed `instanceVariableNames:` keyword. Probably the only thing I’ve changed was adding `uses:` when working with traits. But again, why do I have to recall whether it’s called `uses:` or `using:` and type it between `subclass:` and `instanceVariableNames:`? Wy I cannot just press a button “use traits” and a field will appear where I have to specify traits.

Now, why not? As I said, write a wizard behind the addClass.

Like that, it's out of the way if we don't want to use it :)

I mean, it’s nice that we can subclass by sending a message, but we
don’t develop methods in a template like:

compile: ‘methodCode’ classified: ‘protocolName’

I do. When the browser is broken, it's sometime the only way left :) Or editing Smalltalk code directly on github :)

Yes, but you are not doing that in Nautilus, and there is probably a reason for that. Otherwise we can do an experiment: add #compile:classified: to the method editor and see if people like it.

So maybe we make use of special UI for classes instead of plain
code.

Note that with smart suggestions, you can have both in the same apparently plain code.

I didn’t get that one :(

Well, take for example:

SmaCCCodeGenerator subclass: #SmaCCSmalltalkCodeGenerator
instanceVariableNames: 'isExpressions parseTreeCache category splitIndex'
classVariableNames: 'MaxJumpSize'
poolDictionaries: ''
category: 'SmaCC-Development'

If you right click on parseTreeCache, you can get as menu items:

Look: intelligent GUI, text template ;)

But think of your usage, and also of the other usage: just beginner, new student.

I don’t know how the student thinks, but I’d prefer to have 4 input fields:

- superclass autocompleted with existing classes
- class name
- instance variables that will have visual separation for each var (eg: http://xoxco.com/projects/code/tagsinput/example.html)
- package that will be already entered as it is now (and maybe have some inactive style not to distract)

But you loose the message, as Peter pointed out.

Mind you, those ideas in a class creation dialog, fine.

Thierry

Uko

And the last one will show you that our toolset is geared towards the power user. And this is not going to change anytime soon, to the contrary.

Thierry

Ben Coman

Re: Changing class template

In reply to this post by Peter Uhnak

On Mon, Nov 9, 2015 at 5:06 PM, Peter Uhnák <[hidden email]> wrote:

>> Power users use the template directly (saves you one, two, three mouse
>> clicks and a few mouse mouvements)
>
> +1
>
> From student/beginner perspective I would argue that it is very valuable for
> them to see that creating class is just a regular message send and not some
> special syntax/magic. Adding UI would alienate them from this
> knowledge/revelation.
>

There is a lot of empty space around the current template.
It could easily fit a field based UI plus the text template next to it.
Typing in the UI could dynamically recreate the text template.
The template would remain the entity actually executed to create the class
to demonstrate to newbies class creation is a regular message send.

The UI could categorise the template parts as basic/advanced to
scaffold for newbies,
and power users can just bypass the UI to edit the template directly.

cheers -ben

> On Mon, Nov 9, 2015 at 9:47 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>
>>
>> On 09 Nov 2015, at 06:50, Thierry Goubier <[hidden email]>
>> wrote:
>>
>> Le 09/11/2015 01:33, Yuriy Tymchuk a écrit :
>>
>>
>> On 08 Nov 2015, at 20:14, Thierry Goubier
>> <[hidden email]> wrote:
>>
>> Stef,
>>
>> I don't understand. I have never set a category in a class creation
>> template for the last three years.
>>
>> When I teach using Pharo, I allways tell students to create a
>> package, select the package in the browser and add a class there.
>>
>> Changing #category: for #package: (which is what the fix will be, I
>> bet) is useless.
>>
>>
>> Because what written there is not a package, it’s a package + tag. So
>> it would make sense to have
>>
>> … package: ‘PacakgeName’ tag: ’TagName’
>>
>>
>> Trying to make it simpler for new students, I see :(
>>
>>
>> Exactly, because you say: “each class has in a package and can have a tag,
>> and here you can define that”. Otherwise you have to explain that category
>> is actually a magical thing that splits into a package and a tag by
>> following some rules.
>>
>>
>>
>> But what I’d really enjoy is to have a dedicated UI there. Because we
>> really use class templates as templates. 90% of a time I just change
>> the Superclass, Class and instance variables.
>>
>>
>> As I said.
>>
>> And 9% more I also add
>> a tag to the package.
>>
>>
>> What? You don't do a 'add a tag to a package' operation? You create tags
>> by side effect of a new class creation?
>>
>>
>> Of course.
>>
>>
>> (Your numbers don't add up to 100%. What is the one percent left for then?
>> ;))
>>
>>
>> I guess Traits.
>>
>>
>> So why we cannot have a UI with text fields for
>> this values? Later it can be fancier e.g. classVariables are hidden
>> by default and can be expanded on demand or if the are defined (I
>> don’t like explaining class vars to people and I don’t like them from
>> design point of view). Then also superclass field can have
>> autocompletion only from the defined classes prioritizing the ones
>> from the same package. Instance variables can be converted to slots
>> really fast by lookup, etc…
>>
>>
>> Look, you're making even more complex everytime. But you're welcome to
>> try; such a GUI can be added, yes, especially behind the add Class menu item
>> instead of reusing the full template.
>>
>> A wizard for class creation :)
>>
>> Note that on current Nautilus, if you use add Class in the menu, opening
>> the menu will auto-select what is behind the mouse click. And the template
>> is prefilled, which makes it a bit more complex to create a new clas on
>> Object.
>>
>>
>> It’s not about creation, it’s about working with classes.
>> #compile:classified: is not present in the method template because no one
>> will never change it. Similarly I’ve never ever changed the `subclass:`
>> keyword, so why should it be editable? I’ve never changed
>> `instanceVariableNames:` keyword. Probably the only thing I’ve changed was
>> adding `uses:` when working with traits. But again, why do I have to recall
>> whether it’s called `uses:` or `using:` and type it between `subclass:` and
>> `instanceVariableNames:`? Wy I cannot just press a button “use traits” and a
>> field will appear where I have to specify traits.
>>
>>
>>
>> I mean, it’s nice that we can subclass by sending a message, but we
>> don’t develop methods in a template like:
>>
>> compile: ‘methodCode’ classified: ‘protocolName’
>>
>>
>> I do. When the browser is broken, it's sometime the only way left :) Or
>> editing Smalltalk code directly on github :)
>>
>>
>> Yes, but you are not doing that in Nautilus, and there is probably a
>> reason for that. Otherwise we can do an experiment: add #compile:classified:
>> to the method editor and see if people like it.
>>
>>
>> So maybe we make use of special UI for classes instead of plain
>> code.
>>
>>
>> Note that with smart suggestions, you can have both in the same apparently
>> plain code.
>>
>>
>> I didn’t get that one :(
>>
>>
>> But think of your usage, and also of the other usage: just beginner, new
>> student.
>>
>>
>> I don’t know how the student thinks, but I’d prefer to have 4 input
>> fields:
>>
>> - superclass autocompleted with existing classes
>> - class name
>> - instance variables that will have visual separation for each var (eg:
>> http://xoxco.com/projects/code/tagsinput/example.html)
>> - package that will be already entered as it is now (and maybe have some
>> inactive style not to distract)
>>
>> Uko
>>
>>
>> And the last one will show you that our toolset is geared towards the
>> power user. And this is not going to change anytime soon, to the contrary.
>>
>> Thierry
>>
>>
>