David Garamond <lists / zara.6.isreserved.com> writes:

> Now Ruby2 wants to change so that 'util' in C method calls C#util and 
> 'self.util' calls CC#util. I very much prefer 'self.util' to be the one 
> that calls C#util (and I don't think I'll ever use it a lot). The latter 
> is backwards compatible and how virtually all other languages behave.

I would have to agree.  As an OO programmer, the current behaviour is
what I would expect.  And I'd go so far as to say that it's the
"correct" behaviour.  When I call #util, I'm not "expecting" C#util, I'm
expecting the *right* #util to be called, where the "right" #util is
defined as the one that preserves the invariants of whatever class
self is a member of.  An contrived example of why this is important:

class A

    ...

    def do_stuff
        data = get_some_data()
        store(data)
    end

    def store(data)
        @mydata << data
    end
end

class ThreadSafeA

    ...

    def store(data)
        @mutex.lock
        @mydata << data
        @mutex.unlock
    end
end

a = ThreadSafeA.new
a.do_stuff

In this case if the call to do_stuff resulted in a call to A#store, it
would violate the thread-safety invariant promised by ThreadSafeA.

Maybe not the best example, but it's a pattern which permeates OO
design.  It's the Strategy pattern, really:  a superclass defines some
broad, high-level methods which are implemented in terms of more
granular support methods; and then the implementation strategy is
defined by subclassing it and overriding the suport methods.

Actually, in my mind applying the principle of least astonishment
would lead to expecting store and self.store to have identical
behaviour.  I would expect to have to use something like super.store
or A::store in order to specify that I want the superclass version of
store.

--  
ABG