You can't do that

[Jeff Harrison]

--- John Esak <john at valar.com> wrote:
[Jeff Harrison Wrote]

> > 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...

I don't see any loss of flexibility.  You don't loose
anything in my scenario.  You would still be able to
do it the way it is done now too.  However you would
have this added flexibility.

The whole idea of a function is to have 1 return
value.  That way you could do something like the
following:

If:  xx le call("SquareRoot",yy)
Then:  msgbox("xx is less")

For more flexibility you can even use the arguments to
return values.

As far as keeping track of variables is concerned, I
think this would help.  I guess I will agree to
disagree with you here.  If you are creating a new
processing table and want to use a long variable name
such as "QYTUSED", how do you know if it has been used
already or not in another table that is being called? 
Or for that matter it may be in auto or input
processing.  If used, do you remember if it was
defined as global or external?  This is just one
variable.  You may of course have thousands, and this
would in my opinion be a job to keep straight -
especially if you have a multiple programmer shop.

This "new" scenario (new in quotes, because it has
been used for years in other languages such as C)
would help to keep your variables local to just the
table that is being called, and the values would come
back without danger of interfering with anything else
down the line.

> 
> > > > 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.

I don't think its crazy to impose rules for data
integrity.  These would be rules that I (the
programmer) would define.  If I later make a mistake
or another programmer does something to potentially
corrupt the data then this would be a great fail-safe.

As for my parent/child example, you re-stated it
incorrectly.  My (example) rule would be that you
cannot have child data without a parent.  You may find
this limiting - you may want to create the child data
first - but I think it is a small price to pay for
data integrity.

Also, as I mentioned, if a field should always have a
value this rule could be added to the table.  Then
when a write occurrs - filepro will not allow the
write unless the field is filled in.  These are just
two examples - I'm sure I could think of a whole lot
more.

I have seen data corruption and it is not pretty.  I
can understand that it may not be a problem for you
because you are a small shop, but this is not always
the case out there.  Also, I have often come across
situations where there have been multiple programmers
involved over a span of several years.  In these
situations I have found that data corruption is not
unusual.  

Filepro gives programmers too much credit IMO.  Too
much opportunity to screw up.  I'm suggesting that we
have something in place to prevent some of that.  The
only way that it would be limiting would be in the way
that we define.

...[and 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
> 

I don't understand what you are saying about library
routines and how they would enforce anything.  It
seems to me to be the chicken/egg scenario.  Say I
wite a real slick routine that enforces certain rules
- I call this processing table "lib/rules".  It is a
great routine.  I can see it right there on my hard
drive.  Now programmer 2 comes along and violates all
of those rules.  Oops, he didn't know about
"lib/rules"!

Jeff Harrison
jeffaharrison at yahoo.com

Author of JHExport and JHImport.  The easiest and
fastest ways to generate code for filePro exports and
imports.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com