On Mon, 4 Nov 2002 05:42:37 +0900, Enric Lafont wrote:
>> Hal Fulton:
>> In Ruby, a += b means a = a + b ALWAYS, without fail. This means
>> that you get += "for free" when you define +, and you are spared
>> having to write both. If you want += to have some other meaning,
>> I would have to ask "Why?" It seems logical to me to tie the
>> meaning of += to + (unlike C++).
> 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 +=.

>> As for ++ and --, these are impossible in Ruby for much the same
>> reason I mentioned before. They are operations on variables,
>> whereas Ruby methods and operators work on objects. If I say: x++
>> I am trying to increment the OBJECT that x refers to. Does this
>> mean that every variable with the same value should be changed
>> also? For that matter, what should 5++ mean?
> 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.

> 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."

>>> Undeclared variables, I don't know other people but I do fast
>>> typing and writing "aVariable" and "aVariabel" is a mistake
>>> that I can do very easily. Yes you can say, type more slowly,
>>> but this is not a solution, I would like to have a way to force
>>> the compiler to generate a warning when I use a non
>>> pre-declared (or pre asigned) variable.
>> If you use it on the right hand side, it will be an error.
>> 
>> It was difficult for me to get used to a language without
>> variable declarations. But it seems to be a thing which Matz
>> always insists on. And I got used to it, and now I like it.
> it will be an error because some method will fail, but and
> undefined variable is nil, so it's a valid object. This is
> something that IMHO is an error.

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.

>>> 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.

>>> Don't get me wrong, I understand that Ruby is a young language
>>> that needs some maturing, and I love how easy is to learn, it's
>>> dinamicity and the fact that is a kind of mix between my loved
>>> Smalltalk, Self and other languages. In fact I'm writing this
>>> because I want to understand Ruby better and becasue I want to
>>> make some suggestions for future releases, maybe Mr. Matsumoto
>>> would like to consider some of them
>> My advice is to wait 90 days before suggesting language changes.
>> :) Every newbie makes these suggestions (as I guess I did too).
>> But most of them have been thought of before (as a search of the
>> list archives will show). Some are under consideration, some are
>> planned for the future, and some have been rejected by Matz.
> 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.

> 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.

-austin
-- Austin Ziegler, austin / halostatue.ca on 2002.11.03 at 15.52.53