Lib for optional static typing

hi,

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

@params(String, String)
@return(String)
def concat(_key1, _key2):
return _key1 + _key2

that is something that allows for defining the parameters
and the return type and the corresponding checks at runtime.

i thought i have seen something like that for ruby sometime and
somewhere but i can not find it anymore (or maybe i had simply
visions)

thank you

robertj

robertj wrote:

typing.

that is something that allows for defining the parameters
and the return type and the corresponding checks at runtime.

i thought i have seen something like that for ruby sometime and
somewhere but i can not find it anymore (or maybe i had simply
visions)

thank you

robertj

There is a DbC sample implementation that might be able to do what you
want.

robert

robertj wrote:

that is something that allows for defining the parameters
and the return type and the corresponding checks at runtime.

i thought i have seen something like that for ruby sometime and
somewhere but i can not find it anymore (or maybe i had simply
visions)

thank you

robertj

http://raa.ruby-lang.org/project/strongtyping/

Regards,

Dan

Hi –

On Mon, 5 Dec 2005, robertj wrote:

is there any lib where i could emulate attributes on methods
like there are some libs already now for python 2.4

@params(String, String)
@return(String)
def concat(_key1, _key2):
return _key1 + _key2

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” :slight_smile: 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.

David
__
David A. Black
[email protected]

“Ruby for Rails”, forthcoming from Manning Publications, April 2006!>

On 12/5/05, robertj [email protected] wrote:

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.

-austin

ok,

that seems to handle most of my requirements also
i would prefer a more “declarative” approach.

On Dec 6, 2005, at 8:17 PM, Austin Z. wrote:

On 12/5/05, robertj [email protected] wrote:

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. :wink:

James Edward G. II

“robertj” [email protected] writes:

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. :slight_smile:

This is left as an exercise for the reader.

Christian N. wrote:

fact is that sometimes “static” typing is
class names all over. :slight_smile:

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.

http://groups.yahoo.com/group/pragprog/

James

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools

thats the problem.
sometimes “dymamic guys” argue with as much
stubborness as the “static typing guys” do.
only the other way around.

fact is that sometimes “static” typing is
extremly helpful and sometimes it is in your way
as much.

the question imo not so much if static typing is useful
or if dynamic typing is useful
BUT when to use static typing.

ciao robertj

James B. [email protected] writes:

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. :slight_smile:
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. :slight_smile:

On 12/10/05, robertj [email protected] wrote:

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.

robertj wrote:

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.

Regards,

Dan

robertj wrote:

to define the types.
this was a very pragmatic approach.

See also boo http://boo.codehaus.org/ which has both static
and dynamic typing. http://boo.codehaus.org/Duck+Typing
It has some stuff borrowed from ruby like anonymous closures.

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. :slight_smile:

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.

ciao robertj

Doug H wrote:

See also boo http://boo.codehaus.org/ which has both static
and dynamic typing. http://boo.codehaus.org/Duck+Typing
It has some stuff borrowed from ruby like anonymous closures.

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)

James B.

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools

Bill Atkins wrote:

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”. :slight_smile: 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. :wink:

Jakub

Jakub H. [email protected] writes:

convinced me that there is such a thing as the legendary
“sufficiently smart compiler”. :slight_smile: 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. :wink:

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”.)

Hi –

On Sun, 11 Dec 2005, Daniel B. wrote:

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.

David


David A. Black
[email protected]

“Ruby for Rails”, forthcoming from Manning Publications, April 2006!

Christian N. wrote:

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. :smiley: 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. :wink:

Jakub

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs