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

On 29 Sep 2010, at 16:03, Loren Segal wrote:
> Eleanor,
> On 9/29/2010 8:33 AM, Eleanor McHugh wrote:
>> It strikes me that much of the premise behind this thread is =
misguided as it overlooks the importance of meta-programming in =
developing any Ruby program of substantive size. Where a Java or C++ =
programmer might write a factory method to create instances of a class =
and spend much of their effort enumerating types explicitly, it's not =
unusual in Ruby to write meta-programs which create a variety of class =
and method definitions on request to create or repurpose object =
instances for the task at hand.
>=20
> I'm not sure there's any practical incongruity between =
meta-programming and type annotations. No amount of meta-programming can =
change the body of a method.

This is technically incorrect as Ruby methods can take arbitrary code =
blocks as parameters, which in essence can fundamentally change the =
nature of any such method body at runtime. Couple that with alias_method =
and nominative type annotations look somewhat anaemic.

> You can replace the method itself (alias_method), but because type =
annotations would be attached to the methods themselves, the type =
information would be replaced too.

As I mentioned in my previous reply to Martin, the compilation boundary =
you are tacitly assuming exists is in fact no such thing. You therefore =
have to consider that any use of module_eval, class_eval, eval or class =
opening may result in type annotations coming into existence at an =
arbitrary point during program execution and likewise being discarded.

> Therefore, you can consider any type annotations to a method =
declaration to be something of a "contract" for using the method. Of =
course you can misuse types here (specify something too limiting, or =
something completely wrong), but it wouldn't be fair to consider the =
misused cases first. Do you have any examples of where meta-programming =
would "repurpose" an object such that existing type information would be =
completely invalid?

For some classic examples I recommend studying various of _why?'s =
projects, or at least pondering some of the more unusual tricks in his =
(Poignant) Guide which is an excellent exploration of how to really use =
Ruby's type system to your advantage. On a more mundane level, tricks =
like this exist inside various versions of Rails and many other popular =
projects.


Ellie

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