Inheriting the @ sign from Ruby
aleaxit at yahoo.com
Tue Dec 12 11:38:07 CET 2000
"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
you WOULD know what that does, right? Call method 'bind' on
that object with 'x' as an argument.
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
> 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.
More information about the Python-list