Hi Markus, sorry if it took me a while to answer back.  It was a busy week.

On 3/1/06, Markus Werner <markus.werner+news / wobcom.de> wrote:
> Hi chiaro,
> For me the subject we discuss it is a matter of taste. And for my taste the
> ruby way is OK.
> I like it the way it is and for me it is not surprising and thats why I
> wrote my post.

The reason I find it surprising is that I expect to read from
something and to write to something using the same name to identify
the thing I am reading from or writing to.

I find this symmetry beautiful and intuitive.

If 'puts n' prints out the value of n, then I expect 'n = something'
to change the value of n.  I don't want to be concerned with the fact
that n is a local variable or a method that provides me with access to
an instance variable.

With the current system I would have to specify 'self.n = something'
to make the assignment.  This is unrebesque to me, since it forces me
to see (and to understand) the inner workings of the system, rather
than focus on my problem.

Yet, the discussion on this thread pointed out why it is necessary (see later)

> > never been a problem.  the few times this error slipped through, the
> > tests always caught it.
> Wouldn't it be better if they don't appear at the first place?

This is a matter of attitude.  I used to be all for 'defensive
programming' [1], but I find that tests can allow me to move faster
while catching errors fast.

I prefer to write code where the semantics of what I am doing are
clear to me, rather than having to satisfy the needs of the parser. 
This means that I can be more relaxed and I do not need to specify the
syntactic nature of what I am accessing (local var, instance
attribute, etc..) unless it is necessary to solve an ambiguous
situation.


> Maybe you could explain me why the other way is better.
> I'm open minded so your opinion would really helps do to extend my
> knowledge.

I hope I made my point :-)

The reason why we cannot get rid of the self, as far as I have
understood it, it is related to the use of mixins.  If we didn't have
mixins I would simply propose to resolve the nature of our 'n' sign at
runtime.  If there is an argument 'n', then that argument is 'n'
within our scope, and we would need an explicit 'self.n' to access our
'n' method/accessor.  If there is no 'n' argument, then we look for
'n' methods and finally for 'n' local variables.

If you use mixins however you can have an unpredictable name clash
between names that were intended to be used as local variables within
the mixin and names that you are using as methods in your class.  This
is an error that is very hard to spot, since you are not even supposed
to know what these offending local variable names of the mixin are. 
They are inner workings of the mixin; they are not part of the mixin
'interface' and they should not conflict with your class.

This looks like a problem that is almost impossible to solve in a
non-defensive way.. forcing us to use self in the former case as well,
to protect us from an eventual mixin name clash ambiguity.

I just wish there could be a way to solve the mixin name clashes and
get rid of the 'self' when using the assignment operator on a method.


[1] : http://en.wikipedia.org/wiki/Defensive_programming
--

-- Chiaroscuro --
Liquid Development Blog: http://feeds.feedburner.com/blogspot/liquiddevelopment