Path: utzoo!mnetor!uunet!husc6!rutgers!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!well!shf
From: shf@well.UUCP (Stuart H. Ferguson)
Newsgroups: comp.sys.amiga
Subject: Re: Workbench and object-oriented programming (was Re: Iconification)
Message-ID: <4957@well.UUCP>
Date: 11 Jan 88 12:10:59 GMT
References: <1076@sugar.UUCP> <2826@cbmvax.UUCP> <1103@sugar.UUCP> <4883@well.UUCP> <1355@sugar.UUCP>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 72


In article <something> Peter da Silva writes:
|In article <4883@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes:
|> |> What you really want to do is write a tool called "print" that looks up
|> |> "PRINTER" in the ToolTypes array and fires off the named program when
|> |> you shift-double-click it. Then we want to beat C= into implementing the
|> |> drop-an-icon-onto-a-tool method of firing off programs.
|> 
|> Hmmm.  The problem with the "ToolTypes" method is having a standard way of
|> doing "interprocess communication."  Certainly every word processor has a
|> "Print"-like menu item or items, but how many have a way to receive a
|> "print" MESSAGE?
|
|You're getting a little complex, here.
|
|The basic object that the workbench operates on is NOT the message. The basic
|object is the file (executable or otherwise).

Granted.

|If this takes off, you can convince EA and cohorts to start providing a set
|of small programs with all their programs:
|
|        PRINTER=Dpaint:Printer
|        VIEWER=Dpaint:Viewer
|        EDITOR=Dpaint:dPaint

Yeah, given the existing Workbench, this seems like the only way to
implement this sort of thing.  Each object -- in this case a DiskObject --
knows how to do something to itself (i.e. print, view or edit itself) by
being provided with a pointer to its "method."  The "method" varies
depending on the type of DiskObject.

Sounds like there might be some overhead in redundant code in alot of the
"small programs."  A super-wiz-bang desktop publishing program, for
example, would have a lot of modules that would have to be included in each
of the viewer, printer and editor programs.  The editor would have to load
files, format them, print them (would you really want to start a separate
program just to print your file?) and display them (it's WYSIWYG, isn't
it? :-).  The printer would have to load, format and print files.  The
viewer would have to load, format and display files.

|As an added bonus it's MUCH quicker to load a specialised tool than to load
|dPaint and send a PRINT;filename message....

Not to mention hunting for your key disk :-).  Although having several
programs that do simalar things could take up a lot of disk space.  (It's
the old trade-off, size vs. speed).  I admit, though, the difference between
dPaint and uShow makes the small extra disk space pay off mightily in speed.
Also, for data files without the advantage of an IFF standard, the versions
of the different tools could be a source of dificulties.  Suppose you had
version 3 of the editor but version 2 of the viewer?

| ... ALSO, my browser program (a version
|of Workbench for programmers who don't care much about icons) will allow you
|to set up a TOOLS menu item ...

Sounds like a good idea.  I would suggest you make it possible to provide
paths for searching for tools rather than having to specify "c:uShow".

|When you get your printer tool set up, you can then add:
|        Print;Workbench;sys:PRINTER

This is the kind of simple expandability I would like for the standard
Workbench!  I like your thinking.  If only the Workbench designers had been
thinking that way.

|-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter

-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC		(shf@Solar.Stanford.EDU)