This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Table Request: Accident-Occupant-Effect
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Elijah Meeks <elijahmeeks at yahoo dot com>
- Cc: xconq7 at sources dot redhat dot com
- Date: Thu, 23 Sep 2004 13:59:18 -0400 (EDT)
- Subject: Re: Table Request: Accident-Occupant-Effect
On Thu, 23 Sep 2004, Elijah Meeks wrote:
> (unit college-student (auto-upgrade-to dropout)
> (auto-upgrade-to wageslave) (auto-upgrade-to
> engineer))
The way Xconq parses things is such that the final value of the
'auto-upgrade-to' property would be 'engineer', as the other
previously assigned values would be clobbered.
I did consider making 'auto-upgrade-to' a table rather than an
unit property when I was first implementing that stuff. But, I
opted for a property so that there would be no ambiguities. If it
was a table, then there would be the possibility of multiple
auto-upgrade paths, and if certain material and size conditions
were fulfilled simultaneously, then how would the code be able to
tell which upgrade path to take? Since the auto-upgrade code is
kernel-level, it cannot (should not) make subjective decisions,
and so I thought it better to restrict auto-upgrade paths to be
completely predetermined.
> Though the example's meant to be funny (dropout is
> probably a wreck-type),
:-)
> Sure, sounds great, but before you leave...
Uh oh. At least your message didn't end in "and, and, and...".
Eric