[ruby-core:32654] Re: Proposal for Optional Static Typing for Ruby

On 29 Sep 2010, at 17:14, Martin Pilkington wrote:

> Hi Ellie,
> 
> My inspiration for this has actually been a dynamic language: Objective-C. It offers the only good combination I've seen of highly dynamic OOP and static typing. To give some examples of what it can do:
> 
> NSArray *array = [NSArray array];
> array = @"my string";
> NSLog(@"%d", [array length]);
> 
> When this is compiled I get two warnings. The first about assigning a string to a variable typed as an array, the second is that NSArray may not respond to 'length'. Now if this was Java those would be compiler errors and this code wouldn't run, but as this is Objective-C and objects are duck typed then that code does run and it outputs 9. Now I can choose to throw away that type information if I wish. The following code is exactly the same, except I don't have any of the type checking and so get no warnings:
> 
> id array = [NSArray array];
> array = @"my string";
> NSLog(@"%d", [array length]);
> 
> The static typing doesn't prevent Obj-C being a highly dynamic language. It simply means that you may get warnings if you do something that could be stupid. Now you may wonder, "what if did want to call 'length' on an NSArray, as I'm adding the 'length' method at runtime or forwarding it off to another class to handle?". Well, Objective-C gets around it by providing some methods, so I could do:
> 
> NSArray *array = [NSArray array];
> NSLog(@"%d", [array performSelector:@selector(length)]);
> 
> Of course I could also just do
> 
> id array = [NSArray array];
> NSLog(@"%d", [array length]);
> 
> Either way, the combination of the two is possible, without taking away from the dynamic nature of the language. It isn't 100% perfect, but it works 99% of the time. After all, even in Ruby, most of the time you aren't necessarily doing something incredibly dynamic like calling a method that isn't defined until runtime, so the type information can be useful for finding bugs far more than it would get in the way (which from years of Obj-C experience it never has).
> 
> Thanks
> 
> Martin

Hi Martin,

When we say that Ruby is a dynamic language we're not just referring to the fact it supports dynamic typing, but also tacitly saying that the code encountered at runtime is only loosely coupled to that which is embodied in the source code. As a community we probably don't discuss this as often as we should, especially given that many of the more powerful code refactoring tricks in our toolkit rely upon the use of module_eval to customise objects or mess with the class or meta-class hierarchy. In this sense our mindset is much closer to that of Lisp (eval) or Forth (create...does) than it is to any of the C family of languages.

So whilst I agree that for the particular instances you discuss code annotations could indeed be helpful upon occasion, I'm much more sceptical of their general application and hence of the desirability of adding another layer of complexity to Ruby's interpretation model - especially if that additional layer of complexity doesn't result in any direct runtime benefit.


Ellie

Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason