Surprise of the day

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Surprise of the day

Joerg Beekmann, DeepCove Labs (YVR)

In VW7.7 sorted collections can’t be sorted. For example the following breaks.

 

#(1 2 3 4) asSortedCollection sorted: [:a :b| a > b]

 

My first take on this is that it is a bug.

 

Joerg

-----
Joerg Beekmann
DeepCove Labs
4th floor 595 Howe Street
Vancouver, BC, V6C 2T5
voice +1.604.689.0322
fax   +1.604.689.0311
<a href="blocked::mailto:joerg@deepcovelabs.com" title="blocked::mailto:joerg@deepcovelabs.com">joerg@...


CONFIDENTIALITY NOTICE - This email contains private and confidential
information. If it is not intended for you, delete it and any attachments.

 

 


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Andres Valloud-6
Yes, it looks like a bug...

60913: "Sorted collections fail when receiving sorted:"

Andres.

On 8/4/2010 1:15 PM, Joerg Beekmann, DeepCove Labs (YVR) wrote:

> In VW7.7 sorted collections can’t be sorted. For example the following
> breaks.
>
> #(1 2 3 4) asSortedCollection sorted: [:a :b| a > b]
>
> My first take on this is that it is a bug.
>
> Joerg
>
> -----
> Joerg Beekmann
> DeepCove Labs
> 4th floor 595 Howe Street
> Vancouver, BC, V6C 2T5
> voice +1.604.689.0322
> fax +1.604.689.0311
> [hidden email] <blocked::mailto:[hidden email]>
>
>
> CONFIDENTIALITY NOTICE - This email contains private and confidential
> information. If it is not intended for you, delete it and any attachments.
>
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

James Robertson-7
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
#(1 2 3 4) asSortedCollection sortBlock: [:a :b| a > b] 


James Robertson
Cincom Smalltalk Product Evangelist
Talk Small and Carry a Big Class Library




On Aug 4, 2010, at 4:15 PM, Joerg Beekmann, DeepCove Labs (YVR) wrote:

In VW7.7 sorted collections can’t be sorted. For example the following breaks.
 
#(1 2 3 4) asSortedCollection sorted: [:a :b| a > b]
 
My first take on this is that it is a bug.
 
Joerg
-----
Joerg Beekmann
DeepCove Labs
4th floor 595 Howe Street
Vancouver, BC, V6C 2T5
voice +1.604.689.0322
fax   +1.604.689.0311
<a href="blocked::mailto:joerg@deepcovelabs.com" title="blocked::mailto:joerg@deepcovelabs.com" style="color: blue; text-decoration: underline; ">joerg@...

CONFIDENTIALITY NOTICE - This email contains private and confidential
information. If it is not intended for you, delete it and any attachments.
 
 
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Paul Baumann
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
That also errors in VW 7.5. You'd meant to do:
 
#(1 2 3 4) asSortedCollection: [:a :b| a > b]
 
Paul Baumann 
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Joerg Beekmann, DeepCove Labs (YVR)
Sent: Wednesday, August 04, 2010 4:15 PM
To: [hidden email]
Subject: [vwnc] Surprise of the day

In VW7.7 sorted collections can’t be sorted. For example the following breaks.

 

#(1 2 3 4) asSortedCollection sorted: [:a :b| a > b]

 

My first take on this is that it is a bug.

 

Joerg

-----
Joerg Beekmann
DeepCove Labs
4th floor 595 Howe Street
Vancouver, BC, V6C 2T5
voice +1.604.689.0322
fax   +1.604.689.0311
<a title="blocked::mailto:joerg@deepcovelabs.com" href="blocked::mailto:joerg@deepcovelabs.com">joerg@...


CONFIDENTIALITY NOTICE - This email contains private and confidential
information. If it is not intended for you, delete it and any attachments.

 

 



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Dave Stevenson-3
I think the issue is not whether it can be done a different way (which it can, as Paul demonstrated), but rather whether #sorted: should work for various kinds of collections. Should I have to do this?:
 
    sorted := (aCollection isKindOf: SortedCollection)
        ifTrue: [aCollection sortBlock: aBlock]
        ifFalse: [aCollection sorted: aBlock]
 
I think the argument is for consistency:
 
    sorted := aCollection sorted: aBlock
 
Dave Stevenson
[hidden email]



From: Paul Baumann <[hidden email]>
To: "Joerg Beekmann, DeepCove Labs (YVR)" <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Wed, August 4, 2010 1:38:27 PM
Subject: Re: [vwnc] Surprise of the day

That also errors in VW 7.5. You'd meant to do:
 
#(1 2 3 4) asSortedCollection: [:a :b| a > b]
 
Paul Baumann 
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Joerg Beekmann, DeepCove Labs (YVR)
Sent: Wednesday, August 04, 2010 4:15 PM
To: [hidden email]
Subject: [vwnc] Surprise of the day

In VW7.7 sorted collections can’t be sorted. For example the following breaks.

 

#(1 2 3 4) asSortedCollection sorted: [:a :b| a > b]

 

My first take on this is that it is a bug.

 

Joerg

-----
Joerg Beekmann
DeepCove Labs
4th floor 595 Howe Street
Vancouver, BC, V6C 2T5
voice +1.604.689.0322
fax   +1.604.689.0311
[hidden email]


CONFIDENTIALITY NOTICE - This email contains private and confidential
information. If it is not intended for you, delete it and any attachments.

 

 



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Julian Fitzell-4
Re: [vwnc] Surprise of the day Agreed. I think we took this approach in Grease, if I recall correctly (and Pharo has followed suit).

#sortBlock: is an accessor, #sorted: is a conversion method. That they would happen to have the same implementation on this class is irrelevant.

Julian

On 10-08-04 9:54 PM, "Dave Stevenson" <dave.stevenson@...> wrote:

I think the issue is not whether it can be done a different way (which it can, as Paul demonstrated), but rather whether #sorted: should work for various kinds of collections. Should I have to do this?:
 
    sorted := (aCollection isKindOf: SortedCollection)
        ifTrue: [aCollection sortBlock: aBlock]
        ifFalse: [aCollection sorted: aBlock]
 
I think the argument is for consistency:
 
    sorted := aCollection sorted: aBlock
 
Dave Stevenson
dave.stevenson@...



From: Paul Baumann <paul.baumann@...>
To: "Joerg Beekmann, DeepCove Labs (YVR)" <joerg@...>; "vwnc@..." <vwnc@...>
Sent: Wed, August 4, 2010 1:38:27 PM
Subject: Re: [vwnc] Surprise of the day

That also errors in VW 7.5. You'd meant to do:

#(1 2 3 4) asSortedCollection: [:a :b| a > b]

Paul Baumann



From: vwnc-bounces@... [[hidden email]] On Behalf Of Joerg Beekmann, DeepCove Labs (YVR)
Sent: Wednesday, August 04, 2010 4:15 PM
To: vwnc@...
Subject: [vwnc] Surprise of the day

In VW7.7 sorted collections can’t be sorted. For example the following breaks.
 
#(1 2 3 4) asSortedCollection sorted: [:a :b| a > b]
 
My first take on this is that it is a bug.
 
Joerg
-----
Joerg Beekmann
DeepCove Labs
4th floor 595 Howe Street
Vancouver, BC, V6C 2T5
voice +1.604.689.0322
fax   +1.604.689.0311
joerg@...

CONFIDENTIALITY NOTICE - This email contains private and confidential
information. If it is not intended for you, delete it and any attachments.




This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
vwnc@...
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Julian Fitzell-4
Re: [vwnc] Surprise of the day Sorry, they’re not even the same implementation. The semantics of #sorted: elsewhere is that it always returns a copy. It also doesn’t return a SortedCollection particularly but merely a SequenceableCollection in sorted order.

So SortedCollection>>#sorted: could be implemented thus:

sorted: aBlock
   ^ self copy sortBlock: aBlock; yourself

But it could also be implemented like:

sorted: aBlock
   ^ self asArray sort: aBlock

If you particularly want a SortedCollection from an arbitrary collection, you’d use “aCollection asSortedCollection: [ :a :b | ... ]” (the implementation of which, not surprisingly, also makes use of #sortBlock:)

This almost leads me into a broader discussion of the implied semantics of methods based on the forms of their names, but I’ll leave that for another time.

Julian

On 10-08-05 2:17 PM, "Julian Fitzell" <jfitzell@...> wrote:

Agreed. I think we took this approach in Grease, if I recall correctly (and Pharo has followed suit).

#sortBlock: is an accessor, #sorted: is a conversion method. That they would happen to have the same implementation on this class is irrelevant.

Julian

On 10-08-04 9:54 PM, "Dave Stevenson" <dave.stevenson@...> wrote:

I think the issue is not whether it can be done a different way (which it can, as Paul demonstrated), but rather whether #sorted: should work for various kinds of collections. Should I have to do this?:
 
    sorted := (aCollection isKindOf: SortedCollection)
        ifTrue: [aCollection sortBlock: aBlock]
        ifFalse: [aCollection sorted: aBlock]
 
I think the argument is for consistency:
 
    sorted := aCollection sorted: aBlock
 
Dave Stevenson
dave.stevenson@...



From: Paul Baumann <paul.baumann@...>
To: "Joerg Beekmann, DeepCove Labs (YVR)" <joerg@...>; "vwnc@..." <vwnc@...>
Sent: Wed, August 4, 2010 1:38:27 PM
Subject: Re: [vwnc] Surprise of the day

That also errors in VW 7.5. You'd meant to do:

#(1 2 3 4) asSortedCollection: [:a :b| a > b]

Paul Baumann



From: vwnc-bounces@... [[hidden email]] On Behalf Of Joerg Beekmann, DeepCove Labs (YVR)
Sent: Wednesday, August 04, 2010 4:15 PM
To: vwnc@...
Subject: [vwnc] Surprise of the day

In VW7.7 sorted collections can’t be sorted. For example the following breaks.
 
#(1 2 3 4) asSortedCollection sorted: [:a :b| a > b]
 
My first take on this is that it is a bug.
 
Joerg
-----
Joerg Beekmann
DeepCove Labs
4th floor 595 Howe Street
Vancouver, BC, V6C 2T5
voice +1.604.689.0322
fax   +1.604.689.0311
joerg@...

CONFIDENTIALITY NOTICE - This email contains private and confidential
information. If it is not intended for you, delete it and any attachments.




This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
vwnc@...
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
vwnc@...
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Joerg Beekmann, DeepCove Labs (YVR)
In reply to this post by Paul Baumann

It is not so much that I wanted to create a SortedCollection from an array but rather given an arbitrary SequencableCollection I wanted back another SequencableCollection that was sorted.  Since sorted: was implemented as a conversion method on SequencableCollection I just expected it to work and was surprised it did not.

 

 

 

From: Paul Baumann [mailto:[hidden email]]
Sent: Wednesday, August 04, 2010 1:38 PM
To: Joerg Beekmann, DeepCove Labs (YVR); [hidden email]
Subject: RE: Surprise of the day

 

That also errors in VW 7.5. You'd meant to do:

 

#(1 2 3 4) asSortedCollection: [:a :b| a > b]

 

Paul Baumann 

 

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Joerg Beekmann, DeepCove Labs (YVR)
Sent: Wednesday, August 04, 2010 4:15 PM
To: [hidden email]
Subject: [vwnc] Surprise of the day

In VW7.7 sorted collections can’t be sorted. For example the following breaks.

 

#(1 2 3 4) asSortedCollection sorted: [:a :b| a > b]

 

My first take on this is that it is a bug.

 

Joerg

-----
Joerg Beekmann
DeepCove Labs
4th floor 595 Howe Street
Vancouver, BC, V6C 2T5
voice +1.604.689.0322
fax   +1.604.689.0311
<a href="blocked::mailto:joerg@deepcovelabs.com" title="blocked::mailto:joerg@deepcovelabs.com">joerg@...


CONFIDENTIALITY NOTICE - This email contains private and confidential
information. If it is not intended for you, delete it and any attachments.

 

 

 


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Paul Baumann
Understood. I agree it is a bug.
 
A few years ago I removed all senders of #sorted: from code I maintain. There were problems like you've discovered. #sorted: is dialect-specific and (as you've pointed out) only works for some collections.
 
If the purpose of #sorted: were documented, I think it would read "Answer a collection similar to the receiver with contents sorted according to aBlock". The "similar to the receiver" part is the only part that would distinguish it from #asSortedCollection:. #sorted: for all but subclasses of SequenceableCollection currently answers an array because the receiver type is not appropriate (why not error also?). Some kinds of SequenceableCollection have implementations that SequenceableCollectionSorter should not presume it can safely reorder just because they have a sequence. Those could also be made to answer arrays (to be consistent with the other Collection subclasses). The further you take this though, the more it becomes obvious that #sorted: shouldn't presume it can answer a collection similar to any receiver and that #asSortedCollection: doesn't make this mistake. #sorted: should consistently either error or answer an array when answering 'a similar collection' is not appropriate. When you consider that a set that is sorted: answers an array that can not be added to, then even 'similar to the receiver' should be questioned. The purpose and benefit of #sorted: remains a mystery when presented with inconsistent implementation.
 
Here is another kind of collection that #sorted: can't sort:
 
(100 to: 1 by: -1) sorted: [:a :b | a < b ]
 
Seeing how #sorted: is implemented makes me wonder why someone would want to use it anyway. It looks like it would be inefficient except for limited purposes. These tests tend to confirm even the potential benefit isn't that great:
 
Time microsecondsToRun: [100 timesRepeat: [
(100 to: 1 by: -1) asArray sorted: [:a :b | a < b ]
]]
 4016
 
| array |
array := (100 to: 1 by: -1) asArray.
Time microsecondsToRun: [100 timesRepeat: [
array sorted: [:a :b | a < b ]
]]
 3236
 
| set |
set := (100 to: 1 by: -1) asSet.
Time microsecondsToRun: [100 timesRepeat: [
set sorted: [:a :b | a < b ]
]]
 4856
 
| set |
set := (100 to: 1 by: -1) asSet.
Time microsecondsToRun: [100 timesRepeat: [
(set asSortedCollection: [:a :b | a < b ]) asArray
]]
 3247
 
Time microsecondsToRun: [100 timesRepeat: [
(100 to: 1 by: -1) asSortedCollection: [:a :b | a < b ]
]]
 2997
 
Time microsecondsToRun: [100 timesRepeat: [
((100 to: 1 by: -1) asSortedCollection: [:a :b | a < b ]) asArray
]]
 3399
 
1 - (3236 / 3399) * -100.0
 -4.79553
 
1 - (4856 / 3247) * -100.0
 49.5534
When used ideally, it is potentially a 5% gain over #asSortedCollection:. When used generally, it can be as much as 50% slower than #asSortedCollection: even when taking the extra time to return an array result.
 
It is a bug in a Cincom-specific protocol that I don't see a need for. #asSortedCollection: works fine and is portable. I'd classify it more as a design bug than a technical bug. IMO, Cincom should look into deprecating #sorted: from kernel collections.
 
Paul Baumann 
 


From: Joerg Beekmann, DeepCove Labs (YVR) [mailto:[hidden email]]
Sent: Thursday, August 05, 2010 7:13 PM
To: Paul Baumann; [hidden email]
Subject: RE: Surprise of the day
Importance: High

It is not so much that I wanted to create a SortedCollection from an array but rather given an arbitrary SequencableCollection I wanted back another SequencableCollection that was sorted.  Since sorted: was implemented as a conversion method on SequencableCollection I just expected it to work and was surprised it did not.

 

 

 

From: Paul Baumann [mailto:[hidden email]]
Sent: Wednesday, August 04, 2010 1:38 PM
To: Joerg Beekmann, DeepCove Labs (YVR); [hidden email]
Subject: RE: Surprise of the day

 

That also errors in VW 7.5. You'd meant to do:

 

#(1 2 3 4) asSortedCollection: [:a :b| a > b]

 

Paul Baumann 

 

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Joerg Beekmann, DeepCove Labs (YVR)
Sent: Wednesday, August 04, 2010 4:15 PM
To: [hidden email]
Subject: [vwnc] Surprise of the day

In VW7.7 sorted collections can’t be sorted. For example the following breaks.

 

#(1 2 3 4) asSortedCollection sorted: [:a :b| a > b]

 

My first take on this is that it is a bug.

 

Joerg

-----
Joerg Beekmann
DeepCove Labs
4th floor 595 Howe Street
Vancouver, BC, V6C 2T5
voice +1.604.689.0322
fax   +1.604.689.0311
<a title="blocked::mailto:joerg@deepcovelabs.com" href="blocked::mailto:joerg@deepcovelabs.com">joerg@...


CONFIDENTIALITY NOTICE - This email contains private and confidential
information. If it is not intended for you, delete it and any attachments.

 

 

 


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Julian Fitzell-4
On 10-08-06 4:58 PM, "Paul Baumann" <[hidden email]> wrote:
> If the purpose of #sorted: were documented, I think it would read "Answer a
> collection similar to the receiver with contents sorted according to aBlock".
> The "similar to the receiver" part is the only part that would distinguish it
> from #asSortedCollection:.

I disagree. I think it would read "Answer a sequenceable collection
containing the contents of the receiver sorted according to aBlock. The
receiver is not modified."

A SortedCollection is specifically implemented to allow the contents to
change and to remain sorted when elements are added. If you don't need that
functionality, there's no point demanding a SortedCollection. #sorted:
allows each collection to make the decision of how to most efficiently
create and return the result, whether that is returning a copy of self, a
copy with the sort block changed, an Array created in some fashion or other,
or some other method. It's a protocol that allows you ask for something
specific that you need without specifying the implementation, which is
exactly what OO is supposed to be about.

Julian

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Paul Baumann

>> I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

Yes, that is a better method comment.

#sorted: is broken, uncommented (at least as of VW 7.5), typically slower, and non-portable. You think #sorted: can be better than #asSortedCollection: and should be fixed instead of removed, I respect that. I see why you appreciate it. I'll stick with #asSortedCollection: until #sorted: is better.

Paul Baumann


-----Original Message-----
From: Julian Fitzell [mailto:[hidden email]]
Sent: Monday, August 09, 2010 6:03 AM
To: Paul Baumann; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

On 10-08-06 4:58 PM, "Paul Baumann" <[hidden email]> wrote:
> If the purpose of #sorted: were documented, I think it would read
> "Answer a collection similar to the receiver with contents sorted according to aBlock".
> The "similar to the receiver" part is the only part that would
> distinguish it from #asSortedCollection:.

I disagree. I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

A SortedCollection is specifically implemented to allow the contents to change and to remain sorted when elements are added. If you don't need that functionality, there's no point demanding a SortedCollection. #sorted:
allows each collection to make the decision of how to most efficiently create and return the result, whether that is returning a copy of self, a copy with the sort block changed, an Array created in some fashion or other, or some other method. It's a protocol that allows you ask for something specific that you need without specifying the implementation, which is exactly what OO is supposed to be about.

Julian



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Dave Stevenson-3

Some time ago I wrote some extension methods that allow me to pass a block, a selector, or a collection of blocks/selectors for sorting (see attached). It uses #sorted:, so it has the same bug for SortedCollections, but I think folds might find it useful. Here are some examples:

 

 #(-14 3 1 -3 7 12) sortBy: #abs
 #(-14 3 1 -3 7 12) sortBy: #(abs yourself)
 #(-14 3 1 -3 7 12) sortBy: [:x | x \\ 4]
 #(-14 3 1 -3 7 12) sortBy: (List with: [:x | x \\ 4] with: #yourself)

 

The default sort order is ascending, but a variant allows a descending sort:

 

 aCollection sortBy: #name ascending: false

 

I don't like that #sortBy: seems to imply a mutation of the receiver while actually providing a new collection. Perhaps I should have named it #sortedBy: or something. Handling the arguments:
 ...
 value1 := unarySelectorOrBlock isSymbol
  ifTrue: [element1 perform: unarySelectorOrBlock]
  ifFalse: [unarySelectorOrBlock value: element1].
 ...

 

could be streamlined a bit if Squeak Extensions are loaded (which defines Symbol>>value:):
 ...
 value1 := unarySelectorOrBlock value: element1.
 ...

 

but the attached version works in vanilla VW 7.6. In our code, only a few percent of senders of #sortBy: pass a block (likely because #sorted: and #asSortedCollection: already take a block). About a quarter of our senders pass a collection of selectors, and the rest pass a single selector. I've not yet had a desire to pass a mixed collection containing blocks and selectors, but the examples in the method comments validate that case.

 

Paul indicated that #asSortedCollection: is faster than #sorted:, so if that is important to you I confess I did not optimize #sortBy: for speed.

 

If Cincom felt so inclined, they could probably modify #sorted: to take a block, a selector, or a collection thereof, making that single api more flexible, and eliminating my desire for a separate #sortBy: api. Or, the attached can be freely used/modified by anyone.


 
Dave Stevenson
[hidden email]



From: Paul Baumann <[hidden email]>
To: Julian Fitzell <[hidden email]>; "Joerg Beekmann, DeepCove Labs (YVR)" <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Mon, August 9, 2010 12:32:58 PM
Subject: Re: [vwnc] Surprise of the day


>> I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

Yes, that is a better method comment.

#sorted: is broken, uncommented (at least as of VW 7.5), typically slower, and non-portable. You think #sorted: can be better than #asSortedCollection: and should be fixed instead of removed, I respect that. I see why you appreciate it. I'll stick with #asSortedCollection: until #sorted: is better.

Paul Baumann


-----Original Message-----
From: Julian Fitzell [mailto:[hidden email]]
Sent: Monday, August 09, 2010 6:03 AM
To: Paul Baumann; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

On 10-08-06 4:58 PM, "Paul Baumann" <[hidden email]> wrote:
> If the purpose of #sorted: were documented, I think it would read
> "Answer a collection similar to the receiver with contents sorted according to aBlock".
> The "similar to the receiver" part is the only part that would
> distinguish it from #asSortedCollection:.

I disagree. I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

A SortedCollection is specifically implemented to allow the contents to change and to remain sorted when elements are added. If you don't need that functionality, there's no point demanding a SortedCollection. #sorted:
allows each collection to make the decision of how to most efficiently create and return the result, whether that is returning a copy of self, a copy with the sort block changed, an Array created in some fashion or other, or some other method. It's a protocol that allows you ask for something specific that you need without specifying the implementation, which is exactly what OO is supposed to be about.

Julian



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

sortBy.st (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Julian Fitzell-4
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
Re: [vwnc] Surprise of the day

Hi Paul,

I can't argue with that. :)

Julian

----- Original Message -----
From: Paul Baumann <[hidden email]>
To: Fitzell, Julian; 'Joerg Beekmann, DeepCove Labs (YVR)' <[hidden email]>; [hidden email] <[hidden email]>
Sent: Mon Aug 09 20:32:58 2010
Subject: RE: [vwnc] Surprise of the day


>> I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

Yes, that is a better method comment.

#sorted: is broken, uncommented (at least as of VW 7.5), typically slower, and non-portable. You think #sorted: can be better than #asSortedCollection: and should be fixed instead of removed, I respect that. I see why you appreciate it. I'll stick with #asSortedCollection: until #sorted: is better.

Paul Baumann


-----Original Message-----
From: Julian Fitzell [[hidden email]]
Sent: Monday, August 09, 2010 6:03 AM
To: Paul Baumann; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

On 10-08-06 4:58 PM, "Paul Baumann" <[hidden email]> wrote:
> If the purpose of #sorted: were documented, I think it would read
> "Answer a collection similar to the receiver with contents sorted according to aBlock".
> The "similar to the receiver" part is the only part that would
> distinguish it from #asSortedCollection:.

I disagree. I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

A SortedCollection is specifically implemented to allow the contents to change and to remain sorted when elements are added. If you don't need that functionality, there's no point demanding a SortedCollection. #sorted:
allows each collection to make the decision of how to most efficiently create and return the result, whether that is returning a copy of self, a copy with the sort block changed, an Array created in some fashion or other, or some other method. It's a protocol that allows you ask for something specific that you need without specifying the implementation, which is exactly what OO is supposed to be about.

Julian



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Steven Kelly
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)

Neat! I’ve been meaning to implement sorting by multiple criteria for a while. We have something similar (unary sort criterion, block or selector), with our addition being the caching of the result of the sort criterion for each element. This can produce a useful speedup, e.g. if the sort criteria creates a string. Since we only have a single criterion we simply precalculate the sort value for each element, making an association of element->sortValue, sort the associations with a fixed sortBlock using assoc value, and then collect the keys.

 

Steve

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Dave Stevenson
Sent: 10. elokuuta 2010 1:07
To: [hidden email]
Subject: Re: [vwnc] Surprise of the day

 

Some time ago I wrote some extension methods that allow me to pass a block, a selector, or a collection of blocks/selectors for sorting (see attached). It uses #sorted:, so it has the same bug for SortedCollections, but I think folds might find it useful. Here are some examples:

 

 #(-14 3 1 -3 7 12) sortBy: #abs
 #(-14 3 1 -3 7 12) sortBy: #(abs yourself)
 #(-14 3 1 -3 7 12) sortBy: [:x | x \\ 4]
 #(-14 3 1 -3 7 12) sortBy: (List with: [:x | x \\ 4] with: #yourself)

 

The default sort order is ascending, but a variant allows a descending sort:

 

 aCollection sortBy: #name ascending: false

 

I don't like that #sortBy: seems to imply a mutation of the receiver while actually providing a new collection. Perhaps I should have named it #sortedBy: or something. Handling the arguments:
 ...
 value1 := unarySelectorOrBlock isSymbol
  ifTrue: [element1 perform: unarySelectorOrBlock]
  ifFalse: [unarySelectorOrBlock value: element1].
 ...

 

could be streamlined a bit if Squeak Extensions are loaded (which defines Symbol>>value:):
 ...
 value1 := unarySelectorOrBlock value: element1.
 ...

 

but the attached version works in vanilla VW 7.6. In our code, only a few percent of senders of #sortBy: pass a block (likely because #sorted: and #asSortedCollection: already take a block). About a quarter of our senders pass a collection of selectors, and the rest pass a single selector. I've not yet had a desire to pass a mixed collection containing blocks and selectors, but the examples in the method comments validate that case.

 

Paul indicated that #asSortedCollection: is faster than #sorted:, so if that is important to you I confess I did not optimize #sortBy: for speed.

 

If Cincom felt so inclined, they could probably modify #sorted: to take a block, a selector, or a collection thereof, making that single api more flexible, and eliminating my desire for a separate #sortBy: api. Or, the attached can be freely used/modified by anyone.


 

Dave Stevenson
[hidden email]

 

 


From: Paul Baumann <[hidden email]>
To: Julian Fitzell <[hidden email]>; "Joerg Beekmann, DeepCove Labs (YVR)" <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Mon, August 9, 2010 12:32:58 PM
Subject: Re: [vwnc] Surprise of the day


>> I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

Yes, that is a better method comment.

#sorted: is broken, uncommented (at least as of VW 7.5), typically slower, and non-portable. You think #sorted: can be better than #asSortedCollection: and should be fixed instead of removed, I respect that. I see why you appreciate it. I'll stick with #asSortedCollection: until #sorted: is better.

Paul Baumann


-----Original Message-----
From: Julian Fitzell [mailto:[hidden email]]
Sent: Monday, August 09, 2010 6:03 AM
To: Paul Baumann; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

On 10-08-06 4:58 PM, "Paul Baumann" <[hidden email]> wrote:
> If the purpose of #sorted: were documented, I think it would read
> "Answer a collection similar to the receiver with contents sorted according to aBlock".
> The "similar to the receiver" part is the only part that would
> distinguish it from #asSortedCollection:.

I disagree. I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

A SortedCollection is specifically implemented to allow the contents to change and to remain sorted when elements are added. If you don't need that functionality, there's no point demanding a SortedCollection. #sorted:
allows each collection to make the decision of how to most efficiently create and return the result, whether that is returning a copy of self, a copy with the sort block changed, an Array created in some fashion or other, or some other method. It's a protocol that allows you ask for something specific that you need without specifying the implementation, which is exactly what OO is supposed to be about.

Julian



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

cachingSort.st (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Thomas Brodt
You can also take a look at class SequenceableCollectionSorter itself, which does the job of sorting a collection within sorted:.
Instead of
    aCollection sorted: aBlock,
you can write
    SequenceableCollectionSorter sort: aCollection using: aBlock.
(Since recently, it also returns the sorted collection instead of itself.)

Its usage introduces a class reference, though. And you have to provide the collection to be sorted, but on the other hand, there is no uncertainty whether it returns a copy or not.

We created a subclass of it which also sorts like e.g. this: [ListSorter sort: aCollection byAspects: #(startDate #(embeddedObject someNumber))]

Thomas


Am 10.08.2010 01:58, schrieb Steven Kelly:

Neat! I’ve been meaning to implement sorting by multiple criteria for a while. We have something similar (unary sort criterion, block or selector), with our addition being the caching of the result of the sort criterion for each element. This can produce a useful speedup, e.g. if the sort criteria creates a string. Since we only have a single criterion we simply precalculate the sort value for each element, making an association of element->sortValue, sort the associations with a fixed sortBlock using assoc value, and then collect the keys.

 

Steve

 

From: [hidden email] [[hidden email]] On Behalf Of Dave Stevenson
Sent: 10. elokuuta 2010 1:07
To: [hidden email]
Subject: Re: [vwnc] Surprise of the day

 

Some time ago I wrote some extension methods that allow me to pass a block, a selector, or a collection of blocks/selectors for sorting (see attached). It uses #sorted:, so it has the same bug for SortedCollections, but I think folds might find it useful. Here are some examples:

 

 #(-14 3 1 -3 7 12) sortBy: #abs
 #(-14 3 1 -3 7 12) sortBy: #(abs yourself)
 #(-14 3 1 -3 7 12) sortBy: [:x | x \\ 4]
 #(-14 3 1 -3 7 12) sortBy: (List with: [:x | x \\ 4] with: #yourself)

 

The default sort order is ascending, but a variant allows a descending sort:

 

 aCollection sortBy: #name ascending: false

 

I don't like that #sortBy: seems to imply a mutation of the receiver while actually providing a new collection. Perhaps I should have named it #sortedBy: or something. Handling the arguments:
 ...
 value1 := unarySelectorOrBlock isSymbol
  ifTrue: [element1 perform: unarySelectorOrBlock]
  ifFalse: [unarySelectorOrBlock value: element1].
 ...

 

could be streamlined a bit if Squeak Extensions are loaded (which defines Symbol>>value:):
 ...
 value1 := unarySelectorOrBlock value: element1.
 ...

 

but the attached version works in vanilla VW 7.6. In our code, only a few percent of senders of #sortBy: pass a block (likely because #sorted: and #asSortedCollection: already take a block). About a quarter of our senders pass a collection of selectors, and the rest pass a single selector. I've not yet had a desire to pass a mixed collection containing blocks and selectors, but the examples in the method comments validate that case.

 

Paul indicated that #asSortedCollection: is faster than #sorted:, so if that is important to you I confess I did not optimize #sortBy: for speed.

 

If Cincom felt so inclined, they could probably modify #sorted: to take a block, a selector, or a collection thereof, making that single api more flexible, and eliminating my desire for a separate #sortBy: api. Or, the attached can be freely used/modified by anyone.


 

Dave Stevenson
[hidden email]

 

 


From: Paul Baumann [hidden email]
To: Julian Fitzell [hidden email]; "Joerg Beekmann, DeepCove Labs (YVR)" [hidden email]; [hidden email] [hidden email]
Sent: Mon, August 9, 2010 12:32:58 PM
Subject: Re: [vwnc] Surprise of the day


>> I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

Yes, that is a better method comment.

#sorted: is broken, uncommented (at least as of VW 7.5), typically slower, and non-portable. You think #sorted: can be better than #asSortedCollection: and should be fixed instead of removed, I respect that. I see why you appreciate it. I'll stick with #asSortedCollection: until #sorted: is better.

Paul Baumann


-----Original Message-----
From: Julian Fitzell [mailto:[hidden email]]
Sent: Monday, August 09, 2010 6:03 AM
To: Paul Baumann; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

On 10-08-06 4:58 PM, "Paul Baumann" <[hidden email]> wrote:
> If the purpose of #sorted: were documented, I think it would read
> "Answer a collection similar to the receiver with contents sorted according to aBlock".
> The "similar to the receiver" part is the only part that would
> distinguish it from #asSortedCollection:.

I disagree. I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

A SortedCollection is specifically implemented to allow the contents to change and to remain sorted when elements are added. If you don't need that functionality, there's no point demanding a SortedCollection. #sorted:
allows each collection to make the decision of how to most efficiently create and return the result, whether that is returning a copy of self, a copy with the sort block changed, an Array created in some fashion or other, or some other method. It's a protocol that allows you ask for something specific that you need without specifying the implementation, which is exactly what OO is supposed to be about.

Julian



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Alan Knight-2
In reply to this post by Paul Baumann
I have trouble seeing why #sorted: would be in general slower than asSortedCollection, as they are likely to do almost exactly the same work. I don't think that SequenceableCollectionSorter is radically less efficient than the algorithm encoded into SortedCollection, and if it is, that's something that should be fixed. I particularly have trouble seeing that the usage this would be most useful for, replacing
   aCollection asSortedCollection asArray
which makes two copies of the collection (unless it's already a SortedCollection) would in general run faster than making one copy via
  aCollection sorted

The method doesn't work for some types of collections, specifically anything that a SequenceableCollectionSorter won't work on, and which implement one of the methods involved specifically. That doesn't seem like a huge limitation, and it's one that's pretty easily fixed, as discussed in this thread.

The SequenceableCollection>>sorted: method is commented in current versions.

It's not portable, although it is also in some other dialects. If you wish to write strictly portable code, then it's a construct to be avoided.

At 03:32 PM 2010-08-09, Paul Baumann wrote:

>> I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

Yes, that is a better method comment.

#sorted: is broken, uncommented (at least as of VW 7.5), typically slower, and non-portable. You think #sorted: can be better than #asSortedCollection: and should be fixed instead of removed, I respect that. I see why you appreciate it. I'll stick with #asSortedCollection: until #sorted: is better.

Paul Baumann


-----Original Message-----
From: Julian Fitzell [[hidden email]]
Sent: Monday, August 09, 2010 6:03 AM
To: Paul Baumann; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

On 10-08-06 4:58 PM, "Paul Baumann" <[hidden email]> wrote:
> If the purpose of #sorted: were documented, I think it would read
> "Answer a collection similar to the receiver with contents sorted according to aBlock".
> The "similar to the receiver" part is the only part that would
> distinguish it from #asSortedCollection:.

I disagree. I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

A SortedCollection is specifically implemented to allow the contents to change and to remain sorted when elements are added. If you don't need that functionality, there's no point demanding a SortedCollection. #sorted:
allows each collection to make the decision of how to most efficiently create and return the result, whether that is returning a copy of self, a copy with the sort block changed, an Array created in some fashion or other, or some other method. It's a protocol that allows you ask for something specific that you need without specifying the implementation, which is exactly what OO is supposed to be about.

Julian



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Paul Baumann
>>they are likely to do almost exactly the same work
 
Creating a copy of a hashed collection is less efficient than enumerating a hashed collection to copy elements into an array. The difference is in the hidden cost of hashing for the copy. Compare performance yourself. I gave examples.
 
>>'aCollection asSortedCollection asArray' which makes two copies of the collection
 
Yes. That is the only reason why #sorted: was 5% faster in one example. Consider though, that if a SortedCollection is a reasonable response type then skip the #asArray conversion and get the fastest of all options.
 
>>The method [#sorted:] doesn't work for some collections...That doesn't seem like a huge limitation.
 
It caused problems for us as code evolved. Other collection types came into use. Errors were discovered late in the release cycle. That is the primary reason why all code had been changed to avoid sending #sorted:.
 
>> The SequenceableCollection>>sorted: method is commented in current versions.
 
Good, probably from the last time this topic came up. That is why I mentioned that I'm using VW 7.5. I don't know what it looks like in VW 7.7.
 
>>It's not portable, although it is also in some other dialects. If you wish to write strictly portable code, then it's a construct to be avoided.
 
So in which dialects does it behave similarly? Does it error there also? If there had been any performance advantage to using #sorted: then it would have been kept despite the code not being portable--presuming errors were fixed too.
 
Paul Baumann 
 
 
 


From: Alan Knight [mailto:[hidden email]]
Sent: Tuesday, August 10, 2010 10:16 AM
To: Paul Baumann; 'Julian Fitzell'; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

I have trouble seeing why #sorted: would be in general slower than asSortedCollection, as they are likely to do almost exactly the same work. I don't think that SequenceableCollectionSorter is radically less efficient than the algorithm encoded into SortedCollection, and if it is, that's something that should be fixed. I particularly have trouble seeing that the usage this would be most useful for, replacing
   aCollection asSortedCollection asArray
which makes two copies of the collection (unless it's already a SortedCollection) would in general run faster than making one copy via
  aCollection sorted

The method doesn't work for some types of collections, specifically anything that a SequenceableCollectionSorter won't work on, and which implement one of the methods involved specifically. That doesn't seem like a huge limitation, and it's one that's pretty easily fixed, as discussed in this thread.

The SequenceableCollection>>sorted: method is commented in current versions.

It's not portable, although it is also in some other dialects. If you wish to write strictly portable code, then it's a construct to be avoided.

At 03:32 PM 2010-08-09, Paul Baumann wrote:

>> I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

Yes, that is a better method comment.

#sorted: is broken, uncommented (at least as of VW 7.5), typically slower, and non-portable. You think #sorted: can be better than #asSortedCollection: and should be fixed instead of removed, I respect that. I see why you appreciate it. I'll stick with #asSortedCollection: until #sorted: is better.

Paul Baumann


-----Original Message-----
From: Julian Fitzell [[hidden email]]
Sent: Monday, August 09, 2010 6:03 AM
To: Paul Baumann; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

On 10-08-06 4:58 PM, "Paul Baumann" <[hidden email]> wrote:
> If the purpose of #sorted: were documented, I think it would read
> "Answer a collection similar to the receiver with contents sorted according to aBlock".
> The "similar to the receiver" part is the only part that would
> distinguish it from #asSortedCollection:.

I disagree. I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

A SortedCollection is specifically implemented to allow the contents to change and to remain sorted when elements are added. If you don't need that functionality, there's no point demanding a SortedCollection. #sorted:
allows each collection to make the decision of how to most efficiently create and return the result, whether that is returning a copy of self, a copy with the sort block changed, an Array created in some fashion or other, or some other method. It's a protocol that allows you ask for something specific that you need without specifying the implementation, which is exactly what OO is supposed to be about.

Julian



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Alan Knight-2
At 11:32 AM 2010-08-10, Paul Baumann wrote:
>> they are likely to do almost exactly the same work
 
Creating a copy of a hashed collection is less efficient than enumerating a hashed collection to copy elements into an array. The difference is in the hidden cost of hashing for the copy. Compare performance yourself. I gave examples.

I don't think that the sorted/sorted: methods will ever create a copy of a hashed collection, at least not of those which inherit from Set.

I did run a few of your examples, and did not see significant differences between them. Your sample sizes are very small. If I increased the set to 1000 elements, and increased the number of iterations, it's possible that it was slightly slower, so it may be that SortedCollection does do something that works slightly better in that case than SequenceableCollectionSorter. But it doesn't seem like a major issue.

>>'aCollection asSortedCollection asArray' which makes two copies of the collection
 
Yes. That is the only reason why #sorted: was 5% faster in one example. Consider though, that if a SortedCollection is a reasonable response type then skip the #asArray conversion and get the fastest of all options.

Certainly. However, that method is there because it's not always a reasonable response time, and occurences of asSortedCollection asArray are not infrequent.

>>The method [#sorted:] doesn't work for some collections...That doesn't seem like a huge limitation.
 
It caused problems for us as code evolved. Other collection types came into use. Errors were discovered late in the release cycle. That is the primary reason why all code had been changed to avoid sending #sorted:.
 
>> The SequenceableCollection>>sorted: method is commented in current versions.
 
Good, probably from the last time this topic came up. That is why I mentioned that I'm using VW 7.5. I don't know what it looks like in VW 7.7.
 
>> It's not portable, although it is also in some other dialects. If you wish to write strictly portable code, then it's a construct to be avoided.
 
So in which dialects does it behave similarly? Does it error there also? If there had been any performance advantage to using #sorted: then it would have been kept despite the code not being portable--presuming errors were fixed too.

I only tried Pharo. It works for SortedCollection and Interval there, didn't try anything else.


 
Paul Baumann
 
 
 


From: Alan Knight [[hidden email]]
Sent: Tuesday, August 10, 2010 10:16 AM
To: Paul Baumann; 'Julian Fitzell'; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

I have trouble seeing why #sorted: would be in general slower than asSortedCollection, as they are likely to do almost exactly the same work. I don't think that SequenceableCollectionSorter is radically less efficient than the algorithm encoded into SortedCollection, and if it is, that's something that should be fixed. I particularly have trouble seeing that the usage this would be most useful for, replacing
   aCollection asSortedCollection asArray
which makes two copies of the collection (unless it's already a SortedCollection) would in general run faster than making one copy via
  aCollection sorted

The method doesn't work for some types of collections, specifically anything that a SequenceableCollectionSorter won't work on, and which implement one of the methods involved specifically. That doesn't seem like a huge limitation, and it's one that's pretty easily fixed, as discussed in this thread.

The SequenceableCollection>>sorted: method is commented in current versions.

It's not portable, although it is also in some other dialects. If you wish to write strictly portable code, then it's a construct to be avoided.

At 03:32 PM 2010-08-09, Paul Baumann wrote:

>> I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

Yes, that is a better method comment.

#sorted: is broken, uncommented (at least as of VW 7.5), typically slower, and non-portable. You think #sorted: can be better than #asSortedCollection: and should be fixed instead of removed, I respect that. I see why you appreciate it. I'll stick with #asSortedCollection: until #sorted: is better.

Paul Baumann


-----Original Message-----
From: Julian Fitzell [ [hidden email]]
Sent: Monday, August 09, 2010 6:03 AM
To: Paul Baumann; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

On 10-08-06 4:58 PM, "Paul Baumann" <[hidden email]> wrote:
> If the purpose of #sorted: were documented, I think it would read
> "Answer a collection similar to the receiver with contents sorted according to aBlock".
> The "similar to the receiver" part is the only part that would
> distinguish it from #asSortedCollection:.

I disagree. I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

A SortedCollection is specifically implemented to allow the contents to change and to remain sorted when elements are added. If you don't need that functionality, there's no point demanding a SortedCollection. #sorted:
allows each collection to make the decision of how to most efficiently create and return the result, whether that is returning a copy of self, a copy with the sort block changed, an Array created in some fashion or other, or some other method. It's a protocol that allows you ask for something specific that you need without specifying the implementation, which is exactly what OO is supposed to be about.

Julian



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day

Paul Baumann
Alan,
 
You are right. The performance was the same for those tests once I took more samples. It was not a hash overhead because the set was already converted to an array. Sorry, silly mistake.
 
For some collections, #sorted: can be faster than #asSortedCollection when followed by #asArray (in situations when the response must not be a SortedCollection but any SequenceableCollection would do). The situational advantage presumes that any SequenceableCollection is the most suitable end result (instead of a List or OrderedCollection that can be added to when displayed to a user). The faster of the two approaches depends on situation. It is good to have an option.
 
Some collections will error when sent #sorted: in VW. The errors are still the main reason to avoid #sorted: in VW if collection types may change in your application code.
 
Paul Baumann 
 


From: Alan Knight [mailto:[hidden email]]
Sent: Tuesday, August 10, 2010 12:08 PM
To: Paul Baumann; 'Julian Fitzell'; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: RE: [vwnc] Surprise of the day
Importance: High

At 11:32 AM 2010-08-10, Paul Baumann wrote:
>> they are likely to do almost exactly the same work
 
Creating a copy of a hashed collection is less efficient than enumerating a hashed collection to copy elements into an array. The difference is in the hidden cost of hashing for the copy. Compare performance yourself. I gave examples.

I don't think that the sorted/sorted: methods will ever create a copy of a hashed collection, at least not of those which inherit from Set.

I did run a few of your examples, and did not see significant differences between them. Your sample sizes are very small. If I increased the set to 1000 elements, and increased the number of iterations, it's possible that it was slightly slower, so it may be that SortedCollection does do something that works slightly better in that case than SequenceableCollectionSorter. But it doesn't seem like a major issue.

>>'aCollection asSortedCollection asArray' which makes two copies of the collection
 
Yes. That is the only reason why #sorted: was 5% faster in one example. Consider though, that if a SortedCollection is a reasonable response type then skip the #asArray conversion and get the fastest of all options.

Certainly. However, that method is there because it's not always a reasonable response time, and occurences of asSortedCollection asArray are not infrequent.

>>The method [#sorted:] doesn't work for some collections...That doesn't seem like a huge limitation.
 
It caused problems for us as code evolved. Other collection types came into use. Errors were discovered late in the release cycle. That is the primary reason why all code had been changed to avoid sending #sorted:.
 
>> The SequenceableCollection>>sorted: method is commented in current versions.
 
Good, probably from the last time this topic came up. That is why I mentioned that I'm using VW 7.5. I don't know what it looks like in VW 7.7.
 
>> It's not portable, although it is also in some other dialects. If you wish to write strictly portable code, then it's a construct to be avoided.
 
So in which dialects does it behave similarly? Does it error there also? If there had been any performance advantage to using #sorted: then it would have been kept despite the code not being portable--presuming errors were fixed too.

I only tried Pharo. It works for SortedCollection and Interval there, didn't try anything else.



Paul Baumann
 
 
 


From: Alan Knight [[hidden email]]
Sent: Tuesday, August 10, 2010 10:16 AM
To: Paul Baumann; 'Julian Fitzell'; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

I have trouble seeing why #sorted: would be in general slower than asSortedCollection, as they are likely to do almost exactly the same work. I don't think that SequenceableCollectionSorter is radically less efficient than the algorithm encoded into SortedCollection, and if it is, that's something that should be fixed. I particularly have trouble seeing that the usage this would be most useful for, replacing
   aCollection asSortedCollection asArray
which makes two copies of the collection (unless it's already a SortedCollection) would in general run faster than making one copy via
  aCollection sorted

The method doesn't work for some types of collections, specifically anything that a SequenceableCollectionSorter won't work on, and which implement one of the methods involved specifically. That doesn't seem like a huge limitation, and it's one that's pretty easily fixed, as discussed in this thread.

The SequenceableCollection>>sorted: method is commented in current versions.

It's not portable, although it is also in some other dialects. If you wish to write strictly portable code, then it's a construct to be avoided.

At 03:32 PM 2010-08-09, Paul Baumann wrote:

>> I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

Yes, that is a better method comment.

#sorted: is broken, uncommented (at least as of VW 7.5), typically slower, and non-portable. You think #sorted: can be better than #asSortedCollection: and should be fixed instead of removed, I respect that. I see why you appreciate it. I'll stick with #asSortedCollection: until #sorted: is better.

Paul Baumann


-----Original Message-----
From: Julian Fitzell [ [hidden email]]
Sent: Monday, August 09, 2010 6:03 AM
To: Paul Baumann; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

On 10-08-06 4:58 PM, "Paul Baumann" <[hidden email]> wrote:
> If the purpose of #sorted: were documented, I think it would read
> "Answer a collection similar to the receiver with contents sorted according to aBlock".
> The "similar to the receiver" part is the only part that would
> distinguish it from #asSortedCollection:.

I disagree. I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

A SortedCollection is specifically implemented to allow the contents to change and to remain sorted when elements are added. If you don't need that functionality, there's no point demanding a SortedCollection. #sorted:
allows each collection to make the decision of how to most efficiently create and return the result, whether that is returning a copy of self, a copy with the sort block changed, an Array created in some fashion or other, or some other method. It's a protocol that allows you ask for something specific that you need without specifying the implementation, which is exactly what OO is supposed to be about.

Julian



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Surprise of the day - sorting for multiple criteria

Paul Baumann
In reply to this post by Steven Kelly
Here is another way to sort for multiple fields and multiple criteria. The approach Dave showed is more suited for on-demand dynamic sort criteria across a homogeneous collection of objects; this one is more suited for static sort criteria where sequence rules are maintained on the object to be sorted and the collection can contain heterogeneous objects.
 
Add this method:
 
Symbol>>should: objectA comeBefore: objectB
 "The receiver is expected to be a two argument selector that is used to determine
  if one object should be come before another. objectA and objectB will each be
  send the receiver as a message. The second argument will be an sort field index
  that starts at 1 and is incremented until order is determined."
 
 | i a b |
 i := 1.
 [
  (a := objectA perform: self with: i) isNil ifTrue: [^true].
  (b := objectB perform: self with: i) isNil ifTrue: [^false].
  a < b ifTrue: [^true].
  b < a ifTrue: [^false].
  (i := i + 1) < 1000
 ] whileTrue: [].
 self error: 'An unlikely number of field value matches were returned before returning nil'.
 
Next you add a method to objects that you wish to sort for a criteria. The method should take one argument, which is an index for the sort field to answer. You can even use the same sort criteria method for otherwise dissimilar objects so long as the responses are comparable for a given field index. In this example, #sortableFieldAt: is the sort criteria and when performed will answer the sort field value for a given index:
 
GbcCode>>sortableFieldAt: pos
 ^nil
 
GbcClassReference>>sortableFieldAt: pos
 pos = 1 ifTrue: [^50]. "Order: namespaces, variables, classes, methods"
 pos = 2 ifTrue: [^self hierarchyName].
 pos = 3 ifTrue: [^self lastSourceMagnitude].
 ^nil
 
GbcMethod>>sortableFieldAt: pos
 pos = 1 ifTrue: [^100]. "Order: namespaces, variables, classes, methods"
 pos = 2 ifTrue: [^self className].
 pos = 3 ifTrue: [^self isOverrideInImage ifTrue: [75] ifFalse: [50]].
 pos = 4 ifTrue: [^self isMeta ifTrue: [50] ifFalse: [51]].
 pos = 5 ifTrue: [^self selector].
 pos = 6 ifTrue: [^self lastSourceMagnitude].
 ^nil
 
This is how you'd use it:
 
self asSortedCollection: [:a :b | #sortableFieldAt: should: a comeBefore: b ].
 
If you wanted to use #asSortedCollection then you'd define #<= with a default sort order like this:
 
<= other
    ^#sortableFieldAt: should: self comeBefore: other
 
It fetches a minimal number of field values (but may fetch the same field value more than once). Dissimilar objects can be grouped using a generality from the first field (as shown). One method defines the sort criteria. The sort block specifies the sort criteria to be used but does not define it.
 
This is how the same code can be adapted to caching field values into keys of associations as Steven suggested:
 
    | cachedFields sortedAssociations |
    cachedFields := self collect: [:ea | ea -> ((1 to: 10) collect: [:i | ea sortableFieldAt: i])].
    sortedAssociations := cachedFields asSortedCollection: [:a :b | #at: should: a value comeBefore: b value ].
    ^sortedAssociations collect: [:ea | ea key ]
 
The caching example creates lots of temporary arrays and associations and enumerates more than once; however, it still managed to be 15% faster at sorting 9,467 GbcCode objects in my test. It is faster because it never queries the object more than once for each field value.
 
The caching example caches an arbitrary 10 fields--to accommodate the maximum number of sortable fields in my code. A faster and better approach would likely be to use on-demand query and fill of the cache field values so that field cache collections are grown as necessary and field values are not queried if never used.
 
It would be interesting to compare with the #sortBy: field getter code that Dave showed. I'm not sure there would be much of a performance difference though. Dave's approach is easier to use for application-specified sorts of a collection of homogeneous objects.
 
Paul Baumann 
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Steven Kelly
Sent: Monday, August 09, 2010 7:59 PM
To: Dave Stevenson
Cc: vwnc NC
Subject: Re: [vwnc] Surprise of the day

Neat! I’ve been meaning to implement sorting by multiple criteria for a while. We have something similar (unary sort criterion, block or selector), with our addition being the caching of the result of the sort criterion for each element. This can produce a useful speedup, e.g. if the sort criteria creates a string. Since we only have a single criterion we simply precalculate the sort value for each element, making an association of element->sortValue, sort the associations with a fixed sortBlock using assoc value, and then collect the keys.

 

Steve

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Dave Stevenson
Sent: 10. elokuuta 2010 1:07
To: [hidden email]
Subject: Re: [vwnc] Surprise of the day

 

Some time ago I wrote some extension methods that allow me to pass a block, a selector, or a collection of blocks/selectors for sorting (see attached). It uses #sorted:, so it has the same bug for SortedCollections, but I think folds might find it useful. Here are some examples:

 

 #(-14 3 1 -3 7 12) sortBy: #abs
 #(-14 3 1 -3 7 12) sortBy: #(abs yourself)
 #(-14 3 1 -3 7 12) sortBy: [:x | x \\ 4]
 #(-14 3 1 -3 7 12) sortBy: (List with: [:x | x \\ 4] with: #yourself)

 

The default sort order is ascending, but a variant allows a descending sort:

 

 aCollection sortBy: #name ascending: false

 

I don't like that #sortBy: seems to imply a mutation of the receiver while actually providing a new collection. Perhaps I should have named it #sortedBy: or something. Handling the arguments:
 ...
 value1 := unarySelectorOrBlock isSymbol
  ifTrue: [element1 perform: unarySelectorOrBlock]
  ifFalse: [unarySelectorOrBlock value: element1].
 ...

 

could be streamlined a bit if Squeak Extensions are loaded (which defines Symbol>>value:):
 ...
 value1 := unarySelectorOrBlock value: element1.
 ...

 

but the attached version works in vanilla VW 7.6. In our code, only a few percent of senders of #sortBy: pass a block (likely because #sorted: and #asSortedCollection: already take a block). About a quarter of our senders pass a collection of selectors, and the rest pass a single selector. I've not yet had a desire to pass a mixed collection containing blocks and selectors, but the examples in the method comments validate that case.

 

Paul indicated that #asSortedCollection: is faster than #sorted:, so if that is important to you I confess I did not optimize #sortBy: for speed.

 

If Cincom felt so inclined, they could probably modify #sorted: to take a block, a selector, or a collection thereof, making that single api more flexible, and eliminating my desire for a separate #sortBy: api. Or, the attached can be freely used/modified by anyone.


 

Dave Stevenson
[hidden email]

 

 


From: Paul Baumann <[hidden email]>
To: Julian Fitzell <[hidden email]>; "Joerg Beekmann, DeepCove Labs (YVR)" <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Mon, August 9, 2010 12:32:58 PM
Subject: Re: [vwnc] Surprise of the day


>> I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

Yes, that is a better method comment.

#sorted: is broken, uncommented (at least as of VW 7.5), typically slower, and non-portable. You think #sorted: can be better than #asSortedCollection: and should be fixed instead of removed, I respect that. I see why you appreciate it. I'll stick with #asSortedCollection: until #sorted: is better.

Paul Baumann


-----Original Message-----
From: Julian Fitzell [mailto:[hidden email]]
Sent: Monday, August 09, 2010 6:03 AM
To: Paul Baumann; 'Joerg Beekmann, DeepCove Labs (YVR)'; [hidden email]
Subject: Re: [vwnc] Surprise of the day
Importance: High

On 10-08-06 4:58 PM, "Paul Baumann" <[hidden email]> wrote:
> If the purpose of #sorted: were documented, I think it would read
> "Answer a collection similar to the receiver with contents sorted according to aBlock".
> The "similar to the receiver" part is the only part that would
> distinguish it from #asSortedCollection:.

I disagree. I think it would read "Answer a sequenceable collection containing the contents of the receiver sorted according to aBlock. The receiver is not modified."

A SortedCollection is specifically implemented to allow the contents to change and to remain sorted when elements are added. If you don't need that functionality, there's no point demanding a SortedCollection. #sorted:
allows each collection to make the decision of how to most efficiently create and return the result, whether that is returning a copy of self, a copy with the sort block changed, an Array created in some fashion or other, or some other method. It's a protocol that allows you ask for something specific that you need without specifying the implementation, which is exactly what OO is supposed to be about.

Julian



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
12