2012/10/29 Chris Angelico <ros...@gmail.com>: > On Tue, Oct 30, 2012 at 2:55 AM, Paul Rubin <no.email@nospam.invalid> wrote: >> andrea crotti <andrea.crott...@gmail.com> writes: >>> and we want to change its state incrementing the number ... >>> the immutability purists would instead suggest to do this: >>> def increment(self): >>> return NumWrapper(self.number + 1) >> >> Immutability purists would say that numbers don't have "state" and if >> you're trying to change a number's state by incrementing it, that's not >> immutability. You end up with a rather different programming style than >> imperative programming, for example using tail recursion (maybe wrapped >> in an itertools-like higher-order function) instead of indexed loops to >> iterate over a structure. > > In that case, rename increment to next_integer and TYAOOYDAO. [1] > You're not changing the state of this number, you're locating the > number which has a particular relationship to this one (in the same > way that GUI systems generally let you locate the next and previous > siblings of any given object). > > ChrisA > [1] "there you are, out of your difficulty at once" - cf WS Gilbert's > "Iolanthe" > -- > http://mail.python.org/mailman/listinfo/python-list
Yes the name should be changed, but the point is that they are both ways to implement the same thing. For example suppose I want to have 10 objects (for some silly reason) that represent the next number, in the first case I would do: numbers = [NumWrapper(orig.number)] * 10 for num in numbers: num.increment() while in the second is as simple as: numbers = [orig.next_number()] * 10 composing things become much easier, but as a downside it's not always so easy and convienient to write code in this way, it probably depends on the use case.. -- http://mail.python.org/mailman/listinfo/python-list