On Wed, May 16, 2001 at 01:30:19AM +0900, Bradford Hull wrote:
> Another Ruby Newbie weighs in.  I've only used Ruby a week, but I was 
> beside myself with glee when I saw that somebody had finally put out a 
> language besides SmallTalk that did NOT enforce type-rigidity.  I have 
> always felt that a major part of the rubbery strength of SmallTalk came 
> exactly from the lack of enforced type checking.
> 
> Sure, it's harder to debug if your brain cramps are not pointed out to 
> you by a parser.  But look how useful Pascal was, with its zealous 
> assumptions about purity and perfection in type enforcement (discarded 
> as useless, because too many cases kept coming up where a little more 
> imagination was needed than Pascal's model would allow).
> 
> I respect the fact that strict type control will allow for much better 
> optimization, but I want badly to be able to explore the non-type-safe 
> world a while and see if there are remarkable insights one can come to 
> in this new territory.  Please, if you do add type-checking and 
> constraints, make sure not to let them prohibit using the language with 
> its current SmallTalkish freedom.
> Let them be positively applied options, not default restrictions I have 
> to fight
> my way past yet again.  A programmer can supply their own type-safety 
> when they want to already.
I totally agree (being a newbie too... ;-) ).

I think, methods should not check for the types of the operands - because
doing so forces the programmer to use inheritancy much more than necessary.

Lets say, a method takes a string, does some things with its characters, and
returns an array with the processed charakters.

Maybe I want to use the algorithm in the method, but need it to work on some
other collection.

If there is no forcing of types, I can just extend my Collection class to
support all the operators and methods the algorithm needs.

If the type is forces to "String" I need to make my Collection a subclass of
"String", which may be totallly pointless, since it has nothing in common
with a string beside the Interface.

This leads to my idea. I think if you should be able to force "something" on
the paramteres, it should be Interfaces, not types.

Interface checking is much more powerfull than type checking in my opinion -
a lot of things which are now modules ("Enumerable", "Compareable",...)
would have corresponding interface definitions.

The function would than just say "my parameter needs to be compareable, and
a collection" instead of "a string".

Of course there would be a  "behaves_like?" method (similar to "is_a?") ;-))

I think a prototype of this could be implemented in ruby by using Modules as
Interfaces, which 
.) define all the methods the interface has
.) if one of the methods is calles, it would need to check weather a "real"
method of this name can be found in the class, some superclass, or a mix-in
.) if not, it could raise InterfaceMethodNotDefined

greetings, Florian Pflug