From: Trans <transfire@...>
Date: 2005-07-25T15:55:58+09:00
Subject: Re: Local Instance Methods



Daniel Brockman wrote:
> "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.

That' how I felt at first too, but it grows on you. The other option we
considered was A#g.

> 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.)

I agree that having '.' and '::' mean the exact same thing is kind of a
waste. But I'm not sure if constants and methods really need a seperate
namespace like they have now.

> > 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:

I don;t think people would be inclided to use extra verbosity unless
they had a strict need to do so. So I don;t think this would be a
serious drawback.

> > 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.

True. Well, it provides half of what locally private methods do.

Thanks,
T.