From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26645 invoked by alias); 11 Aug 2004 08:25:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26588 invoked from network); 11 Aug 2004 08:25:13 -0000 Received: from unknown (216.254.0.205) by sourceware.org with QMTP; 11 Aug 2004 08:25:13 -0000 Received: (qmail 31098 invoked from network); 11 Aug 2004 08:25:13 -0000 Received: from dsl081-242-080.sfo1.dsl.speakeasy.net (HELO [192.168.1.112]) (gdb001@[64.81.242.80]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with RC4-SHA encrypted SMTP for ; 11 Aug 2004 08:25:13 -0000 In-Reply-To: <20040811062809.196A34D4015@stray.canids> References: <5956F1E2-EB0D-11D8-9949-000A9569836A@apple.com> <8A54B4DA-EB30-11D8-9650-000A95DA1012@speakeasy.net> <20040811062809.196A34D4015@stray.canids> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Reply-To: gdb@sources.redhat.com From: Chris Friesen Subject: Re: GDB/XMI (XML Machine Interface) Date: Wed, 11 Aug 2004 08:25:00 -0000 To: gdb@sources.redhat.com X-SW-Source: 2004-08/txt/msg00166.txt.bz2 The code is an implementation that doesn't convey the objectives or intent. Is that behavior a bug or feature in the code? It can be difficult to tell if there is not a description of what the code is supposed to do. The specification can set the objectives and intentions that define the bounds of the implementation, act as guidance for testing and other development. This is easier to do in writing than with code. A specification can be as specific or ambiguous as the writer desires, it's a balancing act depending on your needs. Happy spec writing, -ChrisF On Aug 10, 2004, at 11:28 PM, Felix Lee wrote: > Chris Friesen : >> (The code is *not* the spec people...) > > code is usually less ambiguous than specs. it's not clear to me > that there's much point in making a spec for something that's > likely to have only one implementation that will always have > public source code. well, isolating it as a spec should make > some things easier, like the versioning issue. >