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

  Hi Eleanor,

On 9/30/2010 11:01 AM, Eleanor McHugh wrote:
> On 29 Sep 2010, at 16:03, Loren Segal wrote:
>> 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.
>

We seem to be talking about two very different things here. The fact 
that Ruby takes code blocks as parameters doesn't change the fact that 
you can still insert type annotations for an existing method. "Anaemic" 
is one thing, but we're not talking about a feature that will be useful 
in *all* cases, simply a feature that will have high impact on the 
majority of existing code. While there are many tricks in Ruby, and many 
frameworks use these tricks in limited areas, the majority of Ruby code 
still tends to be standard every day non-metaprogrammed Ruby, which 
could easily benefit from these annotations.

>> 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.

I'm not making any assumption about compilation boundaries, and I very 
much know that Ruby is known for making run-time changes to program 
structures. Fortunately, *_eval has no effect on whether or not type 
information is provided. Again, type annotations are not only meant for 
"compile-time", and I never made that claim. I can easily consider that 
annotations would come into existence at an arbitrary point during 
program execution. That fact has no bearing on the benefits. I ask you: 
what's wrong with that?

>> 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.
>

Do you have a specific example? It's easy to say "they're out there, 
just look". Again, I should point out that I'm aware what things can be 
done with Ruby at run-time, but that is not the purpose of this 
discussion. I'll ask again: what Ruby idiom or meta-programming could be 
used in order to make an existing (and still existing) type annotation 
no longer useful for: 1) documentation, 2) optional run-time type 
checking, 3) method overloading, 4) run-time compiler optimization? If 
you can show an example that makes it so none (or at most 1/4) of those 
benefits can be applied to the newly introduced code, I would be 
convinced that Ruby meta-programming could do what you claimed.

- Loren