On 4/6/06, Yukihiro Matsumoto <matz / ruby-lang.org> wrote:
> In message "Re: un_include and un_extend"
>     on Thu, 6 Apr 2006 21:28:46 +0900, "Austin Ziegler" <halostatue / gmail.com> writes:
> |I'd love to change your mind about that. One reason is
> |Transaction::Simple. My preferred use of Transaction::Simple will not
> |be including it into a class, but extending an object with it like so:
> |
> |  foo = "mystring"
> |  Transaction::Simple.start(foo) do |t_foo|
> |    t_foo.gsub!(/my/, "your")
> |    t_foo.rewind_transaction
> |    t_foo.gsub!(/string/, "test")
> |  end
> |  t_foo.start_transaction # I want *this* to throw an exception.
> |
> |It would make certain things easier to manage in classes that use
> |Transaction::Simple. I understand that it wouldn't be easy, and it
> |would be almost impossible to automate, so perhaps only allowing it on
> |modules that have an #unextended method?
>
> Hmm, raising NoMethodError for such case sounds like bad manner for
> me, since the real reason of the error is non-existence of the method,
> but being out of transaction, I guess.  PStore does similar thing, but
> it doesn't raise NoMethodError but PStore::Error for the reason.  Am I
> missing something?

Actually, as Austin mentions in a followup email, that last line was a
typo. It would actually be:

  foo.start_transaction

The idea, I'm guessing (I don't know the internals of
Transaction::Simple) is that Transaction::Simple.start(foo) extends
foo with a module which includes the #start_transaction method, then
calls foo.start_transaction with the block provided. It would be nice
if you could then unextend the module so that foo.start_transaction
once again throws NoMethodError (since it did initially) after leaving
Transaction::Simple::start.

Jacob Fugal