>>
>> 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
