SortedCollection enhancement

I again,

I forgot to ask the most important question ;-)

Does your implementation support switching between ascending/descending for one or more criteria once a collection has been sorted? I guess this is just a matter of changing a boolean and resorting the collection, right?

Joachim

Am Mittwoch, 17. September 2014 09:06:58 UTC+2 schrieb Joachim Tuchel:

Hi Lou,

I had this thread somewhere in the back of my head and am happy I found it.

I will soon need to add some complex sorting to tables and would like to give your code a try.

So: is the file out still current? (If it was my code, there would be around 78 fixes of stupid typos and such over three years)

Would you consider putting it onto vast goodies?

Thanks,

Joachim

Am Dienstag, 1. November 2011 15:53:07 UTC+1 schrieb Louis LaBrunda:

Hi Joachim,

Thanks for your comments.  I decided to go with the methods as described in my last post:

#add:
#addAsc:
#addDesc:

Where the parameter of #add: is an association. I might allow a symbol and default the direction to ascending. I'm open to suggestions on that.

The parameters for #addAsc: and #addDesc: would be symbols.

I have attached the latest fileout.  I hope all these attachments are not a problem for the forum.

For those wondering why I chose to use a boolean the represent the direction instead if a symbol like #Asc or atom like ##Asc, which would be clearer, looking at the the code in #value:value: should tell the story.

Ordinarily one would test the direction and then test for < or > based upon the direction.  Using booleans for the direction eliminates that test and allows the direction value to be the return value of   #value:value:.  This makes for less code and then arguably simpler code.  The test for = and nil protect the code from blowing up with nil values and treats them as less than.

Lou

Hi Joachim,

I have attached a fresh copy of the file out of the DynamicSortBlock class, just in case although I don't think there have been many if any changes.  I should put it in VAST Goodies but right now it is in an app with lots of other little classes so I will need to pull it out into its own app.

DynamicSortBlock acts like a two argument block of code and is used any place a sort block can be used.  It does its work in the #value:value: method (see its comment).  The rest of the methods just make it ease to setup.  It contains two matching ordered collections: #accessors and #directions.  The #accessors collection contains symbols that represent methods of the objects being sorted that should answer the value of interest.  The #directions collection contains booleans (true or false) that represent the direction of sorting for its corresponding accessor (true means ascending, false means descending).  This allows some parts of the sort to be ascending while others are descending.  For example if you are sorting products by descending price and ascending name.

Now to answer your question:

Does your implementation support switching between ascending/descending for one or more criteria once a collection has been sorted? I guess this is just a matter of changing a boolean and resorting the collection, right?

Yes.  DynamicSortBlock is a pretty light weight class, so you could just have two or more defined however you like but the #accessors and #directions collections are exposed and you can do what you like to then.  So, if you wanted to change one or more directions you could or replace the whole collection of directions.  But I think having two instances of DynamicSortBlock would be best.

I hope you find it useful, I have.  Just ask if you have any questions.

Lou

On Wednesday, September 17, 2014 3:09:10 AM UTC-4, Joachim Tuchel wrote:

I again,

I forgot to ask the most important question ;-)

Does your implementation support switching between ascending/descending for one or more criteria once a collection has been sorted? I guess this is just a matter of changing a boolean and resorting the collection, right?

Joachim

Am Mittwoch, 17. September 2014 09:06:58 UTC+2 schrieb Joachim Tuchel:

Hi Lou,

I had this thread somewhere in the back of my head and am happy I found it.

I will soon need to add some complex sorting to tables and would like to give your code a try.

So: is the file out still current? (If it was my code, there would be around 78 fixes of stupid typos and such over three years)

Would you consider putting it onto vast goodies?

Thanks,

Joachim

Am Dienstag, 1. November 2011 15:53:07 UTC+1 schrieb Louis LaBrunda:

Hi Joachim,

Thanks for your comments.  I decided to go with the methods as described in my last post:

#add:
#addAsc:
#addDesc:

Where the parameter of #add: is an association. I might allow a symbol and default the direction to ascending. I'm open to suggestions on that.

The parameters for #addAsc: and #addDesc: would be symbols.

I have attached the latest fileout.  I hope all these attachments are not a problem for the forum.

For those wondering why I chose to use a boolean the represent the direction instead if a symbol like #Asc or atom like ##Asc, which would be clearer, looking at the the code in #value:value: should tell the story.

Ordinarily one would test the direction and then test for < or > based upon the direction.  Using booleans for the direction eliminates that test and allows the direction value to be the return value of   #value:value:.  This makes for less code and then arguably simpler code.  The test for = and nil protect the code from blowing up with nil values and treats them as less than.

Lou