Another newbie question

[Alex Martelli]

Mike Meyer <mwm at mired.org> wrote:
   ...
> Well, the hard-core solution is to note that your class doesn't really
> deal with the type Bar, but deals with a subtype of Bar for which x >
> 23 in all cases. Since types are represented by classes, you should
> subclass Bar so you have a class that represents this subtype. The
> class is trivial (with Eiffel conventions):
> 
> class RESTRICTED_BAR
>    inherits BAR
>    invariant x > 23
> END

Yes, but then once again you have to "publicize" something (an aspect of
a class invariant) which should be dealt with internally; also, this
approach does not at all generalize to "bar1.x>23 OR bar2.x>23" and any
other nontrivial constraint involving expressions on more than
attributes of a single instance's attribute and compile-time constants.
So, besides "hard-coreness", this is just too limited to serve.


> > So, one invariant that had better hold to ensure a certain instance foo
> > of Foo is not about to crash, may be, depending on how Foo's detailed
> > structual geometry is, something like:
> >
> >   foo.beam1.force_transferred_A <= foo.pier1.max_load_top AND
> >   foo.beam1.force_transferred_B <= foo.girder1.max_load_A
> >
> > The natural place to state this invariant is in class Foo, by expressing
> > 'foo' as 'self' in Python (or omitting it in languages which imply such
> > a lookup, of course).
> 
> I don't think that's the natural place. It's certainly one place to
> consider, and may be the best one. However, it might work equally well
> to use preconditions on the methods that add the beam and pier to Foo
> to verify that the beam and pier in question are valid. If the
> attributes of the beam and pier can't change, this would be the right
> way to do it.

What ever gave you the impression that the loads on beams and piers (and
therefore the forces they transfer) "can't change"?  That would be a
pretty weird way to design a framework for structural modeling in any
language except a strictly functional (immutable-data) one, and I've
already pointed out that functional languages, thanks to their immutable
data approach, are very different from ones (like Eiffel or Python)
where data routinely does get changed.


> > If I'm not allowed (because you think "it's silly"!) to express a class
> > invariant in terms of attributes of the attributes of an instance of
> > that class, I basically have to write tons of boilerplate, violating
> > encapsulation, to express what are really attributes of attributes of
> > foo "as if" they were attributes of foo directly, e.g.
> [...]
> > (etc).  Changing a lot of dots into underscores -- what a way to waste
> > programmer time!  And all to NO advantage, please note, since:
> 
> If you knew it was going to be to no advantage, why did you write the
> boilerplate? That's also pretty silly. Care to provide reasons for
> your wanting to do this?

If I had to program under a styleguide which enforces the style
preferences you have expressed, then the stupid boilerplate would allow
my program to be accepted by the stylechecker, thus letting my code be
committed into the source control system; presumably that would be
necessary for me to keep my job (thus drawing a salary) or getting paid
for my consultancy billed hours.  Just like, say, if your styleguide
forbade the use of vowels in identifiers, I might have a tool to convert
such vowels into consonants before I committed my code.  I'm not saying
there cannot be monetary advantage for me to obey the deleterious and
inappropriate rules of any given arbitrary styleguide: it may be a
necessary condition for substantial monetary gains or other preferments.
I'm saying there is no advantage whatsoever to the organization as a
whole in imposing arbitrary constraints such as, "no vowels in
identifiers", or, "no access to attributes of attributes in invariants".


> >> of. Invariants are intended to be used to check the state of the
> >> class, not the state of arbitary other objects. Doing the latter
> >> requires that you have to check the invariants of every object pretty
> >> much every time anything changes.
> > ...in the end the invariant DOES have to be checked when anything
> > relevant changes, anyway, with or without the silly extra indirection.
> 
> No, it doesn't have to be checked. Even invariants that don't suffer
> from this don't have to be checked. It would be nice if every
> invariant was checked every time it might be violated, but that's not
> practical. If checking relationships between attributes attributes is
> the best you can do, you do that, knowing that instead of an invariant
> violation raising an exception after the code that violates it, the
> exception may raised after the first method of your class that is
> called after the invariant is violated. That's harder to debug than
> the other way, but if it's the best you can get, it's the best you can
> get.

Let's silently gloss on the detail that calling "invariant" something
that is in fact not guaranteed not to vary (or at least not to vary
without raising exceptions) is a recipe for semantic confusion;-)  The
point remains that forcing me to define a beam1_load method, which just
delegates to beam1.load, and use beam1_load in my invariant's code
instead of beam1.load, is a silly rule -- yet it follows from the
stylistic prohibition on using beam1.load directly there, which
highlights the fact that said stylistic prohibition is silly in its
turn.


> > But besides the wasted work, there is a loss of conceptual integrity: I
> > don't WANT Foo to have to expose the internal details that beam1's
> > reference point A transfers the force to pier1's top, etc etc, elevating
> > all of these internal structural details to the dignity of attributes of
> > Foo.  Foo should expose only its externally visible attributes: loads
> > and forces on all the relevant points, geometric details of the
> > exterior, and structural parameters that are relevant for operating
> > safety margins, for example.
> 
> You're right. Choosing to do that would be a bad idea. I have no idea
> why you would do that in any language I'm familiar with. I'd be
> interested in hearing about the language you use that requires you to
> do that.

Eiffel PLUS your constraint against using attributes' attributes in an
invariant (language + additional constraint you desire) induces me to
wrap each beam1.load access as an attribute of my class under the name
beam1_load (and so on for all attributes' attributes which I need to
access internally in my invariants).  I guess I can put band-aids on the
self-inflicted wounds by keeping those attributes private, but it would
be better to avoid the wounds in the first place by ditching the style
constraint against using attributes' attributes in invariants.


> >> Invariants are a tool. Used wisely, they make finding and fixing some
> >> logic bugs much easier than it would be otherwise. Used unwisely, they
> >> don't do anything but make the code bigger.
> > I disagree, most intensely and deeply, that any reference to an
> > attribute of an attribute of self in the body of an invariant is
> > necessarily "unwise".
> 
> So do I.

Yet you called it "silly" -- which DOES imply "unwise" (and more).


> >> > I'm also quite dubious as to how you can then express some
> >> > invariants that can be very important
> >> Not all invariants, pre-conditions or post-conditions can be
> >> expressed.
> > Not all can be sensibly CHECKED, but most definitely all can be
> > EXPRESSED.  Another one of my long-standing contentions with Eiffel is
> > the inability to express invariants (and pre- and post- conditions)
> > because the compiler is unable to figure out a decent way to check them;
> > Z and the VDL, just to name very old design languages, show easy ways to
> > allow full expression.  Of course, if a condition is of the form, say,
> > "all items of potentially infinite iterable X satisfy predicate P", it
> > may not be runtime-checkable -- big furry deal, I want to be able to
> > EXPRESS it anyway, because apart from runtime checking there are other
> > precious uses of such conditions (e.g., the compiler might be able to
> > DEDUCE from such a condition some important optimization, or the
> > compiletime proof of other assertions, when run in the appropriate
> > mode).
> 
> So you think that a tool being imperfect means you shouldn't use it
> all? So you don't test your code, because testing can't reveal all
> bugs? That's odd - I always thought that testing was a critical part
> of program development. I'd be interested in hearing about any
> research that justifies doing development with testing, preferably
> with URLs.

Start with:

http://www.mtsu.edu/~storm/
http://www.softwareqatest.com/
http://www.testing.com/
http://www.faqs.org/faqs/software-eng/testing-faq/

and feel free to come back and ask for more once you've exhausted the
wealth of pointers, articles, books and surveys these URLs will direct
you to.

As far as I know, the only outstanding figure in the history of
programming who decisively condemned testing because "it can only show
the presence of bugs, never their absence" was Djikstra; it's funny that
he failed to notice the parallel with Popper's epistemology -- by the
same thought-structure, we should condemn scientific experiments,
because, per Popper, they can only show the falsity of a scientific
theory, never its truth.

I never said nor implied that a tool's imperfections must prohibit its
use: I was just pointing out that your assertion about important
conditions which *can't be expressed* is simply false (as well as
totally inapplicable to the specific examples being discussed).


Alex