[Pharo-dev] Changing class template

Dimitris Chloupis kilon.alios at gmail.com
Mon Nov 9 08:07:20 EST 2015


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 <thierry.goubier at gmail.com>
wrote:

> 2015-11-09 9:47 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk at me.com>:
>
>>
>> On 09 Nov 2015, at 06:50, Thierry Goubier <thierry.goubier at gmail.com>
>> wrote:
>>
>> Le 09/11/2015 01:33, Yuriy Tymchuk a écrit :
>>
>>
>> On 08 Nov 2015, at 20:14, Thierry Goubier
>> <thierry.goubier at gmail.com> 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
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20151109/e2bc6383/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 19834 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20151109/e2bc6383/attachment.png>


More information about the Pharo-dev mailing list