From: Brian Mitchell <binary42@...>
Date: 2007-09-13T02:35:04+09:00
Subject: Re: before, after and around Ruby 1.9

On 9/11/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> On 9/11/07, Pit Capitain <pit.capitain@gmail.com> wrote:
>
> > The module inclusion chain is already dependent on the sequence in
> > which the code is executed, especially if you use super. What I like
> > about Matz's proposal is that there is still only one of these chains
> > and one way to walk them: super. Having a different way to call the
> > next method would make things more complicated, IMO.
>
> Here's the sequence dependency I'm concerned about.
>
> class A
>   def m
>      puts "Hi from A"
>   end
> end
>
> class B < A
>   def m
>      puts "And now a wird from my superclass.!"
>     super
>   end
>
> class B < A
>   #fix the typo
>   def m
>      puts "And now a word from my superclass!"
>   end
> end
>
> B.new.m
>
> With the current semantics, this will produce:
>
> And now a word from my superclass!
> Hi from A
>
> whereas Matz' proposal would produce:
>
> And now a wird from my superclass!
> And now a word from my superclass!
> Hi from A
>
> How do you REPLACE a method implementation which invokes super in this
> brave new world?

Easy:

  class B
    remove_method :m
    def m ... end
  end

Seems to work well with the idea that the method is being removed
making hard to accidentally cover code up.

The main point to make here is that the property of composability is
still a little weird. This makes loading multiple definitions very
fragile since order could easily matter on which things wrap and which
things don't.

Consider the original syntax from Matz's slides (RubyConf '03):

  class Foo
    def foo:pre(*args)
      p 'pre'
    end
    def foo:post(*args)
      p 'post'
    end
    def foo:wrap(*args)
      p 'wrap pre'
      super
      p 'wrap post'
    end
    def foo
      p 'foo'
    end
  end

  Foo.new.foo

Output:
  wrap pre
  pre
  foo
  post
  wrap post

Notice how the pre/post/wrap is syntax defined before and
independently of the foo method. This is a boost to composability
because it waits for foo to exist and if foo is replaced it is still
acting on the correct foo.

This is a big win for dynamic software... the kind written using Ruby.
I still like the super call, and with this syntax, it is easy to keep
it clear on how recursive calls will act. If we aren't careful and
these extensions become widespread, I have a feeling that a lot of
code will find itself breaking other code too easily.

The other side effect of this syntax is that is provides an easy way
to extend into other method specialization features without having
uncooperative and short term syntaxes.

Brian.