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

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

> Hi Ellie,
>=20
> 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:
>=20
> NSArray *array =3D [NSArray array];
> array =3D @"my string";
> NSLog(@"%d", [array length]);
>=20
> 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:
>=20
> id array =3D [NSArray array];
> array =3D @"my string";
> NSLog(@"%d", [array length]);
>=20
> 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:
>=20
> NSArray *array =3D [NSArray array];
> NSLog(@"%d", [array performSelector:@selector(length)]);
>=20
> Of course I could also just do
>=20
> id array =3D [NSArray array];
> NSLog(@"%d", [array length]);
>=20
> 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).
>=20
> Thanks
>=20
> 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