From: Jacob Fugal <lukfugl@...>
Date: 2006-03-14T07:38:34+09:00
Subject: Re: abstract method in Ruby

On 3/13/06, Logan Capaldo <logancapaldo@gmail.com> wrote:
> ... What I'm suggesting is
> that although a program should explode immediately when there's a
> problem, it also shouldn't explode when there isn't one. If I never
> call map, each will never be called, so its ok if I don't implement
> it. Then on the day I do call it, and run it for the first time, it
> expldoes right there, when I'm calling each. I know immediately what
> change I _just_ made caused it to explode. OTOH if I mixin Enumerable
> w/o an each, and each is an "abstract_method" it breaks whether I use
> it or not. But when everbody starts using abstract methods, all of a
> sudden I'm back in the land of compile-fix, compile-fix. Cause that
> error is gonna happen right away, so I have to deal with that
> immediate error. Then I can run it again to make sure it works, but
> now the error happens again, compile-fix ad infinitum.

Umm, except, no. Maybe if we used Erik's "allocation-time checking"
approach, but not with kwatch's NotImplementedError approach. If you
mixin Enumerable, but then never call map/inject/collect/etc., you'll
never get the NotImplementedError exception, just as you never got the
NoMethodError exception. As far as *behavior*, timing/severity of the
failure is exactly the same -- you get an exception when the library
tries to use the method you should have defined.

The value of Erik's approach (which, as Pit and Matz pointed out,
needs refining) is in self-documentation and explicit error messages.
Obviously, you and Ara don't agree on how much that self-documentation
is worth. I'm not sure either; you both make good arguments. This is
the reason why I also vote against it being in the core.

However, I *highly* value the more descriptive exception. I'll take an
exception that tells me "If you want to extend Enumerable, you need to
provide an 'each' method" over "NoMethodError: each" any day. Sure, I
have to go back to the documentation and see what that each method
should do, but I know more precisely why things are failing. You may
disagree, and that's fine. I'm just staing my opinion as to why I
think it will be a valuable non-core library.

Jacob Fugal