Jim Weirich wrote:

> If I understand correctly, it sounds very much like a static lanugage 
> concept, with little applicability to Ruby.  The problem with 
> implementing it is Ruby is not to open up variables to more than one 
> type (that happens automatically), but to artificially restrict the 
> variable to the explicitly listed types.
> 

Can't a little restriction be healthy? In the lecture last week I could 
have, instead of using abstract classes in Java, used Ruby's dynamic 
typing to show that the property could already be set to be of any type. 
But is that freedom a weakness?

If this restriction was used in a large software system, and another 
developer mis-used a list type I had defined, or some other library, 
then the TypeException would be raised. Without the restriction, the 
other developer would be able to set 'next' to be a Fixnum, for example. 
Then, when I call next on the Fixnum I'd get its successor, and not a 
ListItem. I would need to call kind_of? to check that next is returning 
a ListItem and not something else.

If you wanted to be confident that the software was implemented as it is 
specified, would this (variant typing) not be preferable to calling 
kind_of? many times?

>> When he stated that no languages we are taught have this functionality,
> 
> Perhaps the key phrase is "we are taught", because as described, 
> variants sound much like a union in C.  If I recall correctly, even 
> Pascal has variant records that did much the same thing.  Of course, I 
> may be misunderstanding yor description.
> 

We are, unfortunately or necessarily, only taught a few languages. I 
don't agree with the choices, but it's not a problem as I teach myself 
what I can.

I currently do ~90% of my programming in Ruby. I'm currently studying 
(outwith my course) Ruby, Common Lisp and Haskell.

What I don't have is an answer to the question, "How does the freedom of 
Ruby's typing system affect large-scale software development?". I enjoy 
programming in Ruby and have involved it in my final year project and 
every-day tasks. The freedom does make me a little nervous though, as 
unless I have misunderstood the ethos behind it, it seems to imply that 
those who use it must be proficient.

Given the ease with which Ruby can be picked up, there are sure to be 
many people in the near future who put Ruby on their CV who have at best 
a simplistic understanding of its workings/use.

I do not consider this to be a fault of Ruby; far from it. I do however 
forsee in my own future a discussion with a future manager where I 
suggest Ruby and will be required to exemplify Ruby's suitability for a 
large project.

Without restrictions, and without the notion of contracts, what 
foundations could my answer be based on?

Stefan.


-- 
Posted via http://www.ruby-forum.com/.