> 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 <[email protected]> wrote: > > On 09 Nov 2015, at 06:50, Thierry Goubier <[email protected]> > wrote: > > Le 09/11/2015 01:33, Yuriy Tymchuk a écrit : > > > On 08 Nov 2015, at 20:14, Thierry Goubier > <[email protected]> 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 > > >
