From: Lothar Scholz <mailinglists@...>
Date: 2004-12-01T18:27:35+09:00
Subject: Re: Optional static typing (or, What can Ruby 2.0 borrow from Boo?)

Hello gabriele,

gr> Lothar Scholz ha scritto:


gr> Anyway, notice that I submitted  RCR280 wich actually allow you to give
gr> type assertions if you want them:

I must say that i don't like it because it mixes again runtime and
compile time. i would really favour:

# if you want to add an integer to a subclass of Numeric
 def sum a,b
   assert_type "a => Numeric, b = Integer"
   a+b
 end

Only if everything can be extracted statically (by looking at the code)
 then you get into a better position then what is currently available.
 
 Mixing another special feature like conversion into this is something
 i absolutely don't like. Two different purposes should have to
 different notations. Also your RCR makes the situation worse, adding
 more invisble magic. But the main goal here is to be more verbose.

 The assert_type could be extended to help with collections and other
 things a little bit:

 assert_type "h => Hash[Integer], object.foo = String, @myvar = Dummy"

I think there are many more things left for discussion but my
"must do" points are:

1) Don't make the implementation of this customizable to non ruby core
   hackers.

2) Use a special syntax if this is better for readability.
   To do this independent of ruby i suggest to embedd this into a string
   notation. And enforce that the argument is a literal. (Can easly be
   done from the C side).

3) Type constraints are type constraints and nothing else.

4) A program must run exactly the same if you disable the implementation.

5) Don't allow any tricky or shortcuts for lazy programmers.

 
 


-- 
 Best regards,                        emailto: scholz at scriptolutions dot com
 Lothar Scholz                        http://www.ruby-ide.com
 CTO Scriptolutions                   Ruby, PHP, Python IDE 's