2015-11-09 9:47 GMT+01:00 Yuriy Tymchuk <[email protected]>: > > 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. >
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: [image: Images intégrées 1] 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 > > >
