[ruby-talk:14911] Re: Polymorphic methods

Dave Thomas <[e-mail]> wrote:
>"Benjamin J. Tilly" <[e-mail]> 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