Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!amdahl!nsc!voder!apple!lsr
From: lsr@apple.UUCP (Larry Rosenstein)
Newsgroups: comp.lang.misc
Subject: Re: software ICs vs. libraries
Message-ID: <6702@apple.UUCP>
Date: Tue, 10-Nov-87 19:04:57 EST
Article-I.D.: apple.6702
Posted: Tue Nov 10 19:04:57 1987
Date-Received: Fri, 13-Nov-87 04:00:59 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <6644@apple.UUCP> <1039@sugar.UUCP>
Reply-To: lsr@apple.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 57

In article <1039@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>
>How big is Mac App?
>
>How many times is it going to be sitting on the disk or in memory taking up
>room?

MacApp is about 50K of object code, of which 15K is resident.  Right now it
has to be linked with every application, but that is an implementation
detail.  There is nothing that says a "Software IC" has to be linked with
every program.

>Not true. You can also replace it [a library routine]. 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.

Replacing a library routine generally means rewriting more code than you
might have to do in an object-oriented system.  Often you don't want to
replace the whole routine, but only a part of it.  

Even if your library is structured so that you don't have to rewrite much,
one advantage of object-oriented programming is that you can override a
method in a different way in each class.  You could have a single Window
class and implement subclasses that draw the window in different ways, all
in the same application.


Object-oriented systems are not necessarily "a lot less efficient" than
subroutine libraries.  Methods calls can be made very close to procedure
calls in speed.  In Object Pascal, the linker completely eliminates the
run-time binding overhead of a method call, except in the cases where the
programmer uses it.

Whether you write your code in assembler or a high-level language has no
bearing on the issue of libraries vs. object-oriented systems.  Sure,
assembler is likely to be faster and smaller than the output of a compiler.
(One can write a MacApp program in object-oriented assember if you choose.)

>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.

The Amiga shared libraries are not the answer either.  They are
fundamentally the same as the Toolbox, although they provide some higher
level services.  Sharing code is always desirable, but this is independent
from the issue of libraries vs. object-oriented frameworks.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.com