[ruby-talk:00901] Re: Contrast Ruby and Other Languages

Yukihiro Matsumoto writes:
> Hi,
> 
> In message "[ruby-talk:00895] Re: Contrast Ruby and Other Languages"
>     on 99/11/01, Clemens Hintze <[e-mail]> writes:
> 

[...]

> 
> How about `inconvenient OOPL'?

Hmm, hmm, hmm. Difficult, difficult, difficult ...

Python OOP is not inconvenient per se. Perl's one, I would call
inconvenient. But in Python, there are only two things, that disturbes
me ... tiresome 'self.' and ugly parent class method invokation. But
the rest is far better than that of e.g. Perl.

But I don't know, how to name it else ... :-]

[...]

> I understand your feeling.  We may be abusing the word iterator :-)

That would be fine :-) I currently discuss with a Python adept, that
hate Perl, had a glance to Ruby, see the similarity concerning syntax,
and abandom Ruby therefore altogether.

It was not too easy to explain him, the difference between iterator
term used in Ruby vice versa the one used in the rest of the world ...

[...]

>   block_given?
>   with_block?
>   has_block?
>   have_block?
> 

[...]

> How do you feel?  Which one do you like best?  Or other candidate?

I think, I like have_block? the best! But OTOH, with_block? would
describes more clearly what is meant. IMHO, a method doesn't posess a
block, but it is called *with* a block ... :-/ But in that sense,
block_given? would be more appropiate then ... diffcult decision,
really ...

Let us see it within code:

    def greet(whom)
       if have_block?
          yield
       else
          print "Hello "
       end
       print whom
    end

    def greet(whom)
       if with_block?
          yield
       else
          print "Hello "
       end
       print whom
    end

    def greet(whom)
       if block_given?
          yield
       else
          print "Hello "
       end
       print whom
    end

Okay, I think 'block_given?' will win for me (although I don't like it
much, but it express most clearly what is meant, IMHO)!

[...]

> The original list is intended to be mere deference list.  We may have
> to make Ruby PR pages for each other languages.  Anyway, I will add
> the items such as:
> 
>   * Some object is not a class instance.  Type/class mix
>     prevents uniform object treatment.  Extension modules in C
>     can't generate class instances.
>   * Can't inherit classes defined in C.
>   * Hard to make classes mostly defined in the script, partly defined
>     in C.

Here, I am not sure. I can agree, that it is not obvious to do so, and
not easy too, but I think, there is an extension named ExtensionClass
or similar. This extension seems to enable you to bind extension and
Python classes more together.

But I cannot say for sure, as I have not used it ... but wait a moment
...

I have had a look to the Webpage of Python. I was right! Here is what
they say:

___CITE___
Extension Classes - a mechanism for making Python extension types more
class-like (Jim Fulton, Digital Creations)

   Using this mechanism, classes can be developed in an extension
   language, such as C or C++, and the resulting objects can be
   treated like other python classes:

      o They can be subclassed in python, 
      o They provide access to method documentation strings, and 
      o They can be used to directly create new instances. 

   Extension classes provide support for extended method binding
   protocols to support additional method types and additional
   method call sematics.
___END-CITE___

So I think, we can only state, that all these points are true in the
core interpreter of Python. And, for sure, that it is not so easy as
in Ruby anyway! :-)

[...]

> 
> And I'll put some of your statement into the `What's Ruby' page.

Arrgghh! Have you spell-checked my statements????

No you have not ... may I suggest some fixes?

... to add methods to a class, or even an instance during runtime. 
                                      ^ to

... class can import an module and so becomes all it methods for ...
                                 gets ^^^^^^^     ^^ its

Ruby features block in its syntax ...
              ^^^^^ blocks

... to care about maintaining reference count in extension libraries. 
      ^ take                            ^^^^^ counts

May I also suggest, that you introduce something like this:

Ruby features OS independend threading. That means, for the most of
the platforms Ruby is available, you also will have multithreading,
regardless if the OS supports it or not (even under MS-DOS ;-)

> 
>                                                         matz.

\cle