Re: Ruby aesthetics

Albert Wagner wrote:
>>>
>>>>What I really dislike in Ruby, that the data members are seen
>>>
> 
> I suppose what is needed is a good refactoring browser for Ruby.  Then, in the 
> example above, all references to @thing would be automaticallly renamed in 
> progeny.  However, speaking for myself, I don't trust the parent's accessors 
> to not cause side effects.  I view instance variables, like methods, as what 
> a subclass inherits.  I design and maintain with this is mind.  When I change 
> the name of a superclass instance variable, I know to change it in it's 
> subclasses also.  Standard operating procedure. 
> 
> 
> 
>>
>>David
> 
> 

With your attitude, the objects don't have implementations at all, only
interfaces. I think, this is a violation of the principle of object orientation
which allows for a clear separation of implementation and interface.
The power of object-orientation is that you can change the implementation as
long as the interface remains stable.

Refactoring browser: I think this is inherently impossible in Ruby, or
at least so complicated that I don't think that anyone anytime could write
a usable one.

Why?
One of the most powerful features of Ruby is its reflexivity
and possibility to manipulate the ojects and object hierarchy in a very very
high level (I make use of it more and more). You can write methods
(such as attr_accessor) which defines methods automagically. And you can
write methods which generates methods which generates methods which ... -> oo
And all the generated methoods can make use of data members depending on the
generating functions in several complicated ways.

How should a refactoring browser know, which methods generatad the
methods that generated the methods that make use of the data member, in
order to change it?

This level of reflexivity (meta-programming) is a very concise feature in
Ruby and of great value for me and I would (and could)
not want to give up this features for a refactoring browser.

Besides:
I don't think refactoring browsers are a good idea in general:
they delegating semantic tasks from the language which belong
to the language to syntactic tasks in an interactive environment.
But this has to flaws:
1) This is always error prone since the browser must understand the language
    completely. Therefore refactoring browsers work only for very stably defined
    languages. (Or restrict your usage of the language.)
2) The lack of automatization of tasks: since you have to manipulate your code
    manually, the automatization of refactoring processes is impossible unless
    you have a separate scripting language which controlls your browser.
    But I think it is a dead end.

The right solution in my view is Ruby's : the language itself is allowed
to modify the class hierarchy and the programmers should use high level
abstractions in order to make his programm easily refactorable via these
built-in features.

Regards, Christian