Hi guys.
This is a thing that I encounter quite often.
Eg I have a collection of projects and I want to sort them by creation date. It
would be nice to be able to do something like:
projects sortByProp: #creationDate
or by birth date of the author
projects sortByProp: [ :proj | proj author bi
Hi Yuriy,
I though the same. There is a similar situation with pluggable collections
where you have to specify two blocks: one for the hash the other for equality.
So you have to repeat three times the property you're interested in:
PluggableSet new
hashBlock: [ :each | each name hash ];
Hello,
[ Note: So in the default Pharo the method is named #sort: not #sortByProp:
or #sortBy: but it's a detail ]
I like this idea because I also have always the problem. So I would like to
be able to do:
projects sort: #creationDate
The implementation would be, in a similar fashion to how Sym
On 11 Mar 2014, at 10:19, Clément Bera wrote:
> Hello,
>
> [ Note: So in the default Pharo the method is named #sort: not #sortByProp:
> or #sortBy: but it's a detail ]
Yes, my mistake, I was misguided by #isSortedBy:
Now #sortByProp: is my own example method that accepts a block and execute
Hello,
@Uko
Well I implemented Symbol>>value:value: in a similar fashion than
Symbol>>value: for 'aCollection collect: #aSymbol'. But that's not a
perfect solution for sure.
@Camille
I used PluggableSet and PluggableDictionary in my project and they were so
slow that in the end I implemented my
hi Uko,
For Roassal, we have a #sortedAs: defined on all collections
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
SequenceableCollection>>sortedAs: aSortBlockOrSymbol
"Answer a SortedCollection whose elements are the elements of the
receiver. The sort order is defined by the argument, aSortBl
Hi Alexandre,
IMO the isKindOf:, apart from being ugly, will hurt performance badly.
Why not apply aSortBlockOrSymbol to the first element and then choose the
block appropriately? e.g.
aSortBlockOrSymbol isSymbol
ifTrue:
[(#(true false) includes: (self first perform:
On Tue, Mar 11, 2014 at 12:19 PM, Eliot Miranda wrote:
> Hi Alexandre,
>
> IMO the isKindOf:, apart from being ugly, will hurt performance badly.
> Why not apply aSortBlockOrSymbol to the first element and then choose the
> block appropriately? e.g.
>
> aSortBlockOrSymbol isSymbol
>
and here's one with a better comment that includes examples
On Tue, Mar 11, 2014 at 12:19 PM, Eliot Miranda wrote:
> Hi Alexandre,
>
> IMO the isKindOf:, apart from being ugly, will hurt performance badly.
> Why not apply aSortBlockOrSymbol to the first element and then choose the
> block a
Thanks eliot.
On 11 Mar 2014, at 20:51, Eliot Miranda wrote:
> and here's one with a better comment that includes examples
>
>
> On Tue, Mar 11, 2014 at 12:19 PM, Eliot Miranda
> wrote:
> Hi Alexandre,
>
> IMO the isKindOf:, apart from being ugly, will hurt performance badly.
> Why
HiSince Symbol and Blocks are polymorphic could we not simplify the code to be:SequenceableCollection>>sortedAs: aSortBlockOrSymbol "Answer a SortedCollection whose elements are the elements of the receiver. The sort order is defined by the argument, aSortBlockOrSymbol. The receiver cannot be empt
Why do we need one method that takes either a block or symbol?
> SequenceableCollection>>sortedAs: aSortBlockOrSymbol
Perhaps sort: can take a block and sortedAs: a symbol?
Exactly!
Essentially, value: should replace pretty much all usages of perform:. For
example, if Morphic would use value: variants instead of perform: we could
script them without being obliged to create model classes. It would serve
the spirit of fast prototyping much better.
Cheers,
Doru
On Tu
We could indeed, but it offends my sense of value (excuse the pun), since
Symbol>>value: is implemented in terms of #perform: and so is slower. Since
this is a general library routine performance is an issue (the sort block is
used N log N times in sorting the collection) and so I prefer the us
Hi Otto
I think the main reason is to support the second usage scenario:
SequenceableCollection withAllSubclasses sortedAs: [:class | class
methodDict size].
We could try and unify the sort: method to take only blocks while sortedAs:
a symbol but then at the same time we could just put everything
I presume you all know about Griggs work on the subject
http://stackoverflow.com/questions/8204826/smalltalk-sort-a-collection-by-two-criteria
http://objology.blogspot.com/2010/11/tag-sortfunctions.html
2014-03-12 11:23 GMT+01:00 carlo.t :
> Hi Otto
>
> I think the main reason is to support the
Is this multisort feature available for Pharo somewhere?
Regards!
Esteban A. Maringolo
2014-03-12 7:45 GMT-03:00 Nicolas Cellier :
> I presume you all know about Griggs work on the subject
>
> http://stackoverflow.com/questions/8204826/smalltalk-sort-a-collection-by-two-criteria
> http://objol
It's ultra-easy to port, I gave it a try at
MCHttpRepository
location: 'http://smalltalkhub.com/mc/nice/NiceVMExperiments/main'
user: ''
password: ''
See packages TAG-SortFunctions and TAG-SortFunctionsTests
Travis didn't mention the license, so we'll have to ask him.
2014-03-12 13
18 matches
Mail list logo
