From: Lothar Scholz Date: 2005-05-31T21:49:59+09:00 Subject: Re: Intellisense and the psychology of typing Hello Austin, >> reading the code (perhaps in the form of facilitating IDE >> annotations), and helping the compiler. Some RubyDocs seem to have >> type declairations, e.g. RMagick, does anyone know off hand how >> these come about? AZ> These are probably noted by hand. Yes and a standart how these are annotated by hand is missing, so no tool can get help from it. By the way FXRuby also has type hints, but also with its own notation. AZ> No, thank you. This is Not Ruby. This is precisely why I don't AZ> *want* type declarations in Ruby; it's ugly and stupid. AZ> Type *hints* are something else, but should be applied indepenently AZ> of the method declaration. In lisp you can put a (the 'Integer 'method-argument-one) whereever you want. Also in Python you give type hints with statements independent of the method declaration. AZ> No, that's why I document what the method is supposed to do, and AZ> what the user is to expect. The rest of the paragraph is nonsense AZ> once you get to the point where you understand that this is the AZ> responsibility of documentation, not excessively strict type AZ> notations. If I have type notations, then I run into the problem AZ> that I have restricted users of my class and methods. If someone AZ> else makes something that acts just the way that I want it to, why AZ> shouldn't they be able to use my methods just because I was arrogant AZ> (stupid?) enough to restrict the method in the first place. Because you want to keep a garantee about what works with with what types. Sorry but i don't see restriction as a bad thing. AZ> And who needs that explicit interface? I sure as hell don't need to AZ> say: AZ> class Foo implements EnumerableInterface AZ> ... AZ> end AZ> Sorry, but that's not Ruby. Yes thats not ruby 1.X, not sure if it shouldn't be ruby 2.0 If benefits outweight the problems we should try this. But i also would like to support another syntax and something optional like the protocol notation from SmallTalk. Then we use tools to verify that the implements relationships are right. >> On to my second point: a little type information helps the >> compiler. When skimming articles about optimising compilers for >> smalltalk I keep seeing comments like: such and such an optimiser >> couldn't infer that the inner loop operates over floats, so it ran >> 10 times slower than the equivalent C program. AZ> When were these articles written? Frankly, modern compiler AZ> technology -- and type inferencing -- will help far more than type AZ> specification. Type Inferencing is still almost impossible for far to many situations and this will not change because it is fundamental problem. >> There are times when you want to restrict the types to make the >> program run faster, e.g. programming an FFT, but who wants to >> leave the nice Ruby landscape and muck about in the C/C++ or Java >> dirt? AZ> Those who want to make the program run faster. I've never seen any ruby program where i didn't wished that it would run faster. -- Best regards, emailto: scholz at scriptolutions dot com Lothar Scholz http://www.ruby-ide.com CTO Scriptolutions Ruby, PHP, Python IDE 's