RE: binder language, binding directories, bind by copy/reference

> From: Jeff Crosby
>
> > Buck wrote:
>
> > For some reason I can't put into words, I find this... distasteful.
>
> I agree with that sentiment.  What's the difference between that and
> LVLCHK(*NO)?  This is the same thing, to me, as adding fields at the end
> of a file, then creating the file with LVLCHK(*NO).

Remember, I am about as clueless here as they get, but let me make a
comment.  While I agree that a hardcoded signature is sort of like
LVLCHK(*NO), it's more like an intelligent LVLCHK(*NO).  Let's carry the
analogy forward.  This is LVLCHK(*NO) when you know all the original fields
are the same and you're only adding fields to the end of the record.  Now,
if I had applications that read a file, and I knew that the record format
was the same and that those applications had no need for the new fields, I'd
be fine with LVLCHK(*NO).

What Barbara is suggesting (I think!) is that the old fields (e.g., the old
procedures) are not changing, and that older programs aren't using the new
fields (procedures).  Well, to my mind that makes sense.

The only time you'd have to change the signature is if the interface to one
of the existing procedures actually did change.  And then you'd for sure
want to recompile every program that uses that procedure.

This makes lots of sens to me.  It's kind of like the signature identifies
whether the interface has CHANGED.  Having new things added does not change
the interface, it simply extends it.  And in fact, in an OO environment, if
you add things to your interface, you shouldn't have to recompile objects
that talk to you, as long as you satisfy all the old requirements.

Now, it would be nice if the signatures were a little finer grained - one
master signature at the highest level, and then individual signatures for
each procedure.  Then a program could check the master signature, and if it
didn't match, could check the individual signatures for the procedures it
uses.  If those all matched, then it could just continue on.  But that's a
different issue for a different day.