The Inbox: Protocols-jmck.44.mcz

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 [hidden email] wrote:

On 6 September 2013 00:59,  [hidden email] 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 -

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?

It could be:

aList := ((self allStandardVocabularies select: #representsAType) collect:  #vocabularyName as: Array) sorted.
Preferences allowEtoyUserCustomEvents ifFalse: [^aList copyWithout: #CustomEvents].

^aList

2013/9/6 Bob Arning <[hidden email]>

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 [hidden email] wrote:

On 6 September 2013 00:59,  [hidden email] 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 -

Finally getting back to this

On Fri, Sep 6, 2013 at 4:21 PM, Nicolas Cellier <[hidden email]> wrote:

Hmm, that was sort rather than sorted to sort in place.

2013/9/6 Nicolas Cellier <[hidden email]>

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 <[hidden email]>

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 [hidden email] wrote:

On 6 September 2013 00:59,  [hidden email] 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

OK, I see the trick now.

Though collect:as: also works perfectly with an IdentityDictionary

((IdentityDictionary new)
    at: 'foo' put: 2;
    at: 'bar' put: 3;
    collect: #squared as: Array)
->
#(9 4)

2013/9/22 John McKeon <[hidden email]>

Finally getting back to this

On Fri, Sep 6, 2013 at 4:21 PM, Nicolas Cellier <[hidden email]> wrote:

Hmm, that was sort rather than sorted to sort in place.

2013/9/6 Nicolas Cellier <[hidden email]>

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 <[hidden email]>

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 [hidden email] wrote:

On 6 September 2013 00:59,  [hidden email] 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