Begin forwarded message:
> From: Stéphane Ducasse <[email protected]> > Subject: Re: [Pharo-dev] poolDictionaries removal breaks my projects > Date: 2 Feb 2014 00:56:28 GMT+1 > To: Pharo Development List <[email protected]> > > >>>> +1 on this >>> >>> There are some kinds of students who are going to find Smalltalk difficult, >>> yes. I do not see how removing pooldictionaries from the class creation >>> template will affect them. If they ask about them, you can say that they >>> are there and point them to the new class creation message. And take >>> advantage of that to say that class creation is just a message send while >>> you are at it :-) >> >> If your students have problems to grasp the concept of pool dictionaries >> then how do they deal with mathematics and computer science? > > This is the proof that you never taught. I never got the time to arrive to > pool. Why would I teach them something that I used two times over the last 15 > years of programming (ok I just wrote moose and some parts of Pharo :). > > Why should I spend time on a detail when I can teach them real OO design? > Do you think that I attract people to Smalltalk teaching them about Pool? or > because I ask them why the way boolean is implemented is so mind-blowing? I > let you guess. Now during my last lectures (4.5 h in total this year). > One guy leo came after the lecture and told that he loves the way boolean are > implemented and that he wants to an internship with us. > > Is it enough or I should continue? > > > >>>>> „oldtimers“ need freedom. This is one of the reasons I really enjoy >>>>> dynamic typing and Smalltalk. I don’t like to obey to artificial rules >>>>> that only >>>>> put permanent burden to me in order to protect me from something I might >>>>> do wrong sometimes. >>> >>> You still have the freedom to use pool dictionaries. They are still there. >> They are hidden for the sake of simplicity for some students. >> I want my pool dictionaries back :-D > > Don’t use them you do not need them. > Why you cannot express the same with a class and a classvar + messages? > >>>>> >>>> >>>> If you don’t see features you don’t know what the machine can do for you. >>>> >>>> Obscuring things is sometimes a good design strategy, but here there is a >>>> well known artefact breaking tradition here, that isn’t something light. >>>> And the proposed alternative design is far to be better (read: have been >>>> proven itself worth of its added burden of breaking that tradition) >>> >>> So if we cannot break tradition then Traits should never have been >>> introduced? >> Traits are a different kind of thing. They didn’t cripple existing elements >> in Pharo. > > really? > did you see the real class template with traits? It should be like that if we > follow your reasoning > > Object subclass: #NameOfSubclass > uses: T1 (#bar -> #zork) + T2 - {#foo} > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'CollectionsTests-Strings' > > > > > CollectionRootTest subclass: #StringTest > uses: TIncludesTest + TCloneTest + TCopyTest + TSetArithmetic + > TIterateSequencedReadableTest + TPrintOnSequencedTest + > TAsStringCommaAndDelimiterSequenceableTest + TIndexAccess + > TSequencedElementAccessTest + TSubCollectionAccess + TPutBasicTest + > TCopySequenceableSameContents + TCopyPartOfSequenceable + > TCopyPartOfSequenceableForMultipliness + > TCopySequenceableWithOrWithoutSpecificElements + > TCopySequenceableWithReplacement + TReplacementSequencedTest + (TConvertTest > - {#testAsByteArray}) + TConvertAsSortedTest + TBeginsEndsWith + > (TIndexAccessForMultipliness - {#testIdentityIndexOfIAbsentDuplicate. > #testIdentityIndexOfDuplicate. > #collectionWithNonIdentitySameAtEndAndBegining}) + > TSequencedConcatenationTest + TPutTest + TConvertAsSetForMultiplinessTest + > TSortTest + TSequencedStructuralEqualityTest + > TOccurrencesForMultiplinessTest + TCreationWithTest > instanceVariableNames: 'string emptyString elementInNonEmpty notIn > nonEmpty1element withoutEqualElements collectionNotIncluded > indexInNonEmptyArray sameAtEndAndBegining nonEmpty5ElementsSorted > unsortedCollection subcollection3ElementsSorted arrayWithCharacters' > classVariableNames: '' > poolDictionaries: '' > category: 'CollectionsTests-Strings' > > > >> The only problem was the lack of tool support when they were introduced. You >> are comparing apples and oranges. >> >>> >> For generations of Smalltalk newbies it was possible to either grasp the >> concept or ignore it. > > How do you measure that we did not fail? > >> Why do you need to change this without a real solution for those who want to >> use them? >> In my eyes it’s an absolute minority of Pharo users who aren’t able to >> understand the concept. > > Again let me repeat. This is not a question of not being able to understand > or not. > This is an accessibility point. Why do we overhelm people with unnecessary > information. > Now think about it for real (read what I wrote) because I will stop reading > this thread. > > >>>> It’s a half-ass non-solution >>>> >>>> Do you really love cleaning that up? >>> >>> >>> This half-assed non-solution is the same solution as for Traits, >>> essentially. Do you have the same issue with Traits? >>> >> Again you are comparing apples and oranges. Traits didn’t take away anything >> but brought something new. > > No :) > This is why I do not like traits. > >> You took away something. >> BTW how do your students cope with Traits? They must be completely >> overwhelmed. > > They do not see them. because empty traits are not in the class template nor > in the definition of classes that do not use them. > Can you reread this sentence please? > >> And how do you teach the class hierarchy and meta classes? > > much simpler. > >> >> >> >>>> The second part of your homework on this design decision was completely >>>> ignored so expecting it to be loved (popular) is unrealistic >>>> >>>> And by not doing that you just added a problem where there was none >>>> >>>> Not willing to do that second part? >>>> >>>> Then don’t fix what isn’t broken. >>> >>> Please see previous mail. >> >> I am a close lurker of the mailing lists and I completely missed it. >> >> Regards, >> Andreas >
