[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

ruby static typing

vikkous

4/28/2005 9:36:00 PM

Some time ago, I wrote up some ideas I had for a comprehensive static
typing system for ruby. I never quite finished it all, but I'd appreciate
it if people can look it over as it is. I'd like to clean it up and put it
in an RCR (or three).

Looking back now, I see that everything is in there (tho the section on
polyparametric polymorphism could be expanded), except generic types (aka
templates) and the type conversion framework. I'll followup to this thread
with a short write-up on those when I can.

Anyway, here it is. It's kind of long, so I didn't post it to the
newsgroup, but just left it on wiki:

http://www.rubygarden.org/ruby?Flexibl...
13 Answers

Charles Mills

4/28/2005 9:51:00 PM

0


caleb clausen wrote:
> Some time ago, I wrote up some ideas I had for a comprehensive static
> typing system for ruby. I never quite finished it all, but I'd
appreciate
> it if people can look it over as it is. I'd like to clean it up and
put it
> in an RCR (or three).
>
> Looking back now, I see that everything is in there (tho the section
on
> polyparametric polymorphism could be expanded), except generic types
(aka
> templates) and the type conversion framework. I'll followup to this
thread
> with a short write-up on those when I can.
>
> Anyway, here it is. It's kind of long, so I didn't post it to the
> newsgroup, but just left it on wiki:
>
> http://www.rubygarden.org/ruby?Flexibl...

Static typing is proposed very often on the mailing list and usually
doesn't get very far (for good reason IMHO).

Ruby does allow you to write statically typed code as is - via a C
extension.

-Charlie

dblack

4/28/2005 10:06:00 PM

0

Lyndon Samson

4/29/2005 8:12:00 AM

0

On 4/29/05, David A. Black <dblack@wobblini.net> wrote:
>
> The link also has other comments, as well as links to other
> discussions (though there have been many more here on ruby-talk since
> then).
>

It would be nice to have a statically typed Interface of some sort
though, just to have something publishable, enforceable and easy for
tools to analyse.



--
Into RFID? www.rfidnewsupdate.com Simple, fast, news.

dblack

4/29/2005 10:09:00 AM

0

Lyndon Samson

4/29/2005 10:46:00 AM

0

On 4/29/05, David A. Black <dblack@wobblini.net> wrote:
>
>
Thanks for the dense ( in a good way :-) ) response.

I guess my point is there is alot of mistrust in the 'corporate' world
as to whether dynamic/scripty languages are suitable for million+ LOC
projects.

Type safety seems to be a big selling point at that scale, so being
able to 'componentise' chunks of ruby by limiting coupling to using
rigid interfaces might assuage some of that concern. Of course after
the code executes post interface all bets are off with mutable
classes/objects, allthough Object.freeze probably needs a bit of
publicity here.

thanks for your response!

cheers
lyndon



--
Into RFID? www.rfidnewsupdate.com Simple, fast, news.

Florian Groß

4/29/2005 12:22:00 PM

0

Lyndon Samson wrote:

> I guess my point is there is alot of mistrust in the 'corporate' world
> as to whether dynamic/scripty languages are suitable for million+ LOC
> projects.
>
> Type safety seems to be a big selling point at that scale, so being
> able to 'componentise' chunks of ruby by limiting coupling to using
> rigid interfaces might assuage some of that concern. Of course after
> the code executes post interface all bets are off with mutable
> classes/objects, allthough Object.freeze probably needs a bit of
> publicity here.

It has been suggested before that the right way of doing interface
contracts in dynamic languages is to formalize them with unit tests --
that seems to work out quite well (RubyOnRails uses unit tests for
assuring that new database adapters basically work).

There is however still cases where unit tests can not replace
traditional typing -- as a simple example you might have a method that
behaves slightly different depending on whether its argument is
enumerable or not. There is more cases where handling types at run time
would be nice -- type adaption comes to mind: For example you might
write a method that expects something that understands a hash-like
interface (keys, fetch, store, delete) and let your users supply Arrays
and so on as well.

Of course you might argue that those cases don't appear to frequently in
Ruby code and that seems to be true, but it still might be useful to
have idiomatic solutions for them.

So, because of the fairly common requests for static typing in Ruby, the
explorations of the Python community and just generic interest I decided
to code some of this up. You can find the resulting (still quite
experimental) library at http://ruby-contract.ruby...

This library indeed combines unit testing with type checking and while
it lets you use instance-of checks (it is generally compatible with all
checks that can be used in case .. when statements) their use is
discouraged in favor of actual implementation testing. (Which is like
duck-typing, except that it does not only check names, but also behavior.)

Perhaps this will do what you want, but even if it doesn't: Ruby has not
had static typing so far and because of that it is a more productive
language IMHO. I'm not encouraging carelessly written code, but Ruby
just happens to have other preferred ways of ensuring code quality.

Robert Klemme

4/29/2005 2:58:00 PM

0


"caleb clausen" <google@inforadical.net> schrieb im Newsbeitrag
news:pan.2005.04.28.20.28.58.609849@inforadical.net...
> Some time ago, I wrote up some ideas I had for a comprehensive static
> typing system for ruby. I never quite finished it all, but I'd
appreciate
> it if people can look it over as it is. I'd like to clean it up and put
it
> in an RCR (or three).
>
> Looking back now, I see that everything is in there (tho the section on
> polyparametric polymorphism could be expanded), except generic types
(aka
> templates) and the type conversion framework. I'll followup to this
thread
> with a short write-up on those when I can.
>
> Anyway, here it is. It's kind of long, so I didn't post it to the
> newsgroup, but just left it on wiki:
>
> http://www.rubygarden.org/ruby?Flexibl...

Folks, please once and for all drop the idea of static typing in Ruby.
Thank you!

Cheers

robert

Ryan Leavengood

4/29/2005 4:57:00 PM

0

Robert Klemme wrote:
>
> Folks, please once and for all drop the idea of static typing in Ruby.
> Thank you!

I agree. Let me segway into a story related to this that I hope you will
find interesting:

During college I took an Artificial Intelligence (AI) class. In this class
the language we used for solving AI problems was Lisp. This was my first
exposure to Lisp, having previously only used Java or C in my other
classes. Other students in the class were similar.

Once I learned we would be using Lisp I took it upon myself to learn more
about the language and it's idioms, etc. This is just a habit of mine that
has proved very useful over the years as I've tried new languages.

Our main project for the class was an AI to solve a fairly simple game. I
was able to complete this project fairly easily and had fun. I used Lisp
idioms (tail recursion, simple functions, etc.) and in the end I had a
well-written, fairly small program that solved the problem well. Others
who also learned the Lisp idioms faired similarly. But there were several
students in the class who, for whatever reason (laziness,
close-mindedness, naivete) decided to write their Lisp AI program using a
style reminiscent of Java (essentially procedural, even though Lisp is a
functional language.) In one example the resulting program was probably 3
times as large as mine, ugly, hard to read, and to make matters worse, it
didn't even solve the game correctly! Now maybe this was just a bad
student, but I think the biggest problem was his inability to learn and
use Lisp idioms.

The moral? When developing in a certain programming language, the most
efficiency and ease of use can be had when following the languages design
and idioms. Ruby is dynamically typed, and trying to force it to a static
typing paradigm is going against the language and its idioms.

When coding Java, use the Java Way.
When coding C++, use the C++ Way.
When coding Ruby, use the Ruby Way.

Simple as that :)

Regards,
Ryan

Lyndon Samson

4/29/2005 5:10:00 PM

0

On 4/30/05, Ryan Leavengood <mrcode@netrox.net> wrote:
>
> The moral? When developing in a certain programming language, the most
> efficiency and ease of use can be had when following the languages design
> and idioms. Ruby is dynamically typed, and trying to force it to a static
> typing paradigm is going against the language and its idioms.

Well to be fair, I never asked for the entire language to change its
type model, just for some form of interface that could 'seal off'
large sections of functionality/code, like components.

Although they were GUI specific, Remember VBX/OCX, how sweet it was
that you could drop in 3rd party functionality into a MS IDE and the
IDE would immediatly know what the interface to be presented to the
programmer was.

Imagine trying to do the same in Ruby or another softly typed
language, A whole lot of framework code would need to be written and
maintained ( human written unit tests vs compiler enforced type
checking ).

In 'programming in the large' Loose coupling is pretty much enforced
if all you have is an interface, there is no option to 'poke around'
in object internals.

I'm not being instistent, just contemplative :-)







>
> When coding Java, use the Java Way.
> When coding C++, use the C++ Way.
> When coding Ruby, use the Ruby Way.
>
> Simple as that :)
>
> Regards,
> Ryan
>
>


--
Into RFID? www.rfidnewsupdate.com Simple, fast, news.

Ryan Leavengood

4/29/2005 6:49:00 PM

0

Lyndon Samson wrote:
>
> Although they were GUI specific, Remember VBX/OCX, how sweet it was
> that you could drop in 3rd party functionality into a MS IDE and the
> IDE would immediatly know what the interface to be presented to the
> programmer was.
>
> Imagine trying to do the same in Ruby or another softly typed
> language, A whole lot of framework code would need to be written and
> maintained ( human written unit tests vs compiler enforced type
> checking ).

This is probably a naive implementation of what you described above (and
maybe I've misinterpreted you), but it still isn't all that complicated:

class Class
def exposed_methods
@exposed_methods ||= []
end

def attr_exposed(*method_symbols)
(@exposed_methods ||= []).concat method_symbols
end
end

class MyComponent
attr_exposed :do_this, :do_that

def do_this
"do this!"
end

def do_that
"do that!"
end
end

class ComponentUser
def ComponentUser::show_component_methods(component_class)
puts "Exposed methods for #{component_class.name}:"
obj = component_class.new
component_class.exposed_methods.each do |m|
arity = obj.method(m).arity
puts "- #{m}(#{arity >= 0 ? arity : 'variable number of'} arguments)"
end
end
end

class String
attr_exposed :[], :slice, :each_byte
end

if $0 == __FILE__
ComponentUser.show_component_methods(MyComponent)
ComponentUser.show_component_methods(String)
ComponentUser.show_component_methods(Array)
end

This way you can limit clients to what methods they can use based on the
exposed_methods. Of course the clients need to play along nicely, which
Ruby can't necessarily force them to do. But this begs the question,
isn't Class#instance_methods(false) essentially the same as this
exposed_methods in most cases?

Of course after writing this I realized you still don't know what the
arguments mean. But that is what ri is for. Plus even with Java or other
component frameworks you still need some information external to the
component to learn how to use it, even if you know what the static types
of the arguments are.

The results from the above exposed_methods call could be linked with ri in
a component system to ease this. Hmmm, not a bad idea...

Ryan