December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

by Chris Cunnington

On 2015-12-03 6:34 PM, Mariano Martinez Peck wrote: > Hi guys, > > This thing I will ask in this email it's in my mind since YEARS. But I > have always thought it was like that and that there was nothing we > could do. However, I think it's time I ask again :) > > For those that have used Seaside, and you try to debug, you know that > upon request processing seaside uses Exceptions mechanisim to always > have access to the request, session, etc. They way that is done is > very smart :) > > WACurrentRequestContext use: self during: aBlock > > In that case, "self" is the request instance and aBlock the closure > that takes care of the request processing. So, inside that closure, > everywhere you do "WACurrentRequestContext value" you get the correct > request instance. > > So..that's great for Seaside, but debugging gets complicated. While > you can restart, proceed, etc, once inside debugger, you cannot > evaluate any piece of code that will use the session or request > because you get a WARequestContextNotFound. Of course, because I guess > the evaluation you do from cmd+d on a piece of text or via the > debugger inspector, creates another closure/context which does not > receive the WACurrentRequestContext instance. > > Now....besides WACurrentRequestContext I have my own class > UserContextInformation where I basically have a bunch of stuff > associated to the logged user. And I do exactly the same as the > WACurrentRequestContext. And I have the same problem. I really want to > be able to fix this. > > Anyone have an idea on how can I do it? I guess I can change the > debugger, in the place where I evaluate code so that I wrap that > evaluation with my request context instance??? > > Thoughts? > > > -- > Mariano > http://marianopeck.wordpress.com I have a thought. It may just show my shortcomings, but here we go. I base my idea on the notion that a resumable notification is a way to go to an earlier context in the sender chain to get an object, return back to a place later in the sender chain, and then use that object. Your problem is you want an object at a location in the sender chain and it is not there. If you execute WACurrentSession value, you are told that this is not useful as you're out of scope. I would suggest that this is weird to the Smalltalker way of thinking because this is Lisp-like lexical scoping dragged by Avi into Smalltalk. If these things are true to this point, then the problem isn't how to get what you want where you want it but knowing exactly what it is you want. Somewhere earlier in the sender chain is an object. When you find it, you'll use a resumable notification to bring it forward to where you want to use it. So, what object do you want? All my examples are from Seaside2.6. Because we are having a hard time finding the object we want, I'm going to write it in all CAPS in the code examples that follow. WASESSION responseForRequest: ... snip... [WACurrentSession use: SELF during: [ self withEventHandler: [ self performRequest: aRequest ]]] This can be re-written as: WACurrentSession use: ANOBJECT during aBlock [ self with ErrorHandler: [ self performRequest: aRequest ]] on: WACurrentSession do: [:n| n resume: ANOBJECT ] The self in the first example is becoming the pseudo variable in the second example. That's pretty unusual to me. And you know that WACurrentSession value is just a way of saying WACurrentSession raiseSignal. So, now, perhaps you know what object you want, you want that session object, and you want to drag it back to later in sender chain. Use a resumable notification. Maybe something like: WARequestContext push: aRequestHandler during: aBlock [ [ WACurrentRequestContext use: SELF during: aBlock ] ensure: [ handlers removeFirst ] ] on: GiveMeTheSessionRightNow do: [:n| n resume: SELF ] Go back in the sender chain for the object you want. Drag it back to the future. GiveMeTheSessionRightNow raiseSignal FWIW, Chris

Dec. 4, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Ben Coman

On Fri, Dec 4, 2015 at 3:26 AM, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > <uncontrolled snipping> > > On Thu, Dec 3, 2015 at 5:48 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + >> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not >> cause any error in this case. >> >> >> cheers -ben > > > but points aren't commutative: > > 2@2 + 1 " = 3@3" > 1 + 2@2 " = 3@2" > > Of course, 0 wouldn't be an issue, unless you wanted to access x or y! > > -cbc whoops? 1 + (2@2) = 3@3 cheers -ben

Dec. 4, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Ben Coman

On Fri, Dec 4, 2015 at 4:23 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2015-12-03 14:48 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > >> >> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> >> >> >> >> >> 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> >> >> wrote: >> >> > Hi, >> >> > >> >> >> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >> >> >> >> >> @Doru >> >> >> Youâre missing the point: #anyOne *fails* for empty collections. >> >> > >> >> > I am not missing the point at all. I am saying that if you want sum: >> >> > to be generic, it cannot assume a specific Zero object. >> >> > >> >> > And sum: should be generic because of its name. >> >> >> >> I am missing understanding the other use cases. Can you describe >> >> further the generic nature of #sum & #sum: ? I would have thought by >> >> default they only applied to numbers. >> >> >> >> sum can be applied to anything that supports #+, not only numbers >> >> sum: can be applied to any collection with a block that return some >> >> object that supports #+ >> >> To me this is a mis-application of polymorphism, that just because >> something responds to #+ it should be summable. We have overloaded the >> semantics of #+ to mean both numeric addition and >> concatenation/membership, but technically "summation" relates only to >> numeric addition. > > > I didn't wanted to argue for or against any change. I just wanted to clarify > that there are situations in which a generic sum/sum: that throws an error > on empty collections and don't assume a null value makes sense. > > >> >> >> https://www.google.com.au/search?q=define+sum&oq=define+sum >> >> https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate >> >> For example... >> >> * KMModifier implements #+ so what is the expected semantic of " { >> KMModifier shift . KMModifier meta} sum " ? >> To me this is more of a concatenation/join/union facility rather than >> numeric addition. (btw, that expression actually fails since >> KMModifier does not understand minus #- ) . >> >> * String implements #+ and " { '1' . '2' } sum " --> '3', so >> actually its doing numeric addition. However " { 'a' . 'b' } sum " >> produces an error. >> >> So actually there seem some existing problems with summing >> non-numerics. What examples work? >> >> * Trait classes implement both #+ and #- , but the semantic seems >> more to do with membership than numeric addition. I don't how how to >> produce an example of using #sum against traits. >> >> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + >> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not >> cause any error in this case. >> >> >> cheers -ben >> >> >> >> >> >> therefore you can not assume 0 (<- a number) is a proper initial value >> >> therefore you *need* to work with #anyOne >> >> and as you can not assume a proper initial value, you can not assume a >> >> default value for empty collections >> >> -> it should throw an error. If you (the caller of the function) knows >> >> what to do with an empty collection you have >> >> to check, or call inject:into: directly, with a proper initial value. >> > >> > I am sorry but I am getting really tired of this, you should read what >> > is being said. > > > do that change, I am not against it. Ben just asked for an example and I > thought it would be helpful. It was helpful :) It evolved my thinking. Now thinking further, I wonder how returning 0 will work with applications using units like Aconcagua, and if it would over-complicate things to do something like... Collection>>sum | sum sample | self isEmpty ifTrue: [ ^ ArithmeticZero ]. sample := self anyOne. sum := self inject: sample into: [ :accum :each | accum + each ]. ^ sum - sample ArithmeticZero class >> + anObject ^anObject cheers -ben > > >> >> > >> > I am not suggesting to stop using #anyOne because I like why it is there >> > and what it can do. >> > >> > The change I want is what happens with an empty collection when using >> > the simplest selector, #sum. >> > >> > I do not want to say to some collection of numbers #sumIfEmpty: [0], >> > because summing numbers starting from zero is the most common case and >> > everybody expects that, hence the unary selector fits. >> > >> > I want the less common cases to use the more complicated API, as in some >> > collection of colors #sumIfEmpty: [ Color black ] >> > >> > In my book that is common sense API design. >> > >> > Doing that I do no take anything away, because today you already have to >> > make sure the collection is not empty. >> > >> > The only change would be in the error behaviour. I think that is a >> > reasonable price to pay. Instead of having #anyOne fail, it will say that #+ >> > cannot add 0 to some object, and in a comment we can point to the >> > alternative API. > > > > >> >> > >> > http://izquotes.com/quote/242740 right ? >> > >> >> cheers -ben >> >> >> >> > >> >> >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo >> >> >>> <emaringolo(a)gmail.com> wrote: >> >> >>> >> >> >>> I don't want to be heretic (or too orthodox), but why not to >> >> >>> delegate >> >> >>> this behavior to other class (an iterator maybe?). >> >> >>> >> >> >>> It's too tempting adding these convenience methods to Collection >> >> >>> and/or subclasses, but anything that requires an explicit protocol >> >> >>> of >> >> >>> its elements is wrong, IMO. >> >> >>> >> >> >>> something like aCollection arithmetic sum: [...] or.... aCollection >> >> >>> arithmetic avg. On Fri, Dec 4, 2015 at 3:26 AM, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > <uncontrolled snipping> > > On Thu, Dec 3, 2015 at 5:48 AM, Ben Coman <btc(a)openinworld.com> wrote: >> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + >> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not >> cause any error in this case. > > but points aren't commutative: > > 2@2 + 1 " = 3@3" > 1 + 2@2 " = 3@2" > > Of course, 0 wouldn't be an issue, unless you wanted to access x or y!

Dec. 4, 2015

Hook "WACurrentRequestContext" into debugger?

by Mariano Martinez Peck

Hi guys, This thing I will ask in this email it's in my mind since YEARS. But I have always thought it was like that and that there was nothing we could do. However, I think it's time I ask again :) For those that have used Seaside, and you try to debug, you know that upon request processing seaside uses Exceptions mechanisim to always have access to the request, session, etc. They way that is done is very smart :) WACurrentRequestContext use: self during: aBlock In that case, "self" is the request instance and aBlock the closure that takes care of the request processing. So, inside that closure, everywhere you do "WACurrentRequestContext value" you get the correct request instance. So..that's great for Seaside, but debugging gets complicated. While you can restart, proceed, etc, once inside debugger, you cannot evaluate any piece of code that will use the session or request because you get a WARequestContextNotFound. Of course, because I guess the evaluation you do from cmd+d on a piece of text or via the debugger inspector, creates another closure/context which does not receive the WACurrentRequestContext instance. Now....besides WACurrentRequestContext I have my own class UserContextInformation where I basically have a bunch of stuff associated to the logged user. And I do exactly the same as the WACurrentRequestContext. And I have the same problem. I really want to be able to fix this. Anyone have an idea on how can I do it? I guess I can change the debugger, in the place where I evaluate code so that I wrap that evaluation with my request context instance??? Thoughts? -- Mariano http://marianopeck.wordpress.com

Dec. 3, 2015

Re: [Pharo-dev] VoyageMongo and cache compaction

by Ben Coman

I haven't used VoyageMongo, but just a general comment that maybe the testcase is best produced at your end, since you understand the symptoms and can cut down a slice of your application as a template. Publishing that to the mail list provides an explicit demonstration of the problem making it easier for someone to assist. Indeed, as an extension if all the steps to load up VoyageMongo and set up the environment are included, sometimes I'll even be inclined to investigate such things that are unknown to me as a form of goal-directed learning (although right I'm now tied up with some other things). cheers -ben On Thu, Dec 3, 2015 at 10:02 PM, Holger Freyther <holger(a)freyther.de> wrote: > >> On 03 Dec 2015, at 09:58, Holger Freyther <holger(a)freyther.de> wrote: >> >> Hi guys, > > >> This is a write "heavy" workload but at no point in time more than a couple of objects will >> be in the cache. So somehow the VOMongoCache>>#compactIfNeeded check does not >> trigger and/or given the difference in the sizes of the dictionary it is possible that some of >> the dead objects are not removed from the timestamp cache. > > the keyword here is "delete" heavy. VOMongoCache>>#removeValue: is called by the > VOMongoRepository>>#remove: but this leaves the timeStamp (pharo v3 version or > versions in newer) to have an entry for a OID that was removed. > > And as >>#performCompact will only remove "dead" keys from timeStamp/versions it will > leave many delete entries in the timeStamp. > > The other thing is that I wonder why the self mutex critical lock is not taken around the > removal of the object? > > Is there anyone willing to resolve this, create a testcase and make a backport to Pharo3? > > holger

Dec. 3, 2015

Re: [Pharo-dev] [Moose-dev] Re: Explanation how to use GT Debugger and GT SUnit Debugger with DarkThem in Pharo 4.0 [was] Using Re: Re: showing a diff on #assert:equals:

by Andrei Chis

On Thu, Dec 3, 2015 at 10:25 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Thu, Dec 3, 2015 at 6:02 PM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> Finally it works :) >> >> Now this is a rather generic extension. >> If you want to go one step further you can create an extension that shows >> more contextual information related to your application. >> >> > I think I still have some generic possible feedback after playing with it > for some hours that if you can implement that at some point it will be > super awesome: > > 1) I want to use the SUnit debugger EVERY TIME I run tests...even if there > is no #assert:equals:. Any error , any #assert: etc, I do want the SUnit > Debugger. Why? Because showing setUp and tearDown for example are > interesting even if there is no #assert:equals: > 2) Point 1 means that the SUnit debugger must support either displaying or > not the current vs expected tabs ? (or maybe a subclass used for > #assert:equals: ?) > 3) It would be nice to have a button to hide/show the setUp and tearDown. > 4) Would be nice to automatically show tearDown/setUp IF the > implementation is NOT the one of TestCase (empty method) and automatically > hide if it is. > I'll add them to my todo list. Just I do not have too much time right now. > > I think that's all for the moment. I am already enjoying it. > > OHH BTW... you said " it will not switch to the SUnit extension > automatically (that only works in Pharo 5) ". > Is there a quick dirty/hack/override/workaround/hardcode I can do to make > that work in 4.0? > Had a second look and hopefully made this work :). You'll need to load GT-Debugger-AndreiChis.251. With this I also fixed the colors in the black theme so you do not need the hack. Also you can just call #register now instead of #registerExtraToolOn: Cheers, Andrei > > > Thanks in advance!!! > > > >> Cheers, >> Andrei >> >> On Thu, Dec 3, 2015 at 8:22 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Andrei... you rock!!! It works. I copy paste it here so that others can >>> take advantage too. >>> Look also the attached screenshot :) >>> Doru...you were right..you THINK you don't need a any other tool, until >>> someone comes with a little example as a debugger for test cases...wow... >>> those are moldable tools!!!! >>> >>> >>> The code I used (with the hack of the override) is this: >>> http://ws.stfx.eu/ME85BCYIPSU8 >>> (of course, I published the code via the playground hahahha) >>> >>> Thank you! >>> >>> >>> >>> >>> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >

Dec. 3, 2015

Re: [Pharo-dev] [Moose-dev] Re: Explanation how to use GT Debugger and GT SUnit Debugger with DarkThem in Pharo 4.0 [was] Using Re: Re: showing a diff on #assert:equals:

by Mariano Martinez Peck

On Thu, Dec 3, 2015 at 6:02 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Finally it works :) > > Now this is a rather generic extension. > If you want to go one step further you can create an extension that shows > more contextual information related to your application. > > I think I still have some generic possible feedback after playing with it for some hours that if you can implement that at some point it will be super awesome: 1) I want to use the SUnit debugger EVERY TIME I run tests...even if there is no #assert:equals:. Any error , any #assert: etc, I do want the SUnit Debugger. Why? Because showing setUp and tearDown for example are interesting even if there is no #assert:equals: 2) Point 1 means that the SUnit debugger must support either displaying or not the current vs expected tabs ? (or maybe a subclass used for #assert:equals: ?) 3) It would be nice to have a button to hide/show the setUp and tearDown. 4) Would be nice to automatically show tearDown/setUp IF the implementation is NOT the one of TestCase (empty method) and automatically hide if it is. I think that's all for the moment. I am already enjoying it. OHH BTW... you said " it will not switch to the SUnit extension automatically (that only works in Pharo 5) ". Is there a quick dirty/hack/override/workaround/hardcode I can do to make that work in 4.0? Thanks in advance!!! > Cheers, > Andrei > > On Thu, Dec 3, 2015 at 8:22 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Andrei... you rock!!! It works. I copy paste it here so that others can >> take advantage too. >> Look also the attached screenshot :) >> Doru...you were right..you THINK you don't need a any other tool, until >> someone comes with a little example as a debugger for test cases...wow... >> those are moldable tools!!!! >> >> >> The code I used (with the hack of the override) is this: >> http://ws.stfx.eu/ME85BCYIPSU8 >> (of course, I published the code via the playground hahahha) >> >> Thank you! >> >> >> >> >> > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- Mariano http://marianopeck.wordpress.com

Dec. 3, 2015

Re: [Pharo-dev] [Moose-dev] Explanation how to use GT Debugger and GT SUnit Debugger with DarkThem in Pharo 4.0 [was] Using Re: Re: showing a diff on #assert:equals:

by Andrei Chis

Finally it works :) Now this is a rather generic extension. If you want to go one step further you can create an extension that shows more contextual information related to your application. Cheers, Andrei On Thu, Dec 3, 2015 at 8:22 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Andrei... you rock!!! It works. I copy paste it here so that others can > take advantage too. > Look also the attached screenshot :) > Doru...you were right..you THINK you don't need a any other tool, until > someone comes with a little example as a debugger for test cases...wow... > those are moldable tools!!!! > > > The code I used (with the hack of the override) is this: > http://ws.stfx.eu/ME85BCYIPSU8 > (of course, I published the code via the playground hahahha) > > Thank you! > > > > >

Dec. 3, 2015

Re: [Pharo-dev] Differences Compiler vs. OpalCompiler (or parser)

by Nicolai Hess

2015-12-03 16:59 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 20 Nov 2015, at 22:37, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > GTDummyExamples class > d: anInteger > <gtExample> > <label: 'Dummy #d:, depends #c:'> > <description: 'should raise an exception as the argument is not > anInteger'> > <depends: #c:> > <raises: Literal constant expected -> MessageNotUnderstood> > > ^ 1 + anInteger > > The old Parser complains about the class name "MessageNotUnderstood" used > as a pragma > argument without being a string or symbol > > Opal does not complain > > Is Opals behavior intended ? > > > it actually is compiled as a literalâ¦ maybe the idea was that it follows > how literal arrays work? #(thisisasymbol). > But yes, it it confusing and should be changed. > > > > From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770 > > Cascading message sends to super. > > Compiler refuses to compile > super > initialize; > setListProperties > > > It looks like Opal would compile this to > > super initialize. > super setListProperties. > > Intended ? > > > We just use RBParser (or started with RBParser). I think it is intended. > > Do we want to keep it? > > > Yes, I actually like it. > > NBNativeCodeGen > parseOptions: optionsArray > uses association symbol -> block instead of block -> block > for caseOf arguments. > The old parser does not accept this. > > I would say that we change it to be like the old and change set one user. > > Marcus > > > OK

Dec. 3, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Nicolai Hess

2015-12-03 14:48 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > >> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> > >> > >> > >> 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >> > Hi, > >> > > >> >> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> > >> >> @Doru > >> >> Youâre missing the point: #anyOne *fails* for empty collections. > >> > > >> > I am not missing the point at all. I am saying that if you want sum: > to be generic, it cannot assume a specific Zero object. > >> > > >> > And sum: should be generic because of its name. > >> > >> I am missing understanding the other use cases. Can you describe > >> further the generic nature of #sum & #sum: ? I would have thought by > >> default they only applied to numbers. > >> > >> sum can be applied to anything that supports #+, not only numbers > >> sum: can be applied to any collection with a block that return some > object that supports #+ > > To me this is a mis-application of polymorphism, that just because > something responds to #+ it should be summable. We have overloaded the > semantics of #+ to mean both numeric addition and > concatenation/membership, but technically "summation" relates only to > numeric addition. > I didn't wanted to argue for or against any change. I just wanted to clarify that there are situations in which a generic sum/sum: that throws an error on empty collections and don't assume a null value makes sense. > > https://www.google.com.au/search?q=define+sum&oq=define+sum > https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate > > For example... > > * KMModifier implements #+ so what is the expected semantic of " { > KMModifier shift . KMModifier meta} sum " ? > To me this is more of a concatenation/join/union facility rather than > numeric addition. (btw, that expression actually fails since > KMModifier does not understand minus #- ) . > > * String implements #+ and " { '1' . '2' } sum " --> '3', so > actually its doing numeric addition. However " { 'a' . 'b' } sum " > produces an error. > > So actually there seem some existing problems with summing > non-numerics. What examples work? > > * Trait classes implement both #+ and #- , but the semantic seems > more to do with membership than numeric addition. I don't how how to > produce an example of using #sum against traits. > > * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + > 1 " --> 3@3 , so " {} sum " returning 0 would seem to not > cause any error in this case. > > > cheers -ben > > > >> > >> therefore you can not assume 0 (<- a number) is a proper initial value > therefore you *need* to work with #anyOne > >> and as you can not assume a proper initial value, you can not assume a > default value for empty collections > >> -> it should throw an error. If you (the caller of the function) knows > what to do with an empty collection you have > >> to check, or call inject:into: directly, with a proper initial value. > > > > I am sorry but I am getting really tired of this, you should read what > is being said. > do that change, I am not against it. Ben just asked for an example and I thought it would be helpful. > > > > I am not suggesting to stop using #anyOne because I like why it is there > and what it can do. > > > > The change I want is what happens with an empty collection when using > the simplest selector, #sum. > > > > I do not want to say to some collection of numbers #sumIfEmpty: [0], > because summing numbers starting from zero is the most common case and > everybody expects that, hence the unary selector fits. > > > > I want the less common cases to use the more complicated API, as in some > collection of colors #sumIfEmpty: [ Color black ] > > > > In my book that is common sense API design. > > > > Doing that I do no take anything away, because today you already have to > make sure the collection is not empty. > > > > The only change would be in the error behaviour. I think that is a > reasonable price to pay. Instead of having #anyOne fail, it will say that > #+ cannot add 0 to some object, and in a comment we can point to the > alternative API. > > > > > http://izquotes.com/quote/242740 right ? > > > >> cheers -ben > >> > >> > > >> >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > >> >>> > >> >>> I don't want to be heretic (or too orthodox), but why not to > delegate > >> >>> this behavior to other class (an iterator maybe?). > >> >>> > >> >>> It's too tempting adding these convenience methods to Collection > >> >>> and/or subclasses, but anything that requires an explicit protocol > of > >> >>> its elements is wrong, IMO. > >> >>> > >> >>> something like aCollection arithmetic sum: [...] or.... aCollection > >> >>> arithmetic avg. > >> >> > >> >> > >> >> Interesting thought! > >> > > >> > +100 > >> > > >> > Doru > >> > > >> >>> > >> >>> My two cents for this. > >> >>> > >> >>> Regards! > >> >>> > >> >>> > >> >>> Esteban A. Maringolo > >> >>> > >> >> > >> >> > >> > > >> > -- > >> > www.tudorgirba.com > >> > > >> > "Every thing has its own flow." > >> > > >> > > >> > > >> > > >> > > > > > > >

Dec. 3, 2015