From: "Benjamin J. Tilly" Date: 2001-05-09T21:46:29+09:00 Subject: [ruby-talk:14911] Re: Polymorphic methods Dave Thomas wrote: >"Benjamin J. Tilly" writes: > >> In the paragraph before the snippet you show, I said explicit >> or implicit. Hiding the test in a method lookup is what I meant >> by implicit. But the lookup is still there. It needs to be >> performed by the interpreter, understood by the programmer. >> >> It does not come totally free. > >Absolutely. There is always going to be some kind of dispatch >overhead with runtime polymorphism. I'm also nervous with the idea of >spreading the knowledge of my class into a whole lot of other classes, >which the double dispatch requires. Your example of Matju's stuff not >working as a dropin is a good one. I'm worried too about the >engineering aspects of everyone and their dog dropping methods into >base classes. In this case I think that it is worse to roll your own case statement for different types and miss a new class created by inheritance. Eventually I would like to see Matju's mixin part of the core and it documented that anything added to base classes should be added there. In fact the possibility of doing that at some point, and being able to have one place to catch any alternate implementation of a basic data-type is a good reason for having it! But overall, well there is no question that having the option open makes the language more customizable. This is something I have been thinking about recently, thoughts largely started by reading http://www.paulgraham.com/avg.html, then with a healthy dose of http://www.dreamsongs.com/WorseIsBetter.html. I am now flirting with some unorthodox opinions. For a start I think that (all else being equal) a more customizable language is more powerful. However a customizable language will become a *customized* language, and this leads to problems transferring knowledge from company to company or in creating reusable libraries. Thus customizability is better in the small, but carries the seeds of worse in the large. I suspect it is not an accident that Perl is a fairly powerful but not very customizable language, and it is the one where CPAN developed. But that said the question arises of how you trade off a good repository against a better language. My initial thoughts are that generally available repositories of reusable code matter less depending on how specialized your work is, how much code you intend to build on top of the component, and how good you are as a programmer. Here is why: o If you are doing specialized work, you are less likely to find what you are looking for in a repository. o As you amortize the costs of developing the initial component over more software, the initial savings will matter less than overall productivity. o All repositories are of mixed quality. Hopefully code that makes it to a repository is of better than average quality. Thus most programmers will find that software from the repository is better than what they would be able to write given the chance. But if you are a good enough programmer, this reverses. You probaby could write better software. The question is whether it is worth doing so. Anyways I know this is likely to be controversial, but it is a topic on my mind right now that is relevant to the question at hand (is it a good thing to modify the base classes of the language). Plus I wouldn't mind feedback on some of the tangents my thoughts have taken. >So I'm not sure which method I'd personally recommend: I guess I'm >still experimenting. The fact that you are is why you had so much interesting stuff to say in your books. I know people who have programmed for decades who have little to say of interest. But if you spend it learning, well you may only have provisional opinions but they are likely to be _useful_ ones! Cheers, Ben