Re: The BOOLEAN data type

From: Bob Badour <bbadour_at_golden.net>
Date: Thu, 10 Apr 2003 00:00:48 -0400
Message-ID: <sB6la.226$II2.20040765_at_mantis.golden.net>


"Paul" <paul_at_not.a.chance.ie> wrote in message news:MPG.18fec3b2c1a95aea9896c2_at_news1.eircom.net...
>
> bbadour_at_golden.net says...
>
> > > And there would be precious few apps that would need this!
>
> > So says you.
>
> And I still say it.
>
> > I have worked on applications for genetic counsellors, and they
> > might disagree.
>
> And that's fine.
>
> Can you *_not see_* that this kind of discussion is *_completely_*
> irrelevant for 99.9% (probably more) of applications?

All sample designs are completely irrelevant for 99.9999% of applications. The requirements will drive the design, and all applications have different requirements. Can you not see that?

> I think that I've already mentioned that I have a degree and Masters in
> genetics (and a very good friend in the Pasteur who studies nothing but
> sex-determination in humans), so I've probably forgotten more than most
> will ever know about genetics and intersexes and defects.

So? When did either true or false become male or female? For a guy with a Masters degree, some of the simplest points seem to sail clear over your head.

> > With ever more rapid advances in medicine and in
> > understanding human genetics, this sort of thing will only get more
> > important.
>
>
> Not for membership apps for Youth Hostel organisations or 99.99% of
> apps.

The requirements for Youth Hostel organisations are irrelevant for at least 99.9999% of all applications. What makes you think youth hostel dormitory assignment is so special that the general principles governing domain choice no longer apply to it?

> > Someday, someone might have to design a data model for an application
that
> > accounts for chimeras as well. While rare, such people do exist.
>
> Indeed - for genetic counsellors and medics and researchers perhaps -
> for Joe Sixpack - not a chance.

And for 99.9999% of application developers, the requirements of youth hostel dormitory assignment are completely irrelevent. This newsgroup is not comp.databases.hostels.youth

You still have not explained when or how true became either male or female. Nor have you explained what conjunction or implication mean for gender.

You asked what is wrong with using a boolean for gender. I explained that directly and succinctly. I should hope a Master's graduate could comprehend such simple points.

> > > But would call themselves "male" and look "reasonably" male and have
> > > something resembling a willy and use the men's room and be able to
sleep
> > > in the male dorm - even if they were lacking in the willy dept.,
there's
> > > nothing obliging people to strip off in dorms.
>
> > You can make up whatever requirements you want to try to justify your
bad
> > design suggestion. Neither male nor female is true and HasYChromosome
> > necessarily help you to assign dormitories.
>
> This is becoming fruitless - do you or do you not accept that this sort
> of arcane discussion about genetic abnormalities has *_IN EFFECT_* no
> relevance *_WHATSOEVER_* for the vast majority of people either
> designing or using applications?

Do you accept that the requirements for a youth hostel application with exactly two dormitories have no effect or relevance whatsoever for the vast majority of people either designing or using applications? I have given several reasons why a boolean for gender does not make any sense for any application--including youth hostel dormitory assignment.

You have not addressed any of the reasons I gave--not one. When did false become male or female? What meaning does implication have for gender? How does a boolean gender help when the hostel expands its dormitories with additional choices? What are the values for gender? They are not the same as the values for boolean. What are the operations for gender? They are not the same as the operations for boolean. In short, gender <> boolean.

Those are all reasons why boolean is a bad choice for gender, which is the original question you asked. If you won't accept the correct answer, what was the point in asking?

> > I would suggest a Dormitory domain and an AssignedDormitory attribute.
That
> > way, you could have as many dormitories as you need and assign them any
> > number of ways.
>
> There are male and female dorms - no more, no less.

With all due respect, this newsgroup is not comp.databases.hostel.youth.dormitories.two

You asked why boolean is a poor choice for gender. I answered that directly and succinctly. The values for gender are not the same as the values for boolean, and the operations for gender are not the same as the operations for boolean. If you want a good domain choice for gender, choose a domain whose values include the values for gender and whose operations are the operations that apply to gender.

If you don't want answers to your questions, don't ask them.

> Children under 7 may be considered either for the purposes of sleeping
> (if they prefer their mothers or whatever) - which is perhaps a far more
> realistic and real world scenario than the mutants you are talking
> about!

Your one application does not define the universe of discourse in a theory newsgroup. Sorry.

> However, the children's maleness or femaleness is boolean!

If that is the case, please explain what the implication operation means for gender. When and how did true become male or female?

> > > I am writing an application for the real world, not the far out
> > > scenarios you are describing.
>
> > In your real-world application, neither male nor female is true and
> > HasYChromosome will not suffice for assigning dormitories.
>
> It is and it will.

When and how did true become male or female? How does HasYChromosome help for dormitory assignment when some females may have Y chromosomes and some males may not?

> If I wish to debate philosophy and/or go down the
> road of bringing up bizarre sideshow cases for what is a bread and
> butter simple app - then fine.

I wish to discuss theory--as in comp.databases.theory

Values and operations define domains. The values for gender and the values for boolean are different. The operations for gender and the operations for boolean are different. Gender and boolean are different. The differences make boolean an inappropriate choice for gender.

You asked, and I answered. The correct answer doesn't change just because it wasn't the answer you expected. Sheesh!

> I can see the face of the manager of the organisation for which I'm
> writing the app - "Well here Mr Sixpack, you have gender - as you can
> see it has 15 records (what with intersexes and chimerae and
> whatnot!)"...
>
> It just ain't gonna happen.

Why would a domain have records? A domain has values and operations. The boolean domain has a value called true, a value called false and no value called male. The boolean domain has an operation called implication, among other operations, and gender has no such operation.

Your application may at present only care about two gender values: male and female. The fact that boolean also has two values does not make true male and does not make boolean gender.

You asked why boolean is a poor design choice for gender, and I answered: different values and different operations. I cannot help it if you are not capable to comprehend or not willing to accept the answer. The correct answer doesn't change to suit your incapacity or your inflexibility.

> > In any case, I
> > was addressing your sweeping generality regarding meaning in the real
world
> > and not the specific requirements of your application, which are of
course
> > just as meaningless to most of the real world.
>
> You were getting bogged down in arcana.

I am not the one who is fixated on a single application, who cannot comprehend that complete difference in the defining attributes of domains makes domains different, and who thinks his application has theoretical importance beyond all other applications. You refuse to look at anything but arcana.

> > > If one wanders in off the street to join a Youth Hostel Organisation,
I
> > > doubt if anyone's going to ask me about any history of sexual abuse.
>
> > In that case, it might be safer to arrange sleeping arrangements some
other
> > way.
>
> What arrangements? Do you know anywhere (hotel, hostel, whatever) that
> would enquire as to its customers criminal sexual history - "Excuse me
> sir, have you a conviction for buggering young boys?"... you're going
> down the silly trail again!

Get a sense of humour. Buy one if you have to.

> > > > What does the implication function mean for gender?
>
> > > Eh?
>
> > Implication has meaning as a binary operation on boolean values. What
> > meaning does it have for gender if gender is a boolean value?
>
> I may be stupid, but I still don't understand what you mean here.

You contend that boolean is the appropriate domain for gender. A domain defines a set of values and the operations on those values. Boolean does not have male nor female in its set of values, and boolean defines operations (implication among them) that are totally inappropriate for gender.

You asked why boolean is an inappropriate choice for the domain for gender. Boolean defines the wrong set of values for gender and the wrong operations for gender. Since values and operations are the defining characteristics of domains, it would seem pretty clear to me that different values and different operations make boolean a poor choice for gender.

> > > Indeed, which is why I asked in the first place.
>
> > That wasn't what you asked in the first place--at least not the first
place
> > I saw. In the first place, you asked why boolean is an inappropriate
domain
> > for gender. You don't seem particularly willing to accept the answer to
the
> > question, though.
>
> I am perfectly willing so to do!

When do you intend to demonstrate this alleged willingness?

> I am disputing the utility of the
> justification for having anything more than a Boolean in any more than
> 0.001% of applications.

You dispute the need for any other type than boolean for 99.999% of applications?!? That's an extraordinary statement. You are contending that only 0.001% of applications have any use for character strings, numbers, colours, dates, times, etc. etc. etc. Received on Thu Apr 10 2003 - 06:00:48 CEST

Original text of this message