Assignments to uncast dummy fields (was Re: simple

[Tyler]

On Fri, Feb 15, 2008 at 12:18 PM, Kenneth Brody <kenbrody at bestweb.net> wrote:
> Quoting Tyler (Fri, 15 Feb 2008 11:50:29 -0700):
>  [...]
>
> > But...I am not assigning from a field or variable at all, nor am I
>  > performing any mathematical operation.  I am assigning 'r' from
>  > FIELDVAL.  Does this mean that FIELDVAL also does a silent casting of
>  > the variable based on the edit of the FIELDVAL field being referenced?
>
>  No "silent casting" is involved.  It returns the value of the referenced
>  field, including the field's length and type.  Are you saying that if
>  FIELDVAL() references a date field, it shouldn't return a date?
>
>
>  >  I would have thought the return value of a function would not have an
>  > explicit type.
>
>  Are you saying that ADDMONTH() shouldn't return a date?  Or that SQRT()
>  shouldn't return a number?

Suppose it depends on your viewpoint.  ADDMONTH and SQRT both take
specific datatypes.  FIELDVAL, on the other hand, does not.  So no,
*I* would not expect it to cast the return value to a specific type,
especially as that action would seem to be performing operations that
FIELDEDIT already does.  The way I think, I would have called
FIELDEDIT to explicitly cast if I wanted to conserve data type.
Returning a value of the same type as the FIELDVAL argument makes
sense, just not what I was expecting - I would have thought it would
be *, or failing that that r eq "Y" would cast to the string literal
since r has no explicitly defined type and the string literal does.
I'm also used to Javascript and PHP, would have cast r to a string
literal, not the string literal to the more restrictive numeric type.

Tyler