lib for optional static typing

[James Britt]

I probably said it many times, but what if we provided real type checking?

What does the words "real", "type", and "checking" means?

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

 

[gabriele renzi]

James Britt ha scritto:

What does the words "real", "type", and "checking" means?

being not a native english speaker I won't try to explain each single
word, I beg your pardon

But trying to answer the core question (or what I think it is), I mean
that using the full power of the language to write a guard function for
an argument you could assert every possible constraint whatever it's
needed for it, based on ancestry, state of the object, public interface
or whatever.
This basically encompasses everything that can be expressed in ruby, so
I think it matches the idea of a type withouth needing to understand
what a type is.

 

[gabriele renzi]

Austin Ziegler ha scritto:

Hm. No. That would end up requiring a significant change to Ruby,
because sqrt is legal on negative numbers, as long as you have
imaginary (complex) number support available.

yeah, I'm not really suggesting changing Math.sqrt, just an example.

So you would then have
to have overloading instead of simple overriding as Ruby currently
does, because you'd need def Math.sqrt(Positive p) and def
Math.sqrt(Negative p).

Overloading, I have come to believe, is a nightmare compared to
duck-typing. That's one of the reasons I oppose *anything* that
threatens to put it into Ruby, because it's a mess.

I was thinking of multimethods, more than simple overloading C++ style,
but I'm not sure if that belongs to ruby so I won't argue on this.

But would you please explain why do you think multiple dispatch is a bad
thing, it would be interesting to hear the reasons that brought you to
this conclusion.

 

[Austin Ziegler]

Austin Ziegler ha scritto:
yeah, I'm not really suggesting changing Math.sqrt, just an example.

Yeah, but it's a perfect example of what's wrong with trying to put
class restrictions as signatures in Ruby methods.

I was thinking of multimethods, more than simple overloading C++
style, but I'm not sure if that belongs to ruby so I won't argue on
this.

But would you please explain why do you think multiple dispatch is a
bad thing, it would be interesting to hear the reasons that brought
you to this conclusion.

Part of it is the mess that is C/C++; part of it is the mess that is
Java. If I were able to say something like:

class Foo acts as java.util.String
{
=09// ...
}

class Bar
{
=09public String baz(String x) { ... };
}

it might be okay. I'm not necessarily after an inheritance relationship,
but even that's difficult. I am really finding that I prefer writing
code that I want to say "I need this behaviour" not "I need this class."
It's much harder to express that in a multimethod sort of thing, which
is predicated primarily on a preconceived notion that the only way to
get polymorphism is to specify multiple methods that deal with classes.

-austin

 

[Eivind Eklund]

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)

I've got an implementation that works more or less like that available
at http://people.freebsd.org/~eivind/ruby/types/

It also allows more complicated declarations (respond_to checks,
conditional series of parameters, handling of repeats, etc, etc).

If you find ways to use this that turn out to actually be an advantage
in practice, I'd appreciate a mail describing your use. When I tried
to use it with the way I program, I found that it didn't catch errors
any earlier than I'd get them from MethodMissing anyway, and that it
got in the way of my refactoring. That doesn't mean it couldn't be
useful for somebody else, of course.

Eivind.

 

[gabriele renzi]

Austin Ziegler ha scritto:

Yeah, but it's a perfect example of what's wrong with trying to put
class restrictions as signatures in Ruby methods.

I fail to see how redefining a method is better than defining a
specialized version for your own purposes leaving all the rest working
with other implementations, but I am quite dumb usually, so it is ok.

Part of it is the mess that is C/C++; part of it is the mess that is
Java. If I were able to say something like:

class Foo acts as java.util.String
{
// ...
}

class Bar
{
public String baz(String x) { ... };
}

it might be okay.
I'm not necessarily after an inheritance relationship,
but even that's difficult.

I think you could easily do this with a multimethod dispatch defaulting
on #=== in ruby, asserting a pseudo is-a property like
def String.===( Foo f) true end

But now I understand your reasons, thanks for sharing.