"Trans" <transfire / gmail.com> writes:

> An example of a call mechanism:
>
>   class A
>     def f
>       A\g  # Peter's Syntax

I'm not incredibly turned on by that syntax; unfortunately,
I don't have any obviously better suggestion myself.

It would have been nice if we could use the °∆A::g°« syntax
for this.  Correct me if I'm wrong, but I think this would
be possible if °∆Curses.addch(?x)°« could *not* be written as
°∆Curses::addch(?x)°« (so that °∆Foo::bar°« could be changed to
always mean °»invoke °∆bar°« as defined in °∆Foo°« on self°…).

(Note that even if this was done, °∆Foo::BAR°« could still
mean what it currently does, because there is no ambiguity
when no method calls are involved.)

While this change would probably break most Ruby code that
currently exists, fixing it could be done mechanically:
Just substitute "\1.\2" for /(\w)::([a-z])/ everywhere.

You'd think another potential option would be °∆self.A::g°«,
but of course that currently means °∆self.A.g°«, and °∆self.A°«
is the only way to call a method named °∆A°«.  (Though if the
previously mentioned syntax is an option, then so is this.)

>     end
>     def g
>       "in g"
>     end
>   end
>
> A possible downside to a call mechinism is that the method
> is still part of the inheritance chain.

Another downside is that people would be tempted to add the
prefix °∆A\°« to every method call that would have been
non-virtual in C++.  I can see two bad consequences of that:

 * It would add loads of clutter, including the class name
   sprinkled all over the place.

 * It would be a step backwards towards static languages,
   because it would mean tempting people to decide early
   whether or not a method will need to be overridden.

> On the upside the syntax can be used to call specific
> acestor's methods (i.e. bypassing the direct parent,
> which #super dosen't allow).

Yes, that would certainly be useful.  I don't think the
syntax is suited for doing °»locally private°… methods, but
this use case makes it all worthwhile.

I'm thinking primarily about cases such as the following.

  class Foo < Bar
    include Baz
    def initialize(moomin, snufkin)
      super(moomin)
      Baz\initialize(snufkin)
    end
  end

The above could also be written as follows,

  class Foo < Bar
    include Baz
    def initialize(moomin, snufkin)
      Bar\initialize(moomin)
      Baz\initialize(snufkin)
    end
  end

or with the syntax I proposed above:

  class Foo < Bar
    include Baz
    def initialize(moomin, snufkin)
      Bar::initialize(moomin)
      Baz::initialize(snufkin)
    end
  end


If there were a way to make private methods truly private,
that'd be a better approach to °»locally private°… methods.
But that seems rather difficult to get right.

-- 
Daniel Brockman <daniel / brockman.se>

    So really, we all have to ask ourselves:
    Am I waiting for RMS to do this?   --TTN.