Cliff Wells <cl************ @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
