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 =3D [NSArray array];
array =3D @"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 =3D [NSArray array];
array =3D @"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 =3D [NSArray array];
NSLog(@"%d", [array performSelector:@selector(length)]);

Of course I could also just do

id array =3D [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


On 29 Sep 2010, at 1:33PM, Eleanor McHugh wrote:

> A more profitable place to look for inspiration in building tools that =
support Ruby development would be amongst dynamic languages such as =
Smalltalk, Lisp and Forth. Like Ruby none of these assume a single =
compilation phase which fixes type properties indefinitely.