Collection sorting question..

Hi all..

I've got a SortedCollection that I'm creating and overriding the
#sortBlock on to specify my own algorithm for the sort and this works
great for any subsequent #add that I do..  However, my problem arises
later after these objects are written out to a pgsql database w/ Glorp's
help.  Once I re-read these objects, that customized #sortBlock is now
gone and my sorting reverts back to the default algorithm -- I tried
overriding #<= for the object, but had other issues when I was doing
#add w/ it and losing every other added object for some reason (but
#sortBlock worked fine).  Are there other ways to override the default
sort for a collection that can be part of the object itself instead of
being specified outside the scope of the object (after the object is
instantiated)?  I guess I'd like to know if I can just specify
#sortBlock as a method in my object that is part of the collection -- I
looked briefly at the SortedCollection code and it didn't seem like it..
I'm sure this falls under the newbie category!

Thanks!

Rick Flower wrote:
Nevermind.. I ended up subclassing SortedCollection and overriding
#initialize (not the class side version) and set the instance variable
'sortBlock' to have my own custom sort algorithm and it seems to work fine.

Rick Flower wrote: Your first solution was a correct one -- change the <=  in the objects
being sorted.
Change the sortBlock: is also valid.  I don't know Glorp -- do you have
access to the sortedCollection before
it gets loaded to set a sortBlock:??  If not, then I would fall back on
the <= change in your objects.


>
>

--
Dennis Smith                        [hidden email]
Cherniak Software Development Corporation       +1 905.771.7011
400-10 Commerce Valley Dr E                Fax: +1 905.771.6288
Thornhill, ON Canada L3T 7N7    http://www.CherniakSoftware.com

Dennis Smith wrote:

> Your first solution was a correct one -- change the <=  in the objects
> being sorted.
> Change the sortBlock: is also valid.  I don't know Glorp -- do you have
> access to the sortedCollection before
> it gets loaded to set a sortBlock:??  If not, then I would fall back on
> the <= change in your objects.

I don't believe that Glorp allows some sort of intervention after
objects are read in but before they can be operated on (for lack of a
better term).. I might try fiddling with the <= again and see if I can
get it working -- I'd rather have the sort algorithm in the object being
sorted instead of as part of another (more specific) object.

At 05:29 PM 10/19/2006, Rick Flower wrote:
>Dennis Smith wrote:
>
>>Your first solution was a correct one -- change the <=  in the objects being sorted.
>>Change the sortBlock: is also valid.  I don't know Glorp -- do you have access to the sortedCollection before
>>it gets loaded to set a sortBlock:??  If not, then I would fall back on the <= change in your objects.
>
>I don't believe that Glorp allows some sort of intervention after objects are read in but before they can be operated on (for lack of a better term).. I might try fiddling with the <= again and see if I can get it working -- I'd rather have the sort algorithm in the object being sorted instead of as part of another (more specific) object.

Defining <= really ought to work. If it doesn't, something is seriously wrong somewhere (probably with the <= method).

It does seem like rather a limitation not to be able to specify a sorted collection with a sort block for an attribute to be read from the database. So now you can specify the collectionType: of an attribute as a collection instance as well as a collection class. So if you do
     aClassModel newAttributeNamed: #things collection: (SortedCollection sortBlock: [:a :b | a flirp: b]) of: Things.
it'll be sorted on read from the database.

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

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Alan Knight wrote:

> Defining <= really ought to work. If it doesn't, something is
> seriously wrong somewhere (probably with the <= method).

That's what I thought, but was missing 1/2 of my collection for some
reason.. I'll look into it further and see what I can find!

> It does seem like rather a limitation not to be able to specify a
> sorted collection with a sort block for an attribute to be read from
> the database. So now you can specify the collectionType: of an
> attribute as a collection instance as well as a collection class. So
> if you do aClassModel newAttributeNamed: #things collection:
> (SortedCollection sortBlock: [:a :b | a flirp: b]) of: Things. it'll
> be sorted on read from the database.

Alan -- are you suggesting that a new feature has been added to Glorp to
address this?  That would be pretty cool.. Thanks..

-- Rick

At 06:05 PM 10/19/2006, Rick Flower wrote:
Alan -- are you suggesting that a new feature has been added to Glorp to address this?  That would be pretty cool.. Thanks..
--

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

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross