Unification of Methods and Functions

David MacQuigg dmq at gain.com
Wed May 19 17:56:05 EDT 2004


On 17 May 2004 20:11:44 -0700, moughanj at tcd.ie (James Moughan) wrote:

>David MacQuigg <dmq at gain.com> wrote in message news:<4ka7a0t585802d81i417j5ufmrdjbq6hei at 4ax.com>...

>> We need to make a distinction between users and programmers in our
>> expectations of what kind of errors they will make.  Users only need
>> to *read* a class definition and understand what it does.  Programmers
>> are the group that needs to remember to add a call to the superclass
>> when they write a new class.
>> 
>> I am a user of the Qt Toolkit, but I would not attempt to add a class
>> to their existing hierarchy.  Nor would I expect Trolltech to provide
>> me with some kind of robust class-generating function that was
>> guaranteed to generate an error-free class at any point in their
>> hierarchy I might chose to insert it.
>
>If you're writing code, you're writing it to be modified at some
>point, unless it's a few lines-long script.  If the modifications are
>made by someone else then they will reasonably expect that the code
>doesn't contain implicit deathtraps, like non-local data.

The trade-off, in the case of _numAnimals is: Do we want a simple
program with instant display of this number, or a more complex program
that scans the entire hierarchy to re-create the total every time it
is needed.

There is an analogy in the netlisting programs used in circuit design.
Netlisting a big design is a time-consuming operation, so each cell is
netlisted when it is saved.  When the design is simulated, there is a
quick check of the time-stamps on the entire hierarchy, to make sure
all of the incremental netlists are up-to-date.  One could argue that
somehow the time-stamps could get out-of-sync (incorrect clock setting
on a client machine, etc.).  Yet nobody says that not netlisting the
entire design every time is bad programming.

It's always a compromise.  Robustness is never absolute.

-- Dave




More information about the Python-list mailing list