so that we can discuss in the list
This is related to http://code.google.com/p/pharo/issues/detail? id=1353
According to usage of classVarNames, a sorted Array would behave better
- same class as instVarNames (I remember such discussion in Pharo) - optimized without extra code cost (especially if keys are also an Array) - sorted Array do compare fast with = (better than Sets) - no need to sort a sorted Array, so half senders will be simplified
Delete commentComment 1 by bschwab@anest.ufl.edu, Today (11 hours ago) This gives me Dolphin flashbacks to a change (IIRC in the RB) that had to be regressed because it broke the serializer. I am only now getting close to using SIXX (the presumptive successor to Dolphin's STB for me), so I do not know whether the analogy will hold. However, it seems to me that knowing the order in which things were defined is important. If a sender wants them sorted, a single #asSortedCollection should "sort" the problem, but there is no way to undo it if the result is sorted before one sees it. Another option would be to add #basicXYZ to return the unsorted version of the collection and then do as you propose; either way, I think the unsorted order should be preserved for the sake of serializers and similar systems.
Delete commentComment 2 by nicolas.cellier.aka.nice, Today (2 hours ago) The problem of current definition of classVarNames is precisly that they are unordered. The order is not defined by user, it just depend on the hash codes of classVarNames modulo the size of classPool, unless we sort them. Please look at usage.
On Oct 21, 2009, at 11:23 PM, Nicolas Cellier wrote:
Proposal is logged at http://code.google.com/p/pharo/issues/detail?id=1354 Recently in trunk
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project