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