[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: ITLA
[Gnu-arch-users] Re: ITLA
Tue, 02 Mar 2004 15:04:28 +0100
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
Tom Lord <address@hidden> writes:
> > Of course, this is just low-level stuff, and would never shine thru up
> > to the "declarative level".
> The last paragraph is probably the most important.
> Keep in mind, too, that someone might want to write extensions that
> crawl over the set of commands -- perhaps to format a help message or
> perhaps to make some new kind of menu-driven interface. Keeping all
> the relevent data in the simplest format (e.g., s-exps following an
> extensible syntax over basic types) makes that easy.
If you have a brief glance at the codebase, you'll see that there is a
(itla ui) module. This currently is a crude wrapper around a single
<tla> instance, using the Guile REPL and GOOPS for user-interaction. I
just came up with this as a quick hack to have something to play
around with, not intending it as a permanent solution. So my question
is: do you feel comfortable with this design (a low-level interface,
using GOOPS, designed for maximum flexibility) and an eventual command
processor/UI built on top of that?
I think this seperation is warranted, to quote you:
| (define-command (init-tree version dir nested?)
| (help-message (category tree)
| (% tla init-tree -H))
| (parameters (version new-fq-version-name)
| (dir (extended existing-directory))
| (nested? (extended y-or-n)))
| (output plain-text)
| (run-tla "init-tree"
| (if dir (list "-D" dir))
| (if nested? (list "--nested"))
I think there might be concepts apparent in this code that don't
belong into the low level interface: new-fq-version-name, for instance
(if I understand correctly) will cause the user to be prompted for a
*new* version name. I would consider the knowledge about existing
versions not something to be located at the low level interface (but
easily extracted using it). Also, prompting, as indicated by y-or-n
doesn't belong there.
But, on the other hand, this separation turns up the issue of
duplication: Since you'd want access most TLA commands also through
the low-level interface, you'd define most commands in two places,
which is unfortunate.
> For example, since you have the basic idea of a command processor of
> the sort we're discussing, can you:
> (a) imagine an implementation
> (b) presume the implementation is built, has at least a CLI a
> front-end and maybe a GUI front end.
> (c) assume that lots of people have written code against this
> and then:
> (d) imagine implementing something like:
Looks and sounds interesting, this segusoland stuff.
> in a way that everybody's existing code "just works" with
> the new input method?
I hope you didn't mean for me now to come up with an implementation
plan (cough), but I'll try to keep that in the back of my mind.
Andreas Rottmann | address@hidden | address@hidden | address@hidden
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Say NO to Software Patents! -- http://petition.eurolinux.org/