From owner-cvs-all Thu Jan 3 16:20:19 2002 Delivered-To: cvs-all@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 5259637B41B; Thu, 3 Jan 2002 16:20:09 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id g040JxC77674; Thu, 3 Jan 2002 19:19:59 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Thu, 3 Jan 2002 19:19:58 -0500 To: Julian Elischer From: Garance A Drosihn Subject: Re: cvs commit: src/share/man/man3 queue.3 Cc: Matthew Dillon , Poul-Henning Kamp , Stephen McKay , John Baldwin , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Greg Lehey Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.1 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 3:04 PM -0800 1/3/02, Julian Elischer wrote: >On Thu, 3 Jan 2002, Garance A Drosihn wrote: > >> At 2:00 PM -0800 1/3/02, Julian Elischer wrote: >> In any case, we are not disagreeing with you just to irritate you, or >> because we don't understand what you are hoping to do. We just think >> you're breaking a useful abstraction of "queues" (generic queues, not > > tailq-specific queues), and that you should not do that. > >I DO understand the point of making them interchangable, but I think it's >a false goal. If we wanted to make them interchangable we'd just have >"QUEUE" and not 4 (was 5) different types. >It's enough to make one go and write one's own rather than using the >macros, really... It is very useful to have an idea of an abstract class, so to speak, and then "subclasses" of that class. It's just object-oriented programming via CPP macros... TAILQ_FOREACH and STAILQ_FOREACH are method-names for these subclasses of "GENERICQUEUE". Your position seems to be that "if we have a good enough man page for a class, then there is no need to subclass it". Okay... So maybe I did spend New Year's trying to learn ruby... >BTW a macro name for the FOREACH termination test would be >TAILQ_FOREACH_COMPLETED(&head, var) where &head would be completely >ignored in most implementations I think. I'm not sure that's quite the right name, but it is probably better than anything I have thought up so far... An earlier message talked about sample code of: LIST_FOREACH(p, head, field) if (test(p)) break; if (p == NULL) bar; else baz; If that's what we're trying to duplicate, your suggestion comes out to be something like: if (LIST_FOREACH_COMPLETED(p, head)) bar; /* ie, 'p == null' */ else baz(p); /* do something with the 'p' we exited with */ Or maybe something with the reverse-sense of that. if (LIST_FOREACH_EXITED_AT(p, head)) baz(p); /* do something with the 'p' we exited with */ else bar; /* ie, 'p == null' */ I'm just trying to come up with some alternate ideas, I don't know if that is any better. My inclination is for a test which is the reverse- sense of the test that you're suggesting, but _EXITED_AT might be getting a bit too long. I'd hate to be accused of talking too much :-) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message