From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200106182131.WAA02827@localhost.localdomain> To: 9fans@cse.psu.edu Subject: Re: [9fans] source code as data not text In-Reply-To: Message from David Gordon Hogan of "Mon, 18 Jun 2001 14:48:35 EDT." <20010618184843.68F9819A00@mail.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Steve Kilbane Date: Mon, 18 Jun 2001 22:31:03 +0100 Topicbox-Message-UUID: bd20b2de-eac9-11e9-9e20-41e7f4b1d025 dhog: > What if the code were accessed through a file system interface > which is cross-platform? As has been pointed out, how something is stored isn't that relevant here; the issue is *what*, and the principle issue is whether your program is stored as ascii source, or as some other representation (that presumably adds additional structuring, else why bother?) If you're storing an ascii file, then whether you store it in a cvs-like system, an RDBMS or something entirely different isn't that much more important than whether it's stored in a file system that's on a local disk or a networked one: you may need to use special means to retrieve it, but that's your call. If it's plain ascii, and you've got an editor that can show pretty colours, then fine. I'm happy for you, and it doesn't mean that anything special has to be done to the file that'll stop it working on any other editor. If your source file is saved as something that represents additional structure, then I'd suggest you're using the wrong terminology: that's an object file, that's been compiled into another representation. From here on in, you need a special set of tools to interpret and manipulate the contents of that file. Regardless of the means by which you retrieved the file, it's effectively a black box to most of the surrounding system. As I've said for many a year, "standardise on file formats and protocols, and the applications take care of themselves." steve