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