Why does Python mix OO concepts and non OO concepts for operation s on basic types?
Quinn Dunkan
quinn at bolivar.ugcs.caltech.edu
Sun May 26 14:28:34 EDT 2002
More information about the Python-list mailing list
Sun May 26 14:28:34 EDT 2002
- Previous message (by thread): Why does Python mix OO concepts and non OO concepts for operation s on basic types?
- Next message (by thread): Why does Python mix OO concepts and non OO concepts for operation s on basic types?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 22 May 2002 22:59:18 GMT, Michael P. Soulier <msoulier at mcss.mcmaster.ca_.nospam> wrote: > Actually, one of the few things I like about Ruby is that all objects in >Ruby do have methods, and thus to add two numbers... > > 2 + 4 > 2.+(4) > > are equivalent. Not really: irb(main):001:0> 1 + 2 * 3 7 irb(main):002:0> (1).+(2).*(3) 9 irb(main):003:0> ... and everyone was annoyed with smalltalk for being consistent that way :) However, I don't think of 'obj.method' style notation as being the definition of 'OO'. It's just a style of syntax. len(o) is just as 'OO' as o.len(), and the real question is "why is the syntax different?". One reasonable answer to that (besides history) is that f(x) and x.f() both have different notational conveniences. It's nice to be able to type map(len, lists) rather than [ a.len() for a in lists ], but it's also nice to be able to type a.append(x) rather than list.append(a, x). x.f() tends to be notationally handy where a closure on the first argument is frequently useful (e.g. a.append). a.len is not so useful.
- Previous message (by thread): Why does Python mix OO concepts and non OO concepts for operation s on basic types?
- Next message (by thread): Why does Python mix OO concepts and non OO concepts for operation s on basic types?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list