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