On Wednesday, July 16, 2003, at 10:28 AM, Mark J. Reed wrote:

> Peter (having a bad day) Hickman wrote:
>> [snip]

>> The call for pre/post increment/decrement operators is pretty 
>> frequent.
>
> Well, that's because they're useful. :)  I mean, sure, x += 1
> works everywhere that ++x would, but if what you really want is
> x++ then you have to break it up into two statements.  [snip]

The x++ operator has been discussed extensively on this list on a 
number of occasions. The likelihood of it ever being added to Ruby is 
almost infintesimally close to zero. The fundamental reason, I think, 
is that a Fixnum object (upon which such an operator would operate) 
should never be mutable. The x+=1 operator emphasizes that a new Fixnum 
object is being assigned to the applicable variable.

> [snip]

>> We've had Java/C++/Whatever programmers ask for type checking, 
>> operator
>> overloading, polymorphism and a whole host of compile time checking.
>
> That would be a more fundamental change, obviously; Ruby is just not a
> strongly-typed language.  [snip]

There has been a lot of discussion on the list about this. Not 
surprisingly, Dave Thomas' contributions to the "type" discussions are 
extremely lucid and helpful. Ruby is strongly-typed. It is, however, 
dynamically typed and one does not declare types for variables (except 
deliberately and after creating code to implement variable type 
declaration). To the developer, Ruby is "duck-typed" -- objects are 
defined by the method calls they respond to.

>
> Now, as an O-O language Ruby automatically supports some forms
> of polymorphism.  And I do think it would occasionally result in
> clearer code if we could define multiple methods with the same name
> distinguished by number of arguments, rather than manually checking
> and dispatching within a single method, but that's a minor quibble.
> [snip]
Not to get into a paean to Dave Thomas, but a powerful way of 
approaching this kind of problem area is to define a private initialize 
method for a class and then create many methods with different names 
that call the initialize method to create different but related 
objects. There are some excellent discussions of this in the mailing 
list archives.

>> We've had programmers who wanted 'initialize' changed to 'new' so that
>> they would have less to type.
>
> Again, I'm all for concision (even though I know that it's not
> a real word), wherever it doesn't impede clarity.  In this case
> it would even enhance it - you call MyClass.new and that results
> in MyClass#new being executed.  Not only less typing, but also
> a more logical connection, easier to remember, and no conflicts
> since class methods and instance methods have separate namespaces.
> Sorry, why is this a bad idea again? :)
>
>> [snip]

I have never felt the desire to want to change def initialize to def 
new. For whatever reason, I have always felt comfortable with using the 
word initialize in the "model" part of the design and the word "new" in 
the controller part of the design.

Regards,

Mark