🚀 go-pugleaf

>>>>> On 19 Nov 90 19:57:07 GMT, mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) said:

Mike> In article <CIMSHOP!DAVIDM.90Nov18152138@uunet.UU.NET>
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!"