[Baypiggies] Frequently Argued Objections

[Kelly Yancey]

Warren Stringer wrote:
> On Jun 21, 2008, at 7:13 PM, Shannon -jj Behrens wrote:
> 
>> On Sat, Jun 21, 2008 at 11:18 AM, Warren Stringer <warren at muse.com> 
>> wrote:
>>> Yee HAW!  Here, have some beef jerky while I explain why us cowboy
>>> programmers are annoyed: Self has to be explicitly used yet is 
>>> implicitly
>>> passed as a parameter. Second, when counting keywords in the standard 
>>> python
>>> library, "self" is the most common keyword, beating the 2nd most common
>>> keyword by almost a factor of two. I mentioned this to JJ, who says 
>>> that he
>>> uses self and non-self in the same code base. I would love to see an 
>>> example
>>> where this is useful, where the NRO wouldn't suffice. As a mere 
>>> tenderfoot
>>> Pythonista, all I see "self" doing is obfuscating the wide open white 
>>> spaces
>>> that I have grown to love.
>>
>> Are you sure it was me?  Are you referring to calling self by another
>> name?  I might have said it's possible, but I don't remember ever
>> doing it.
>>
>> -jj
> 
> 
> *Is* there a reason to NOT use self? If not, then self is redundant. If 
> the reason to use self is to bypass name resolution order, then I would 
> suggest making the less common case explicit and the more common one 
> implicit.
> 

   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.

   Kelly

* In case anyone is curious, the dynamically-created classes where
   ctypes.Structure subclasses whose fields depended on the OS (hence
   the need for a factory).  The structures contained pointers into a
   data structure represented by the factory method's class (also a
   ctypes.Structure subclass) so references needed to be held to the
   parent object to prevent it being GC'ed prematurely.

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