before i begin a word of warning:
if you, after reading this post, feel the almost unbearable urge
to answer me; if you feel that my poor soul must be saved
from the evil soothing of static typedness; if you think i must
be enlightened to the wonderful world of dynamic typing…
PLEASE resist it!
make some breathing exercises or take a cold shower.
really i dont want to discuss the merrits of static vs. dymanic typing.
ok here is my question:
is there any lib where i could emulate attributes on methods
like there are some libs already now for python 2.4
that is something that allows for defining the parameters
and the return type and the corresponding checks at runtime.
It sounds like you’re more interested in class/module ancestry than
type.
You can always use is_a? (possibly lightly wrapped, if that makes it
feel
more “official” There are also things like the “StrongTyping”
module,
which (despite its name) is, as I understand it, essentially doing the
kind of ancestry-filtering you’re interested in.
There’s also been some work on type-matching in Ruby, though it’s a
non-trivial problem.
that seems to handle most of my requirements also
i would prefer a more “declarative” approach.
You will, however, find that such a module and approach gets in your
way of writing quality Ruby code.
You may not want to debate the merits of static vs. dynamic typing,
but if you’re wanting static typing, then Ruby may not be what you
really want. Aside from that, you may want to look at writing your own
mechanisms. There are things that I will have to be doing to encode
some “typing” information in a future version of PDF::Writer; examples
of how to do that as appropriate for your domain will be visible at
that point.
that seems to handle most of my requirements also
i would prefer a more “declarative” approach.
You will, however, find that such a module and approach gets in your
way of writing quality Ruby code.
You may not want to debate the merits of static vs. dynamic typing,
but if you’re wanting static typing, then Ruby may not be what you
really want.
Amen! I so agree.
I did my time in the Java trenches and I understand static typing
well. Heck, every time I read another Design Patterns book, it takes
me a week to get back to coding idiomatic Ruby. Nothing else feels
right though.
It really is a mindset change. At least make sure you give it a try,
before you abandon the benefits.
Ruby was meant to be free and she’ll fight you if you try to reign
her in.
the question imo not so much if static typing is useful
or if dynamic typing is useful
BUT when to use static typing.
The real question is where to get a type-system that is flexible
enough to analyze non-runtime dynamic parts of Ruby without spraying
class names all over.
the question imo not so much if static typing is useful
or if dynamic typing is useful
BUT when to use static typing.
The real question is where to get a type-system that is flexible
enough to analyze non-runtime dynamic parts of Ruby without spraying
class names all over.
This is left as an exercise for the reader.
BTW, there is a discussion on the Pragmatic Programmer mailing list
right now about the pros/cons of static typing.
Except the archives are only accessible by members, which probably
read it already anyway.
system without being restricting on the rest of the system.
Common Lisp supports something like that. All values are dynamically
typed by default (as in Ruby), but typing can be added to specific
areas where you need it. The user can decide whether to have the
typing used only as a compiler hint to get faster code, and/or to have
it enforced so that an error will be signaled when an attempt is made
to store an object of the wrong type into that variable.
I’m not familiar with Visual Basic, but is it the case that all
objects will eventually be COM objects? I was under the impression
that they’re pretty separate concepts. Doesn’t seem that pragmatic if
I have to change my regular code to a COM object just to get typing.
system without being restricting on the rest of the system.
the only language i know that did an excellent job on that
was VB (classic) where you could work mostly untyped
(if you wanted and you did not care bout performace).
whenever you wanted to release a COM-object you had
to define the types.
this was a very pragmatic approach.
ciao robertj
Evan Webb mentioned that it would be possible to add a pseudo type
system via Behaviors. He may even have a working implementation for
Sydney, but I’ll have to double check. It would look something like
this:
pseudocode
require “behavior/strongtyping”
def foo(String x, y)
end
In this example, x must be a String, while y can be anything. In
effect, optional typing.
I’m actually not sure if I want this, though. I know I’ve supported it
in the past, but I worry that Java/C/C++ programmers coming to Ruby,
fearing the removal of the static typing training wheels, might adhere
to this style too readily when it should only be used sparingly.
If you pass “-wsa” to the booc.exe compiler, it will use “end”
statements like ruby instead of python-like indenting (although
it still requires the redundant colon at the beginning of a block).
The real question is where to get a type-system that is flexible
enough to analyze non-runtime dynamic parts of Ruby without spraying
class names all over.
that is certainly a point of view that many “typed” guys
would subscribe to.
the problem imo is not to define a “sound” typesystem
(as most static typing systems try to do and fail
regardless of the imense effort that has been put into)
but one that helps to define contracts on the borders of your
system without being restricting on the rest of the system.
the only language i know that did an excellent job on that
was VB (classic) where you could work mostly untyped
(if you wanted and you did not care bout performace).
whenever you wanted to release a COM-object you had
to define the types.
this was a very pragmatic approach.
I believe JScript.net also gives the choice of dynamic/static typing.
(Since it also supports the open ‘class’, prototype run-time
modification, it strikes me as the most palatable of the .net languages)
Common Lisp supports something like that. All values are dynamically
typed by default (as in Ruby), but typing can be added to specific
areas where you need it. The user can decide whether to have the
typing used only as a compiler hint to get faster code, and/or to have
it enforced so that an error will be signaled when an attempt is made
to store an object of the wrong type into that variable.
Well, personally, I really like Common Lisp and its approach. But
concerning compiler hints…what about the Stalin Scheme compiler? I
recently started studying compiler techniques it uses and it almost
convinced me that there is such a thing as the legendary “sufficiently
smart compiler”. I’m just wondering, if there is such a thing for
Scheme, would Ruby also benefit from such a kind of compiler? Such a
dynamic object model that Ruby uses is quite a beast to tame, on the
other hand, the optimizations that Stalin performs are nothing short of
a miracle.
convinced me that there is such a thing as the legendary
“sufficiently smart compiler”. I’m just wondering, if there is
such a thing for Scheme, would Ruby also benefit from such a kind of
compiler? Such a dynamic object model that Ruby uses is quite a beast
to tame, on the other hand, the optimizations that Stalin performs are
nothing short of a miracle.
Oh, but the time it actually needs to compile and the megabytes of C
it generates… not worth in the general case, IMO.
And Stalin code still is far not as run-time dynamic as Ruby. (Which
is the real problem. We should have something like “eval-on-compile”.)
In this example, x must be a String, while y can be anything. In
effect, optional typing.
s/typing/ancestry-checking/
I’m actually not sure if I want this, though. I know I’ve supported it
in the past, but I worry that Java/C/C++ programmers coming to Ruby,
fearing the removal of the static typing training wheels, might adhere
to this style too readily when it should only be used sparingly.
I think there are two main problems with this kind of thing: first,
that it could short-circuit people learning about how type actually
works in Ruby; and second, that it might discourage more Ruby-esque
program design. It looks like it adds something to Ruby, but it
doesn’t (since is_a? is already available), and in practice perhaps
subtracts something.
Oh, but the time it actually needs to compile and the megabytes of C
it generates… not worth in the general case, IMO.
And Stalin code still is far not as run-time dynamic as Ruby. (Which
is the real problem. We should have something like “eval-on-compile”.)
Well, that’s the “static language implementation” part. You cold
treat it as a compiler of a dynamic language into a fast static form,
which is something the docs say anyway:
"It is designed to be used not as a development tool but rather as a
means to generate efficient
executable images either for application delivery or for production
research runs. "
It’s worth in the final case, not in the general one.
There are also things like the “StrongTyping”
You cold