On Thu, 4 Oct 2001, HarryO wrote:

> In article <Pine.LNX.4.40.0110031734520.27796-100000 / zaphod.atdesk.com>,
> "Paul Brannan" <pbrannan / atdesk.com> wrote:
>
> > How about the following?  The only major disadvantage is that it will be
> > a little bit slower than using a real Proc:
>
> As I've already said to Paul in a separate reply, I like this approach,
> since it's a nice class in itself, and it makes for a neat, orthogonal
> way of handling the issue I had.
>
> I hacked his code slightly, to make it not inherit from DelegateClass, but
> simple implement a call() method itself.  I haven't heard back from Paul
> yet as to whether there's a particular reason he went in that direction,
> so if anyone else can explain what I'd be missing by having a call()
> method directly in DumpableProc I'd appreciate it.

The reason I went with the DelegateClass was that it is safer; if a new
method is added to Proc, then (assuming the DumpableProc class is created
after the new method is added) the new method will also be available to
the DumpableProc.  The method_missing hack would also work (and as
discussed before, works with methods added at run-time), but is not as
concise.

Another other good reason for using the DelegateClass is that it works
when you pass the function a block.  It is a bit slower as a result, but
the speed difference is not significant for most applications.

Deriving from Proc does not work, since the constructor is expecting a
block.

I particularly like matju's method, since it allows one to make a proc
dumpable with only a few changes.  It is less safe, since it modifies Proc
and Kernel, and that also means a small speed hit, even when you don't
want to make your proc dumpable.  But just being able to add a % to make
the proc dumpable is an interesting ability.

Paul