Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!wuarchive!brutus.cs.uiuc.edu!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac
Subject: Re: Real Multifinder
Message-ID: <3994@internal.Apple.COM>
Date: 31 Aug 89 17:43:00 GMT
Sender: usenet@Apple.COM
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 28
References:<46100321@uxe.cso.uiuc.edu> <1989Aug15.001507.14552@sj.ate.slb.com> <24626@iuvax.cs.indiana.edu> <3576@internal.Apple.COM> <1989Aug16.175351.24310@sj.ate.slb.com> <7420@microsoft.UUCP> <1428@draken.nada.kth.se>

In article <1428@draken.nada.kth.se> d88-jwa@nada.kth.se (All this was 
brought to you by h+@nada.kth.se  Replys via email welcome!) writes:
> In article <7420@microsoft.UUCP> t-stevep@microsoft.UUCP (Steve Pool) 
writes:
> >I really think it's time for the Mac programming model to be updated.
> >That's probably unreasonable, considering the amount of code that would
> >undoubtedly cease functioning, but it would sure make me happy!
> 
> Of course not! Already working code has no reason to break even if
> we change the future development system. You'll just have a skeleton
> ready, where you put in your (pointers to) functions. I thought
> that MacApp already did this. I could be wrong, I haven't used it.

There are 2 issues.  One is changing the development system.  For example, 
MacApp makes a radical change to the programming model, but it is layered 
on top of the standard ROM calls.  

The other issues is changing the fundamental set of ROM calls.  This 
happens incrementally, as new features are added.  The difficulty in 
adding new features is ensuring compatibility, and sometimes compatibility 
issues affect the design.  I think Steve Pool was advocating a fresh start 
at designing the system without worrying about compatibility.

Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1