Why we will use obj$func() often

[David MacQuigg]

On Fri, 23 Apr 2004 13:40:55 -0700, "Mark Hahn" <mark at prothon.org>
wrote:
>"David MacQuigg" <dmq at gain.com> wrote ...
>> >def getFunc():
>> >    counter = 0
>> >    def count():
>> >            &counter += 1
>> >            print &counter
>> >    return count
>
>> Here is how I would do it in Python:
>>
>> class Accumulator:
>>     def __init__(self):
>>         self.count = 0
>>     def bump(self):
>>         self.count += 1
>>         print self.count
>
>> It took me a few minutes to understand what the "closure" was doing.
>> The Python code is more clear ( at least for anyone who will have to
>> be working with classes anyway).  There is nothing new to learn.
>>
>> Functionality       = same
>> Size of Source Code = same
>> Transparency        = Python wins
>
>Yes, it's a tie in this example.  There are many cases however where you are
>already in a situation where you have a function and the closure is
>beneficial and creating a "class" would be unneeded overhead.  I don't
>really have the time to create something large enough here to demonstrate
>it.  You'll just have to take my word for it (or not).
>
>It's a tool for your toolchest and it's the kind of thing that if your not
>familiar with it you'll never miss it, but once you learn it and use it a
>few times you'll wonder how you ever lived without it.  Also I can drag out
>the old tired argument that if the closure bothers you "you don't have to
>use it".

I appreciate that I may be missing something important because it can
only be seen in a larger example.  For many years I scoffed at C++
thinking I could do anything I needed without OOP.

Still, the question of whether we should include special syntax for
closures is an important question that deserves some time on a
use-case before even putting it into Prothon, let alone expecting
Python users to learn it.  

I'm not seeing the "overhead" of classes that you refer to.  To me, a
class is very lightweight thing.  I use nested classes, for example to
store hierarchies of variables, like
window1.plot2.xaxis.label.font.size = 12

It is quite alright to show a small example and expect us to
extrapolate to something 100 times larger.  Even if we extrapolate the
example above, however, Python still wins.

I don't like the "toolchest -- don't have to use it" argument, because
that could be used to justify *any* added syntax, and I really like
the compactness of Python.  The more overlapping features we have, the
more confusion there will be in reading someone else's programs, for
example.

I don't like the "once I learn it argument" either.  An equally valid
argument is that people who have developed a *habit* in other
languages of using closures, are now unnecessarily dependent on them,
and will have to learn simpler techiques to get by in Python.

By the way, if we work on the example a little, Python wins on
transparency *and* codesize.

class A:
    count = 0
    def bump(self):
        A.count += 1
        print A.count

c = A().bump
c(); c(); c()

-- Dave