You can't do that

[John Esak]

>
> > > Here are some other "would be nicest":
> > >
> > > Functions and arguments would be nice.  I would
> > like
> > > to pass arguments to a particular call (or chain)
> > and
> > > have it return a value.
> >
> > Now hold on... am I missing something. This is
> > pretty much *exactly* what I
> > use CALL tables for in the first place. What do you
> > mean???
> >
>
> Ok, to clarify here, I would like to do something like
> the following:
>
> returnvariable = call("mycode",arg1,arg2)
>
> Does this make sense? This way I could pass arg1 and
> arg2 into the call table without worrying having to
> keep track of which variables should be used in which
> tables and which ones should be defined as global, or
> external, etc.  You could set aside new system
> maintained fields like @p1, @p2, etc to refer to the
> parameters within the "mycode" table.

>
> Also, within "mycode", you could have a return
> (returnvalue) statement that would return a value to
> the calling table and populate the returnvariable
> above.
>

Okay, I'm glad you clarified this. Now, I'm sure I disagree with you on
this. That construct would be severely limiting to what is now a completely
open situation that can do anything. "A" return-value??  I sometimes have 20
return values from a CALL table. An argument pair like argv, argc... nah,
you just have to keep track of all that anyway... no savings there.
Currently, you can pass any value(s) to a CALL and return any values(s) from
it. Keeping track of what has to be defined'd global and what has to be
define'd extern could not be simpler, I don't see this as any kind of valid
complaint. It's just so obvious and trivial a thing to do correctly. The
flexibility is only a bonus for the extremely odd situation. I do however,
agree, as I said, that a CALL should be allowed to be nested within
another...

> > > Rules for data integrity.  It would be nice to be
> > able
> > > to set up certain rules in define processing that
> > > would prevent certain situations from being
> > allowed.
> > > For example one could set up a rule to ensure that
> > > there would be no child data without a header
> > record.
> > > Another rule could be that a certain field must be
> > > filled in and no duplicates allowed, etc.
> >
> > I hear what you are saying... but it sounds like
> > setting up some tight
> > library CALLS might do this. I'm not trying to say
> > filePro can do everything
> > you're asking for in this regard, and this sounds
> > like a neat idea, but then
> > again, even if you had these built-ins, wouldn't you
> > change them once in a
> > while to do exactly what you want. So, therefore
> > wouldn't good library
> > functions developed over the years do the same thing
> > for you and be closer
> > to how you like things done anyway?
> [snip]
>
> No, I don't think so.  I'm talking about making
> certain customizable rules that would be imbedded into
> the structure of the filepro file.  If someone
> attempts to break these rules - almost certainly it
> would be because they made a programming mistake.
> Therefore an error would point out the mistake to the
> programmer and not allow the corruption to take place.
>
> Yes, I could change the rules, but if I do, and
> corruption takes place, then shame on me!

>
> Library routines would not work for this because there
> would be nothing to enforce the use of these routines
> on the programmer.  And who is to say that an error
> would not get introduced into these routines anyway?

Nope, we disagree again. Sorry. Just too crazy to impose any kind of rules
on a system and structure that is by its design free from constraint. Your
very first example, for example, is completely foreign to me... (or you
stated it badly, perhaps) The idea that you can't have a parent record if
there is no child data... well, it's too strange for me. THAT is an
exception, not a norm, and pretty highly undesirable in my mind. So, would
be almost any other rule along these lines that you can define. Ane as for
library functions not working because nothing would enforce them, or alert
you.... well, the first library function you seem to need in your scenario
of rules could easily be one that enforces library functions. I don't think
the kinds of rules you are suggesting would help anyone. I think
understanding the program completely and how it is going to function is more
important and will server anyone better than enforced rules. Perhaps, some
of the things you want could be turned on and off with an environment
variable PFNOVICE=ON/OFF and such. That is the only way I would like to see
such implemented, if at all. I think they would be of extremely limited
value in any case. filePro is all about complete flexibility including the
possibility of making and constructing errors.

John