I'd say that it is not quite a proxy nor a decorator as their main characteristic is to maintain the api of its wrapee, and so be polymorphic and transparent. At least not the number example. The main reason of this wrappers are to augment the api. But i do not know if that has a name.
However, a wrapper implementing mutual exclusion could enter in the decorator category... Le 7 janv. 2016 16:38, "Sven Van Caekenberghe" <s...@stfx.eu> a écrit : > > > On 07 Jan 2016, at 16:31, Ben Coman <b...@openinworld.com> wrote: > > > > On Thu, Jan 7, 2016 at 9:40 PM, Sven Van Caekenberghe <s...@stfx.eu> > wrote: > >> > >>> On 07 Jan 2016, at 14:23, Ben Coman <b...@openinworld.com> wrote: > >>> > >>> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito > >>> <guillermopol...@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 <s...@stfx.eu> > wrote: > >>>>> > >>>>> Hi Henrik, > >>>>> > >>>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <henri...@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-boun...@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 > > >
