yes johan you are right again :)

Stef

>> OK, back to topic and to summarize: we now all fully understood that the 
>> original message 
>> including pools is still there, will not break code loading or other things 
>> and that the 
>> change is on the Nautilus level. 
> 
> Yes, thanks for understanding and summarizing well. 
> 
>> But still the simple question left to be anwered here: what will this change 
>> of reducing the 
>> class template in the default browser give us? What problem did it really 
>> solve?
>> 
>> The answer given so far is that it may be problematic when teaching because 
>> you want to
>> introduce to language features step by step. But you said yourself in your 
>> own post 
>> that 
>> 
>> <quote>
>>  It is BORING to have to say to kids:
>>      - do not care of classvar
>>      - do not care of pooldictionaries
>> </quote>
>> 
>> So my question: if you are bored of the "complexity" of BOTH (!) 
>> - why do we hide pools now 
>> - and leave class variables still left in the template? 
>> 
>> I really do not understand because with the change it now looks in 
>> Pharo3.0 Latest update: #30732 like this:
>> 
>>  Object subclass: #Foo
>>      instanceVariableNames: ''
>>      classVariableNames: ''
>>      category: 'Bar'
>> 
>> So why do we keep class vars then? According to your mail we would have to 
>> remove them too.
> 
> From my point of view this is a different design decision to take since it is 
> a different feature of the language. So it is not included in the change that 
> I proposed. And BTW I leave it to somebody else to make the call and propose 
> a change to Pharo that addresses this (or not, as may be the case).
> 
>> Additionally this change violates the intention of a template (which one 
>> usually just has to fill out) 
>> and one now has to remember the original full keyword and have to type it in 
>> again - which is IMHO 
>> really awkward and stupid. 
>> 
>> So with all respect: I still can not see the introduction of the reduced 
>> template as a step forward 
>>                   or an improvement. 
> 
> For me, this reduces to the case of Traits. A low usage (arguably), so uses: 
> is not present in the template. We do the same for pooldictionaries. If you 
> are against this, and say that you should just fill in the template, then 
> logically you should be against how Traits are handled. Following that logic, 
> you are advocating for:
> 
> Object subclass: #NameOfSubclass
>       uses: ''
>       instanceVariableNames: ''
>       classVariableNames: ''
>       poolDictionaries: ''
>       category: ''
> 
> Am I correct?
> 
> ---> Save our in-boxes! http://emailcharter.org <---
> 
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
> 
> 






Reply via email to