--Apple-Mail-7--221960717 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 28 Jan 2005, at 01:10, Curt Sampson wrote: > On Fri, 28 Jan 2005, Eric Hodel wrote: > >> 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 te%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 bject > 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 bject.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 bject.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 - drbrain / segment7.net - 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 P.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 BN -----END PGP SIGNATURE----- --Apple-Mail-7--221960717--