> 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
