Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!bu-cs!purdue!decwrl!sun!quintus!pds
From: pds@quintus.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: How 'Bout HyperCard!
Message-ID: <1002@sandino.quintus.UUCP>
Date: 20 May 88 22:08:34 GMT
References: <15372@uflorida.cis.ufl.EDU> <31411@linus.UUCP> <3768@cbmvax.UUCP> <2019@sugar.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 61
Posted: Fri May 20 18:08:34 1988

In article <2019@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes:
> In article <987@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes:
> > IFF data is self-identifying, but that really isn't enough.  In order
> > to use this approach, every program must include all the code for
> > dealing with all the kinds of data that they expect someone to try to
> > paste in.
> 
> So what's wrong with an "iff.library"?
> Also: 'every program must include all the code for dealing with all the
> kinds of data that they expect someone to try to paste in.' isn't quite
> true. They only need to deal with the kinds of data that people will try
> to paste in and that is useful to them.

Ah, but they should be able to deal with the new wiz-bang kind of pie
chart that hasn't been invented yet, too.  If the code that knows how
to manipulate an object is not required to be part of the program that
has to do the manipulation, then 

	(1) It doesn't have to be considered by the application writer.
	(2) An old program can manipulate new kinds of objects invented
	    since the program was published.
	(3) The code to manipulate all these objects is not stored in
	    every single application that has to deal with them, but
	    once in a library (that's what libraries are for, after
	    all).
	(4) The code is not present in memory if it is not needed
	    (i.e., there are no instances of it present).  Why have the
	    code for handling bar charts in memory if you don't HAVE
	    any bar charts?
	(5) through the magic of shared libraries, the code for
	    manipulating a particular object is only present in memory
	    once, no matter how many programs (processes) are
	    manipulating that kind of object.

> Whether or not it can read them,
> a text editor isn't going to be able to do anything useful with SMUS files
> or ANIMs (for example).

But a hypertext system SHOULD.  The point is that this approach makes it
possible to deliver small components.  By this I don't mean, say, an
individual bar chart, but a new KIND of chart.  IFF lets me deliver
individual bar charts.  It makes it possible for me to invent a new kind
of chart, but only as part of a program I'm delivering.  If someone
wants to be able to incorporate this kind of chart into a document, they
have to convince a purveyor of word processors to do the work.  An
object-oriented system would allow the encapsulation of the methods for
handling this type of chart in a single place, so that any program could
use it without having to know about it ahead of time, other than to know
the names of the methods it must support.

Another bonus of this is that existing objects can be replaced.  For
example, if I don't like the way bar chars look or behave, I can write
my own bar chart object to replace the old one.  A better example might
be scrolling windows:  if I decide that I want the left mouse button to
make the window scroll up the right to scroll down, I could modify the
scrolling window class.  Thus I've changed the way every program that
uses the scrolling window object behaves.
-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds