How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?

[Stephen Horne]

On Wed, 25 Feb 2004 20:42:38 GMT, Joe Mason <joe at notcharles.ca> wrote:

>In article <mailman.100.1077717447.8594.python-list at python.org>, Dave Brueck wrote:

>> someFunc(functionCallback)
>> f = Foo()
>> someFunc(f.methodCallback)
>> 
>> This is pretty darn useful and IMO quite Pythonic: the creator of the function
>> and the creator of the callback have to agree on only the most minimal set of
>> details - just those relating to the calling interface - leaving completely
>> open any implementation details.
>
>I still don't see how this is notable.  Seems perfectly straightforward to
>me - I'd just assume that's how it worked except in C++, about which I
>never assume anything.

I don't know how widespread it is among very high level languages, but
there is a reason (in the not-that-high-level sense) that C++, and
other 3GLs with classes hacked on don't. I'm assuming object Pascals
and Basics (esp Delphi and VB) count here, though don't sue me if I'm
wrong - I'm not familiar with object support in either.

A bound method needs more information that the address of the function
that implements it. It also needs the address of the object that it
applies to, stored along with the function address. So a bound method
may look like a function when it is called, but in low level
implementation detail, it is not the same thing. In the Python
internals, I imagine there is a bound method type which contains
pointers to both the object and the unbound method.

The thing is that a bound method amounts to a restricted version of
currying - in effect, you have curried the 'self' parameter.

With currying, you can define a more sepecialised function using a
more general one by specifying some subset of the parameters. A simple
Python-like syntax may be...

  def original_fn (a, b, c) :
    pass

  specialist_fn = original_fn (, 2, )

  specialist_fn (1, 3)

The currying in the assignment statement supplies parameter b, with
the remaining parameters a and c not being provided until the call.

To implement a curry'd function, you need a closure in addition to the
original function address - a record recording the values of the
parameters that have been supplied so far, and which parameters have
yet to be supplied. Just as you need the object bound-to as well as
the method to implement a bound function.

Imperative 3GLs kept functionality and data pretty thoroughly
separated - hence a lot of the OO fuss. Currying is standard in
functional languages. But currying predates object orientation by a
long time. In fact, I'm pretty sure it was invented about a century
ago as math (lambda calculus) rather than as programming, though I
could easily be confused.

Anyway, from this perspective, the bound method is an interesting
in-between concept. I've sometimes wondered if full currying support
may have been a better choice, but then a bound method is much more
efficient simply because it's simpler - not to mention avoiding some
syntactic difficulties I ignored above.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk