how to avoid instance variable collisions?

[James Miller]

Howdy,

Ruby Newbie Question: When extending a class, what's the conventional
method for avoiding collisions between instance variables introduced in
the subclass and those already defined in the base class chain?

It seems the same problem can occur when using Modules for "mixins,"
too. The only suggestion I've found is to prefix one's instance
variable names with thier class names, i.e., a poor man's namespace
mechanism, which isn't very comforting. If there's no language support
for this problem, it means that to be absolutely sure that your variable
names won't collide you have to go mucking around in base class
implementations, which doesn't sound very OO at all.

 

[gabriele renzi]

James Miller ha scritto:

Howdy,

Ruby Newbie Question: When extending a class, what's the conventional
method for avoiding collisions between instance variables introduced in
the subclass and those already defined in the base class chain?

It seems the same problem can occur when using Modules for "mixins,"
too. The only suggestion I've found is to prefix one's instance
variable names with thier class names, i.e., a poor man's namespace
mechanism, which isn't very comforting. If there's no language support
for this problem, it means that to be absolutely sure that your variable
names won't collide you have to go mucking around in base class
implementations, which doesn't sound very OO at all.

Yeah, it is the same for both mixin and classes, and there is no
*direct* language support to avoid this.
And there are no private methods in the java sense (i.e. not
redefineable in subclasses).

The usual folk wisdom is that this is a problem that seem really nasty
but does not really happen often. Actually, I think I never hit it in
the last 3 years, but I'd like "private" stuff too.

OTOH I think a real OO purist should prefer encapsulation over
inheritance so this problem won't arise