sort procedure of T(FP)List

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

sort procedure of T(FP)List

Marc Santhoff
Hi,

i wonder why the declaration of the comparing function of list objects
is the way it is:

TListSortCompare = function (Item1, Item2: Pointer): Integer;

Since I am writing a class that sorts a list it owns depending on
another property naming the property of the list items for sorting, I
would like to have it made a "procedure of object":

TListSortCompare = function (Item1, Item2: Pointer): Integer of object;

I'm dealing with lists of files and directories that should get sorted
by name, date, ...
If the comparing function is a plain non object function I have to make
some sort of unit global variable or the like for telling it, what
property is the sort criteria. I don't like this design, although in
this case there is only one soritng process at a time.

Is this a concession imposed by Delphi compatibility?

(If you can suggest a better strategy for using this stuff, please do.)

TIA;
Marc


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: sort procedure of T(FP)List

Geno Roupsky


2006/5/2, Marc Santhoff <[hidden email]>:
Hi,

i wonder why the declaration of the comparing function of list objects
is the way it is:

TListSortCompare = function (Item1, Item2: Pointer): Integer;

Since I am writing a class that sorts a list it owns depending on
another property naming the property of the list items for sorting, I
would like to have it made a "procedure of object":

TListSortCompare = function (Item1, Item2: Pointer): Integer of object;

I'm dealing with lists of files and directories that should get sorted
by name, date, ...
If the comparing function is a plain non object function I have to make
some sort of unit global variable or the like for telling it, what
property is the sort criteria. I don't like this design, although in
this case there is only one soritng process at a time.

Is this a concession imposed by Delphi compatibility?

It is in fact Delphi that did it that way

(If you can suggest a better strategy for using this stuff, please do.)

In fact you could have different function for every kind of sort and switch them on the fly when the properties determining the kind of sort that should be made changes. In my experience there is no much code duplication involved in this technique and you could make for example one compare function for every field, after that you make a _complex_ ones calling the simple ones.

Either way it is not very OO based approach but of course you could make a descendand class of tfplist and add you own sorting code.
--
Geno Roupsky
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: sort procedure of T(FP)List

Marc Santhoff
Am Freitag, den 05.05.2006, 11:03 +0300 schrieb Geno Roupsky:
> In fact you could have different function for every kind of sort and
> switch them on the fly when the properties determining the kind of
> sort that should be made changes. In my experience there is no much
> code duplication involved in this technique and you could make for
> example one compare function for every field, after that you make a
> _complex_ ones calling the simple ones.

The only thing I'm afraid of is stumbling into threading issues in the
future (most likely when I have fogotten the details of sorting ;).

> Either way it is not very OO based approach but of course you could
> make a descendand class of tfplist and add you own sorting code.

This is what I did.

Thanks,
Marc


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: sort procedure of T(FP)List

Geno Roupsky


2006/5/6, Marc Santhoff <[hidden email]>:
Am Freitag, den 05.05.2006, 11:03 +0300 schrieb Geno Roupsky:
> In fact you could have different function for every kind of sort and
> switch them on the fly when the properties determining the kind of
> sort that should be made changes. In my experience there is no much
> code duplication involved in this technique and you could make for
> example one compare function for every field, after that you make a
> _complex_ ones calling the simple ones.

The only thing I'm afraid of is stumbling into threading issues in the
future (most likely when I have fogotten the details of sorting ;).

It is the response of the compare function not the sorting one to synchronize whatever global(outside it's scope) variables is accesses, so no matter what approach you take you still will have issues with threads.

--
Geno Roupsky
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: sort procedure of T(FP)List

Marc Santhoff
Am Samstag, den 06.05.2006, 19:36 +0300 schrieb Geno Roupsky:

>
>
> 2006/5/6, Marc Santhoff <[hidden email]>:
>         Am Freitag, den 05.05.2006, 11:03 +0300 schrieb Geno Roupsky:
>         > In fact you could have different function for every kind of
>         sort and
>         > switch them on the fly when the properties determining the
>         kind of
>         > sort that should be made changes. In my experience there is
>         no much
>         > code duplication involved in this technique and you could
>         make for
>         > example one compare function for every field, after that you
>         make a
>         > _complex_ ones calling the simple ones.
>        
>         The only thing I'm afraid of is stumbling into threading
>         issues in the
>         future (most likely when I have fogotten the details of
>         sorting ;).
>
> It is the response of the compare function not the sorting one to
> synchronize whatever global(outside it's scope) variables is accesses,
> so no matter what approach you take you still will have issues with
> threads.

Yes, and it is much easier to deal with this in objects as instances of
classes than to do it on procedure level counting bytes with getmem
(imo).

That's why i wanted to use a function of object (avoiding nasty
globals). I've written it already ans it is very clear and compact.

Regards,
Marc


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal