ouf honor is safe :) So try to convince VA to do a better job than ANSI. because with sort: polymorph and sorted (suboptimal but ok) we can have a better solution
Stef >>>>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and >>>>>>> an instance creation method. That's what it sounds like and shouldn't >>>>>>> be implemented on non-sorted collections. >>>>>> >>>>>> Why? what would be the reason not to use sortBlock: for others? >>>>> >>>>> The intention is different. #sortBlock: tells a collection to maintain >>>>> itself as sorted even after additions and deletions. This message is not >>>>> appropriate for collections that do not have that ability. >>>>> >>>>> #sortBlock: is not the best name for this functionality, but I think >>>>> it's bad to use #sortBlock: with a different meaning. >>>> >>>> I agree :) >>>> Now SortedCollection should understand sort too which uses sortBlock: >>>> My main concern is polymorphism between collection which are nearly the >>>> same! >>> >>> #sortBlock: is an accessor for the sortBlock instance variable on >>> SortedCollection. It makes no sense for a collection that doesn't have >>> that instance variable to have that accessor. >> >> did I say that? I do not think so. I'm not that idiot. >> No I say that SortedCollection should understand sort: > > Ah, apologies - I misunderstood what you were saying (I was a little > surprised that you would be arguing what I thought you were arguing :) > ). > > Julian > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
