Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!sdd.hp.com!usc!jarthur!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.sys.amiga.tech Subject: Re: REXX command standards Message-ID: Date: 21 Nov 90 18:53:38 GMT References: <1990Nov14.033931.12883@evax.arl.utexas.edu> <1990Nov17.151516.14252@sisd.kodak.com> >>>> On 19 Nov 90 19:57:07 GMT, mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) said: Mike> In article Mike> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: David> Perhaps an alternative suggestion to an AREXX command standard would David> be a single command by which AREXX could ask the program in question David> what its command equivalents for the AREXX standard would be. The David> result of such a command would be a list that's indexed by the standard David> commands. Scripts desiring to be standard would work indirectly off David> this list whereas people not up to standardization yet would use the David> program's internal commands directly (because those are the one's they David> would most like learn first). Mike> Remember, commands are the _easy_ half of doing an ARexx design for an Mike> application. You have to decide what objects you're going to let the Mike> user manipulate, and how those objects are going to be represented to Mike> the Rexx script. After all, it's tweaking the text in the editor that's Mike> what makes Rexx scripts entertaining. Or tweaking the drawing in the CAD program. Or tweaking the painting in the paint program. Or tweaking the animation in the ray-tracing program. Point being, sounds like there could be one h*** of a lot of objects to talk about in an AREXX standard if you start talking at too high or too complex a level. True, its an easy starting place, but all these programs have one thing in common -- they work with commands (in the AREXX context). Attempting to build a standard that incorporates all the possibilities of even just one of these types of programs would effectively make all programs that incorporates these standards the same, wouldn't it? So, wouldn't that tend to reduce distinguishing features between programs making for less incentive to develop new programs of a particular type? (the first one there is the standard?) Mike> Of course, if part of the command interface is that "macros can be Mike> invoked as commands", mg will never support it well. Yet another problem with building a standard that's too high level (standard *commands* equating to *many* program internal manipulations)? -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"