Local Instance Methods

[Daniel Brockman]

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 =E2=80=98A::g=E2=80=99 syntax
for this. Correct me if I'm wrong, but I think this would
be possible if =E2=80=98Curses.addch(?x)=E2=80=99 could *not* be written =
as
=E2=80=98Curses::addch(?x)=E2=80=99 (so that =E2=80=98Foo::bar=E2=80=99 c=
ould be changed to
always mean =E2=80=9Cinvoke =E2=80=98bar=E2=80=99 as defined in =E2=80=98=
Foo=E2=80=99 on self=E2=80=9D).

(Note that even if this was done, =E2=80=98Foo::BAR=E2=80=99 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 =E2=80=98self.A::g=E2=80=99=
,
but of course that currently means =E2=80=98self.A.g=E2=80=99, and =E2=80=
=98self.A=E2=80=99
is the only way to call a method named =E2=80=98A=E2=80=99. (Though if t=
he
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 =E2=80=98A\=E2=80=99 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 =E2=80=9Clocally private=E2=80=9D 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 =E2=80=9Clocally private=E2=80=9D methods.
But that seems rather difficult to get right.

--=20
Daniel Brockman <[email protected]>

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

 

[Trans]

It occurs to me that there is a way to create psuedo-local methods if
we have private instance vars. Assuming instance vars are private:

class A
def initialize
@m = lambda { puts "Like a local method!" }
end
def m
@m.call
end
end

That being the case one is led to the possibility of

def @m
puts "Like a local method"
end

T.

 

[Trans]

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.

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.

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.

 

[Brian Candler]

I tend to view this as way of minimizing namespace pollution and
possible naming clashes.

What if I want to include two different modules from two different
sources and they both use a common method and/or instance variable
name? How do I resolve that?

One way is to choose method names which are highly unlikely to clash.

module ABC
def _ABC_func(foo)
@_ABC_var1 = foo
...
end
end

Regards,

Brian.

 

[Daniel Amelang]

=20

That being the case one is led to the possibility of
=20
def @m
puts "Like a local method"
end

+1 Nice reuse of existing symbol that has the same flavor.

Dan