January 2016 - Pharo-dev - lists.pharo.org

Interrupting processes question. Can method return be interrupted?

by Denis Kudriashov

Look at example: methodA | result | result := false. [result := self methodB] ensure: [result ifTrue: [...]] methodB result := 1 < 2. ^result Imagine now that methodB starts execution in context of call inside methodA. Is it possible to terminate process at point of methodB return (^result)? In that case ensure block in methodA will perform wrong logic.

Jan. 7, 2016

Re: [Pharo-dev] [Vm-dev] How to compile Spur VM in Windows?

by Esteban Lorenzano

Hi Hernan, > On 06 Jan 2016, at 23:46, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > Hola Esteban :) > > As suggested, I am using sources from https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-buil… <https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-buil…> > > I have some questions: > > 1) The sources.tgz file in CI already includes the generated C code (in src/ directories) and CMake files (in build/ directories) ? So for checking the build it would not be necessary to evaluate "PharoVMBuilder buildWin32â. I never built the VM using those sources, so I donât know how it will go. In general, I think what you say is ok. > > 2) Just out of curiosity, VMMakerTool is usable these days? Nope, we use CMakeMaker (could work, never tried). > > 3) I evaluated : PharoVMBuilder buildWin32. and received a lot of warnings (conflicting return types, undeclareds, etc) in Transcript - attached - Is this expected or should I try to update PharoVMMaker? And if so, from where? I think you are âsafe to goâ with those warnings. I should review them, though. Esteban > > HernÃ¡n > > 2016-01-06 16:08 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > btw you might be able to build SpurVM using an old non-spur Pharo 5.0 imageâ¦ not sure, but I do not see a reason why you couldnât :) > > Esteban > > >> On 06 Jan 2016, at 20:05, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> https://github.com/estebanlm/pharo-vm/tree/spur64 <https://github.com/estebanlm/pharo-vm/tree/spur64> >> >> because I still do not merge with master >> instructions should work, but right now you WILL NOT be able to build a VM, because there is a bug in OpalCompiler who prevents building the VM in spur imagesâ¦ and probably there are other issues, I couldnât test further. >> >> So I would say you need to wait until I can restore the builds here: https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/ <https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/> >> >> (itâs been almost one month since I cannot build :( ) >> >> Esteban >> >> >>> On 06 Jan 2016, at 19:33, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >>> >>> Hello >>> >>> I am trying to compile Spur VM in Windows 8.1. >>> >>> As far as I understand Spur VM needs the Pharo 5.0 image format, is that right? >>> >>> Apparently instructions here https://github.com/pharo-project/pharo-vm/blob/master/README-Win32-fasttrac… <https://github.com/pharo-project/pharo-vm/blob/master/README-Win32-fasttrac…> are only applicable to "Old VM" in Pharo 3.0 >>> >>> Does anyone have any idea how to clone/compile the Spur VM (i.e. Pharo 5.0) ? >>> >>> Cheers, >>> >>> HernÃ¡n >>> >> > > > <buildWarnings.txt>

Jan. 7, 2016

Re: [Pharo-dev] ifError: implementation is bad

by Stephan Eggermont

On 07-01-16 13:11, Denis Kudriashov wrote: > What you think? Can be put it in Pharo 5? Such change can touch some > packages This is exactly why I want a compact archive representation of all source code in the repos. Then we know what's touched. Stephan

Jan. 7, 2016

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

by Sven Van Caekenberghe

> On 07 Jan 2016, at 16:31, Ben Coman <btc(a)openinworld.com> wrote: > > On Thu, Jan 7, 2016 at 9:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> On 07 Jan 2016, at 14:23, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito >>> <guillermopolito(a)gmail.com> wrote: >>>> I like these last. >>>> >>>> Particularly because >>>> >>>> - it cleans the collectionâs API >>>> - we can continue extending this idea to add parallelism, mutual exclusion... >>> >>> I don't understand the second point. >> >> Wrapping an object in another to add behaviour is a standard technique (as opposed to adding the behaviour to the object itself). There can be several reasons for doing this. It is not necessarily or always a good idea either (for example, extension protocols are nice too). > >> "standard technique" > > Does it have a pattern name?, that I could look up to learn more (btw > I have Design Patterns Smalltalk Companion - but its hard to remember > them without using them in practice.) ? Something in the general direction of Proxy, Decorator and/or Adaptor ? > cheers -ben > >> >>>>> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> Hi Henrik, >>>>> >>>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <henrin10(a)student.uia.no> wrote: >>>>>> >>>>>> Like this? >>>>>> http://smalltalkhub.com/#!/~Latsabben/NumIt >>>>> >>>>> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives. >>>>> >>>>> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result: >>>>> >>>>> <Collections-Operations-SvenVanCaekenberghe.1.mcz> >>> >>> Interesting to great enthusiasm from several people. Looks like I'm >>> in the minority but I'm wary of this. It seems like >>> over-intellectualized design. >> >> Yes, maybe ;-) >> >>> I'll need to remember whether to send >>> #magnitude or #numbers before an operation and which matches up with >>> which operations. This seems harder for newcomers. >> >> #(1 2 foo true false) sum => ? >> #() sum => ? >> { window1. window2. window3 } max => ? >> >>> Are there any other programming languages that do it this way? >> >> There are not so many fully dynamic languages with non-homogeneous collections. Most languages have static typing and generic types (both are not what we want). But I would love to see how comparable languages solve this 'problem'. >> >> Most language won't allow (or don't define) operations on collections that could fail because of the fact that they contain the wrong objects. >> >> Having said that, I am not saying that I want to move away from our flexibility/simplicity ! >> >>>>> >>>>> There are some examples in the class comments. >>> >>> Class comment says CollectionOperations is "a class that offers >>> extended API to operate on collections assumed to contain objects of a >>> certain type." >>> >>>>> 1. CollectionOperations >>>>> 2. OperationsOnMagnitudes >>>>> 3. OperationsOnNumbers >>>>> 4. OperationsOnSequenceableNumbers >>> >>> So 2 & 3 refer to the elements of the collection, so 4 makes me wonder >>> what elements are sequence-able numbers? So 4 breaks the pattern to >>> refer to the type of collection not just the type of element. >> >> Yes, that is a problem, it feels wrong. There are several dimensions that cannot be captured in one simple hierarchy. >> >>> Why is #average defined for OperationsOnNumbers rather than >>> OperationsOnMagnitudes? If I have a collection of magnitudes like Time >>> "17:28 . 17:29 . 17:31 . 17:32" or Duration "4 minutes . 6 minutes" >>> I would expect to be able to get 17:30 and 5 minutes as the respective >>> averages. >>> But then it doesn't make sense to average other magnitudes like >>> Character, so where does that leave us? >> >> You are wrong, a Magnitude is only comparable, it does not mean it can do arithmetic. You need arithmetic to compute average. >> >> In this case, you could use #numbers to indicate that you see your objects as compatible with that (and the time objects mostly are). >> >> But summing an empty collection of Durations, you would probably want Duration zero to be the result, and then we are back to our original problem ;-) >> >>> Also I'd like to sum Durations but its not defined for OperationsOnMagnitudes. >>> >>> I guess I fear there is hidden complexity for little gain. Maybe >>> those that like the idea can collaborate on a package they use on >>> their own projects to work out the kinks. >>> >>> cheers -ben >>> >>>>> >>>>> Sven >>>>> >>>>>> Best regards, >>>>>> Henrik >>>>>> >>>>>> -----Original Message----- >>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo >>>>>> Sent: Thursday, December 24, 2015 9:58 AM >>>>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: >>>>>> >>>>>> Just a remark. >>>>>> I think that we discarded the proposition of having >>>>>> >>>>>> aCol arithmetic sum >>>>>> >>>>>> but I found it nice because there if was clear that you want to get back >>>>>> 0 for #(). >>>>>> >>>>>> Stef

Jan. 7, 2016

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

by Nicolai Hess

2016-01-07 16:31 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Thu, Jan 7, 2016 at 9:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > >> On 07 Jan 2016, at 14:23, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito > >> <guillermopolito(a)gmail.com> wrote: > >>> I like these last. > >>> > >>> Particularly because > >>> > >>> - it cleans the collectionâs API > >>> - we can continue extending this idea to add parallelism, mutual > exclusion... > >> > >> I don't understand the second point. > > > > Wrapping an object in another to add behaviour is a standard technique > (as opposed to adding the behaviour to the object itself). There can be > several reasons for doing this. It is not necessarily or always a good idea > either (for example, extension protocols are nice too). > > > "standard technique" > > Does it have a pattern name?, that I could look up to learn more (btw > I have Design Patterns Smalltalk Companion - but its hard to remember > them without using them in practice.) ? > Decorator? https://en.wikipedia.org/wiki/Decorator_pattern > > cheers -ben > > > > >>>> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>> > >>>> Hi Henrik, > >>>> > >>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <henrin10(a)student.uia.no> > wrote: > >>>>> > >>>>> Like this? > >>>>> http://smalltalkhub.com/#!/~Latsabben/NumIt > >>>> > >>>> That is a cool take on a possible approach. Thanks for doing it, it > makes it much easier to think about and discuss alternatives. > >>>> > >>>> This inspired me to do something similar, but not quite. I am just > thinking out loud by implementation. Here is my result: > >>>> > >>>> <Collections-Operations-SvenVanCaekenberghe.1.mcz> > >> > >> Interesting to great enthusiasm from several people. Looks like I'm > >> in the minority but I'm wary of this. It seems like > >> over-intellectualized design. > > > > Yes, maybe ;-) > > > >> I'll need to remember whether to send > >> #magnitude or #numbers before an operation and which matches up with > >> which operations. This seems harder for newcomers. > > > > #(1 2 foo true false) sum => ? > > #() sum => ? > > { window1. window2. window3 } max => ? > > > >> Are there any other programming languages that do it this way? > > > > There are not so many fully dynamic languages with non-homogeneous > collections. Most languages have static typing and generic types (both are > not what we want). But I would love to see how comparable languages solve > this 'problem'. > > > > Most language won't allow (or don't define) operations on collections > that could fail because of the fact that they contain the wrong objects. > > > > Having said that, I am not saying that I want to move away from our > flexibility/simplicity ! > > > >>>> > >>>> There are some examples in the class comments. > >> > >> Class comment says CollectionOperations is "a class that offers > >> extended API to operate on collections assumed to contain objects of a > >> certain type." > >> > >>>> 1. CollectionOperations > >>>> 2. OperationsOnMagnitudes > >>>> 3. OperationsOnNumbers > >>>> 4. OperationsOnSequenceableNumbers > >> > >> So 2 & 3 refer to the elements of the collection, so 4 makes me wonder > >> what elements are sequence-able numbers? So 4 breaks the pattern to > >> refer to the type of collection not just the type of element. > > > > Yes, that is a problem, it feels wrong. There are several dimensions > that cannot be captured in one simple hierarchy. > > > >> Why is #average defined for OperationsOnNumbers rather than > >> OperationsOnMagnitudes? If I have a collection of magnitudes like Time > >> "17:28 . 17:29 . 17:31 . 17:32" or Duration "4 minutes . 6 minutes" > >> I would expect to be able to get 17:30 and 5 minutes as the respective > >> averages. > >> But then it doesn't make sense to average other magnitudes like > >> Character, so where does that leave us? > > > > You are wrong, a Magnitude is only comparable, it does not mean it can > do arithmetic. You need arithmetic to compute average. > > > > In this case, you could use #numbers to indicate that you see your > objects as compatible with that (and the time objects mostly are). > > > > But summing an empty collection of Durations, you would probably want > Duration zero to be the result, and then we are back to our original > problem ;-) > > > >> Also I'd like to sum Durations but its not defined for > OperationsOnMagnitudes. > >> > >> I guess I fear there is hidden complexity for little gain. Maybe > >> those that like the idea can collaborate on a package they use on > >> their own projects to work out the kinks. > >> > >> cheers -ben > >> > >>>> > >>>> Sven > >>>> > >>>>> Best regards, > >>>>> Henrik > >>>>> > >>>>> -----Original Message----- > >>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On > Behalf Of stepharo > >>>>> Sent: Thursday, December 24, 2015 9:58 AM > >>>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> > >>>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: > >>>>> > >>>>> Just a remark. > >>>>> I think that we discarded the proposition of having > >>>>> > >>>>> aCol arithmetic sum > >>>>> > >>>>> but I found it nice because there if was clear that you want to get > back > >>>>> 0 for #(). > >>>>> > >>>>> Stef > > > > > >

Jan. 7, 2016

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

by Ben Coman

On Thu, Jan 7, 2016 at 9:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 07 Jan 2016, at 14:23, Ben Coman <btc(a)openinworld.com> wrote: >> >> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito >> <guillermopolito(a)gmail.com> wrote: >>> I like these last. >>> >>> Particularly because >>> >>> - it cleans the collectionâs API >>> - we can continue extending this idea to add parallelism, mutual exclusion... >> >> I don't understand the second point. > > Wrapping an object in another to add behaviour is a standard technique (as opposed to adding the behaviour to the object itself). There can be several reasons for doing this. It is not necessarily or always a good idea either (for example, extension protocols are nice too). > "standard technique" Does it have a pattern name?, that I could look up to learn more (btw I have Design Patterns Smalltalk Companion - but its hard to remember them without using them in practice.) ? cheers -ben > >>>> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> Hi Henrik, >>>> >>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <henrin10(a)student.uia.no> wrote: >>>>> >>>>> Like this? >>>>> http://smalltalkhub.com/#!/~Latsabben/NumIt >>>> >>>> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives. >>>> >>>> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result: >>>> >>>> <Collections-Operations-SvenVanCaekenberghe.1.mcz> >> >> Interesting to great enthusiasm from several people. Looks like I'm >> in the minority but I'm wary of this. It seems like >> over-intellectualized design. > > Yes, maybe ;-) > >> I'll need to remember whether to send >> #magnitude or #numbers before an operation and which matches up with >> which operations. This seems harder for newcomers. > > #(1 2 foo true false) sum => ? > #() sum => ? > { window1. window2. window3 } max => ? > >> Are there any other programming languages that do it this way? > > There are not so many fully dynamic languages with non-homogeneous collections. Most languages have static typing and generic types (both are not what we want). But I would love to see how comparable languages solve this 'problem'. > > Most language won't allow (or don't define) operations on collections that could fail because of the fact that they contain the wrong objects. > > Having said that, I am not saying that I want to move away from our flexibility/simplicity ! > >>>> >>>> There are some examples in the class comments. >> >> Class comment says CollectionOperations is "a class that offers >> extended API to operate on collections assumed to contain objects of a >> certain type." >> >>>> 1. CollectionOperations >>>> 2. OperationsOnMagnitudes >>>> 3. OperationsOnNumbers >>>> 4. OperationsOnSequenceableNumbers >> >> So 2 & 3 refer to the elements of the collection, so 4 makes me wonder >> what elements are sequence-able numbers? So 4 breaks the pattern to >> refer to the type of collection not just the type of element. > > Yes, that is a problem, it feels wrong. There are several dimensions that cannot be captured in one simple hierarchy. > >> Why is #average defined for OperationsOnNumbers rather than >> OperationsOnMagnitudes? If I have a collection of magnitudes like Time >> "17:28 . 17:29 . 17:31 . 17:32" or Duration "4 minutes . 6 minutes" >> I would expect to be able to get 17:30 and 5 minutes as the respective >> averages. >> But then it doesn't make sense to average other magnitudes like >> Character, so where does that leave us? > > You are wrong, a Magnitude is only comparable, it does not mean it can do arithmetic. You need arithmetic to compute average. > > In this case, you could use #numbers to indicate that you see your objects as compatible with that (and the time objects mostly are). > > But summing an empty collection of Durations, you would probably want Duration zero to be the result, and then we are back to our original problem ;-) > >> Also I'd like to sum Durations but its not defined for OperationsOnMagnitudes. >> >> I guess I fear there is hidden complexity for little gain. Maybe >> those that like the idea can collaborate on a package they use on >> their own projects to work out the kinks. >> >> cheers -ben >> >>>> >>>> Sven >>>> >>>>> Best regards, >>>>> Henrik >>>>> >>>>> -----Original Message----- >>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo >>>>> Sent: Thursday, December 24, 2015 9:58 AM >>>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: >>>>> >>>>> Just a remark. >>>>> I think that we discarded the proposition of having >>>>> >>>>> aCol arithmetic sum >>>>> >>>>> but I found it nice because there if was clear that you want to get back >>>>> 0 for #(). >>>>> >>>>> Stef > >

Jan. 7, 2016

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

by Denis Kudriashov

2016-01-07 14:24 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Very, very cool Sven (and Henrik!)! > > > > And it even works with exotic objects: { 1@2. 2@3 } numbers sum ââ> (3@5 > )â > > > > I really not understand how it helps with original problem. There was > example with colors sum which was stop people to allow sum on empty > collection. How extra message solve it? > > (You should look at the code ;-) > > The example is confusing and not really relevant (because the points are > not numbers). > > Basically, sending #numbers to a collection returns an object, called a > 'collection operations' object (just a wrapper) that offers an interface to > do more operations on the collection, with the additional assumption that > it now contains (real) numbers. > > #(1 2 3) numbers sum => 6 > #() numbers sum => 0 > #(1 2 3) numbers product => 6 > #() numbers product => 1 > > #(1 2 3) asSet magnitudes max > #() asSet magnitudes maxIfEmpty: [ 100 ] > > But again, the code was just me thinking out loud, inspired by what Henrik > did, I am totally not sure it is a really good idea. Ok. I see it. And I like It.

Jan. 7, 2016

Re: [Pharo-dev] Atomic commits

by Damien Cassou

Hi, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> writes: > I wish the commits were much more atomic than they currently are... I agree. This is important (and one of my research topics https://hal.inria.fr/hal-01116225 :-)). Martin Dias worked on EpiceaUntangler to help developers do atomic commits http://smalltalkhub.com/#!/~MartinDias/EpiceaTaskClusterer. To put that in production, we need the Random Forest algorithm implemented in Pharo. > I can still open a fresh Pharo image and browse and review the whole code > snapshot there. > Or I can navigate more easily in history with git tools. > But if I wanted a lightweight review thru web, focusing on the diffs and > navigating a bit in history without replicating the repository, I can't. Skip is working on a code review tool. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Jan. 7, 2016

Re: [Pharo-dev] OSProcess stdout not working in OSX [WAS] Re: Status of GitFileTree in Pharo 5.0 and Spur

by Dimitris Chloupis

you could use the older Cog JIT VM but that means also an older pharo 5 non spur image. I managed to get it working that way. I am now studying ObjC to help with getting pharo better integrated with MacOS. On Thu, Jan 7, 2016 at 3:40 PM Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sun, Jan 3, 2016 at 12:54 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Le 03/01/2016 16:49, Mariano Martinez Peck a Ã©crit : >> >>> mmmm ok, I am giving it a try but it seems it's not working or... mostly >>> likely, I am doing something wrong. >>> I just created a repo via github web interface, then I clone it to my >>> machine, and then I tried to add the gitfiletree repo in MC Browser, but >>> I get an error in: #currentBranch because #gitBranchs answered an empty >>> array. But the `git branch` command was really executed as I can see the >>> output of it in the stdout of the VM. So I guess OSProcess stdout >>> setting may be what is not working? >>> >> >> You're on Mac when you do that, right? >> >> OSProcess output redirection doesn't work in the latest Mac VM... my >> fault (introduced in the OSProcess plugin) :( but I have no idea why the fd >> dup / pipes work on Linux and not on Mac OS X. >> >> > Thierry, is there a way we can rollback or do something with this change > that broke the stdout redirection in the OSProcess plugin? > > And if true, can we make the CI build new VMs with such a fix ? > > I want to use GitFileTree in 5.0 :( > > > > >> Thierry >> >> >>> Thanks in advance, >>> >>> On Sun, Jan 3, 2016 at 12:01 PM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>> >>> Hi Thierry, >>> >>> I had some problems with OSProcess in 5.0 with Spur so I wonder >>> what's the status with GitFileTree. Is it working with latest 5.0? >>> I tried to search some tests to confirm this but I found none. >>> >>> Thanks in advance, >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 7, 2016

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

by Sven Van Caekenberghe

> On 07 Jan 2016, at 14:23, Ben Coman <btc(a)openinworld.com> wrote: > > On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: >> I like these last. >> >> Particularly because >> >> - it cleans the collectionâs API >> - we can continue extending this idea to add parallelism, mutual exclusion... > > I don't understand the second point. Wrapping an object in another to add behaviour is a standard technique (as opposed to adding the behaviour to the object itself). There can be several reasons for doing this. It is not necessarily or always a good idea either (for example, extension protocols are nice too). >>> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Hi Henrik, >>> >>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <henrin10(a)student.uia.no> wrote: >>>> >>>> Like this? >>>> http://smalltalkhub.com/#!/~Latsabben/NumIt >>> >>> That is a cool take on a possible approach. Thanks for doing it, it makes it much easier to think about and discuss alternatives. >>> >>> This inspired me to do something similar, but not quite. I am just thinking out loud by implementation. Here is my result: >>> >>> <Collections-Operations-SvenVanCaekenberghe.1.mcz> > > Interesting to great enthusiasm from several people. Looks like I'm > in the minority but I'm wary of this. It seems like > over-intellectualized design. Yes, maybe ;-) > I'll need to remember whether to send > #magnitude or #numbers before an operation and which matches up with > which operations. This seems harder for newcomers. #(1 2 foo true false) sum => ? #() sum => ? { window1. window2. window3 } max => ? > Are there any other programming languages that do it this way? There are not so many fully dynamic languages with non-homogeneous collections. Most languages have static typing and generic types (both are not what we want). But I would love to see how comparable languages solve this 'problem'. Most language won't allow (or don't define) operations on collections that could fail because of the fact that they contain the wrong objects. Having said that, I am not saying that I want to move away from our flexibility/simplicity ! >>> >>> There are some examples in the class comments. > > Class comment says CollectionOperations is "a class that offers > extended API to operate on collections assumed to contain objects of a > certain type." > >>> 1. CollectionOperations >>> 2. OperationsOnMagnitudes >>> 3. OperationsOnNumbers >>> 4. OperationsOnSequenceableNumbers > > So 2 & 3 refer to the elements of the collection, so 4 makes me wonder > what elements are sequence-able numbers? So 4 breaks the pattern to > refer to the type of collection not just the type of element. Yes, that is a problem, it feels wrong. There are several dimensions that cannot be captured in one simple hierarchy. > Why is #average defined for OperationsOnNumbers rather than > OperationsOnMagnitudes? If I have a collection of magnitudes like Time > "17:28 . 17:29 . 17:31 . 17:32" or Duration "4 minutes . 6 minutes" > I would expect to be able to get 17:30 and 5 minutes as the respective > averages. > But then it doesn't make sense to average other magnitudes like > Character, so where does that leave us? You are wrong, a Magnitude is only comparable, it does not mean it can do arithmetic. You need arithmetic to compute average. In this case, you could use #numbers to indicate that you see your objects as compatible with that (and the time objects mostly are). But summing an empty collection of Durations, you would probably want Duration zero to be the result, and then we are back to our original problem ;-) > Also I'd like to sum Durations but its not defined for OperationsOnMagnitudes. > > I guess I fear there is hidden complexity for little gain. Maybe > those that like the idea can collaborate on a package they use on > their own projects to work out the kinks. > > cheers -ben > >>> >>> Sven >>> >>>> Best regards, >>>> Henrik >>>> >>>> -----Original Message----- >>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo >>>> Sent: Thursday, December 24, 2015 9:58 AM >>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: >>>> >>>> Just a remark. >>>> I think that we discarded the proposition of having >>>> >>>> aCol arithmetic sum >>>> >>>> but I found it nice because there if was clear that you want to get back >>>> 0 for #(). >>>> >>>> Stef

Jan. 7, 2016