Idea about method parameters

[Markus Schaber]

Hi,

John Roth <johnroth at ameritech.net> schrub:

> "Markus Schaber" <markus at schabi.de> wrote in message
> news:5243253.PRQshPE9Mp at lunix.schabi.de...
>> Chris Barker <chrishbarker at home.net> schrub:
>>
>> > Markus Schaber wrote:
>> >
>> >> Now I'd love to have the possibility to shorten this by typing:
>> >>
>> >> class A:
>> >>     def m(self, self.value):
>> >>         pass # or the other work to be done
>> >
>> > I suspect that this will clash with the internals somewhere, but I
>> > love it!
>>
>> This is why I gave the following semantic definition:
>>
>> class A:
>>     def m(self, value):
>>         self.value = value
>>         del value
>>         #the other work here
> 
> I like the idea - it's one of those neat little shortcuts that makes
> initializaing a class much simpler, and may even make 'setter'
> attribute functions trivial.
> 
> What bugs me a bit is the 'del' in your semantic definition. It's
> obviously there to reinforce the notion that the binding is to the
> instance variable, not to the local variable, but should it be? I
> don't have any problem with binding it to the local variable,
> and it does make it semantically equivalent to the current
> situation - that is, binding to a local variable, and then rebinding
> to an instance variable.

That's correct, but without the del, you implicitly create a new 
binding in the local procedure namespace.

I also thought about this idea, especially as a shortcut to access 
value for further calculations in the procedure.

But as the namespace is empty before the def():, it is not obvious that 
an assignment to self.value (which is in the def:) also creates a 
binding to something in the local namespace. This binding is implicitly 
created and hides bindings from "outer" namespaces (e. G. the module 
namespace). And it doesn't obey the "better explicit than implicit" 
rule.

> The other thing I find problematic is the notion that it could
> bind to any visible object, such as the class, superclass or
> module. Frankly, I'd consider this to be an invitation to
> obfuscation. Granted, it's easy enough to do with an additional
> assignment, but I'd rather not tax my brain with having to check
> exactly where the parameter wound up. That way lies errors,
> especially when I've been working too late.

That's a good argument against this extension, and that was why I 
personally would have limited it to accesses to self. (Better: the 
first parameter of a method which is often called self by convention)

But I also wanted to discuss it for access to the own class or 
superclasses. Module level or everything else somehow accessible never 
was in my mind - but on the other side, this would be consequent and 
consistent.

markus
-- 
"The strength of the Constitution lies entirely in the determination of 
each citizen to defend it. Only if every single citizen feels duty 
bound to do his share in this defense are the constitutional rights 
secure." -- Albert Einstein