August 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Comparison for SequencableCollection

by Peter UhnÃ¡k

On Sun, Aug 2, 2015 at 6:44 PM, webwarrior <reg(a)webwarrior.ws> wrote: > > On 02.08.2015 19:02, Peter UhnÃ¡k [via Smalltalk] wrote: > > > (a b c) = (b a c) if a = b > > > > (a b c) < (b a c) if a < b > > The semantics are well defined. > > > > > > Since you mentioned JavaScript, you should know that you can't compare > > arrays with ==, because it does object comparison. > > > > No. Sorted collection maintains order of its elements, and I'm > talking > > about order on [the set of] sequencable collections > > > > This will make sense only if the objects have overriden their #=. > > Which also means that it is not very useful to use #<, because you can't > > define order without overriding #=. > > Technically, you can: > (a < b) not and: [ (b < a) not ] "a and b are equal" > Well if the two objects are not comparable, then you've just made them equal. :) > > But of course it's reasonable to implement #= and #hash along with #< - > that's what TComparable requires. > Implementing #=/#hash just to achieve ordering seems like a terrible idea, considering #= affects a lot and often it will be context-dependent. (Sometimes you want to compare objects one way, sometimes another, that's why there's #sorted: method.) > > > Compare it to sorting a collection, where you can either do #sorted, > > which will do "a <= b" by default, but you can still do #sorted: and > > specify the sort order, dtto with PluggableDictionary etc. > > So if anything, it would make more sense to be able to block-based > > testing (without relying on #<), because more often then not you will > > have your values wrapped in some (bigger) objects. > > Something like #compare:using: where second argument is a binary block? > Might be a solution, although not as elegant. > Question is what are return values of the method and what is expected to > be returned from the block? > String>>#compare: returns integer from 1 to 3; > SequencableCollection>>#findBinary: expects either 0, negative or > positive integer; #sorted: expects boolean; #max:, #min:, etc. expect > object to be compared. My point was, that in object world you will usually have more complex objects than just strings. For example you have a class "Person" that has "name" and "surname" attributes. Suddenly you can't override #=, because it doesn't make sense in context to lexicographic ordering... do you want the order to be by name or by surname? Or something else? That's why I wrote that implementing just #< has very constrained use-case, because you can't specify what you want to order. Of course you can do "somePeople collect: #name < (otherPeople collect: #name)" but you still want it to be done on People collection, not the collection of strings. Or maybe I am forcing not very common use case?

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by webwarrior

On 02.08.2015 19:02, Peter UhnÃ¡k [via Smalltalk] wrote: > (a b c) = (b a c) if a = b > > (a b c) < (b a c) if a < b > The semantics are well defined. > > > Since you mentioned JavaScript, you should know that you can't compare > arrays with ==, because it does object comparison. > > No. Sorted collection maintains order of its elements, and I'm talking > about order on [the set of] sequencable collections > > This will make sense only if the objects have overriden their #=. > Which also means that it is not very useful to use #<, because you can't > define order without overriding #=. Technically, you can: (a < b) not and: [ (b < a) not ] "a and b are equal" But of course it's reasonable to implement #= and #hash along with #< - that's what TComparable requires. > Compare it to sorting a collection, where you can either do #sorted, > which will do "a <= b" by default, but you can still do #sorted: and > specify the sort order, dtto with PluggableDictionary etc. > So if anything, it would make more sense to be able to block-based > testing (without relying on #<), because more often then not you will > have your values wrapped in some (bigger) objects. Something like #compare:using: where second argument is a binary block? Might be a solution, although not as elegant. Question is what are return values of the method and what is expected to be returned from the block? String>>#compare: returns integer from 1 to 3; SequencableCollection>>#findBinary: expects either 0, negative or positive integer; #sorted: expects boolean; #max:, #min:, etc. expect object to be compared. > And finally "Because in almost every programming language..." is not an > argument. > You could argue that "1 + 2 * 3" should return "7", because that's how > every language does it and that's how mathematicians did it for > thousands of years. And yet Smalltalk happily returns "9" and yet it > makes sense, and some could argue that it's even better. > > Peter > > On Sun, Aug 2, 2015 at 4:59 PM, Alexandre Bergel <[hidden email] > </user/SendEmail.jtp?type=node&node=4840722&i=0>> wrote: > > > I'd say it is questonable if SequenceableCollections should be comparable by default. > > +1 > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p484072… > > To unsubscribe from Comparison for SequencableCollection, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…>. > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p484072… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by Peter UhnÃ¡k

> > (a b c) = (b a c) if a = b (a b c) < (b a c) if a < b > The semantics are well defined. Since you mentioned JavaScript, you should know that you can't compare arrays with ==, because it does object comparison. No. Sorted collection maintains order of its elements, and I'm talking > about order on [the set of] sequencable collections This will make sense only if the objects have overriden their #=. Which also means that it is not very useful to use #<, because you can't define order without overriding #=. Compare it to sorting a collection, where you can either do #sorted, which will do "a <= b" by default, but you can still do #sorted: and specify the sort order, dtto with PluggableDictionary etc. So if anything, it would make more sense to be able to block-based testing (without relying on #<), because more often then not you will have your values wrapped in some (bigger) objects. And finally "Because in almost every programming language..." is not an argument. You could argue that "1 + 2 * 3" should return "7", because that's how every language does it and that's how mathematicians did it for thousands of years. And yet Smalltalk happily returns "9" and yet it makes sense, and some could argue that it's even better. Peter On Sun, Aug 2, 2015 at 4:59 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > I'd say it is questonable if SequenceableCollections should be > comparable by default. > > +1 > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by Alexandre Bergel

> I'd say it is questonable if SequenceableCollections should be comparable by default. +1 Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by webwarrior

No. Sorted collection maintains order of its elements, and I'm talking about order on [the set of] sequencable collections On 02.08.2015 15:46, jtuchel [via Smalltalk] wrote: > Am 02.08.15 um 14:11 schrieb webwarrior: > > I was surprised when discovered that in Pharo comparison is not > defined for > > lists, arrays and similar datastructures. > > > > Because in almost every programming language (F#, Python, Javascript > just to > > name few) you can compare lists, arrays, etc. By convention, the > ordering is > > lexicographical, just like in strings. > > BTW: This would be SortedCollection, not OrderedCollection or its > superclass. > Still I am not convinced that I really need an implementation of #< in > SequencableCollection. Too many ways to interpret what greater or equal > or lower could mean... > > > > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p484070… > > To unsubscribe from Comparison for SequencableCollection, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…>. > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p484070… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by webwarrior

On 02.08.2015 15:44, jtuchel [via Smalltalk] wrote: > I'd say it is questonable if SequenceableCollections should be > comparable by default. > > is (a b c) equal or lower than (b a c) ? > Doesn't this depend heavily on what is in the Collection and what the > meaning of the Sequence of two Collections is? (a b c) = (b a c) if a = b (a b c) < (b a c) if a < b The semantics are well defined. Of course, it depends on what's in collection! That's the point - we compare collections by their content. If some elements are not comparable, we'll get DoesNotUnderstand - expected behavior when comparing non-comparable objects. It's the same story as with equality. > So I'd say there is not much use in putting comparisons into the base > class library, because there is a ton of assumptions about the > Collections in whatever implementation one can imagine. I would assume > that this is the job of some business object that holds objects in a > SequenceableCollection. Don't you think? There is only one assumption - that elements of the first collection are comparable to the elements of the second collection. And I think that we shouldn't multiply entities beyond necessity by creating a class when using simple datastructure would be sufficient. > The fact that other languages provide such an implementation doesn't > mean much to me, to be honest. I choose a SequencableCollection in order > to keep objects in a certain order, nothing more, nothing less. That's why we have methods such as polynomialEval: and asDigitsToPower:do: (and I'm not talking about extension methods) ? > I think it is important to not get "overridden" by the fact that > something is extremely easy to do in Smalltalk. We can easily make bad > mistakes, just because we can. > > Just my 2 cents > > Joachim > > Am 02.08.15 um 14:11 schrieb webwarrior: > > > I was surprised when discovered that in Pharo comparison is not > defined for > > lists, arrays and similar datastructures. > > > > Because in almost every programming language (F#, Python, Javascript > just to > > name few) you can compare lists, arrays, etc. By convention, the > ordering is > > lexicographical, just like in strings. > > > > It took little time to add needed methods to SequencableCollection, > but I > > think its better to have them in core library (core image, or how do you > > call it?). > > > > > > > > -- > > View this message in context: > http://forum.world.st/Comparison-for-SequencableCollection-tp4840704.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p484070… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by jtuchel＠objektfabrik.de

Am 02.08.15 um 14:11 schrieb webwarrior: > I was surprised when discovered that in Pharo comparison is not defined for > lists, arrays and similar datastructures. > > Because in almost every programming language (F#, Python, Javascript just to > name few) you can compare lists, arrays, etc. By convention, the ordering is > lexicographical, just like in strings. BTW: This would be SortedCollection, not OrderedCollection or its superclass. Still I am not convinced that I really need an implementation of #< in SequencableCollection. Too many ways to interpret what greater or equal or lower could mean...

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by jtuchel＠objektfabrik.de

I'd say it is questonable if SequenceableCollections should be comparable by default. is (a b c) equal or lower than (b a c) ? Doesn't this depend heavily on what is in the Collection and what the meaning of the Sequence of two Collections is? So I'd say there is not much use in putting comparisons into the base class library, because there is a ton of assumptions about the Collections in whatever implementation one can imagine. I would assume that this is the job of some business object that holds objects in a SequenceableCollection. Don't you think? The fact that other languages provide such an implementation doesn't mean much to me, to be honest. I choose a SequencableCollection in order to keep objects in a certain order, nothing more, nothing less. I think it is important to not get "overridden" by the fact that something is extremely easy to do in Smalltalk. We can easily make bad mistakes, just because we can. Just my 2 cents Joachim Am 02.08.15 um 14:11 schrieb webwarrior: > I was surprised when discovered that in Pharo comparison is not defined for > lists, arrays and similar datastructures. > > Because in almost every programming language (F#, Python, Javascript just to > name few) you can compare lists, arrays, etc. By convention, the ordering is > lexicographical, just like in strings. > > It took little time to add needed methods to SequencableCollection, but I > think its better to have them in core library (core image, or how do you > call it?). > > > > -- > View this message in context: http://forum.world.st/Comparison-for-SequencableCollection-tp4840704.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Aug. 2, 2015

Comparison for SequencableCollection

by webwarrior

I was surprised when discovered that in Pharo comparison is not defined for lists, arrays and similar datastructures. Because in almost every programming language (F#, Python, Javascript just to name few) you can compare lists, arrays, etc. By convention, the ordering is lexicographical, just like in strings. It took little time to add needed methods to SequencableCollection, but I think its better to have them in core library (core image, or how do you call it?). -- View this message in context: http://forum.world.st/Comparison-for-SequencableCollection-tp4840704.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 2, 2015

Re: [Pharo-users] Tabular: XLSX import

by Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾

It looks like I need some guidance to understand contemporary packaging/deployment/versioning system. I know it exists, but I don't know details. Can you kick me in the right direction? Maybe some link? 2015-08-02 11:21 GMT+03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > it would be sooo cool to have a configuration in the catalogâ¦ > > Esteban > > On 01 Aug 2015, at 20:58, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > > Hello. > Some time ago I announced Tabular > <http://ss3.gemtalksystems.com/ss/Tabular.html>, some effort to make a > tool for spreadsheets import/export. > > This is short notice: Vincent Blondeau have added XLSX import > functionality! > It's also mostly proof-of-concept now, but even at this stage it's quite > usable. > > Thanks, Vincent! > > >

Aug. 2, 2015