On 2/14/07, Hans Fugal <[EMAIL PROTECTED]> wrote:
I disagree that duck typing (which is a feature of ruby also) is a problem. I find it much more useful than not. I do agree however that it is important to document what is accepted and expected for your methods.
Doesn't this defacto need to document your parameters bring back much of the verbosity of a statically typed language? I'm not trying to be inflammatory, it's a sincere question I've had for a long time. I've avoided using dynamic languages partly for this reason. Granted that the interpreter doesn't *require* you to specify the type or order of parameters, it makes sense that this is a good idea (especially when working on a larger project, or building a lib that will be used by others). But if this information is valuable, wouldn't it be better if the language forced you to specify the type and order of parameters? Wouldn't it be better to remove the guess work about how a method, class, and library are used because the contract for how you call them is embedded in the language?
Incidentally, Ruby has similar (perhaps worse) limitations in threading. These are on the table for repair with the virtual machine work being done. The story is long, but basically you can do threads but they're not real threads, and I say that in the pragmatic sense not the academic sense.
Is this a limitation for Rails? Does Rails run as a single process with green threads or messaging, or pooled out in separate processes like mod_perl or CGI? Thanks, -Bryan /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
