Finally getting back to this

On Fri, Sep 6, 2013 at 4:21 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> Hmm, that was sort rather than sorted to sort in place.
>
>
> 2013/9/6 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
>
>> That's the limit of select:thenCollect:, it would have to be declined
>> into select:thenCollect:as:...
>>
>> Anyway, #CustomEvents was a value of the Dictionary no?
>> So you would not expect removeKey: to remove a value, would you?
>>
>
The keys are the same vocabularyName as that returned in the collect:
block. See for instance Vocabulary class>>addStandardVocabulary:
aVocabulary. So the associations created by the select:thenCollect: are of
the form vocabularyName->vocabularyName.


>> It could be:
>>
>> aList := ((self allStandardVocabularies select: #representsAType)
>> collect:  #vocabularyName as: Array) sorted.
>> Preferences allowEtoyUserCustomEvents ifFalse: [^aList copyWithout:
>> #CustomEvents].
>> ^aList
>>
>
Sending collect: still gets you an IdentityDictionary which doesn't like
as: Array. The original code returned aList asSortedArray. If we send that
to the result of select:thenCollect: then use your copyWithout form it
works as well. I've placed a new version of Protocols in the inbox with
these changes.

Hopefully this version will appease the gods...

John


>>
>>
>> 2013/9/6 Bob Arning <arning315 at comcast.net>
>>
>>>  The issue is that Dictionary>>collect: used to return an
>>> OrderedCollection. Now it returns a Dictionary.
>>>
>>> Cheers,
>>> Bob
>>>
>>>  On 9/6/13 10:07 AM, Bert Freudenberg wrote:
>>>
>>> On 2013-09-06, at 08:21, Frank Shearar <frank.shearar at gmail.com> <frank.shearar at gmail.com> wrote:
>>>
>>>
>>>  On 6 September 2013 00:59,  <commits at source.squeak.org> <commits at source.squeak.org> wrote:
>>>
>>>  A new version of Protocols was added to project The Inbox:http://source.squeak.org/inbox/Protocols-jmck.44.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: Protocols-jmck.44
>>> Author: jmck
>>> Time: 5 September 2013, 7:59:50.198 pm
>>> UUID: c4a851ef-6f9c-6f43-b0f4-b4ff12060089
>>> Ancestors: Protocols-fbs.43
>>>
>>> Vocabulary class>>typeChoices throws an error if Preferences>>allowEtoysUserCustomEvents is false
>>> Mantis #7786
>>>
>>> =============== Diff against Protocols-fbs.43 ===============
>>>
>>> Item was changed:
>>>  ----- Method: Vocabulary class>>typeChoices (in category 'type vocabularies') -----
>>>  typeChoices
>>>        "Answer a list of all user-choosable data types"
>>>
>>>        | aList |
>>>        (aList := self allStandardVocabularies
>>>                select:
>>>                        [:aVocab | aVocab representsAType]
>>>                thenCollect:
>>>                        [:aVocab | aVocab vocabularyName]).
>>> +       Preferences allowEtoyUserCustomEvents ifFalse: [aList removeKey: #CustomEvents].
>>> -       Preferences allowEtoyUserCustomEvents ifFalse: [aList remove: #CustomEvents ifAbsent: []].
>>>        ^ aList asSortedArray!
>>>
>>>  I'm not in front of an image right now, but I find it a bit strange
>>> that something Dictionary-y like #removeKey: is being sent to
>>> something called "aList".
>>>
>>> If aList will contain a Dictionary sometimes and a list-like
>>> collection (Array, OrderedCollection) other times, first let me run
>>> and hide in a corner so my crying doesn't upset anyone, and second
>>> let's change the variable name to aListOrDictionary.
>>>
>>>  No, the proposed "fix" is just plain wrong.
>>>
>>> #allStandardVocabularies answers an IdentityDictionary, and aList is an OrderedCollection (at least in the Etoys image) so the original #remove:ifAbsent: makes sense, whereas #removeKey: does not.
>>>
>>> - Bert -
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>


-- 
jmck.seasidehosting.st
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130922/3cce5b0a/attachment.htm