Fwd: sort: and sortBlock:
Locked
1234
1234
Re: FixedIdentitySet [was Re: Fwd: sort: and sortBlock:]
 
|
2009/12/23 Martin McClure <[hidden email]>:
> Nicolas Cellier wrote: >> >> While looking at it, FixedIdentitySet asArray ^ self, is this really expected ? > > FixedIdentitySet is a very odd beast. I'm afraid I don't see the value > of it at all, but I haven't looked at the code that uses it. > > Regards, > > -Martin > Yes, very bad example, only used in traits implementation and should be considered as private, so who ever use it should learn to not send asArray, nor any other inherited message but a few. I suspect inheriting basicAt: basicAt:put: and basicSize: should be enough, which completely disqualify the choice of superclass, but I won't bother more. Anyway, I'm impressed by (Array allSubclasses size), I would expect zero as a good number. Nicolas > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: sort: and sortBlock:
|
|
In reply to this post by Martin McClure-2
>> Not really :)
>> I was more looking at the user perspective. >> You often want an orderedCollection (add:) vs Array at: >> but which deals with duplicate as a Set. > > Could you clarify? What's an example? In Moose we build package representation in which the order is important first references is more important that second. Now my colleagues used an OrderedSet to keep the order but make sure that he can use add: (but did not care of possible duplicates). > What is the index of something > that you add but was already there? From his example the index is more important per se as soon as the order is kept since after he iterates on this data structure to build visualization. > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: sort: and sortBlock:
|
|
In reply to this post by Martin McClure-2
>
> #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! > #sorted, #sorted: -- VW already has this. VA is adding it. >> >> What is sorted? a boolean predicate method? >> What a bad name. Did they forgot Kent? > > An example of my previous message -- this name is confusing and should > probably not be used. Yes I agree > Squeak/Pharo should add it, IMO, but we'll add it to Grease if not. It >>> returns a sorted copy of SequenceableCollections and a sorted Array of >>> all other collections. >> >> Please not this is bogus. It does not work with certain subclasses of Sequenceable >> And much more important it has a bad name. >> Because with a nice name >> sortCopy then it would be much better. >> So with one method in VW you can get it >> >> sortCopy >> ^ self sorted > > +1 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: sort: and sortBlock:
|
|
In reply to this post by Martin McClure-2
On Dec 23, 2009, at 10:57 PM, Martin McClure wrote: > Stéphane Ducasse wrote: >>> >>> Not all collections are sortable and #sort: is sorting in-place, so it's hardly doable. >> >> But it would be nice to have sort: and sortBlock: polymorph. >> Because right now we cannot have OrderedCollection and Array or SortedCollection interchanged. > > OrderedCollection, Array, and SortedCollection by design all have > different semantics, not just different internal implementations. In > such a case you cannot expect to be able to interchange them in all > circumstances. sure but when I know what I'm doing iterating for example I should be able and sorting them before iterating is a good motivation to iterate on them. > In many cases you can, but when for instance you use #sortBlock: you'd > better not have an Array or OrderedCollection, and when you use #add: > you'd better not have an Array, because those classes do not support the > *meanings* of those selectors. Yes I know :) Now not having sort in SortedCollection is a lack of vision. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: sort: and sortBlock:
|
|
In reply to this post by Nicolas Cellier
>>
> > I'd like a selector that I can apply to any collection like a Set too. > For example, in some implementations keys are a Set (original st80) in > others keys are an Array (Squeak trunk/Pharo). > So, in order to have more portable pieces of code I ended up with > (self keys asArray sort). > Maybe the most simple thing would be to define > Collection>>sort > ^self asArray sort May be and to redefine it on OrderedCollection, ArrayedCollection and SortedCollection Now in VW sorted consistently do a copy and sort inplace is only define for sequenceable (which does not work for interval) this is what VW does with sorted Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: sort: and sortBlock:
|
|
In reply to this post by Adrian Kuhn
can be defined on Collection since it does not work on Array.
Now extending Collection that way produce non API polymorphic objects! Defining a new class with specializing add: is MUCH better because of that exact purpose. Please do not propose to extend Collection with method only working for a subset we have enough to them On Dec 23, 2009, at 10:55 PM, Adrian Kuhn wrote: > Stéphane Ducasse <stephane.ducasse@...> writes: > >> I was more looking at the user perspective. >> You often want an orderedCollection (add:) vs Array at: >> but which deals with duplicate as a Set. > > A simple method should do that job > > Collection >> #addIfAbsent: element > (self includes: element) ifFalse: [ self add: element ] > > usage > > coll := OrderedCollection new. > coll addIfAbsent: #foo. > coll addIfAbsent: #bar. > coll addIfAbsent: #qux. > coll addIfAbsent: #bar. > self assert: coll asArray = #(foo bar qux). > > --AA > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: sort: and sortBlock:
|
|
In reply to this post by Martin McClure-2
>>>
>> >> Arg, I pressed tab, then (oops) space and sent the message too soon... >> I wanted to add this comment: >> "Sort the collection in place if possible, otherwise answer a sorted Array. >> Subclasses that can sort in place should override this message." >> > > Interesting. Possibly good. But what would you do when you knew you > wanted a *copy* that was sorted? "myCollection copy sort" would work, > but might or might not create two copies, depending on whether the > original class was one that could be sorted in place. > > I'm now leaning toward defining #copySorted or some such on Collection > for this purpose. And *maybe* also doing what you propose with #sort. + 1 This is good it means that the solution is not obvious :) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: sort: and sortBlock:
|
|
In reply to this post by Levente Uzonyi-2
On Wed, Dec 23, 2009 at 9:22 AM, Levente Uzonyi <[hidden email]> wrote:
> On Wed, 23 Dec 2009, Julian Fitzell wrote: >> #sort and #sort: -- Squeak/Pharo have it on ArrayedCollection, VW has >> it on SequenceableCollection, and VASt will now add it. This sorts the >> instance in place. >> > The problem here is that not all SequenceableCollections are sortable, > for example instances of Interval can't be sorted. In squeak trunk > ArrayedCollection and OrderedCollection understand both. Meh... Interval shouldn't inherit #at:put: either, but it does. It's just life with the Collection hierarchy we have. In fact, on VW at least, #sort: is implemented in terms of #at:put: so trying to sort an Interval just triggers an Exception saying "you cannot store into an Interval". But how platforms choose to implement it is really up to them - the goal is that any Collection that should be sortable in place responds to #sort and #sort: somehow, whether that's through inheritance, traits, or multiple implementations, I don't (personally) care. >> #sorted, #sorted: -- VW already has this. VA is adding it. >> Squeak/Pharo should add it, IMO, but we'll add it to Grease if not. It >> returns a sorted copy of SequenceableCollections and a sorted Array of >> all other collections. >> > > +1, except for SequenceableCollection, see above Yes, Intervals are a bit weird in this case - again, I'd lean towards #shouldNotImplement unless it fails naturally in some other way but I don't feel strongly about it. Our platforms tests will test for it on individual classes; again, how exactly the behaviour ends up on each of those classes is not that important to me. Julian _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: sort: and sortBlock:
|
|
On Dec 24, 2009, at 9:54 AM, Julian Fitzell wrote: > On Wed, Dec 23, 2009 at 9:22 AM, Levente Uzonyi <[hidden email]> wrote: >> On Wed, 23 Dec 2009, Julian Fitzell wrote: >>> #sort and #sort: -- Squeak/Pharo have it on ArrayedCollection, VW has >>> it on SequenceableCollection, and VASt will now add it. This sorts the >>> instance in place. >>> >> The problem here is that not all SequenceableCollections are sortable, >> for example instances of Interval can't be sorted. In squeak trunk >> ArrayedCollection and OrderedCollection understand both. > > Meh... Interval shouldn't inherit #at:put: either, but it does. It's > just life with the Collection hierarchy we have. In fact, on VW at > least, #sort: is implemented in terms of #at:put: so trying to sort an > Interval just triggers an Exception saying "you cannot store into an > Interval". > > But how platforms choose to implement it is really up to them - the > goal is that any Collection that should be sortable in place responds > to #sort and #sort: somehow, whether that's through inheritance, > traits, or multiple implementations, I don't (personally) care. Yes so SortedCollection should understand short: too. > >>> #sorted, #sorted: -- VW already has this. VA is adding it. >>> Squeak/Pharo should add it, IMO, but we'll add it to Grease if not. It >>> returns a sorted copy of SequenceableCollections and a sorted Array of >>> all other collections. >>> >> >> +1, except for SequenceableCollection, see above sorted is bad name > > Yes, Intervals are a bit weird in this case - again, I'd lean towards > #shouldNotImplement unless it fails naturally in some other way but I > don't feel strongly about it. Our platforms tests will test for it on > individual classes; again, how exactly the behaviour ends up on each > of those classes is not that important to me. > > Julian > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: sort: and sortBlock:
|
|
>
> sorted is bad name Now given the situation and the result of the discussion we could have it in addition to sort sorted -> always a copy sort -> inplace when possible on SortedCollection, OrderedCollection and others. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |