Selectable sort

  • Thread starter Thread starter Gary Owsiany
  • Start date Start date
G

Gary Owsiany

Ok, the silence is deafening. I posted my selectable
sort application to show that you can use the IComparable
Interface just as effectively as the IComparer Interface
and the feedback has been, well, there hasn't been any
feedback. Does that mean I have silenced my critics?
Are you so overwhelmed by my programming prowess that I
have left you speechless? Or do you think it is so bad,
that it's not worth responding to?
Chris Dunaway, Herfried, Bill McCarthy are you there?

Gary
 
Hello,

Gary Owsiany said:
Ok, the silence is deafening. I posted my selectable
sort application to show that you can use the IComparable
Interface just as effectively as the IComparer Interface
and the feedback has been, well, there hasn't been any
feedback. Does that mean I have silenced my critics?
Are you so overwhelmed by my programming prowess that I
have left you speechless? Or do you think it is so bad,
that it's not worth responding to?
Click to expand...

I feel sorry, I do not have enough time at the moment to have a look at the
code, but I will repost the link to the code so that the others will find
it:

http://home.swbell.net/gar-car/sourcecode.html

Regards,
Herfried K. Wagner
 
Hi Gary,


I lost track of that thread and have only just caught up with it again. So
much beating about the bush - it's no wonder you're feeling frustrated.

Regarding zipping - there's been a discussion of that in the topic:
"Automating Excel from VB .NET". I'm in favour of zipped files that I can
utilise immediately. If it doesn't make it too big to include the whole
project/solution, I'll thank you for making it easier for me.

I'm off clubbing* tonight so I'll be too tired this weekend.. I <will>
check it out, however - I'll go to your site and dowload, and give you my
thoughts. :-)

Another thought - if you translate it into C# and post it to the
languages.csharp group, you'll be at the bottom of a rugby scrum before you
know it!!

Regards,
Fergus.

* <not> baby seals.
 
Hi Gary,

Correction:
Just downloaded.

Got it into a new solution (I'm on v2002).

Compiled [Had to comment out TestSort.vb: CompareTo()
- Error: Value of type 'Selectable_Sort.TestSort'
cannot be converted to 'Selectable_Sort.Person'.]

Haven't studied the code (see previous post).

But suggestions on the data:
Carol, F and Gary M will sort the same by name or gender.

How about more names fewer numbers. Have some names with both genders,
eg Sam,

How about far, far fewer items. The minimum data set that will
illustrate your point. It's good if it fits in the box such that I don't have
to scroll. I hate playing clicky-clicky - it makes me lose interest.

Later, :-)
Fergus

ps. About that web page .... no comment!! Lol,
 
Gary,
I did take a look to it and for me it looks very nice and compact.
Nick (Nak) was longtime active in this newsgroup to collect all information
about Collections and Arrays.
I think he can give a better comment than me.

Some simple things.
I did not see for what where the raising of the events (I deleted them all
and nothing happened)
I (you see I means nothing) would delete replace the m_ and make it all m
To make it readable for myself I did put all the policies classes on one
page.

And I think you live in the US a datingservice starting at 20 :-)
Here in Europe where I live it is not that age, but for the example it is
nicer to start at 5 or something, that shows that it is a real integer sort
too.
(On msdn there is an example from a datesort with Icomparer, maybe you can
implement that too).

But I did learn again a lot from it and will examine it further.
Thanks
Cor
 
Cor said:
Gary,
I did take a look to it and for me it looks very nice and compact.
Nick (Nak) was longtime active in this newsgroup to collect all information
about Collections and Arrays.
I think he can give a better comment than me.

Some simple things.
I did not see for what where the raising of the events (I deleted them all
and nothing happened)
I (you see I means nothing) would delete replace the m_ and make it all m
To make it readable for myself I did put all the policies classes on one
page.

And I think you live in the US a datingservice starting at 20 :-)
Here in Europe where I live it is not that age, but for the example it is
nicer to start at 5 or something, that shows that it is a real integer sort
too.
(On msdn there is an example from a datesort with Icomparer, maybe you can
implement that too).

But I did learn again a lot from it and will examine it further.
Thanks
Cor
Click to expand...
Thanks for the feedback. Yes, there were some "unused" events. I am
currently programming in Smalltalk and it is a "normal" practice on
"setters" to include the event. That way, it is available for binding. My
main focus was the use of the IComaparable vs. the IComparer Interface. My
view is to give the object (Person in this case) the behavior of sorting, as
opposed to "funneling" all of the person objects through a "sorter" that is
given the sorting algorithm to use. The analogy is a teacher in a classroom
who wants to sort the students by age. The "IComparable" way is that the
students are told to "sort yourself by age" and let the students do it
themselves. The teacher doesn't have any knowledge of the student's ages.
The "IComparer" way is that each student has to come to the teacher who then
asks "what is your age?" and then he places each student in the correct
order.
 
Hi Gary,

I had a good old study and was horrified!!

Ok, I'm only teasing, I needn't be so alarmist. There were some things
that I didn't like so I changed them. :-). But that then left a cold wind
blowing through a different hole! Swings and roundabouts coming up.

Firstly I agree with you that "sort yourselves out" has a better feel to
it than "line up over there while Mr Sorter deals with you". I think it's
better for a user if they don't have to worry about having to specify a
comparer.

Saying alFoo.Sort() is nice and simple. The list of Foos gets sorted
without user interaction. As it should be - who knows more about a Foo than
clsFoo?

Another alternative is that clsFoo defines the comparer and the user
specifies it
alFoo.Sort (clsFoo.BuiltInFooComparer1)

The last, and most common case, is that the user has to implement the
whole thing
alFoo.Sort (UserDefinedFooComparer).
Which is not hard but it's always a pause in the flow. And an odd scrap of
code that has to be stuck somewhere.

The first and second alternatives get a bit not-much-difference-there-ish
when using the non-default comparer. Because while in the second you just use
clsFoo.BuiltInFooComparer2 instead of 1, in the first you need an extra line
to tell the Foos which comparer to use. clsFoo.SortBy (ComparerId).

I had a look at what Help had to say about IComparable. There aren't many
Types that implement it - just the basic ones - Numbers, Enums, Strings (and
Versions).

Here's the bit that had me worried: In the central class, Person, each
Person has their own instance of SortPolicy (and SortPolicyChanged). That's
not good for three reasons. The first is that it's a lot of overhead for what
is probably a minor part of a Person's function. Secondly every change of
SortPolicy requires a change to every Person in the array to be sorted.
Finally it's possible to assign different policies to different Persons.
Sorting an array of such would be highly unpredictable.

In finding out what implements IComparable, I had to consider - Strings
and Numbers don't carry around a SortPolicy. Programmers would be up in arms!
So it must be that the <class> impements the interface. So that was the first
change I made to the code. I specified the SortPolicy field, Property and
Changed event as Shared.

This made it easier in the DatingService, too. The loop went straight out,
to be replaced by ArrayList.Clone() and Person.SortPolicy=.... [ps. Why did
you use an enumerator rather than For Each - Is that SmallTalk talking?].

Having the class determine the SortPolicy fixes the efficiency and
security issues but that cold wind blows. What if I have two arrays of Persons
and want them sorted in different ways?

Over to you Gary. Your turn in this discussion. :-)

Regards,
Fergus
 
Fergus Cooney said:
Hi Gary,

I had a good old study and was horrified!!

Ok, I'm only teasing, I needn't be so alarmist. There were some things
that I didn't like so I changed them. :-). But that then left a cold wind
blowing through a different hole! Swings and roundabouts coming up.

Firstly I agree with you that "sort yourselves out" has a better feel to
it than "line up over there while Mr Sorter deals with you". I think it's
better for a user if they don't have to worry about having to specify a
comparer.

Saying alFoo.Sort() is nice and simple. The list of Foos gets sorted
without user interaction. As it should be - who knows more about a Foo than
clsFoo?

Another alternative is that clsFoo defines the comparer and the user
specifies it
alFoo.Sort (clsFoo.BuiltInFooComparer1)

The last, and most common case, is that the user has to implement the
whole thing
alFoo.Sort (UserDefinedFooComparer).
Which is not hard but it's always a pause in the flow. And an odd scrap of
code that has to be stuck somewhere.

The first and second alternatives get a bit not-much-difference-there-ish
when using the non-default comparer. Because while in the second you just use
clsFoo.BuiltInFooComparer2 instead of 1, in the first you need an extra line
to tell the Foos which comparer to use. clsFoo.SortBy (ComparerId).

I had a look at what Help had to say about IComparable. There aren't many
Types that implement it - just the basic ones - Numbers, Enums, Strings (and
Versions).

Here's the bit that had me worried: In the central class, Person, each
Person has their own instance of SortPolicy (and SortPolicyChanged). That's
not good for three reasons. The first is that it's a lot of overhead for what
is probably a minor part of a Person's function. Secondly every change of
SortPolicy requires a change to every Person in the array to be sorted.
Finally it's possible to assign different policies to different Persons.
Sorting an array of such would be highly unpredictable.

In finding out what implements IComparable, I had to consider - Strings
and Numbers don't carry around a SortPolicy. Programmers would be up in arms!
So it must be that the <class> impements the interface. So that was the first
change I made to the code. I specified the SortPolicy field, Property and
Changed event as Shared.

This made it easier in the DatingService, too. The loop went straight out,
to be replaced by ArrayList.Clone() and Person.SortPolicy=.... [ps. Why did
you use an enumerator rather than For Each - Is that SmallTalk talking?].

Having the class determine the SortPolicy fixes the efficiency and
security issues but that cold wind blows. What if I have two arrays of Persons
and want them sorted in different ways?

Over to you Gary. Your turn in this discussion. :-)

Regards,
Fergus
Click to expand...
Easy answer first. Yes it is a Smalltalk thing to use iterators. In
Smalltalk all collections know how to iterate over themselves so all you do
is say: "SomeCollection do: [ :each | each blah ]." The do: method is the
"iterator". Using For..Next in Smalltalk is "not cool".

Next, I think you must have missed the fact that the SortingPolicy variable
is a Class (i.e. Public Shared) variable on Person. That means all
instances of the Person class will share the same value (that's why I made
it a class variable). That way I only need to assign it once, and I can be
sure that all instances of the Person class will sort properly (Notice in
the DatingService class that the SortMembers() method uses
Person.SortingPolicy = ...). It is only an instance variable in the
DatingService class. The addMember() method on DatingService is a bit
deceptive, but my understanding of VB is that you can use either the Class
name (Person) or an instance reference (in this case aPerson) to access the
value. I was just testing out this part of VB for my own sake. I could
have just used Person.SortingPolicy in AddMember().

As for the last question, (what if I have two arrays of Persons needing
different sorts), my answer is I didn't have two arrays of Persons that
needed to be sorted differently - that's why I wanted to build a full
working application. It was never a requirement (of this app) to have two
arrays that sorted differently (even though, that occurs in dating service,
the original array is a collection of Persons that is "sorted differently"
than the sorted array in the second list). However, if that had been a
requirement, I may have designed it differently. I design my apps based on
requirements, not "what-ifs".

Back to you, Fergus.

Regards,
Gary
 
Correction--
After your comments about using an instance variable and changed event on
sorting policy, I took another look at my zip file and I realized that I
zipped the wrong version of the project. This version was a test to see
what the overhead would be if I used and "instance" variable for my sorting
policy, as opposed to a class variable. Sorry for the confusion. You are
right in your comment that says a Public Shared (Class) variable handles the
sorting policy on Person better than an instance variable.
My mistake.
I will upload the other version.

Regards,
Gary

Fergus Cooney said:
Hi Gary,

I had a good old study and was horrified!!

Ok, I'm only teasing, I needn't be so alarmist. There were some things
that I didn't like so I changed them. :-). But that then left a cold wind
blowing through a different hole! Swings and roundabouts coming up.

Firstly I agree with you that "sort yourselves out" has a better feel to
it than "line up over there while Mr Sorter deals with you". I think it's
better for a user if they don't have to worry about having to specify a
comparer.

Saying alFoo.Sort() is nice and simple. The list of Foos gets sorted
without user interaction. As it should be - who knows more about a Foo than
clsFoo?

Another alternative is that clsFoo defines the comparer and the user
specifies it
alFoo.Sort (clsFoo.BuiltInFooComparer1)

The last, and most common case, is that the user has to implement the
whole thing
alFoo.Sort (UserDefinedFooComparer).
Which is not hard but it's always a pause in the flow. And an odd scrap of
code that has to be stuck somewhere.

The first and second alternatives get a bit not-much-difference-there-ish
when using the non-default comparer. Because while in the second you just use
clsFoo.BuiltInFooComparer2 instead of 1, in the first you need an extra line
to tell the Foos which comparer to use. clsFoo.SortBy (ComparerId).

I had a look at what Help had to say about IComparable. There aren't many
Types that implement it - just the basic ones - Numbers, Enums, Strings (and
Versions).

Here's the bit that had me worried: In the central class, Person, each
Person has their own instance of SortPolicy (and SortPolicyChanged). That's
not good for three reasons. The first is that it's a lot of overhead for what
is probably a minor part of a Person's function. Secondly every change of
SortPolicy requires a change to every Person in the array to be sorted.
Finally it's possible to assign different policies to different Persons.
Sorting an array of such would be highly unpredictable.

In finding out what implements IComparable, I had to consider - Strings
and Numbers don't carry around a SortPolicy. Programmers would be up in arms!
So it must be that the <class> impements the interface. So that was the first
change I made to the code. I specified the SortPolicy field, Property and
Changed event as Shared.

This made it easier in the DatingService, too. The loop went straight out,
to be replaced by ArrayList.Clone() and Person.SortPolicy=.... [ps. Why did
you use an enumerator rather than For Each - Is that SmallTalk talking?].

Having the class determine the SortPolicy fixes the efficiency and
security issues but that cold wind blows. What if I have two arrays of Persons
and want them sorted in different ways?

Over to you Gary. Your turn in this discussion. :-)

Regards,
Fergus
Click to expand...
 
Hi Gary,

I'm curious - What's wrong with For..Each ? In VB it's just simple syntax
for an iterator. What does it do in SmallTalk that's different?

[I've read your correction].

The main thrust of my post was about the need for a class-level
SortPolicy. But we are both in agreement on that. :-)

The last part about multiple lists was actual an argument against me (as
the sole proponent, at that point, of shared) but it now falls upon us both.

|| I design my apps based on requirements, not "what-ifs".


I don't accept your cop out [pokes out tongue] of only designing the class
for right here, right now, nothing more. If that's habitual then it's a bit
like cultivating blinkers, which seems a shame.* There are levels of what-if.
There's a big difference between what if I have two lists of Persons and what
if I design my class to be able to interact with a multitude of other classes
in an orgy of mutual sorting!! [The mind boggles :-)]

You've given a nice angle on sorting but you refuse to address a detail
that so severely restricts its use ? No. I want more from you than that. :-)

Regards,
Fergus

* [I say that because I'm sort of the opposite - I have wild flights of
fantasy before I settle down to an implementation.]
 
Hi Gary
When you have done that, will you then place the Url in this thread?
We love to make long threads
Cor
 
Back
Top