🚀 go-pugleaf

In article <6644@apple.UUCP>, lsr@apple.UUCP (Larry Rosenstein) writes:
> In article <951@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
> >
> >I'll have to disagree with that. The MAC toolbox violates a fundamental law
> >of O/S design: FIRST, make the easy things easy. You should be able to
> >operate like this (enter fantasy mode):
> >
> >	Window = OpenWindow(x0, y0, x1, y1, xmax, ymax, 0);
> >
> >This gives you a minimal window. It gives you a window of size (x1-x0) by
> 
> You are absolutely right that the Macintosh does not provide BUILT-IN higher
> level calls such as this.  

It should. Even better, for some purposes, is

	fp = fopen("CON:0/0/320/200/Console Window", "r+");

> One problem you run into is what if you don't want a window with 1 "pane";
> you want a window with 2 panes each with its own pair of scroll bars.

Open two windows. This is a flip answer, but for the most part this is a
perfectly acceptable way of doing things. It gives the user more flexibility,
too. I've seen painting programs on the Mac that to this that are wonderful.

> So
> you need the lower level calls as well as higher level calls which handle
> common cases.

Sure, but you shouldn't need the lower level calls until you're getting into
guru territory. The high level calls should do 99% of the job.

> This leads to the idea of software libraries, which provide the higher level
> calls.  There are a couple such libraries for the Macintosh...

How big is Mac App?

How many times is it going to be sitting on the disk or in memory taking up
room?

The typical "real" Mac application is at least 200K these days. 200K is a big
application on the Amiga. Part of this is because these libraries are part
of the system on the Amiga (and you can add your own shared libraries pretty
easily).

> That's where object-oriented programming starts helping.  When a program is
> structured using objects and methods, then it is possible to override 1
> particular method and inherit the rest unchanged.  With a library of
> routines, you either call the routine or not, you can't modify how it works,
> except by varying the parameters.

Not true. You can also replace it. Object oriented stuff is considerably
easier than libraries, but is also a lot less efficient. Why isn't the toolbox
written this way? Rhetorical question: assembler is faster. Shared libraries
are a decent compromise.

In any case, my point is still that something like tha Mac toolbox isn't
the answer. You just described something that might be, if it wasn't carried
around innumerable times.
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.