Thanks for your remarks guys, this is just a paper my book is available at
*shameless plug* http://manning.com/carrero :).
I ripped out the part about the continuations, clarified the duck typing a
little bit.  Replaced the global variables with regular variables.
I also explained about blocks and the difference with a lambda, the
conversion argument and mention that developers have made that implicit
typing work for them in their applications.
And I explain the require 'wpf' and 'wpf_elements' lines in the example on
WPF.

I describe these models (static/dynamic, strong/weak) in my book in more
detail with C# as the statically typed language. I just wanted to keep that
more lengthy discussion out of this paper. I see the paper as an appetizer
to go buy the book.

I agree on the appearance argument.
I will change the word from implicit to automatic (automagic rubs me the
wrong way because there is rarely magic involved in programming and I'm
pedantic). And I'll write that off due to not being a native english speaker
:)


Hopefully they will publish the new version when the people wake up in the
time zone where Manning is.


Thanks again
Ivan

On Mon, Aug 25, 2008 at 9:48 AM, Peter Bacon Darwin <
[EMAIL PROTECTED]> wrote:

>  John Lam is right but it does depend on your point of view.  The Ruby
> interpreter itself does not do any automatic type conversions but the
> built-in libraries are cleverly written to give the appearance of implicit
> conversion.  So if you view the libraries as part of the whole then you can
> assume that type conversion is implicit.
>
> Pete
>
>
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Orion Edwards
> *Sent:* Sunday,24 August 24, 2008 23:45
>
> *To:* [email protected]
> *Subject:* Re: [Ironruby-core] Green paper on IronRuby
>
>
>
> I'd argue against that.
> The fact that methods are called, and you can intercept or override them is
> enough for me to make it not 'implicit.' Perhaps implicit is not the right
> word, but yeah.
>
> Contrast this with C, where some bits are just rammed into some containers,
> or PHP, which decides completely by itself what to do with your variables
> based on however it feels that day.
>
> Jim Deville wrote:
>
> I'd actually disagree that Ruby doesn't do implicit type conversions. #to_int 
> is implicitly called in the example John gave (well, kinda called, I think 
> #coerce is called, which tries #to_int), it just happens that String doesn't 
> have to_int defined. This is the basis of the entire coercion protocols, 
> which I only barely understand.
>
>
>
> JD
>
> ________________________________________
>
> From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Tomas Matousek [EMAIL 
> PROTECTED]
>
> Sent: Saturday, August 23, 2008 3:12 PM
>
> To: [email protected]
>
> Subject: Re: [Ironruby-core] Green paper on IronRuby
>
>
>
> Continuations are not supported.
>
>
>
> Tomas
>
>
>
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] <[EMAIL PROTECTED]>] On 
> Behalf Of Ryan Riley
>
> Sent: Saturday, August 23, 2008 1:45 PM
>
> To: [email protected]
>
> Subject: Re: [Ironruby-core] Green paper on IronRuby
>
>
>
> 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]<mailto:[EMAIL PROTECTED]> <[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:[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
> [mailto:ironruby-core <ironruby-core>-<mailto:ironruby-core-> <ironruby-core->
>
> [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]>] On Behalf Of 
> Ivan Porto Carrero
>
> Sent: Friday, August 22, 2008 12:31 PM
>
> To: [email protected]<mailto:[email protected]> 
> <[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]<mailto:[email protected]> 
> <[email protected]>
>
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
>
>
>
> --
>
> Ryan Riley
>
> [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
>
> http://www.panesofglass.org/
>
> _______________________________________________
>
> Ironruby-core mailing list
>
> [email protected]
>
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
>
> --
> *Orion Edwards *
> Web Application Developer
>
> T: +64 7 859 2120
> F: +64 7 859 2320
> E: [EMAIL PROTECTED]
>
> *Open2view.com *
> *The Real Estate Website*
>
>
> _______________________________________________
> Ironruby-core mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
GSM: +32.486.787.582
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim

<<image001.jpg>>

_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

Reply via email to