On Thu, Jan 7, 2016 at 9:40 PM, Sven Van Caekenberghe <[email protected]> wrote: > >> On 07 Jan 2016, at 14:23, Ben Coman <[email protected]> wrote: >> >> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito >> <[email protected]> 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 <[email protected]> wrote: >>>> >>>> Hi Henrik, >>>> >>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <[email protected]> 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:[email protected]] On Behalf Of >>>>> stepharo >>>>> Sent: Thursday, December 24, 2015 9:58 AM >>>>> To: Pharo Development List <[email protected]> >>>>> 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 > >
