Inheriting the @ sign from Ruby

[Alex Martelli]

"Roy Katz" <katz at Glue.umd.edu> wrote in message
news:Pine.GSO.4.21.0012120138090.2874-100000 at y.glue.umd.edu...
>
> I was reading a Dr. Dobb's recently and it mentioned that Ruby uses the @
> symbol to denote instance members of a class.  This appeals to me because
> I can comprehend it faster than seeing 'self' pasted in front of a
> name, especially when the statement is buried in dense code.

'self' is not "pasted in front of a name" -- 'self' is an object,
and it is used with perfectly regular syntax for object access.

Thus, there is no special-case syntax needed: the regular syntax,
which you need anyway for general cases, takes care of everything
in the special-case as well.


> Why not bind @ to the first argument of method definitions? Consider:
>
>
>   class X:
>
>     def __init__( self, x ):
>
>       @bind(x)     # binds to 'self', because
>                    # 'self' is the first argument to __init__

If you called
    someotherobject.bind(x)
you WOULD know what that does, right?  Call method 'bind' on
that object with 'x' as an argument.

Therefore,
    self.bind(x)
does exactly the same thing, simply and predictably -- the
object on which 'bind' is called being, unsurprisingly,
the one named 'self'.

So, you would like '@identifier' to be a special-case
syntax meaning exactly the same as 'self.identifier' (if
the first argument, as per normal convention, is named
'self').


>     def bind(myself, x):
>       @x = x   # equivalent to myself.x

The violation of the convention (using 'myself' instead
of 'self' as the name of the first argument) is not
remedied by the '@' kludge, of course.  Whenever a use
of 'self' is desired, that cannot be brought to the
attribute-access syntax of self.whatever (passing
'self' as an argument to getattr, or to a base-class
version of a method, etc, etc), such a violation of
normal expectations will make your code harder to read
and understand by any maintainers.

I'd much rather have a lint-like checking that the
argument expected to be named self is in fact thus
named, with a warning when it isn't.


> What faults or strengths do you see with this?

I see no strength in this supplementary syntax form
offering a second, different way to express what can
be perfectly well expressed explicitly today.

I see it as a fault that all this does is offer a
second, different way to express what can be perfectly
well expressed explicitly today.

It would also be a (small) step along the road of
turning the currently crystal-clear syntax of Python
into that morass of special-purpose, ad-hoc, 'convenient'
kludges that make certain other languages' typical
programs look so peculiarly similar to line noise.


Alex