04-14-2010 07:57 AM
I vote that we either implement an overrideable "sort value" method for all classes (default empty string) or we simply ignore classes when sorting.
Having LV peek at the private data behind the scenes makes me a bit queasy. This could be manipulated to find out class data contents.....
Just my 2c.
Shane
04-14-2010 10:09 AM
04-14-2010 10:49 AM
04-14-2010 11:40 AM
I see. You're talking about the middle image in the original post.
I can see why you would want that to work, but it should pointed out that the logic for breaking the wire in the rightmost image applies in the center image as well. The fact that the class is third in order and will probably not be used for sorting does not mean that it will NEVER be used for sorting. I would say that IF this was changed, then classes should have no effect on the sort and should be returned in the same order they were in the original array.
04-14-2010 01:20 PM
Sounds good to me...just treat the LV Classes like they are all the same value, for the purposes of sorting. Anyway, I included a link to this thread in the CAR, so these ideas should be visible to the eventual CAR fixer.
04-14-2010 03:46 PM
Yup, ignore the classes when sorting as I said previously.
I don't think anything else is really viable.
Shane.
04-15-2010 02:02 AM
04-15-2010 04:06 AM
Well that's a goot time to teach the user about the meaning of private data and encapsulation and why it's NOT a bug.
Shane.
04-15-2010 08:17 AM
Something to that effect should be added to the Sort documentation when this issue is resolved.
Lynn
04-15-2010 10:10 AM
Intaris wrote:Well that's a goot time to teach the user about the meaning of private data and encapsulation and why it's NOT a bug.
This has less to do with encapsulation and more with the class-is-a-data-type concept. To sort any data type, you need some sort of logic and the problem is compounded when you need to sort "non-matching" data types.