int/long unification hides bugs

[Alex Martelli]

Cliff Wells <clifford.wells at comcast.net> wrote:
   ...
> > Of course, this has nothing to do with silly and arbitrary bounds such
> > as 2**31-1.  But constraint checking should not necessarily be ruled out
> > as a generally helpful technique.
> 
> Not at all.  I do quite a bit of database programming and use
> constraints (foreign keys, unique indices, etc) extensively.  The

Yep, and besides such 'structural' constraints even the simple kind of
check such as "this number is alway between X and Y" may to a lesser
extent come in handy.

> concept is also in widespread use in GUI programming libraries for
> controls that deal with user input (e.g. masked input controls).  In
> fact, most controls present in a GUI implicitly constrain user input
> (menus, buttons, etc).

A different case, IMHO.  An input/'edit' box with inherent checks is a
bit closer.

> Of course what you describe above can be done now using functions and
> derived classes, but it would certainly be interesting to have a general
> (and concise) way of describing constraints within the language itself.

Functions are in general the proper way to check, but having to
explicitly call the checking function each time a change may have
occurred gets old fast.

What I was musing about is (well, half of it) is easy to implement if
you're using qualified names rather than barenames -- each assignment to
a.x may easily be made to go through a setter-function that calls an
appropriate checker function.  Attaching similar setter-functions to
barenames is a very alien concept to Python today, but in a sense the
difference could be seen as mere syntax sugar.

The other half of the problem has to do with mutables, and ensuring a
checker function (on object invariants, if you will) runs after each
mutation -- not all that new a notion, just a part of design by contract
(people always focus on preconditions and postconditions and appear to
forget invariants, which are just as crucial;-).

I'm not sure there's a "grand unification" between these halves just
waiting to happen.  Surely, though, a little add-on package making it
easy to add checker functions and providing a few typical such checkers
might be of some help.  If the checkers could be easily disabled at the
flip of a switch (say the debug flag;-) they might even help by being
potentially-executable specifications of programmer intention (much like
DbC helps in part exactly because it _can_ be disabled that way;-).

Guess I'm mostly musing on the general issue and the 2**31-1 silliness
was just a spark that lit some waiting tinder in my mind;-).


Alex