From owner-freebsd-current Wed Jun 19 12:25:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA10854 for current-outgoing; Wed, 19 Jun 1996 12:25:03 -0700 (PDT) Received: from watson.grauel.com (watson.grauel.com [199.233.104.36]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA10847 for ; Wed, 19 Jun 1996 12:25:01 -0700 (PDT) Received: from sparcmill.grauel.com (sparcmill.grauel.com [199.233.104.34]) by watson.grauel.com (8.7.5/8.7.3) with SMTP id OAA04212; Wed, 19 Jun 1996 14:33:00 -0500 (EST) Received: by sparcmill.grauel.com (SMI-8.6/SMI-SVR4) id OAA26670; Wed, 19 Jun 1996 14:24:20 -0500 Date: Wed, 19 Jun 1996 14:24:20 -0500 From: rjk@sparcmill.grauel.com (Richard J Kuhns) Message-Id: <199606191924.OAA26670@sparcmill.grauel.com> To: Terry Lambert Cc: current@FreeBSD.org Subject: Re: tcl -- what's going on here. In-Reply-To: <199606191840.LAA13530@phaeton.artisoft.com> References: <199606191521.KAA24028@sparcmill.grauel.com> <199606191840.LAA13530@phaeton.artisoft.com> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > > > This is all really nasty, there's no compelling reason for tcl to be > > > brought into the main tree, > > > > tcl is on every system I administer; I use it extensively. Linked with the > > appropriate libraries, it can greatly speed the development of tools using > > those libraries. IMHO, bringing tcl into the main tree would encourage the > > growth and development of FreeBSD. > > I have to say that the issue is real, but I also do not agree with the > need for TCL. > > TCL uses a tool encapsulation model, requiring TCL changes to match > corresponding tool changes when they occur to the embedded tool. This > is grossly inefficient and unmodular. > Either I'm having trouble parsing this paragraph, or you're thinking about using tcl differently than I am. Assume a library that provides a low-level service -- libdisk.a, for example. For the tcl interface, I'd write some C code that defines a tcl object (maybe called a `Disk') that responds to some more-or-less generic set of messages ("format", "describe_boot_block", etc). A properly designed (buzz-word alert!) object-oriented interface would present a consistent view of the higher-level Disk tool to any tcl code, insulating the tcl code from changes to the lower-level libdisk tool. ... > I believe "throw away code" should not be encouraged in > the source tree. > I fully agree; just don't throw out the baby (easier/faster development) with the bathwater. -- Rich Kuhns rjk@grauel.com PO Box 6249 Tel: (317)477-6000 x319 100 Sawmill Road Lafayette, IN 47903