--Apple-Mail-7--221960717
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
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]
http://www.google.com/search?
q=site%3Ablade.nagaokaut.ac.jp+type+check
[2]
http://people.freebsd.org/~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.)
--
Eric Hodel - (e-mail address removed) -
http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
--Apple-Mail-7--221960717
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFB+nnyMypVHHlsnwQRAkwCAKDOxHQO8sWrx9zXJ2WlJUgr1UUz+wCgtJT9
w8dst3LeEL+xAUAZU+GJwKw=
=mVBN
-----END PGP SIGNATURE-----
--Apple-Mail-7--221960717--
.