Re: domains aren't subtypes, right?

"Paul G. Brown" <paul_geoffrey_brown_at_yahoo.com> wrote in message news:57da7b56.0306030801.3c3aad8e_at_posting.google.com...
> "Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message
news:<v2UAa.11$0m2.38_at_news.oracle.com>...
> > In short: having more datatypes is not an answer. Having better
datatypes is
> > the answer.
>
> Can't resist this . . . .
>
> What convinces you that you (or anyone) has a unique pipeline to truth
and
> beauty that makes you a superior judge of when one data type design is
'better'
> than another?
>
> In support of your conclusion that Oracle's 'one size fits all' date
type is
> 'better', you have presented an aesthetic argument based on a single
use-case.
> For every example you can come up with where it makes sense to use a
> DATETIME/TIMESTAMP type to represent both date & time, I can think of
one
> where it is awkward (not to mention the confusion it creates in systems
where
> meta-data is used to help users navigate around the schema and
understand
> what it represents).
>
> Applications vary in their requirements. That's why modern programming
> languages developed abstract types/modules/object classes/components. My
> experience in software engineering (and life) is that it is too diverse
to
> be standardized, and that tools which can be modified to suit reality
are
> more useful tools than those designed by people who tell you what you
need.

Ironically, my expression was coherent with your idea of favoring complex advanced datatypes instead of many primitive ones (one per each complex type component)!

From that physical perspective (which is BTW the most fundamental and consistent view of the world) time is linear, homogenous, continuous, etc. It doesn't contain leap years, missing year 0, summer time switch, and other nonsence. We just measure the time in homogenous units from some reference point. There is nothing complicated about that.

Now, we want to be "consistent" with the past, and are unwilling to change those ugly artifacts, like the summer time switch. Therefore, every programmer on the planet, have to insert extra "if" statement into his calendar program. It is actually fine if the programmer does it so that the end user wouldn't have to, but in reality I have to reset dozen of old-fashioned non-programmable clocks twice a year.

Generally, there are superior and inferior units. For example, Metric System is superior to the Old Imperial System (called "standard" in the US;-). Is my judgement aesthetical? Mostly, because arguments riduculing complexity of primitive culture artifacts never scientifically based. Received on Tue Jun 03 2003 - 19:52:12 CEST