- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: sort: and sortBlock:

by Julian Fitzell

On Wed, Dec 23, 2009 at 9:22 AM, Levente Uzonyi <leves(a)elte.hu> 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

Dec. 24, 2009

Re: [Pharo-project] SUnit forked, gofer it

by Lukas Renggli

Indeed, it aways runs all tests of a class. Should that be changed? I found it more useful to run them all, instead of just one. Lukas 2009/12/24 Adrian Kuhn <akuhn(a)iam.unibe.ch>: > Tudor Girba <tudor.girba@...> writes: > >> It should work if your mouse is over the methods pane. > > Not true in OB. > > > -- > 4th Workshop on Dynamic Languages and Applications > Submit papers by March 31, 2010. http://bit.ly/dyla2010 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 24, 2009

Re: [Pharo-project] New pharo images

by StÃ©phane Ducasse

tx This is cool! Damien in 1.1 may be we should put the nice little font of Cuis on :) On Dec 24, 2009, at 9:22 AM, Damien Cassou wrote: > I've just released new Pharo images, for both 1.0rc1 and 1.1alpha cores. > > http://pharo-project.org/pharo-download > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 24, 2009

Re: [Pharo-project] Fwd: sort: and sortBlock:

by StÃ©phane Ducasse

>>> >> >> 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 :)

Dec. 24, 2009

Re: [Pharo-project] Fwd: sort: and sortBlock:

by StÃ©phane Ducasse

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 > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 24, 2009

Re: [Pharo-project] Fwd: sort: and sortBlock:

by StÃ©phane Ducasse

>> > > 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

Dec. 24, 2009

Re: [Pharo-project] Search squeaksource for all senders of a method?

by Lukas Renggli

It is on the nice-to-have list since the beginning (5 years). Unfortunately there is currently no index and searching 7 GB of compressed versions is not practically feasible either. Maybe the GemStone version has a solution to that? AFAIK they keep the versions all in the stone and could easily index the internal data. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 24, 2009

[Pharo-project] New pharo images

by Damien Cassou

I've just released new Pharo images, for both 1.0rc1 and 1.1alpha cores. http://pharo-project.org/pharo-download -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Dec. 24, 2009

Re: [Pharo-project] Fwd: sort: and sortBlock:

by StÃ©phane Ducasse

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

Dec. 24, 2009

Re: [Pharo-project] Fwd: sort: and sortBlock:

by StÃ©phane Ducasse

> > #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

Dec. 24, 2009