Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)

On Fri, 21 May 2004 18:05:20 +1000, thirdrock <iktaccounts at optusnet dot com dot au> wrote:

(snip stuff I agree with)

>> And this is exactly the reason why I'd never use XDb1 for serious work,
>> unless I encounter a problem area where the advantages of allowing
>> untyped
>> data outweigh the disadvantages.
>
>It is said that if all you have is a hammer, everything looks like a nail.
>There are a range of applications that require more flexibility than
>strongly typed languages provide. Often the language of choice used is
>Perl, and those who use it take the work seriously. But is a language a
>database, or a database a language? After all, SQL Server stores the data
>on disk as binary, whether or not it is integer or string, and it is the
>database engine that reads/writes from/to the disk that enforces the
>datatype. How is this different from using member functions/overloaded
>operators in an object database?

I'm afraid I don't see what point you're trying to make.

>> In 99.9% of all applications that store a person's age, comparisons have
>> to be made: who is younger than 45 years? Who is older, John, Mary or
>> Fido? How can XDb1 (or any other type-less database) anser the last
>> question is the user has provided the following input:
>>
>> over-the-hill isa age.
>> very-young isa age.
>> 7 isa age.
>> john is over-the-hill.
>> mary is very-young.
>> fido is 7.
>>
>> Most computers I have used will classify very-young as greater than
>> over-the-hill and will refuse to compare either of these to 7.
>
>Er, it's the software (or operating system) that does the
>classification/comparison, not the computer. You did mean software right?
>And that is not an indication of how computers work, only a limitation of
>the current software.

Yes, I did mean the software. Sorry for the sloppy choice of words.

(snip some more stuff I agree with)

>> is not defined for the character domain and would result in an error. I
>> know all this, and I can rely on it - if and only if the database ensures
>> that only numeric data will be accepted in the Age column and only
>> character data in the Color column.
>
>See my comment above about operator overloading. Also, your Colour could
>be an RGB value. Where are you then? In weakly typed languages/databases
>you can accept black and 0 and white and 16777216 as Colours.

In a relational database, I can define Colour with a datatype that accepts RGB values instead of english names. If overloading of operators is added as a feature in the future, you could accept create a datatype colour that accepts both, that will overload the = operator to return true if 'red' is compared to 0xFF0000 and that will gladly accept the expression 'green' + 'orange' and return 'yellow' (green = 0x00FF00; orange = 0xFF5000; the result of adding (mixing) these colors is the bitwise or of these RGB values: 0xFFFF00, or yellow).

But I (the developer) have to do this. I'll have to write the code for the overloaded = and + operators. If I do that, I can extend the range of acceptable values for the "colour" domain to include all English color names, all 3-byte values from 0x000000 to 0xFFFFFF and all integers that are a decimal representation of one of those 3-byte values. After that, the end user will still be unable to enter 'banana' in the color field of his application screen and expect the software to know that (s)he means a slightly dark yellow.

Overloading gives the designer the possibility to create lots of extra possibilities for the user. But the user still can't use things that are not pre-defined by the designer. That's the point I was trying to make: XDb1's parser will gladly accept ages of 7, "over the top", "slightly older than I am" or even "I think therefore I am" without bothering to check if it has any overloaded operators that are able to do anything useful with that data.

Best, Hugo

-- 

(Remove _NO_ and _SPAM_ to get my e-mail address)