We've had this debate before. Please go read the past discussions [1] before trying to bring something new to the table, or saying ruby needs 'X' to be successful. Especially since we've got lots of ways to add typing to ruby already [2] [3].
[1] site:blade.nagaokaut.ac.jp type check - Google Search
[2] Index of /~eivind/ruby/types/
[3] http://mephle.org/StrongTyping/
Wow, talk about missing the point.
No, I know exactly your point, but you are being very bad at expressing it. Constantly saying that everybody is attacking you does not add credit to your statement, either. Eivind Eklund wrote a rather wonderful piece on exactly what you haven't expressed, but want to. Unfortunately its URL escapes me.
1. Ruby already has typing, in fact it already has strong typing. There
is no way to apply an operation to (invoke a method on) an object where
the operation is not suited to the type of the object.
This is now about the third time we've gone around with people attacking
the idea of restricting how objects can be passed around based on their
class, which I'm quite happy to attack, too. We're in full agreement here!
The speed at which you have responded, and the way you are thinking you have been attacked indicate you haven't read nearly enough of the history of this debate in Ruby (if it all). Only 3 hours is not enough to fully comprehend why what you want is hard in Ruby, and why people are perfectly happy the way things are.
Let me go back to your original statement, since that is your clearest post on your position to date...
No, Ruby's implementation of [Duck Typing] is the problem. You can do duck typing
very much like Ruby does and still have statically checked types; you
just need a type inference engine to do that for you.
I fully agree with you that a type inferencing engine can do this for you, but in Ruby it will be hard (the Self papers are the best reference on this).
I think that that may actually be the next big step in popular
programming languages. A lot of programmers these days expect that they
will both never have a memory leak, and never have to track memory
allocations and deallocations by hand. So we have garbage collectors.
Yep, its always great when the computer does things for us. Nobody here will debate you on that.
Soon people may see that it's perfectly reasonable to expect to be told
at compile time type about type mismatches, and yet not have to keep
track of types by hand, in the way that Java forces you to (and prevents
duck typing). So add a type inference engine or whatever you need for
this.
Yes, this would benefit us greatly, except for one problem... There is no "compile time" in Ruby, there is only run-time. (Self's type inferencing doesn't have a problem with having no "compile time", but Self has several advantages over Ruby. Its biggest advantage is that Self has people who want to work on this problem working on this problem... Ruby doesn't).
And now back to the rest of your mail:
So can we talk about TYPES, not classes, and maybe you can tell me
what you disagree with about making Ruby a bit smarter about this sort
of thing?
I agree Ruby should be as smart as it can about this, it is just hard (please see the Self papers and the history of this discussion on the mailing list).
That an unmodified standard Ruby installation, attempts to
execute the second statement of this complete program:
a = Object
a.not_a_method
and then throws an exception is just silly. Any bozo can just look at it
and say it's not going to work. A computer can look at much more complex
things and say it's not going to work.
Ok, here is your much more complex thing, but not too complex, but I cannot tell if it is going to work until I run it:
srand Time.now.to_i
Thread.start do
sleep rand(1)
ObjectSpace.each_object(Object) do |o|
def o.not_a_method() end
end
end
a = Object.new
a.not_a_method # not_a_method may or may not be defined here
No "compile time" type inferencer can tell you if that is going to work or not. A run-time type inferencer needs to do lots of things to tell you if that is going to work, and even still, it may not know that a.not_a_method is going to work until just before you try to call a.not_a_method.
This is why you feel your ideas are being attacked so much. You cannot be certain that a.not_a_method will work until, at best, just before you are about to call it and nobody can take your execution timeslice.
The type inferencer must do a lot of work just before you try something to tell you if it failed or not. I can get an identical message by just trying it, and for everybody that is shooting you down, that's exactly what they are comfortable with.
We like duck typing, and we're perfectly happy that exceptions are raised when things won't work.
Oh, and one more:
begin
a = Object.new
a.not_a_method # The type inferencer must not give up here!
rescue
class Object; def not_a_method() end; end
retry
end
(Yes, I've used code exactly like this to do rapid prototyping, its incredibly cool.)
PGP.sig (186 Bytes)
···
On 28 Jan 2005, at 01:10, Curt Sampson wrote:
On Fri, 28 Jan 2005, Eric Hodel wrote:
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
afaict main problem with this thread