Speaking of continuations, what is the status of continuations for IronRuby? Is it in or out? If it's in, then I would think you should leave it.
On Sat, Aug 23, 2008 at 9:44 AM, John Lam (IRONRUBY) <[EMAIL PROTECTED]>wrote: > Hi Ivan, > > I thought I'd give a few quick comments on your paper: > > - re: Duck Typing - I wouldn't characterize Ruby as not caring, or "caring > less" about its type hierarchy. Ruby does depend on the type hierarchy > (which includes mixins) to determine the method resolution order when > dispatching method calls. > > - re: implicit type conversions - while it's true that Ruby does not > perform implicit type conversions by default for the case of 1 + "1", > programmers are free to (and have done) overloads of the "+" method to do > exactly this kind of thing. > > - I think it would be better to simply describe the typing models > (static/dynamic, weak/strong) by example in different exemplar languages > followed by some examples in Ruby that characterizes it as a strong/dynamic > language. > > - In the case of your conversion argument, "Ruby won't allow you however to > change the type of an integer object without an explicit conversion step ... > ". The conversion step actually creates a new object - it doesn't change the > type of an existing object. This is an important distinction since "changing > the type of an object" would infer somehow changing the 'shape' of the > object. This can be accomplished in Ruby by adding / removing / changing > mixins, adding / removing / changing methods etc. In other languages like > Python, you can change the 'shape' of a class by redefining what its base > class is. This, to me, is the essence of what makes a language 'dynamically > typed' - you can change types at runtime vs. baking them at compile time. > > - re: closures - blocks also capture their containing lexical scope. > Lambdas are required to turn blocks into first-class entities (assigning to > variables). > > - re: continuations - I would cut out the section on continuations entirely > since it is an esoteric construct that is not consistently supported across > all Ruby implementations. > > - re: example of overloading System::String: You introduce global variables > in your example without explaining what they are. I would rewrite this using > only local variables since we have the artificial limitation of not > supporting locals yet in our console. > > - re: WPF example. There's a lot of magic included in the require 'wpf' > line of code. While this is early in the book, I would definitely call out > the magic in require 'wpf', or at least make a goal of explaining how that > magic works in a subsequent chapter that you can forward ref from the > example. > > Thanks, > -John > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:ironruby-core- > > [EMAIL PROTECTED] On Behalf Of Ivan Porto Carrero > > Sent: Friday, August 22, 2008 12:31 PM > > To: [email protected] > > Subject: [Ironruby-core] Green paper on IronRuby > > > > Manning just published my green paper on ironruby. > > http://manning.com/free/green_carrero.html > > > > _______________________________________________ > Ironruby-core mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Ryan Riley [EMAIL PROTECTED] http://www.panesofglass.org/
_______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
