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