Let's make Nautilus menu longer with a full class template ! -1, Honestly
Shortening the default class description is also painfull when you port code, because it makes the class appear different (description with and without pool dictionaries) in the change sorter. I wrote a pac change reader to port SmaCC from Dolphin to Pharo, and, really, this kind of change makes that unusable. In short, make that change correctly: at the Nautilus level. It's a GUI issue, not a language issue. Just go your average GUI approach : a wizard for creating classes, with at least ten "Next" to go through for each class creation ;) As an aside: I suspect there are others low-levels Smalltalk langage features that we feel engaged to change or hack them because they appear straight through the GUI, instead of being mapped to whatever flavor of the day in the GUI. A list of recent changes which do belong to that: The all protocol. A special AST node type for #subclass:instanceVariables:... Some of RPackage features and requests (which, I think, have the nice side effect of making RPackage harder to implement) Thierry ________________________________________ De : Pharo-dev [[email protected]] de la part de Pharo4Stef [[email protected]] Date d'envoi : vendredi 31 janvier 2014 20:50 À : Pharo Development List Objet : Re: [Pharo-dev] poolDictionaries removal breaks my projects >> Hi Torsten, >> >> I think it is a design decision / tradeoff, and therefore there is no >> fundamentally "right way" to do it. For me, it is the same case as the uses: >> message for Traits. It's not in the template by default because it is used >> very infrequently. So for language simplicity it should not be there. For >> me, simplicity is one of the core points of Smalltalk so this is why I feel >> strongly about it. > > I don’t see how this change make Smalltalk (the language) simpler. For me > this change looks more like an obfuscation than a simplification. How many lectures did you give? It is annoying to have to explain something that usually people do not need to know. >> When I say "very infrequently", this is of course a fuzzy metric, I know. >> And I understand that you do not agree with this design decision. >> >> But on the other hand, I don't think that it is too hard to remember where >> to add the pooldictionaries: line if you need it, and the old message with >> this line still works, so all old examples still work. > > How should newcomers know how to enter pool dictionaries? I rarely use pool > dictionaries and if I will need it I surely have forgotten about > this change and expect irritation and frustration. Newcomers do not use pooldictionaries. In 10 years smalltalking I used them twice. > > So, a -1 for this change from my side. We just need a full class template menu item.
