From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3425 invoked by alias); 23 Sep 2004 17:59:23 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 3418 invoked from network); 23 Sep 2004 17:59:22 -0000 Received: from unknown (HELO ob2.cmich.edu) (141.209.20.21) by sourceware.org with SMTP; 23 Sep 2004 17:59:22 -0000 Received: from egate1.central.cmich.local ([141.209.15.85]) by ob2.cmich.edu (8.12.10/8.12.10) with ESMTP id i8NHqx41025875; Thu, 23 Sep 2004 13:52:59 -0400 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Sep 2004 13:59:20 -0400 Received: from localhost (localhost [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 4CE9870023; Thu, 23 Sep 2004 13:59:18 -0400 (EDT) Date: Thu, 23 Sep 2004 18:23:00 -0000 From: Eric McDonald To: Elijah Meeks Cc: xconq7@sources.redhat.com Subject: Re: Table Request: Accident-Occupant-Effect In-Reply-To: <20040923150900.81622.qmail@web13121.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 23 Sep 2004 17:59:20.0018 (UTC) FILETIME=[0CCE0B20:01C4A197] X-CanItPRO-Stream: default X-Spam-Score: 0.5 () SUBJ_HAS_UNIQ_ID X-Bayes-Prob: 0.0001 X-Scanned-By: CanIt (www . canit . ca) X-SW-Source: 2004/txt/msg01232.txt.bz2 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