On Mon, Oct 21, 2013 at 1:07 PM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > One of the reasons multiple languages exist is because people find that > useful programming idioms and styles are *hard to use* or "ugly" in some > languages, so they create new languages with different syntax to make > those useful patterns easier to use. But syntax is not everything. > Whether you write: > > object.method(arg) // Python, VB, Ruby, Java > object#method arg // OCaml > object:method arg // Lua > method object arg // Haskell, Mercury > object method arg // Io > object->method(arg) // C++, PHP > method(object, arg) // Ada, Dylan > send method(arg) to object // XTalk family of languages > > > etc. does not really change the fact that you are calling a method on an > object, despite the change in syntax. Even Forth has frameworks that let > you write object-[oriented|based] code using a stack and reverse Polish > notation syntax.
There seems to be a school of thought that "if it doesn't have special syntax, the language doesn't support it". This is true to an extent (eg C doesn't support sockets, the code is all in the standard library), and it does distinguish C from C++ in object orientation (C's version is simply dedicating the first function argument to 'self', where C++ and Python and so on have an alternative syntax that puts the self/this argument before the function name), but I don't know that it's the whole story. Python 2.x has special (and somewhat magical) syntax for file I/O; Python 3.x, as far as I know, has none - open and print are just builtins, with no magic around them. Which is better? I would say that standard functions are inherently more flexible (you can shadow print and call the original, for instance), but that would mean that the better way is to NOT "support" I/O. If an analogy helps, let's look at the trading card game Magic: The Gathering. The general design principle is that unusual effects get written out on the card, rather than having actual rules to support them; rulebook text is used only when printing abilities on the card is unable to do everything. (There are also keyword abilities, which are like Python's builtins - "fear" simply means "can't be blocked except by artifact and/or black creatures", and it could just as well be written out on the card.) Does this mean that Magic supports lifelink (which has entries in the Comprehensive Rulebook) but doesn't support defenders (which simply can't attack)? I think not; the game is most definitely designed for both. Granted, C probably wasn't designed with object orientation in mind; but it doesn't take very much effort to make it work (just pointer casts and some argument order conventions). Sure, a bit of real support helps (preventing accidental cross-casts), but it's pretty easy to manage without. Adding to the list of object oriented C systems is NIH: http://ifdeflinux.blogspot.com/2012/05/quick-libnih-tutorial.html It's small enough and light enough to be used by really early systems like Upstart (a Linux bootloader) and it's a garbage-collected object-oriented C library. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
