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] 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]> <mailto:[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]>
<mailto:[EMAIL PROTECTED]> [mailto:ironruby-core-
<mailto:ironruby-core-> <mailto:ironruby-core->
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]>] On Behalf Of Ivan Porto Carrero
Sent: Friday, August 22, 2008 12:31 PM
To: [email protected] <mailto:[email protected]>
<mailto:[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]>
<mailto:[email protected]>
http://rubyforge.org/mailman/listinfo/ironruby-core
 
 
 
--
Ryan Riley
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[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:  <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] 

Open2view.com 
The Real Estate Website 



<<image001.jpg>>

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

Reply via email to