From: Albert Wagner Date: 2002-09-13T09:17:21+09:00 Subject: Re: not grasping the method overloading/multi-dispatch thing On Thursday 12 September 2002 06:36 pm, Tom Sawyer wrote: > On Thu, 2002-09-12 at 17:09, Albert Wagner wrote: > > That is true. Yet, there is an implied contract where arg1 and arg2 must > > respond to #to_s. As a mind game, assuming that argument typing were > > really desirable, and forgetting for a moment the objections, what would > > be a cool way to specify the _behaviour_ expected from argument objects? > > (Not using initializing code like #responds_to, etc.) Smalltalkers > > tended to adopt the convention of prefixing a class name with a- or an- > > (aString, anInteger); but Smalltalk was single inheritance, without > > mixins. > > that's an interesting question. so rather then meth(Integer i) meaning i > is kind_of Integer, rather it should mean responds_to all the same > methods as Integer? > > but how do you take only a intersection of it? perhaps not perfect but > set theory might be useful, though perhap a bit odd. (borrowing from > array): > > def meth(Integer & Array i) > > meaning i is something that responds to the methods common to Integer > and Array. odd isn't it? of course other set operators could be used. > and you could define "TypeMaps", essentially empoty classes with dummy > methods just for this purpose. > > my only problem with the whole type vs. calss argument, is what if two > objects have two differnt method with the same name that return > completly different types or classes of object? so return values need to > be taken into consideration too. in fact that's really wahts important > --not that the methods have the same name, but that they produce the > same type or class (which? both?) of thing. > > this is getting messy. LOL. Yep. The info needed is implicit in the method. The "TypeMaps" could be built by parsing the method to see what methods were invoked on the args. I wonder if something like this is the "implicit typing" I read that some compilers do.