--- "David A. Black" <dblack / wobblini.net> wrote:

> Hi --
> 
> On Tue, 4 Oct 2005, Eric Mahurin wrote:
> 
> > To take advantage of type (really class) inference in an
> > optimal way, you'd need to know that the methods aren't
> > changing.
> 
> What about type (really type) inference? :-)  There have been
> some
> interesting projects looking at the matter of checking types
> in Ruby
> (not based on class/module membership), including one by
> Eivind and I
> think one by Florian Gross.  It's not easy... but anything
> less is, I
> think inevitably and almost by definition, going to reduce
> what one
> can do in Ruby.

Maybe I misunderstood what Eivind was asking for.  From the
last message it sounded like he was asking for the
interpreter/comilier/VM to try to infer what the class was for
the object of some variable.  The reason for doing this would
be  to transform something dynamically typed (all ruby
variables) to something statically typed.  I think this is the
critical thing needed in dynamically typed languages to give
performance that approaches statically typed languages.  I
don't know of any dynamically typed languages that have been
able to do this yet, but I think it is the next threshold. 
Maybe the "self" language has, but I still haven't found any
benchmarks for it.

It sounds like you are talking about type checking not class
inference.  I don't see a whole lot of use for specifying
something in the code to show the duck typing you are using for
various arguments in a method.  Maybe having rdoc scan the code
to see what methods the arguments are using would be useful
(somehow format this info in the generated docs).  This would
not be a trivial thing and I'm even sure how you would
completely describe the duck-type (I know you hate that term)
of an argument.



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com