[Baypiggies] Frequently Argued Objections

[Kelly Yancey]

Warren Stringer wrote:
> Hey JJ, Kelly, I've combined both of your replies,
> 
> On Jun 23, 2008, at 2:48 AM, Shannon -jj Behrens wrote:
> 
>> Let's make it really fun:
>>
>> from thirdparty import *
>>
>> class A(B):
>>  def bar():  # Assuming we have implicit self.
>>    foo()
>>
>> Now, did foo come from:
>>
>> * The parent class B?
>> * Something in thirdparty?
>> * Something in thirdparty that someone else shoved in there dynamically?
>> * Something in builtins that someone else shoved in there dynamically?
>> * Some global in the current module that's a few hundred lines down?
>> * Some global in the current module that someone else shoved in from
>> a third-party module? ;)
>>
>> Using self cuts down on the possibilities which:
>>
>> a) Saves the interpreter from doing a bunch of useless dict lookups.
>> b) Saves the reader from trying to figure out what's going on.
> 
> OK, I'm sure that I'm missing something. Couldn't this be resolved with 
> something like:
> 
> 1) B.foo()
> 2) super.foo() # or ..foo() with dot_as_self convention expanded to 
> emulate a file system

Give me back my polymorphism!

> 3) thirdparty.foo()

   So we're removing the "from thirdparty import foo" syntax in order to 
solve the ambiguity?

> 4) __builtins__.foo(
> 

   My eyes, they burn.

> Moreover, since we're talking about not using self for items that are 
> local to the class, the example should really be:
> 
> class A(B):
>   def foo:
>      ... # foo statements
>   ...  # other statements
>   def bar():
>       foo()
> 
> In this case, the resolving of 'foo' ranges from blindingly easy (when 
> the distance from foo's declaration is short), to search-ably easy (when 
> the distance from foo's declaration is long)
> 

   OOP without polymorphism OR inheritance?
   I don't want to live in your world. :)

Kelly
-- 
http://kbyanc.blogspot.com/

> On Jun 22, 2008, at 11:53 PM, Kelly Yancey wrote:
>>
>>  I admit, I have had to call self by another name on a couple of 
>> occasions.  Specifically, I had a factory method in one class that 
>> returned instances of a dynamically-created class.  The returned 
>> objects had methods that referenced both their own instance's 
>> attributes and attributes of the factory method's parent object (via 
>> closure).  Since there were two objects involved, I used self to refer 
>> to the factory-generated object itself, and had the factory method use 
>> a different name for its own object reference argument so the 
>> generated object could still access both.
>>  Complicated?  Sure.
>>  Possible with implicit self?  Nope
> 
> 
> As with other languages, 'self' can still be available; simply not 
> required.
> 
> On Jun 23, 2008, at 2:48 AM, Shannon -jj Behrens wrote:
>> As a blanket statement, polymorphism can be confusing.  When I see
>> "self", at least it's a good sign that I should start looking at
>> either the class's documentation or one of its ancestor's
>> documentation.
>>
>> -jj
> 
> These days, I do a search within the IDE, a spotlight search (Mac), or a 
> Google Desktop search (PC). WIth several IDEs, I can right click to find 
> the definitions. Some tools provide an accurate call graph. Many of 
> these tools weren't available when Python was first created. 
> Thirty-three years ago, most of my debugging involved reading code 
> printouts from a KSR 35 teletype. Since then, my habits have changed.
> 
> My guess is that:
>     1)  9 times out of 10 the var in self.var is blindingly obvious,
>     2) 99 times out of 100 it is obvious after a 10 second search,
>     3) when non-obvious, it may indicate an obscure namespace that
>          a) has ballooned out to a complexity that should be refactored
>         b) wouldn't be solved by simple code reading aides, like self
> 
> \~/
> 
> 
>