Simon,
As Sean O’Dell has said, the point is to communicate intentions, not to
absolutely forbid people from doing things.
yes, i understood that the first time. (sorry, i just spent a couple of hours reading through hugely verbose posts that tended toward repetition)
So I see it as acceptable for someone to write a class that “promises”
to behave like a bird, but doesn’t really (or extends an existing
class). The author has made the decision. But they were immediately
aware that the called method expected a bird, and presumably very
carefully investigated the implications of breaking the expected
behaviour.
you see the the problem you have with such an appraoch is perceisly that there is no quality assurance, which defeats the purpose. the real acid is in the testing. so, at best, your talking good docs here, becuase this won’t buy you anything except more keystrokes.
In Ruby you certainly should be able to bypass anything if you wish -
it’s the language philosophy and wouldn’t be Ruby without it.
agreed
Maybe we should be using the term “type hinting” rather than “type
checking”? That’s certainly what I’m talking about, and pretty sure it
is what Sean O’Dell is talking about too. Hints to the programmer
reading the code, hints to code doing “reflection” type operations,
hints available to the runtime environment when generating error
messages. But nothing compulsory, nothing “forcibly checked” - well,
unless the user wants it checked.
again, docs. why have “hints” hard coded? next thing you know we’ll have to have DRM in our code. 
beyond that youre taking .kind_of?, or better, respond_to? validation code checks, which is fine as far as it goes (see euphoria below). but what ruby really needs is a real dynamic type system which requires real code reflection, as suggested by #duck_signature.
eg (wild speculation here)
ruby foo.rb
==> just as now, no typechecking of any sort. No performance hit.
On error, the metadata about method parameters may be used to
provide improved error messages. There will be minor memory usage
increase due to the metadata stored - should be very small though.ruby --type-warn foo.rb
==> generates warnings on possible violations, typically used during
debugging or uat phases. A performance hit of 10% or so expected and
acceptable in this situationand maybe…
ruby --type-check foo.rb
==> strict type-checking, with errors reported on typecheck failures.
Available to those who want it, and are willing to wear the
performance hit. Some libraries may not work in this mode.
essentially you have proposed the euphoria type system, which i think is a good system and dosen’t require a whole new Edifice of Implication.
T. Onoma, do you actually have a concrete proposal related to type info?
The duck_signature method you mention is a syntax for consulting type
info, assuming it has somehow been gathered. I haven’t seen an email by
you that suggests how that type info might have been acquired in the
first place, or how it is stored…
the first part of how it is aquired was actually a code challenge i put out to fellow rubists, but either no one saw it or…or they just think i never have anything good to say. i don’t know. not only was i trying to show what such a type system might consist of, but also demonstrate some limitation of ruby itself, that might be of interest in ruby2: b/c duck_signature CAN’T be done in pure ruby (at least not without a “reparse the_file_i_am.rb” hack) although i would love to see someone prove me wrong!
subsequently, the signiture is just arrays of arrays. once aquired it would be possbile to campare the requirements of a caller to the interface that the callee provides. some rough psuedo:
class TheUnknown
def init(x, y)
puts x.to_i
puts y + x
end
def whip(a)
puts a.whip
end
end
class MySomething
def to_i; 4; end
def whip; puts ‘whipped!’; end
end
r = TheUknown.new
e = MySomething.new
r.duck_doable?(e) # => {:init=>[true, false], :whip=>[true]}
the implemenation of such a scheme would be via assessing intersection of duck_signature arrays. and of course there are plenty of other mechinisim that can be designed around the idea. even the Promises notion, but with real promises, not hints. mind you there never is such a thing as a perfect solution. what if .to_i returned a string? somewhere along the line its up to the low-level designers to implement correct/standard semantic execution, but the high-level coder should be able to tap into the “bottom rung” as a LCD for type correlation.
perhaps we can head this thing off at the pass, if you provide your prefered psudeo code for “Promises”, i’ll work on how duck_signature can be used to provide a corollary to it.
and thank you, thank you, thank you! for actually giving me a moment of your time.
-t0