Home Original page

[Python-ideas] Method chaining notation

spir denis.spir at gmail.com
Sun Feb 23 12:51:25 CET 2014 
On 02/23/2014 06:27 AM, Haoyi Li wrote:
>> >The other means you're doing declarative stuff, transforming objects into
> new temporary objects. That distinction is huge
>
> I guess that's where people disagree. I think the distinction is not huge.
> Whether imperatively constructing something or "declaratively" (???) doing
> transformations, the *meaning* of the code is the same: start from some
> *foo* and do *some stuff *on *foo *in sequence until the *foo *is what I
> want.
>
> Whether it's implemented using mutation or allocation/garbage-collection is
> an implementation detail that clouds our view of a higher-level semantic:
> initializing an object with some stuff. In fact, this distinction is so
> meaningless that many languages/runtimes will turn one into the other as an
> optimization, because the semantics are exactly the same.

It's not the same if you have references to some of the objects involved; in 
python via "symbolic assignments", assignments which right side is a symbol, as 
in "b=a".

This is the whole point, I guess, and one core difficulty of complex system 
modelisation. Such references exist in the model being expressed (as in, Bob is 
Ann's boyfriend, and the football team goal keeper, and the manager of the shop 
around the corner, and...); or else your code is wrong (you're making up 
inexistent refs to things, as artifact of your coding style).

The 2 methods above are not semantically equivalent. In the mutative case, 
you're talking about one single *thing* (the representation of one thing in the 
model, correctly "reified" in code). This thing may be multiply ref'ed, because 
it is a thing and as such has multiple *aspects* or *roles* (or competences?). 
In the functional case, you making up new objects at every step, thus if there 
were ref's they would be broken. We should only use such a style for non-things, 
meaning for plain data (information) *about* things.

(This style is not appropriate for GUI widgets, which conceptually are things, 
and pretty often ref'ed. Instead widgets should be created on one go.)

d
More information about the Python-ideas mailing list