Re: Write my own library/extension or create package that calls external program?
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.lang.tcl archive

Re: Write my own library/extension or create package that calls external program?

From: Adrian Ho <tcl@03s.net>
Date: Sun Mar 05 2006 - 11:24:49 CET

On 2006-03-05, Kevin Walzer <sw@wordtech-software.com> wrote:
> I've been making (glacial) progress at learning C so I can implement
> some extensions that expose parts of the Mac OS X API not currently
> wrapped by Tcl/Tk. However, I recently ran across a cool set of
> command-line utilities that do *exactly* what I want--they do things
> like get and set custom icons, convert them into formats readable by
> Tcl/Tk, etc.
>
> Is there any reason *not* to write a batch of Tcl procedures that wrap
> the functionality of these tools, and then bundle that as a Tcl package?
> (At the Tcl package level, the procedures would probably work by running
> a lot of exec functions out to the command-line tools.)

Well, you'll be dealing with osxutils lifecycle issues, e.g.:

* output format changes
* command-line syntax overhauls
* historical assumptions that no longer hold
* any other changes that would break your code

If it's for public consumption, and esp. in production code, you'd
have deployment issues. Do you include a fixed copy of osxutils in
your package, thereby trading off installer size for a more stable and
predictable environment?

How about osxutils' own dependencies? Do you include those too to
prevent major breakage during an unrelated (or so the user thinks)
upgrade or package removal?

How about the dependencies' own dependencies? Apply recursively.

And is any of the above even relevant to your use case? Are you even in
a position where you have to care about all of this?

> Is speed an issue?

Only the user of your package can answer that question -- if
s/he's creating a million aliases, for instance, I think the extra
process-spawning + other overhead of [exec] could *really* suck. You may
want to simply try the speed out for yourself on some practical tasks.

> Is this considered lousy application design?

Not really, at least not in my book. It's true that using the appropriate
APIs would be more elegant, but go with whatever works reliably and is
"fast enough" for the job. It's hard to feed the family with b0rkenware
or vaporware...

> Do others wrap the functions of command-line programs in Tcl procedures
> to provide a cleaner (though non-C-level) interface to them?

I don't see why not. I haven't needed to do that yet, but I wouldn't
rule it out...

- Adrian
Received on Sun Apr 30 02:23:42 2006