From: Enric Lafont <enric@1smart.com>
Date: 2002-11-04T07:59:08+09:00
Subject: Re: Thoughts on Ruby

Austin Ziegler wrote:

>On Mon, 4 Nov 2002 05:42:37 +0900, Enric Lafont wrote:
>  
>
>>OK, if you have a:
>>  def += (anArgument)
>>      return (self + anArgument)
>>  end
>>
>>You will have exactly the same behaviour you have know, whitout
>>any trick
>>    
>>
>
>The problem, of course, is that I can now do:
>
>  def +=(anArgument)
>    return (self - anArgument)
>  end
>
>This subverts the whole point of +=.
>  
>
Yes of course, and I can do
def printReport
  STDIN.each_line {|aLine|  aLine.chomp!}   # Nothing gets printed
end

This does not means nothing, It's the work of the programmer to keep up 
with the semantics of a program, If I choose a bad name for a routine, 
Ruby can not do nothing (it's not his job)

>>Equally, you could define a
>>  def Object::++(anArgument)
>>      return anArgument + 1
>>  end
>>
>>AND
>>
>>  def Integer::++
>>      return self + 1
>>  end
>>    
>>
>
>What, then, is the result of:
>
>  "foo"++
>
>? Also, your definition of ++ with an argument makes no sense.
>  
>
Yes you need also Object:++ (without arguments), ++ is a method that 
adds one to the receiver

Object::++(anArgument) is the way to say  ++x (pre-increment) because 
I'm using the implicit object that Ruby uses , in this context it has a 
lot of sense, Integer::++ is the post-increment operator, this way you 
can have pre and post increment operators.

>>And you have NOW for free a pre-increment and a post increment.
>>This tries to explain the POWER of the every call is a method
>>    
>>
>
>Really, though, it doesn't explain it. It explains why you think
>that Ruby should have += as a separate method and that it should
>have ++/-- operators (even as methods), but it's not clear why you
>think that this demonstrates "every call is a method."
>  
>
I come from Smalltalk, and for me it's very natural that every call is a 
method, maybe I need to look for better examples, but I hoped that this 
example was enought.

>>    
>>
>Again; on the RHS (including either side of a a boolean test), it
>*is* an error. On the LHS, however, it won't be -- because LHS is an
>assignment. I just did the following:
>
>  p b == a
>
>I got:
>
>  NameError: undefined local variable or method `b' for
>  #<Object:0x2789330>
>
>I don't think that it's necessary to require declaration.
>  
>
I can not give you a real example now, but I remember a case where a bug 
was introduced becasue a mistake in the variable name. This is what made 
me think in a way to make the compiler check this errors. I'm testing 
now again, and yes, the behaviour is right, I'll look for that code to 
see how the bug was generated.

>>>>Why are Strings arrays of integers ? aString[0] is an integer,
>>>>yes, it's the way it is, but I would like to have String as an
>>>>array of chars, and char if you want as a descendant of Integer
>>>>(nice election because a Unicode String is and array of double
>>>>chars i.e. integer), I don't know you, but for me aString[i].chr
>>>>=='x' is somewhat unnatural, because it breaks the semantic of a
>>>>String, so it's not intuitive for me.
>>>>        
>>>>
>>>This was never intuitive for me either.
>>>      
>>>
>>Thanks, at least I'm not the only one
>>    
>>
>
>It's not intuitive -- it's bitten me more than once. But it's also
>something that as I said earlier is a *clear* issue. I think that it
>will be fixed by 2.0, if not earlier.
>
>  
>
>>My comments appeared, becasue Ruby is really very similar to
>>Smalltalk, just the small diferences makes Ruby less powerfull
>>that it can be.
>>    
>>
>
>I disagree that it reduces Ruby's power. I'm already finding Ruby to
>be the most expressive language that I've ever dealt with, bar none.
>  
>
Take the time to learn Smalltalk.... Ruby is very expressive and compact 
(I love it), and I don't recomend you to use Smalltalk, I'm learning 
Ruby because it's better suited to a lot of my daily tasks.

>>Just as an example, the closures are not objects, yes you can
>>"objectify" a closure, but closures seems to be a patch to the
>>language instead of an extension of it.
>>    
>>
>
>This isn't true.
>
>  def foo(a, &b)
>    p a
>    p b.arity
>  end
>
>  foo("foo") { |a| p "foo" }
>  foo("bar") { |a, b| p "bar" }
>  foo("baz") { |a, *b| p "baz" }
>
>No, you can't do { |a| p "foo" }.arity, but IMO this is a feature,
>not a bug.
>  
>
Con la iglesia hemos topado .... :-)  It's a phrase that says that the 
discussion is over because we have arrived to the bug vs. feature, and 
nothing can be discussed here. Ok, I agree it's a feature...

Enric