Evaluating opinions - FilePro Error Messages

[Fairlight]

On Thu, Jun 03, 2004 at 04:55:26PM -0400, Jay Ashworth, the prominent pundit,
witicized:
> On Thu, Jun 03, 2004 at 04:41:30PM -0400, Nancy Palmquist wrote:
> > Fairlight wrote:
> > > Tecnically yes.  However, how hard would it be to actually put code in fP
> > > that prevents one from modifying the key field(s) of the lookup index to
> > > prevent people from making the mistake at all?  I shouldn't think very
> > > difficult, since it knows exactly what fields it's dealing with.
> > 
> > Never support this in a million years. After I attach to a record with
> > a lookup, why should it not allow me to change a KEY field any way
> > I want. How does it know what I will do next? You are asking it to
> > change a fundemental feature, to protect bad logic.
> 
> I concur entirely.  That's not the proper solution.

I was thinking off the cuff.  After Nancy went into it, I could see that it
was a bad solution.  I was trying to think of a way to prevent the
programmer from shooting themselves in the foot--especially ones just
learning.

Then again, fP makes more concessions to that end than many languages.  If
you take C as an example, it makes next to zero concessions towards keeping
you from trampling your own data and algorithms.  Witness the usual torrent
of buffer overruns, misplaced pointers, etc. that show up as security
alerts.  Perl falls inbetween--it's more fault tolerant in not actually
-crashing- your code unless it has absolutely no other option, but it's
still easier to hang yourself from a convenient module named Lamp::Post.
*grin* OTOH, you can do -really- neat things, like write a non-stop daemon
that could accept changes to all its functionality so long as the core
protocol needed no changes.  You can actually re-define functions, so on
a HUP or USR1 or whatnot, you could eval() the relevant files containing
the functions and redefine the behaviour of the program on the fly, if
you wrote it modularly enough and account for objects if you use them and
change the structure of their data.  I've already tested this theory and
produced a brief proof-of-concept program that worked correctly.  Perl
will generate warnings if you have them turned on, but you're free to
shoot yourself in the foot.  With more power comes more responsibility, I
suppose.

In this lookup case, it really doesn't even come down to the syntax
checker, since there are perfectly allowable -technical- practices in any
language that aren't semantically advisable (to say the least).

So I recant--don't fix it, then.  :)  I suppose thinking it should be fixed
so you can't is about equivalent to wanting C rewritten so you can't
misplace pointers.  Silly on my part, now that I think of it.

> My impression has always been that fptech's corporate opinion of our
> idea, going back at least three owners now, was roughly equivalent to
> John's.  Ken, Wally and Bud are all listening here.  If they think the
> ideas are useful no doubt they can find a way to use them.

A few more that you didn't list also listen on and off.  

> I do see sales literature trumpeting the actions of school boards who
> are likely to get sued really badly for what fpTech thinks is neat...

Assuming you're referring to the biometrics package, dare I open the
proverbial can of worms and ask on what grounds they would be sued?

> but I won't start that.

*laugh*  Jay, that's like saying, "You know, this is entirely screwed up,
but I'm not going to say anything."  You just -said- something already.  :)

NOW explain what you meant, as you have piqued my curiosity.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html