Assignments to uncast dummy fields (was Re: simple

[Brian K. White]

----- Original Message ----- 
From: "Tyler" <tyler.style at gmail.com>
To: "Kenneth Brody" <kenbrody at bestweb.net>
Cc: <filepro-list at lists.celestial.com>
Sent: Friday, February 15, 2008 2:44 PM
Subject: Re: Assignments to uncast dummy fields (was Re: simple


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


You're saying it's more sane to have metadata disappear unless you're careful to avoid it, instead of having to go out of your way to discard/override/modify metadata?

I disagree.

analogy analogy... a piece of paper says "2 oranges", call that the data in a defined field.
You are blind and your good buddy Joe Fieldval reads the paper aloud and says "two".

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

Yeah filePro definitely does have some quirks that are "not what I was expecting".

One thing to remember about expectations; You can't be better than average without being different than average. While the principle of least surprise is valid, I think the value of exceeding expectations outweighs the value of falling within expectations.

One can think of these differences from everyone else as either bizarre incompatiblities, superior features, or merely as application-driven or audience-driven specializations. I think it's mostly the last. Some of the quirks might not be better than the norm in general, but they are usually more tuned to most of filepro's audience and their types of tasks, and so they're better for them and for fp.

One classic example I went bonkers over when I first hit it, but agreed with once someone pointed out the ramifications that hadn't occured to me at first, was If: "1" eq "123" --> True
As per usual, in that case, the fault for the initial grief, if any, lay with me for not realizing those ramifications, not with fp for being more useful (in that one little way if not others) than other generic languages.

I don't happen to think that preserving a data's type wherever possible by default falls into this catagory though. I may be naive and wrong, or merely spoiled by fp, but what I expect is sanity by default and having to go out of ones way to break things. So in this case fp does what I expect.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!