On 11/03/2004, at 3:10 AM, Elliott Hughes wrote:
I tend to take the view of horses for courses,
high level <----------------------------------------> low level
dynamic typing
static typing
generalisation more important efficiency more
important
"scripting" languages compile
to machine code
Ruby approaches this from the left, where as languages such as C/C++
and java approach this from the right.
I hadn't thought of the idea of directors vs enablers, but that's an
interesting thought on "do you trust your fellow programmers to do the
right thing." Or, is that people confusing NASA style mission critical
with business style mission critical?
To get back to the main thought behind this post. If your trying to
write generalised or high level abstract code then dynamic typing is
good as it helps, me at least, avoid worrying about what type I'm
dealing with and concentrate on the problem. However, when I'm writing
library routines I'd like to be able to do signature checking if not to
increase efficiency at least to avoid type checking. Especially when it
comes to writing modules to interface to libraries in other languages.
For example, I'm writing an interface to flow tools, which I'll post
something on at a later date, in which I quiet often check the incoming
VALUE for its type. This not only means that I'm duplicating a lot of
code but it can make the intention of the code less clear.
It would be useful to have at this level of ruby, if not also at a high
level, a version of rb_define_method that has the ability to do the
signature checking for me. For example,
the current open file method is registered, thus,
rb_define_method(vflow, "open", vf_open, 1)
Now I'm not sure how you'd do the next bit may be something like this,
rb_define_method_sig(vflow, "open", vf_open_str, T_STRING)
then if an a method that took an fixnum was defined,
rb_define_method_sig(vflow, "open", vf_open_fixnum, T_FIXNUM)
Overloading the vflow.open() method from within ruby, but making the
code clearer.
I seem to have headed off on a tangent, so I'll stop at this point
before I get any further off subject.
Jeff.