From: Tim Hunter <cyclists@...>
Date: 2003-02-28T09:42:17+09:00
Subject: Re: [ANN] RMagick 1.0.0 now available

Thanks for the suggestion.

I thought about trying to automatically generate some or all of the "bang"
methods from the non-bang methods but ultimately gave it up as a bad job.
It may be that I'm just not smart enough, though :-)

My reasoning, such as it is, is that in general images are big, so it
benefits you to minimize the number of duplicates. Some ImageMagick
methods modify the input image. Some return a modified copy of the input
image. It seems to me that there's some benefit in tailoring each bang
method such that it takes advantage, if it can, of IM's implementation.
That is, if IM's method modifies the input image, then the Ruby bang
version should call it directly instead of making a copy, modifying the
copy, and discarding the original. This tells me that I should write each
bang method individually, after examining the underlying ImageMagick
implementation.

I also have a mild aethestic aversion to cluttering up the API with a lot
of methods that would rarely if ever be used.

And, as a last resort, if you're writing an application and could use a
bang version of a particular RMagick method, you can always add it to the
Image class yourself using the code you show here.


On Thu, 27 Feb 2003 23:33:13 +0900, Brian Candler wrote:

> On Thu, Feb 27, 2003 at 11:19:46PM +0900, Tim Hunter wrote:
>> In the end which bang methods get added is mostly going to be decided
>> by user input. Which ones do you think would be useful?
> 
> Could you catch them using method_missing? Or if you wrote them all as
> bang methods, you could wrap the non-bang methods as:
> 
>   def foo
>     dup.foo!
>   end
> 
> (Array#sort is implemented like this, using Array#sort!). But maybe
> 'dup' isn't good enough in this case, as it's not a deep copy. Just a
> thought anyway.
> 
> Regards,
> 
> Brian.