On Thu, Jan 7, 2016 at 9:40 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
>
>> On 07 Jan 2016, at 14:23, Ben Coman <btc@openinworld.com> wrote:
>>
>> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito
>> <guillermopolito@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@stfx.eu> wrote:
>>>>
>>>> Hi Henrik,
>>>>
>>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <henrin10@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@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
>
>