[DB-SIG] dBase III and VFP tables

[Carl Karsten]

On Tue, Jul 19, 2011 at 8:41 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> Carl Karsten wrote:
>>
>> for those of you that are wondering about this nuttyness:  VFP is a
>> dBase derivative.  In there early days, there was no support for Null.
>>  But a side effect of adding a row but not storing values to it was
>> empty fields.  the best example is a date.  dates are stored on disk
>> as a string "YYYYMMDD"  and in the case of an empty date: "        ".
>> Same with numbers: N(6,2) would store 3.14 as "  3.14" and an empty
>> number was "      ".  Then they added Null support, but instead of
>> using this empty state, they added a flag, so now a field could be
>> Null, Blank or have a value.  which was a mistake, but here we are.
>
> Thanks for the clarification, Carl.
>
>> For D/T I am not sure you have a choice.  What value would you return
>> for an empty date other than Null?
>
> As it happens, I created custom Date, Time, and DateTime objects so that I
> could deal with the empty values.  I probably just should have returned None
> from the beginning, but did I mention that this is the project I have
> learned Python with?

Impressive!

>
> Now that I have them, I'm thinking of keeping and continuing to use them for
> the empty case... but not sure if that's a great idea, hence my question
> here.

I would say supporting Empty is a backwards compatibility thing: If
there was code that relied on it, then you should continue to support
it.

When I was using VFP I never needed both values.

My guess is the custom objects will cause problems and solve none.


>
>> for Logical I would return False.  Mainly because I am pretty sure
>> that because in VFP an empty logical will be treated as .f. anywhere a
>> logical is evaluated.
>
> The test I tried before I left work seems to confirm that (it was just
> printing).



-- 
Carl K