Two minor syntactic proposals

[Gareth McCaughan]

Roy Katz wrote:

> I am interested to know what you find inelegant about the existing
> define-a-function-and-bind-it-to-a-class (d-b-c) idiom?
> 
> Look at it this way:  The "in .. def" statement's only usable purpose is
> to implement something which can already be done..
> 
> There was a similar proposal to add 'aliasing' to Python with a
> "alias X: existingVar" statement, but Alex M. very nicely stated that a
> simple '=' is elegant enough. 

Well, I think Alex was absolutely right about the "alias"
statement. I'm not sure what similarity you see here.

The inelegance I see with the existing idiom is a matter
of verbosity and repetition. You have to say the name of
the new function three times (unless you define it with
a different name -- "_" or something -- but that is inelegant
for more obvious reasons).

> With regards to your latter proposal, again: having 'self' as the first
> argument is *so* critical.   Say class C has a method foo, and
> an instance c.  When one calls 'c.foo()', the interpreter calls
> C.foo(c)'.  That is why 'self' is the first argument to a method.

Er, yes, I know. If I gave the impression that I don't
understand what the "self" parameter means and why it's
used, then I screwed up. Sorry.

> I suppose.. one could modify the interpreter to allow
> statements like these:
> 
>   class C:
> 
>     def self.x(...): pass   # method
>     def C.x(...): pass      # static or class method

Um. That's an argument against my proposal, because the
way I'd imagined it the second would define an ordinary
method in which the instance argument was called "C". If
people might think of the proposal as enabling class
methods, that would definitely be a problem with it.

> but then, 'self' was never a special keyword... 

Nor was I proposing that it should be one.

> (note also that static methods can be implemented in modules instead of in
> classes.  I like this approach because I hate my CompSci instructors, who 
> like C++ and /insist/ on being able to define class methods
> (imbecilic concept IMHO.  print>>^H^H ). But that's just me. 

In languages where the class is the unit both of encapsulation
and of inheritance, class methods make a lot of sense. I prefer
languages like Python and Common Lisp where the concepts are
separated, but it's not a no-brainer.

-- 
Gareth McCaughan  Gareth.McCaughan at pobox.com
.sig under construc