Date: Wed, 19 Jun 1996 15:17:02 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rjk@sparcmill.grauel.com (Richard J Kuhns) Cc: terry@lambert.org, current@FreeBSD.org Subject: Re: tcl -- what's going on here. Message-ID: <199606192217.PAA14306@phaeton.artisoft.com> In-Reply-To: <199606191924.OAA26670@sparcmill.grauel.com> from "Richard J Kuhns" at Jun 19, 96 02:24:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. > > ... And then you build a script, which is throw away code, which encapsulates the order of operation for these objects and their preferred interactions in order to define a system interface. My problem is with the enabling act of building the script to be sufficient as providing the sole system interface for a given set of objects. The "adduser" example is a good case in point. Another would be the partition management and disklabel management (which if we design honestly, are instances of the same operation with gratuitiously different interfaces... an attempt to make it hard for the users? No: an expediency permitted [*encouraged*] by the software that controls their interactions.). > > 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. I agree with not throwing out the baby... which is why you put it in ports, so people can use it for rapid prototyping or site-specific administrative tasks, with no danger of those scripts creeping into the source tree. My problem with it being a system component is that it is acceptable to build other system components from it if it is guaranteed to exist. Look at the mess we have with the /etc/rc* files not being data driven; it's wrong to think that hacking an rc file to set system data can be an acceptable way of solving a configuration-change problem. The main obstacle to updating the system is the data is embedded in scripting in the /etc directory. The main obstacle to templating diskless/dataless systems from a single update template ("just reboot after the server is updated") is data embedded in scripting in the "/etc" directory imported by the client. The main obstacle to changing system policy templates for use in the creation of new users, given a TCL or PERL script-based "adduser", would be the policy data embedded in the TCL/PERL script. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606192217.PAA14306>