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 situation
> 
>   and 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