Adiscussion on C-style method overloading had taken place at the list
already.
Preconditions and postconditions could be checked "manually" when
needed.
I think a language has "critical mass". When reached, the language
becomes another language. Like C and C++.
You see C++ having some disatvantages due to compatibility with C.
# -----Original Message-----
# From: MikkelFJ [mailto:mikkelj-anti-spam / post1.dknet.dk]
# Sent: 12 ¥Î¥¿¥Õ¥à 2001 ¥Ì. 10:11
# To: ruby-talk ML; undisclosed-recipients:
# Subject: [ruby-talk:17689] Re: Old chestnut: invariants,
# pre/post conditions and so on
#
#
#
# > > The reason Eiffel is a bit better off here is that you
# can state the
# > > - class invariant for a class
# > > - preconditions for a method
# > > - postconditions for a method
# ....
# > Indeed, I would have thought it especially _easy_ to add
# such features
# > to well-designed dynamic languages.
#
# I'm not familiar with Eiffel, so I may be off the track
# but... If pre/post conditions can be added to Ruby in a way
# the removes some of the dynamic behaviour, this can be
# extremely valuable for a Ruby compiler. If such checks were
# dynamic, you need not really add anything to the language,
# you would just need insert assertions into the code
# (simplified - there is the subclassing issue).
#
# The JScript.Net compiler uses type inference to identify
# possible value types. It would be obvious to do something
# similar with Ruby. With the addition of invariants, the
# typeinference could be improved. A compiler switch could also
# be used to assume that the invariants are true, after a
# program has been thoroughly tested.
#
# While typeinference would not be the primary argument for
# adding invariants, I think this aspect should be carefully
# considered if such a feature is added.
#
# The nice thing about invariants are, that they are
# 1) more precise than the typical type declaration in a
# "typesafe" language.
# 2) they are optional. That is, the user is not forced to
# declare variables and types.
#
# Mikkel
#