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