<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <title>TeXShop</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <style type="text/css" media="screen">@import "v1.css";</style>
</head>

<body>

<!-- title and menu -->
<div id="header">
  <ul>
  <li class="titel"><img alt="Logo" src="logo_klein.png" />TeXShop</li>
  <li><a href="index.html">About</a></li>
  <li><a href="tahoe.html">Tahoe</a></li>
     <li><a href="obtaining.html">Obtaining</a></li>
    <li><a href="installing.html">Installing</a></li>
     <li id="current"><a href="history.html">History</a></li>
    <li><a href="extras.html">Extras</a></li>
    <li><a href="links.html">Links</a></li>
  </ul>
</div>

<!-- gutter with download links -->
<div id="subheader">
<center> [ Direct Download: <a href="texshop-64/texshop.zip">Latest TeXShop</a> | <a href="texshop-64//texshopsource.zip">Latest TeXShop Source</a> ] [ <a href="mailto:koch@uoregon.edu">Contact</a> ] </center> 
</div>

<!-- links on the left -->
<div id="menulinks">
<ul>
<li><a href="history.html">History</a></li>
<li><a href="collaborators.html">Collaborators</a></li>
<li><a href="intel-arm.html">Intel and Arm</a></li>
<li id="mcurrent"><a href="arc.html">ARC</a></li>
<li><a href="64bits.html">64 Bits</a></li>
<li><a href="fragilebaseclasses.html">Fragile Base Classes</a></li>
<li><a href="autosave.html">Automatic Saving</a></li>

<!--
<li><a href="texshop-64/texshop.zip">TeXShop 3 for Lion</a></li>
<li><a href="texshop-64/texshopsource.zip">Lion Source</a></li>
-->
</ul>
</div>

<!-- main content -->
<div id="main">


<h3>Object Oriented Programming</h3> 

<p> In December, 1979, Steve Jobs and several Apple engineers visited Zerox PARC, where they were shown three crucial technologies: the Graphical User Interface, Object Oriented Programming, and Networking. Jobs immediately recognized the importance of the first, but he later admitted that he did not understand the significance of the other two.

<p>By the time Jobs and a few carefully chosen engineers left Apple to form NeXt, all three technologies were front and center in their minds. In particular, engineers at NeXt adopted Objective C as the programming language for the NeXt, and invented Interface Builder to make Object Oriented Programming a much easier, visual experience. When NeXt returned to Apple, this Object Programming layer was renamed Cocoa.

<p> Object Oriented Programming begins with a useful metaphor. Imagine that a typical program is build from a collection of small independent pieces called "objects". Each object has a memory, its "instance variables",
and defines a series of "messages" that it can send or receive. These messages form the procedures or functions implemented by the object. Objects interact by sending messages to each other. The objects are not created statically when the program begins; instead they are created dynamically by the program as needed, and thrown away when no longer necessary. 

<p> For example, a window on the computer screen may correspond to a window object in the code. This window object knows how to resize the window or move it to a new position on screen, how to temporarily hide or show the window, and how to permanently close it. When the user asks for a  new window, a new window object is created to handle this  window; when the user closes a window, its window object is released from memory. Thus  code objects are created dynamically rather than all at once when the program starts, because users create windows dynamically as needed, rather than all at once at bootup.

<p> Programmers do not need to create  objects from scratch. Instead Cocoa has a rich store of pre-built objects which programmers can request as needed. When Cocoa provides such an object, it is already "hooked up".
Thus if the programmer requests a window, the window appears on the screen able to resize itself or move elsewhere without writing any code at all.

<p>Before object oriented programming,  this could be accomplished by providing a large library of pre-written code.
But that approach is messy and intractable; a programmer than sees gigantic sections of code that he or she did not write  and can barely understand, and must   insert their own code inside these incomprehensible chunks of code. In object oriented programming, the code which makes an object work is hidden. Programmers aren't distracted by it, and cannot see it even if they want to. A programmer can send a message to a window asking it to resize itself, but never sees all the smaller tasks and special cases the code considers to make that happen.

<p> It wouldn't be very useful to get a library of pre-build objects from Apple which a user cannot modify. If I want a window on the screen, I'll happily let Apple resize and move it, but I need to control the contents of the window.
Maybe I want a window to show editable text, or perhaps a picture, or maybe a movie.
 So the most crucial feature of object oriented programming is that a programmer can request a prebuilt object and then modify it by changing the behavior of some of its build-in procedures.

<p> For example, window objects have a content region and a "draw" procedure which
draws the contents of the content region. This draw procedure is already hooked up, so it is called whenever the window resizes or moves elsewhere. The prebuilt draw routine does some very complicated things. It calculates the visible portion of the content region and sets a "clip region" so that when the drawing actually occurs, it only draws in this visible portion, but not into another window covering part of the window being drawn. And then, after all this preparation, the draw routine of the default window actually draws. It erases the previous contents and then draws nothing.

<p> When a user asks for a window object, he or she accepts all of this default behavior except the final command to "draw nothing." This part is overridden, and instead the new object draws some text, or a picture, or shows a movie. 
So the programmer has to write code for the things that make a program unique, but does not have to write code for the mundane tasks which, while complicated, are understood and already written by Apple.

<h3>Automatic Reference Counting</h3>

<p> A Cocoa program can create big objects, like those controlling windows, and also lots of little objects. Suppose I have a number 3.14159 and I want to round it to an integer 3. Or perhaps I want to write that number
=as a string of text. Cocoa has an object called NSNumber to handle tasks like these. A programmer can create an NSNumber object initialized to the value 3.14159, and then ask the object for its "integer value" or its "string value". Then the NSNumber object should be thrown away.

<p> A typical procedure in Cocoa might create five small objects at the start, use these objects to do something, and then throw them all away at the end. But often a procedure creates -objects and then sends these objects to  other procedures. Suppose a procedure creates an object and sends this object to window B and window C. Suppose later window B is closed. Should it throw the object away? YES if C is already closed, but NO otherwise. 

<p> Originally Apple had very elaborate rules to handle such memory management. But other object oriented languages adopted an easy way to handle it called "garbage collection". At regular intervals, the program would pause and go through the list of all objects currently in the system, determining how many other pieces were still using that object. If nobody was still using it, the object was thrown away.   At one point, Apple = adopted garbage collection for Cocoa. But then they created the iPhone, which is programmed in Cocoa. Garbage collection would mean that the phone would become unresponsive at random moments. That was unacceptable.

<p> Instead, Apple invented a method called Automatic Reference Countings or ARC. The rough idea is that objects keep track of the number of parts of the system using them. Whenever one of these parts of the system quits, it reduces the reference count of all objects using it by one. When the reference count of an object reaches zero, that object throws itself away. 

<p> Eventually Apple adopted ARC for Cocoa programs on all platforms, but a programmer could opt into ARC on a source file by source file basis. For a long period of time that summer, I gradually adopted ARC for all of TeXShop. The process was painful, and for a long period of time there were no new releases or bug fixes as file after file was switched over. 

<p> Instabilities remained, and some of my collaborators were extremely helpful tracing them down. In the end, the ARC battle was worth it. A key lesson is that when Apple makes a significant change, it is best to bite the bullet and adopt the change. Avoiding change is easier in the short run, and dangerous in the end.


<!--
<h4>Automatic Saving</h4>

Automatic Saving is a powerful new feature in Lion. 

<p>When Auto Save is on, you can essentially forget about saving files. The file will automatically be saved every few minutes. Only changes will be saved so there is not a lot of disk activity. With medium size documents, this is completely unnoticeable on my machine. I'll be interested in the experience of users with very large source files. Apple provides additional ways to optimize this feature which I have not implemented yet because I suspect they won't make much difference with TeX source files.

<p> If you quit a program, you will no longer be asked to save changed files. Instead the changes will automatically be saved. Similarly if you shut down your machine and Auto Save is activated for all programs, then the machine will simply shut down. But the next time you boot up, all those programs
will start again and all the documents will have the latest changes you made before shutting down.

<p> If you copy the source of a file, or drag the entire file to mail, or do similar operations, the file will automatically be saved first and users will always
get the latest version.

<p> It is still possible to directly save a file using the "Save" menu command or keyboard equivalent. When Auto Save is on, this command is renamed
"Save A Version."

<p> In previous Macintosh systems, file that have been edited are marked as "dirty" with a black circle in the red close button at top left of the window. 
When Auto Save is on, edited documents are marked by appending the word "- Edited" to the document's name in the window's title bar.  If you "Save A Version", this "- Edited" notice goes away.

<p> Since the Macintosh is only saving changes, it has a complete record of all the versions of the document. Theoretically, you could go back to
earlier versions and reconstruct the document as it was yesterday, or last month. As we will see in a moment, this isn't just theoretically possible --- it
is actually easy.

<p> You might wonder if the file containing a document has all the old versions hidden away somewhere. Could I send someone the TeX source of a letter of recommendation which currently says ``Paul is a creative student'', but whose initial version said ``Paul hasn't had a new idea in years"? Happily,
no. Files on disk only contain the latest version.

<p> What happens if I decide to experiment , get confused, lose my way, and end up with a source document that makes no sense, and then
discover that my crazy changes have been saved out from under me?
This question has several answers. First, if you typeset your experiment, then you saved over the old source anyway. But you can use undo to get
back to the original document because TeXShop's undo works even across file saves.

<p> However, Lion has a much nicer solution to this problem. It has always been true in
TeXShop and other programs that you can click the title of a window while holding down the control or apple key and see a complete path to
your document, listed as a series of entries in a drop down menu. By selecting an item in this menu, you can directly go to that spot of the file system.

<p> With Auto Save on, you can click in the title of a window without holding down a key and another menu will drop down. This
menu has the following items: Lock (or Unlock), Duplicate, Revert to Last Opened Version, and Browse All Versions. Suppose we select
that last item.

<p> The Macintosh screen then switches to a Time Machine view showing the current document on the left and a receding stack of earlier views on the right. You can leaf through these earlier versions, noting the date and time that the version was created. All
these views are alive, so you can copy and paste between versions, or restore an earlier version. 

<p> This works even if you have not activated Time Machine. So it is a personal Time Machine just for TeXShop source documents.

<p> Often users have a folder of old papers which they haven't edited in a long time, but refer back to from time to time. Lion understands this
 and implements a "Locking" feature for old papers. When a document has not been edited for 15 days, it is automatically "locked" and the window title shows the document name followed by the text "- Locked". Automatic saving is turned off for such documents and "Save A Version" puts up a warning dialog.

<p> If a document is locked, clicking on the word "Locked" produces a drop down menu with an item which Unlocks the file. Thus if you really want to work on the file again, you can do so. 

<p> If a document is active, the drop down menu from the title bar contains the command "Lock", so once a document is finished, it is easy to Lock it.

<p>  
-->
 </div>


</body>
</html>