From: Sean O'Dell Date: 2003-11-20T06:02:05+09:00 Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) On Wednesday 19 November 2003 12:29 pm, Austin Ziegler wrote: > On Thu, 20 Nov 2003 04:45:56 +0900, Sean O'Dell wrote: > > No, type checking based on class inheritance (and mix-ins) is > > completely fine. Just think of the checking not as "type > > enforcement" but as "interface declaration." > > Class != type. Type checking on inheritance is, IMO, explicitly a > bad thing in Ruby. I've already said I don't want type checking. I've used that term incorrectly. All I want is a declaration that an object implements a certain interface. > > A class is a declaration which says "I do this." > > No. A class is a declaration which says "I *am* this." There is a > difference, and it's this difference that I think people aren't > getting. As I noted earlier, a StringIO does not inherit (at all!) > from either String or IO, but it conforms to the expectations of > both. Name-based type checking would unnecessarily restrict your > capabilities. Okay, again, terminology. When I say an object declares "I do this" I am not speaking about the function of one or more methods. I am talking about the entire purpose of the class, which I equate to "I am this." > >> It's good to have the mechanism like that, I agree, even I put > >> the feature in my latest slides. But there's still long way to > >> design and implement it efficiently, if I am right. > > Matz: note that Python went through this discussion five years ago > and it still doesn't have it. I'm not sure Ruby *really* needs it, > either. The only thing that I think Ruby could use is a standardized > way of publishing method signature information for the cases I've > outlined. A good system of method signatures serves the same purpose in my mind, if they're convenient enough to call that we can expect people to actually use them where they're needed, and not avoid them because they're a pain to use. Either way, the called method can ask "does this object do what I want?" which is all I am after. > > If a programmer goes out of his way to change the object > > radically, fine, it will break just like it breaks now. No harm > > done. > > Bollocks. You've been given several examples as to how it would > break things, especially Ruby's dynamism. Huh? I know how it breaks things. Right now, an error occurs deep in someone else's code. Sooner or later, that's simply going to happen. > > The alternative would be to enforce that all expected methods and > > parameters are present in a precise form, and that would be > > insanely strict. > > No, the alternative is to document and assume that the programmer's > not an idiot. You *don't* have to typecheck; just use the methods > expected. True, that's what we have now. I guess doing nothing is an option. > > Some people will need it occassionally, probably library > > developers mostly. > > As someone who has *primarily* developed libraries, I can tell you > that I haven't needed it. I suspect most of the users of my > libraries wouldn't want it, either. As someone who has developed libraries in Lisp, C, C++, Java, Ruby, Perl, Visual Basic, Delphi, Pascal, bash shell, as well as developing O'Basic, a complete script language itself, I can tell you that I have always tried to make life easier for the developers who have had to use my libraries. If you don't want to provide type checking to your users, then you are not putting yourself in their shoes when something goes wrong because they passed in the wrong object. You are intimately knowledgable about your code whereas they are not. It's entirely frustrating to get errors messages fly out from deep in someone else's code, and not a single word about what type of object is expected. If you document your library, that's fantastic, but documentation does not always evolve in perfect sync with the code, and many libraries are either devoid of documentation or are poorly documented thusly. Sean O'Dell