On Tue, Oct 01, 2002 at 11:27:59AM +0900, Bryan Murphy wrote: > Gavin Sinclair wrote: > >If you find yourself in a situation where you want these things, but also > >want > >to use Ruby, either: > >- use Ruby as a prototype and then convert to Java if necessary > >- enforce type-compliance to key methods by raising exceptions > > > > > While I understand your point, I do have to disagree and say that Mixins > aren't anything like interfaces coming from my perspective. > > From my perspective, interfaces and/or contracts are a way to > unerringly guarantee than an object *ALWAYS* provides specific > functionality. Mixins are a way to share common functionality amongst > multiple objects via code-reuse, but they don't guarantee that said > functionality will be implemented (methods can be changed after the > fact). A contract says I must do something. If I no longer do > something, I no longer follow that contract and it is therefore no > longer valid. I've never read anything about Ruby Mixins being > immutible like this > Also, another important reason why I think the two concepts don't > serve the same purpose is that interfaces *only* guarantee > functionality. They say nothing about how that functionality is > implemented (are you reading from a database? or from an xml file?). > A mixin is a mixin and it behaves a certain way. You can have two > mixins with the same behavior, they may look and act the same but > they are in fact two distinct things (unless I'm misunderstanding > Mixins). You can use Mixins to implement interface like > funtionality, so your point is certainly valid. But you can't use > Mixins to GUARANTEE that functionality across the board for all > time. That's the missing piece for a lot of us. I don't think that Mixins are equivalent to language checked interfaces either, but I also disagree with some of your conclusions. For one, I don't think that interfaces practically guarantee specific functionality any more than mixin's. The interface guarantees a specific interface -- you shall be able to call method fu with class sna. But you are no more sure that the correct thing will happen when sna.fu is called. Mixins are more useful for indicating that not only will method fu exist in a class and that a functionality is implemented a certain way. True, with ruby's dynamic classes, there's no certainty that the class hasn't been altered, but really is it that any more certain that the backend implementation of an interface has been changed since the last sync with an outside codebase? To me features such as interfaces are very useful for design, but when you get to implementation, they get in the way because you often end up debugging several abstraction layers away from the actual bugs. For programmers which come from stricter environments, I understand it feels odd - it felt odd to me at first too. Giving up discipline enforcing features such as interfaces, and type checking is disorienting and a little scary. I'm getting a little nebulous, but looking back those features are good at preventing "mechanical" errors, but usually break down when programmers try to extend them to enforce human "semantical" relationships. Giving up those features may increase some rates of mechanical errors but in exchange you get focus - the ability to concentrate on the design and implementation of your code "semantics" with very few syntax mechanics obscuring your vision. Ultimately, I think it's this focus on the human factor is what drives my productivity higher with Ruby. -- Alan Chen Digikata LLC http://digikata.com