From: Thien Vuong Date: 2003-11-17T10:23:35+09:00 Subject: Re: Strong Typing (Re: Managing metadata about attribute types) Nathan Weston wrote: > Ryan Pavlik wrote in message news:<20031107184353.002a2059.rpav@mephle.com>... > >>The problem is people seem to think that "implements String behavior" >>and "is a String" are two different things. I'm not sure why. > > > I think in the ruby world, when people say "implements String > behavior", they really mean "implements some relevant subset of String > behavior". I'm not sure that attributing people in the ruby world really means something when they say something else is quite representative of "people in the ruby world" :). > This is where duck typing (which really isn't a type system at all, > IMO) becomes more flexible than type systems based on the class of an > object. > If I wanted a relevant subset of String, would that be better (i.e. safer/faster) represented by a class/module representing that subset or just one or a combination of respond_to?. I would argue most of the time, that it is the former. > Whether this flexibility is a good thing is up for debate. Any type > system will catch some errors, and throw away some otherwise valid > programs. It's a question of freedom vs. safety, and the ruby > community mostly seems to come down on the side of freedom (at least > where programming languages are concerned). I don't think it is a flexibility issue only. As ruby is a dynamic language, class/modules could be as easily created/extended/included to remap the class/module hiearchy to the desired set. It looks more like the issue is convenience of being able to say: - I'm very sure that the this object behaviour/or my need could be encapsulated fully in this method - so there is no good reason to create extra code to do needless things. This is valid and works much of the time, but does not scale into the argument that class/module checkin is an inferior/crutchy way to design. Once the needed object behaviour becomes more complex, class/module interface is needed to describe that behaviour (of course, respond_to combination/manipulation could do it too, but we would be trying to reinvent the wheel against a proven/established system already). I was drawn to ruby because of the OO capability + extra dynamicity which added to the OO capablity - and it would be a shame to just embrace the dynamics only and drop the OO.