home *** CD-ROM | disk | FTP | other *** search
/ Amiga Plus 1995 #2 / Amiga Plus CD - 1995 - No. 2.iso / internet / faq / englisch / comp.lang.objective-c < prev    next >
Encoding:
Text File  |  1995-04-11  |  91.2 KB  |  2,601 lines

  1. Archive-name: Objective-C/answers
  2. Version: $Id: answers,v 3.5 1995/02/13 11:51:25 tiggr Exp $
  3.  
  4.  
  5.                  Answers to
  6.  
  7.              FREQUENTLY ASKED QUESTIONS
  8.  
  9.                concerning Objective-C
  10.  
  11.  
  12. This is the first in a series of three informational postings concerning
  13. comp.lang.objective-c.  This first part answers FAQs; the second part lists
  14. available class libraries and the third part is a simple sample Objective-C
  15. program.
  16.  
  17. This posting answers the following questions:
  18.  
  19.  1   What is Objective-C?
  20.  2   What is the difference between Objective-C and C++?
  21.  3   What exactly is it that makes Objective-C have `classes similar to
  22.      Smalltalk', and what are the resulting capabilities of Objective-C?
  23.  4   What are the `nice features' of Objective-C?
  24.  5   What are some of the common problems of the language and how can I work
  25.      around them?
  26.  6   What object encapsulation does Objective-C provide?
  27.  7   What are Protocols?
  28.  8   How can garbage collection be applied to Objective-C?
  29.  9   What is the difference between the NeXTSTEP, Stepstone and GNU CC
  30.      versions of Objective-C?
  31.  10  What written information concerning Objective-C is available?
  32.  11  What kind of Objective-C support is provided by Stepstone?
  33.  12  What kind of Objective-C support is provided by NeXT?
  34.  13  What kind of Objective-C support is provided by GNU?
  35.  14  What kind of Objective-C support is provided by BPG.
  36.  15  What are the newsgroups to read or mailing lists to subscribe to in order
  37.      to stay up-to-date on developments for GNU Objective-C?
  38.  16  Are there any FTP sites with Objective C code?  Where?
  39.  17  For more information...
  40.  
  41. (To find a question search on the question number starting a line.)
  42.  
  43. 1   What is Objective-C?
  44.  
  45.     Objective-C is an object oriented computer programming language.  It is
  46.     a superset of ANSI C and provides classes and message passing similar to
  47.     Smalltalk.
  48.  
  49.     Objective-C includes, when compared to C, a few more keywords and
  50.     constructs, a short description of which follows.  For a complete example
  51.     of the application of the constructs, see part 3 of this FAQ.
  52.  
  53.     `@interface' declares a new class.  It indicates the name of the class,
  54.     the name of its superclass, the protocols adhered to (see Q7), the
  55.     layout of the instance variables (similar to the definition of a struct,
  56.     but including encapsulation information (see Q19)) and declares the
  57.     methods implemented by this class.  A class' interface usually resides
  58.     in a file called `<classname>.h'.
  59.  
  60.     `@implementation' defines a class.  The implementation is no more than a
  61.     collection of method definitions.  Without an implementation, a class
  62.     does not exist at run time.  The implementation of a class usually
  63.     resides in a file called `<classname>.m'.
  64.  
  65.     A `@category' is a named collection of method definitions which are
  66.     added to an existing class.  A category is not allowed to redefine a
  67.     class' existing methods.
  68.  
  69.     Objective-C includes the predefined type `id' which stands for a pointer
  70.     to some object.  Thus, `id obj;' declares a pointer to an object.  The
  71.     actual class of the object being pointed to is almost irrelevant, since
  72.     Objective-C does run-time type checking.
  73.  
  74.     `-message;' declares a method called `message'.  The `-' indicates that
  75.     the message can be sent to objects.  A `+' instead indicates the message
  76.     can be sent to class objects.  A method is similar to a function in that
  77.     it has arguments and a return value.  The default return type is `id'.
  78.     If a method has nothing useful to return, it returns `self', which is a
  79.     pointer to the object to which the message was sent (similar to `this'
  80.     in C++).
  81.  
  82.     [obj message], [obj message: arg1] and [obj message: arg1 with: arg2]
  83.     are examples of sending a message to the object OBJ with 0, 1 and 2
  84.     arguments respectively.  The name of the message is called the selector.
  85.     In this example, the selectors are: `message', `message:' and
  86.     `message:with:', respectively.
  87.  
  88. 3   What is the difference between Objective-C and C++?
  89.  
  90.     C++ follows the Simula 67 school of OO programming, where Objective-C
  91.     follows the Smalltalk school.  In C++ the static type of an object
  92.     determine whether you can send it a message, in Objective-C the dynamic
  93.     type determine it.  The Simula 67 school is safer, in that more errors
  94.     are detected at compile time.  The Smalltalk school is more flexible, as
  95.     some valid programs will execute correctly in Smalltalk, where they
  96.     would be rejected by Simula 67.
  97.  
  98.     Stepstone's Objective-C allows you to chose between the dynamic and
  99.     static binding, GNU and NeXT do not.  ANSI C++ allows you to use dynamic
  100.     binding, but discourages you from doing so.
  101.  
  102.     In many ways, the difference between C++ and Objective-C is more a
  103.     question of mindset than technical barriers.  Are you willing to offer
  104.     some flexibility for some safety?  Advocates for the Simula 67 school
  105.     claims that a well designed program doesn't need the extra flexibility
  106.     (a lie), while advocates for the Smalltalk school claims that the errors
  107.     are no problem in practice (another lie).
  108.  
  109.     Pragmatic differences between Objective-C and C++ include:
  110.  
  111.     C++ has operator overloading.  Some consider this to be `syntactic
  112.     sugar', and it is, but it can be a quite handy bit of sugar.
  113.  
  114.     C++ has multiple inheritance.  There are several ways to `get
  115.     around' this in Objective-C (see below).
  116.  
  117.     The added syntax and semantics of C++ is huge, while Objective-C is
  118.     C plus just a small number of new features.
  119.  
  120. 3   What exactly is it that makes Objective-C have `classes similar to
  121.     Smalltalk', and what are the resulting capabilities of Objective-C?
  122.  
  123.     Objective-C is as close to Smalltalk as a compiled language allows.  The
  124.     following is a list of the features `taken' from Smalltalk:
  125.  
  126.       * Objective-C is compiled---Smalltalk is only partially compiled.  The
  127.     current Objective-C implementations are all *much* faster than any
  128.     Smalltalk.  For example ParcPlace Smalltalk-80/4 is at least 3 times
  129.     slower than both the GNU and NeXT Objective-C's.  (This was measured
  130.     using the Self/Smalltalk benchmark suite available by FTP from
  131.     `self.stanford.edu:pub/Self-2.0.1'.)
  132.  
  133.     The big difference of course is that Objective-C does hybrid typing:
  134.     one can choose to represent a string as a `char *' or as an object,
  135.     whereas in Smalltalk, everything is an object.  This is a reason for
  136.     Objective-C being faster.  On the other hand, if every bit of
  137.     information in an Objective-C program would be represented by an
  138.     object, the program would probably run at a speed comparable to
  139.     Smalltalk and it would suffer from not having optimizations
  140.     performed on the basic classes, like Smalltalk can do.
  141.  
  142.       * You may add or delete methods and classes at runtime.  (On GNU and
  143.     NeXT one can load new classes and categories.  On Stepstone, which
  144.     lacks categories, the only way to add methods is to load a subclass
  145.     which then does a `+poseAs:' of the class to have methods added.
  146.     This is less flexible, but it sort-of does the trick of just adding
  147.     methods.)
  148.  
  149.       * Much of the syntax, i.e. Smalltalk uses method names like
  150.     `a:method:name:', as does Objective-C.  In Objective-C, the message
  151.     sending construct is enclosed in square brackets, like this:
  152.     `[anObject aMessage: arg]' whereas Smalltalk uses something like
  153.     `anObject aMessage: arg'.
  154.  
  155.       * The basic class hierarchy, that is, having class `Object' in the very
  156.     top, and letting most other classes inherit from it.
  157.  
  158.       * Most method names in class object is the same.  E.g. `respondsTo:'.
  159.     What is called `doesNotUnderstand:' in Smalltalk is called
  160.     `doesNotRecognize:' in Objective-C.
  161.  
  162.       * Smalltalk normally uses `doesNotUnderstand:' to implement
  163.     forwarding, delegation, proxies etc.  In Objective-C, these tasks
  164.     are different:
  165.  
  166.         forwarding/delegation: `forward::' can be overridden to
  167.         implement forwarding.  On the NeXT, `forward::' is even used
  168.         when passing to super.
  169.  
  170.         proxies: (Next) An instance of the NXProxy class forwards all
  171.         methods and their arguments to the remote object via Mach
  172.         messages.
  173.  
  174.       * Objective-C has meta classes mostly like Smalltalk.
  175.  
  176.       * Objective-C does not have class variables like Smalltalk, but pool
  177.     variables and globals are easily emulated via static variables.
  178.  
  179. 4   What are the `nice features' of Objective-C?
  180.  
  181.     The possibility to load class definitions and method definitions
  182.     (which extend a class) at run time.
  183.  
  184.     Objects are dynamically typed: Full type information (name and type
  185.     information of methods and instance variables and type information
  186.     of method arguments) is available at run time.  A prime example of
  187.     application of this feature is `-loadNibSection:owner:' method of
  188.     NeXTSTEP's Application class.
  189.  
  190.     Persistence [...].
  191.  
  192.     Remote objects [...].
  193.  
  194.     Delegation and target/action protocols [...].
  195.  
  196. 5   What are some of the common problems of the language and how can I work
  197.     around them?
  198.  
  199.     There are some `common problems':
  200.  
  201.     There is no innate multiple inheritance (of course some see this as
  202.     a benefit).
  203.  
  204.         To get around it you can create a compound class, i.e. a class
  205.         with instance variables that are ids of other objects.
  206.         Instances can specifically redirect messages to any combination
  207.         of the objects they are compounded of.  (It isn't *that* much of
  208.         a hassle and you have direct control over the inheritance
  209.         logistics.)  [Of course, this is not `getting around the problem
  210.         of not having multiple inheritance', but just modeling your
  211.         world slightly different in such a way that you don't need
  212.         multiple inheritance.]
  213.  
  214.         Protocols address the absence of multiple inheritance (MI) to
  215.         some extent: Technically, protocols are equivalent to MI for
  216.         purely "abstract" classes (see the answer on `Protocols' below).
  217.  
  218.         [How does Delegation fit in here?  Delegation is extending a
  219.         class' functionality in a way anticipated by the designer of
  220.         that class, without the need for subclassing.  One can, of
  221.         course, be the delegate of several objects of different
  222.         classes.  ]
  223.  
  224.     There are no class variables.
  225.  
  226.         You can get around this by defining a static variable in the
  227.         implementation file, and defining access methods for it.  This
  228.         is actually a more desirable way of designing a class hierarchy,
  229.         because subclasses shouldn't access superclass storage (this
  230.         would cause the subclass to break if the superclass was
  231.         reimplemented), and allows the subclass to override the storage
  232.         (if the classes access all their own variables via methods).
  233.  
  234.         [The question remains what the exact syntax of class variables
  235.         should be: Should a class object A be seen as an instance of its
  236.         meta-class MA, which has a super class MB being the meta-class
  237.         of A's super, B, and, as such, should A have separate instances
  238.         of class variables defined for B?  Or not?]
  239.  
  240. 6   What object encapsulation does Objective-C provide?
  241.  
  242.     Object encapsulation can be discerned at two levels: encapsulation of
  243.     instance variables and of methods.  In Objective-C, the two are quite
  244.     different.
  245.  
  246.     Instance variables:
  247.  
  248.     The keywords @public, @private and @protected are provided to secure
  249.     instance variables from prying eyes to some extent.
  250.  
  251.         @public        anyone can access any instance variable.
  252.         @protected    only methods belonging to this object's
  253.                 class or a subclass thereof have access to
  254.                 the instance variables.
  255.         @private    only methods of this class may access the
  256.                 instance variables.  This excludes methods
  257.                 of a subclass.
  258.  
  259.     If not explicitly set, all instance variables are @protected.
  260.     Note: Instance variable encapsulation is enforced at compile-time.
  261.     At run-time, full typing information on all instance variables is
  262.     available, which sort-of makes all variables @public again.  This
  263.     information is for instance used to do instance variable lookup by
  264.     NeXTSTEP's `loadNibSection:owner:' method, making it completely
  265.     safe.
  266.  
  267.     Methods:
  268.  
  269.     To the Objective-C runtime, all methods are @public.  The programmer
  270.     can only show his/her intention of making specific methods not
  271.     public by not advertising them in the class' interface.  In
  272.     addition, so-called private methods can be put in a category with a
  273.     special name, like `secret' or `private'.
  274.  
  275.     However, these tricks do not help much if the method is declared
  276.     elsewhere, unless one reverts to indicating the object's type at
  277.     compile time.  And the runtime doesn't care about all this and any
  278.     programmer can easily circumvent the tricks described.  Thus, all
  279.     methods really are always @public.
  280.  
  281. 7   What are Protocols?
  282.  
  283.     Protocols are an addition to Objective-C that allows you to organize
  284.     related methods into groups that form high-level behaviors.  Protocols
  285.     are currently available in NeXTSTEP (since 3.0) and GCC (since 2.4).
  286.  
  287.     Protocols address the MI issue.  When you design an object with multiple
  288.     inheritance, you usually don't want *all* the features of both A and B,
  289.     you want feature set X from A and feature set Y from B.  If those
  290.     features are methods, then encapsulating X and Y in protocols allows you
  291.     to say exactly what you want in your new object.  Furthermore, if
  292.     someone changes objects A or B, that doesn't break your protocols or
  293.     your new object.  This does not address the question of new instance
  294.     variables from A or B, only methods.
  295.  
  296.     Protocols allow you to get type-checking features without sacrificing
  297.     dynamic binding.  You can say "any object which implements the messages
  298.     in Protocol Foo is OK for this use", which is usually what you want -
  299.     you're constraining the functionality, not the implementation or the
  300.     inheritance.
  301.  
  302.     Protocols give library builders a tool to identify sets of standard
  303.     protocols, independent of the class hierarchy.  Protocols provide
  304.     language support for the reuse of design, whereas classes support the
  305.     reuse of code.  Well designed protocols can help users of an application
  306.     framework when learning or designing new classes.  Here is a simple
  307.     protocol definition for archiving objects:
  308.  
  309.     @protocol Archiving
  310.     -read: (Stream *) stream;
  311.     -write: (Stream *) stream;
  312.     @end
  313.  
  314.     Once defined, protocols can be referenced in a class interface as
  315.     follows:
  316.  
  317.     /* MyClass inherits from Object and conforms to the
  318.        Archiving protocol.  */
  319.     @interface MyClass: Object <Archiving>
  320.     @end
  321.  
  322.     Unlike copying methods to/from other class interfaces, any incompatible
  323.     change made to the protocol will immediately be recognized by the
  324.     compiler (the next time the class is compiled).  Protocols also provide
  325.     better type checking without compromising the flexibility of untyped,
  326.     dynamically bound objects.
  327.  
  328.     MyClass *obj1 = [MyClass new];
  329.  
  330.     // OK: obj1 conforms to the Archiving protocol.
  331.     id <Archiving> obj2 = obj1;
  332.  
  333.     // Error: obj1 does not conform to the TargetAction protocol.
  334.     id <TargetAction> obj3 = obj1;
  335.  
  336.     Another use of protocols is that you can declare an ID to conform to
  337.     some protocol in order to help the compiler to resolve method name
  338.     conflicts:
  339.  
  340.     @interface Foo: Object
  341.     -(int) type;
  342.     @end
  343.  
  344.     @protocol Bar
  345.     -(const char *) type;
  346.     @end
  347.  
  348.     -blah1: d
  349.     {
  350.       id t = [d someMethod];
  351.       do_something_with ([t type]);
  352.     }
  353.  
  354.     -blah2: d
  355.     {
  356.       id <Bar> t = [d someMethod];
  357.       do_something_with ([t type]);
  358.     }
  359.  
  360.     In this example, there are two kinds of the `-type' method.  In the
  361.     method `-blah1:', the compiler doesn't know what return type to expect
  362.     from `[t type]', since it has seen both declarations of `-type'.  In
  363.     method `-blah2:', it knows that `t' conforms to the `Bar' protocol and
  364.     thus that `t' implements the `-type' method returning a `const char *'.
  365.  
  366. 8   How can garbage collection be applied to Objective-C?
  367.  
  368.     Currently, there are two implementations of garbage collection which can
  369.     be used in Objective-C programs [that I'm aware of].  Both methods use a
  370.     radically different approach.
  371.  
  372.     Garbage Collection in an Uncooperative Environment
  373.  
  374.         This implements garbage collection of chunks of memory obtained
  375.         through (its replacement of) malloc(3).  It works for C, C++,
  376.         Objective-C, etc.
  377.  
  378.         @article{bw88,
  379.         title="Garbage Collection in an Uncooperative Environment",
  380.         author="Hans J\"urgen Boehm and Mark Weiser",
  381.         journal="Software Practice and Experience",
  382.         pages=807-820,volume=18,number=9,month=sep,year=1988}
  383.  
  384.         It is available as `ftp://parcftp.xerox.com:/pub/gc/gc4.3.tar.gz'.
  385.  
  386.     Garbage Collection through Class Abstraction
  387.  
  388.         This implements garbage collection through class abstraction
  389.         (and hence is Objective-C specific).  Anything to be garbage
  390.         collectible must be an object (instance of a subclass of a
  391.         specific class) or have such an object for a wrapper.
  392.  
  393.         Available as `ftp://ftp.es.ele.tue.nl:/pub/tiggr/tobjc.tar.gz'
  394.  
  395.     Apart from the obvious radical difference, another difference currently
  396.     is also noteworthy: The first method automatically protects objects
  397.     pointed to from the stack, bss or data segments; the second doesn't.
  398.  
  399. 9   What is the difference between the NeXTSTEP, Stepstone and GNU CC
  400.     versions of Objective-C?
  401.  
  402.     NeXT extended Stepstone's definition of the language to include new
  403.     constructs, such as protocols, which are touted to deal with some
  404.     aspects of multiple inheritance.
  405.  
  406.     Stepstone supports static _binding_, whereas NeXTSTEP and GNU CC don't.
  407.     All implementations do support static _typing_.
  408.  
  409.     Stepstone has a standard set of Foundation class libraries that work
  410.     across all supported machines, including NeXTSTEP.  NEXTSTEP comes with
  411.     its own set of libraries (called `kits').  GNU libobjc.a currently only
  412.     includes the `Object' class, though people are busy on a Real library
  413.     (see part two of this FAQ (The ClassWare Listing) for details).
  414.  
  415.     The `Object' class of all implementations differ.
  416.  
  417.     NeXTSTEP and GNU CC support Categories, Stepstone doesn't.
  418.  
  419.     NeXT has a native language debugger, Stepstone and GNU don't.  [This is
  420.     not really true, since NeXT's debugger is gdb, the GNU debugger, and
  421.     their extensions are available though they haven't appeared in the
  422.     official FSF distribution yet.  Besides, debugging objc with a C
  423.     debugger, like generic GDB, is quite acceptable.]
  424.  
  425.     NeXTSTEP (from version 3.0) and GCC (from version 2.4) support protocols
  426.     and forward declarations of classes, Stepstone currently does not.
  427.  
  428. 10  What written information concerning Objective-C is available?
  429.  
  430.     Books:
  431.  
  432.     Brad J. Cox, Andrew J. Novobilski: Object Oriented Programming: An
  433.     Evolutionary Approach.  Addison-Wesley Publishing Company, Reading,
  434.     Massachusetts, 1991.  ISBN: 0-201-54834-8.
  435.  
  436.     abstract:    The first book on Objective-C, which actually is a
  437.                     book on object oriented system development using
  438.                     Objective-C.
  439.                     
  440.  
  441.     Lewis J. Pinson, Richard S. Wiener: Objective-C: Object Oriented
  442.     Programming Techniques.  Addison-Wesley Publishing Company, Reading,
  443.     Massachusetts, 1991. ISBN 0-201-50828-1.
  444.  
  445.     abstract:       Includes many examples, discusses both Stepstone's
  446.                     and NeXT's versions of Objective-C, and the
  447.                     differences between the two.
  448.  
  449.  
  450.     Timothy Budd: An Introduction to Object-Oriented Programming.
  451.     Addison-Wesley Publishing Company, Reading, Massachusetts.
  452.     ISBN 0-201-54709-0.
  453.  
  454.     abstract:       An intro to the topic of OOP, as well as a comparison
  455.                     of C++, Objective-C, Smalltalk, and Object Pascal
  456.  
  457.  
  458.     Simson L. Garfinkel, Michael K. Mahoney: NeXTSTEP Programming Step
  459.     ONE: Object-Oriented Applications.  TELOS/Springer-Verlag, 1993
  460.     (tel: (800)SPR-INGE).
  461.  
  462.     abstract:       It's updated to discuss NeXTSTEP 3.0 features
  463.                     (Project Builder, new development environment)
  464.                     but doesn't discuss 3DKit or DBKit.
  465.  
  466.  
  467.     NeXTSTEP Object Oriented Programming and the Objective C Language.
  468.     Addison-Wesley Publishing Company, Reading, Massachusetts, 1993.
  469.     ISBN 0-201-63251-9.
  470.  
  471.     abstract:     This book describes the Objective-C language as it
  472.             is implemented for NeXTSTEP.  While clearly targeted
  473.             at NeXTSTEP, it is a good first-read to get to learn
  474.             Objective-C.
  475.  
  476.     Articles
  477.  
  478.     `Why I need Objective-C', by Christopher Lozinski.
  479.     Journal of Object-Oriented Programming (JOOP) September 1991.
  480.     Contact info@bpg.com for a copy and subscription to the BPG
  481.     newsletter.
  482.  
  483.     Abstract:    This article discusses the differences between C++
  484.             and Objective-C in great detail and explains why
  485.             Objective-C is a better object oriented language.
  486.  
  487.     `Concurrent Object-Oriented C (cooC)', by Rajiv Trehan et. al.
  488.     ACM SIGPLAN Notices, Vol. 28, No 2, February 1993.
  489.  
  490.     Abstract:    This article discusses cooC, a language based on the
  491.             premise that an object not only provides an
  492.             encapsulation boundary but should also form a
  493.             process boundary.  cooC is a superset of
  494.             Objective-C.
  495.  
  496.     `Porting NEXTSTEP Applications to Microsoft Windows',
  497.     by Christopher Lozinski.  NEXTWORLD EXPO Conference Proceedings,
  498.     San Francisco, CA, May 25-27, 1993.  Updated version of the article
  499.     available from the author.  Contact info@bpg.com.
  500.  
  501.     Abstract:    This article describes how to develop Objective-C
  502.             applications for both Microsoft Windows and
  503.             NEXTSTEP.
  504.  
  505.     GNU Documentation
  506.  
  507.     The GNU project needs a free manual describing the Objective-C
  508.     language features.  Because of its cause, GNU cannot include the
  509.     non-free books in the GNU system, but the system needs to come with
  510.     documentation.
  511.  
  512.     Anyone who can write good documentation, please think about giving
  513.     it to the GNU project.  Contact rms@gnu.ai.mit.edu.
  514.  
  515. 11  What kind of Objective-C support is provided by Stepstone?
  516.  
  517.     Compilers and runtime for: Apple Macintosh (running Mac Programmers
  518.     Workshop), DEC Stations (ULTRIX), Data General AViiON (DG/UX),
  519.     HP9000/300,400,700,800 (HP-UX), IBM RISC System/6000 (AIX), MIPS,
  520.     NeXT, PC-AT (MS-DOS), PS/2 (AIX or OS/2), SCO/NCR UNIX SYS V, Sun 3, 4,
  521.     SPARCstations (SunOS or Solaris), Silicon Graphics INDIGO and VAX(VMS).
  522.     Other ports available by market demands or consulting services.
  523.  
  524.     ICpak101 Foundation Class Library is available on all the above.
  525.     ICpak201 GUI Class Library is available on platforms that support
  526.     XWindows, Motif, OpenWindows and SunView.
  527.  
  528.        The Stepstone Corporation
  529.     (203) 426-1875 - (800) BUY-OBJEct voice / (203) 270-0106 fax
  530.     75 Glen Road
  531.     Sandy Hook, CT 06482
  532.  
  533. 12  What kind of Objective-C support is provided by NeXT?
  534.  
  535.     The Objective-C compiler and libraries come bundled with the
  536.     NEXTSTEP Developer CD.  The compiler essentially is GNU CC.  For
  537.     information on the Kits which are part of NEXTSTEP, see the
  538.     ClassWare Listing (part 2 of this FAQ).
  539.  
  540.     Products are:
  541.  
  542.         NEXTSTEP 3.3 for NeXT, Intel and HP-PA Computers
  543.         Enterprise Objects Framework 1.0
  544.         Portable Distributed Objects Release 2.0
  545.  
  546.     NeXT Computer, Inc.
  547.     900 Chesapeake Drive
  548.     Redwood City, CA 94063
  549.     tel: 800 848 NEXT
  550.     fax: 415 780 2801
  551.     email: NeXTanswers@NeXT.COM
  552.     www: http://www.next.com/
  553.  
  554. 13  What kind of Objective-C support is provided by GNU?
  555.  
  556.     GNU CC, since version 2, comes with an Objective-C compiler.  The
  557.     current distribution of GNU CC (version 2.6.3) includes an Objective-C
  558.     compiler and runtime library.  The latter includes the `Object' class.
  559.     Some people are working on GNU libraries, see part two of this FAQ (The
  560.     ClassWare Listing) for details.
  561.  
  562.     If you haven't switched to a GNU CC as recent as 2.4 yet, here's one
  563.     reason to do so: The new runtime (as of 2.4) is more than 3 times as
  564.     fast as the old runtime (pre 2.4) w.r.t. method invocation.
  565.  
  566.     Free Software Foundation
  567.     675 Massachusetts Avenue
  568.     Cambridge, MA  02139
  569.     +1-617-876-3296
  570.  
  571.     General questions about the GNU Project can be asked to
  572.     gnu@prep.ai.mit.edu.
  573.  
  574.     GNU CC comes with an Objective-C compiler and runtime library which
  575.     includes the Object class.
  576.  
  577.     Most GNU software is packed using the new `gzip' compression program.
  578.     Source code is available on most sites distributing GNU software.
  579.  
  580.     For information on how to order GNU software on tape, floppy, or
  581.     cd-rom, check the file etc/ORDERS in the GNU Emacs distribution or in
  582.     GNUinfo/ORDERS on prep, or e-mail a request to: gnu@prep.ai.mit.edu
  583.  
  584.     By ordering your GNU software from the FSF, you help us continue to
  585.     develop more free software.  Media revenues are our primary source of
  586.     support.  Donations to FSF are deductible on US tax returns.
  587.  
  588.     The following sites all carry mirrors of the GNU software at prep.
  589.     Please try them before prep.ai.mit.edu!   thanx -gnu@prep.ai.mit.edu
  590.     ASIA: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:/ftpsync/prep,
  591.         cair.kaist.ac.kr:/pub/gnu, ftp.nectec.or.th:/pub/mirrors/gnu
  592.     AUSTRALIA: archie.au:/gnu (archie.oz or archie.oz.au for ACSnet)
  593.     AFRICA: ftp.sun.ac.za:/pub/gnu
  594.     MIDDLE-EAST: ftp.technion.ac.il:/pub/unsupported/gnu
  595.     EUROPE: irisa.irisa.fr:/pub/gnu, ftp.univ-lyon1.fr:pub/gnu,
  596.         ftp.mcc.ac.uk, unix.hensa.ac.uk:/pub/uunet/systems/gnu,
  597.         ftp.denet.dk, src.doc.ic.ac.uk:/gnu, ftp.eunet.ch,
  598.         nic.switch.ch:/mirror/gnu,
  599.         ftp.informatik.rwth-aachen.de:/pub/gnu,
  600.         ftp.informatik.tu-muenchen.de, ftp.win.tue.nl,
  601.         ftp.funet.fi:/pub/gnu, ftp.stacken.kth.se, isy.liu.se,
  602.         ftp.luth.se:/pub/unix/gnu, ftp.sunet.se:/pub/gnu,
  603.         archive.eu.net
  604.     SOUTH AMERICA: ftp.unicamp.br:/pub/gnu
  605.     WESTERN CANADA: ftp.cs.ubc.ca:/mirror2/gnu
  606.     USA: wuarchive.wustl.edu:/systems/gnu, labrea.stanford.edu,
  607.         ftp.digex.net:/pub/gnu, ftp.kpc.com:/pub/mirror/gnu,
  608.         f.ms.uky.edu:/pub3/gnu, jaguar.utah.edu:/gnustuff
  609.         ftp.hawaii.edu:/mirrors/gnu, ftp.cs.widener.edu,
  610.         vixen.cso.uiuc.edu:/gnu, mrcnext.cso.uiuc.edu:/pub/gnu,
  611.         ftp.cs.columbia.edu:/archives/gnu/prep,
  612.         col.hp.com:/mirrors/gnu, gatekeeper.dec.com:/pub/GNU,
  613.         ftp.uu.net:/systems/gnu
  614.  
  615. 14  What kind of Objective-C support is provided by BPG.
  616.  
  617.     BPG provides the Borland Extensions to Objective-C which allows the
  618.     Objective-C translator to be used with the Borland Compiler, and makes
  619.     it easy to develop Objective-C application for Microsoft Windows.
  620.  
  621.     BPG provides the Smalltalk Interface to Objective-C which makes
  622.     Objective-C objects look like Smalltalk Objects.  It can be used to
  623.     build Graphical User Interface on portable Objective-C objects, or to
  624.     sell Objective-C libraries to Smalltalk developers.
  625.  
  626.     BPG provides the Objective-C Message Bus which sends Objective-C messages
  627.     across heterogeneous computer platforms.
  628.  
  629.     BPG has a library of objects for modelling Objective-C programs.  A browser
  630.     application has been built on this library.  Other potential applications
  631.     include adding class variables to Objective-C, adding runtime information
  632.     about instance variables, and method argument types, generating object
  633.     versions, and eventually building a browser/translator.
  634.  
  635.     Christopher Lozinski
  636.     BPG
  637.     35032 Maidstone Court
  638.     Newark, CA 94560
  639.     Tel: (510) 795-6086
  640.     fax: (510) 795-8077
  641.     email: info@bpg.com
  642.  
  643. 15  What are the newsgroups to read or mailing lists to subscribe to in order
  644.     to stay up-to-date on developments for GNU Objective-C?
  645.  
  646.     Read comp.lang.objective-c, which is bound to discuss current events.
  647.     There is also a mailing list, gnu-objc@gnu.ai.mit.edu, discussing this
  648.     very topic.  To subscribe to this list, send a mail with your request to
  649.     `gnu-objc-request@gnu.ai.mit.edu.'
  650.  
  651.     Furthermore, the various kits that are being developed each come with
  652.     their own mailing list.  See part 2 of this FAQ for more information.
  653.  
  654. 16  Are there any FTP sites with Objective C code?  Where?
  655.  
  656.     ftp.cs.rochester.edu:/pub/objc
  657.     sonata.cc.purdue.edu        (NEXTSTEP)
  658.     cs.orst.edu            (NEXTSTEP)
  659.     ftp.stack.urc.tue.nl        (NEXTSTEP)
  660.     ftp.informatik.uni-muenchen.de
  661.     ftp.informatik.uni-freiburg.de
  662.     ccrma-ftp.stanford.edu        (MusicKit)
  663.     ftp.cs.unl.edu:/pub/ObjC    (sw && c.l.obj-c last few weeks)
  664.  
  665.     See also part 2 of this FAQ.
  666.  
  667. 17  For more information...
  668.  
  669.     See part 2 of this FAQ, Objective-C/classes a.k.a. the ClassWare
  670.     Listing, for an overview of available Objective-C classes and libraries.
  671.  
  672.     See part 3 of this FAQ, Objective-C/sample a.k.a. the Simple Sample
  673.     Program, for an example Objective-C program.
  674.  
  675. The early version of this FAQ was compiled by Bill Shirley, with the aid of
  676. many people.  The current version is being maintained by Tiggr, aided by a
  677. lot of people, including: Per Abrahamsen, Paul Burchard, Brad Cox,
  678. Christopher Lozinski, Mike Mahoney, Jon F. Rosen, Paul Sanchez, Lee Sailer,
  679. Bill Shirley, Subrata Sircar, Ted Slupesky, Richard Stallman and Kersten
  680. Krab Thorup,
  681.  
  682. A World Wide Web hypertext version of this FAQ is maintained by Brian Harvey
  683. (theharv@csld.ucr.edu) and can be found at:
  684.     http://csld.ucr.edu/NeXTSTEP/objc_faq.html
  685.  
  686. Any text in between `[' and `]' is a comment.  Comments indicate `problems'
  687. with this FAQ, which should be solved.  Send your suggestions, additions,
  688. bug reports, comments and fixes to `tiggr@es.ele.tue.nl'.
  689.  
  690.     The information in this file comes AS IS, WITHOUT ANY WARRANTY.  You may
  691.     use the information contained in this file or distribute this file, as
  692.     long as you do not modify it, make money out of it or take the credits.
  693. Archive-name: Objective-C/classes
  694. Version: $Id: classes,v 3.4 1995/02/13 11:51:26 tiggr Exp $
  695.  
  696.  
  697.  
  698.                 Objective-C
  699.  
  700.                  ClassWare Listing
  701.  
  702.  
  703.  
  704. This is the second of three FAQ postings for comp.lang.objective-c.  This
  705. posting lists available kits and classes, to aid the reader in answering the
  706. question `to re-use or to re-invent?'.  In order to keep this list up to date
  707. and as interesting and diverse as possible, send your additions, deletions
  708. and suggestions to tiggr@es.ele.tue.nl.
  709.  
  710. The available classes and kits are categorized as follows:
  711.  
  712.     Stepstone    Stepstone libraries,
  713.             for use with Stepstone's environment
  714.     NeXT        NeXT kits, for use with NEXTSTEP
  715.     FSF        FSF maintained/released classes
  716.             for use with GNU CC
  717.     Third Party    commercial classes
  718.     GPL        classes released under the GPL
  719.     Public Domain    public domain classes---no GPL
  720.  
  721.  
  722. Stepstone
  723.  
  724.     Bundled with the compiler is ICpak 101 Foundation Class Library.  This
  725.     library provides twenty classes and more than three hundred methods
  726.     including such things as Collections (OrdCltn, Stack, Set, Dictionary,
  727.     SortCltn), Arrays (IdArray, IntArray), String, Sequences, Automatic
  728.     Object I/O (ASCII Filer), etc.
  729.  
  730.     The ICpak 201 Graphical User Interface library is used to build iconic
  731.     multi window user interfaces for workstation applications.  The library
  732.     consists of 58 classes and over 1,100 methods.  Classes include such
  733.     things as Controllers, Menu's, Menu Items, Icons, Windows(StdLayer),
  734.     Timers, Buttons, Text, etc, etc.  ICpak 201 is ported to X Windows,
  735.     OpenWindows, Motif and SunView and provides a consistent user interface/
  736.     look-and-feel between all platforms.
  737.  
  738.     Contact
  739.  
  740.     The Stepstone Corporation
  741.     75 Glen Road
  742.     Sandy Hook, CT 06482
  743.     tel: +1 203 426-1875
  744.     fax: +1 203 270-0106
  745.     telex: 506127
  746.  
  747. NeXT
  748.  
  749.     Common Classes
  750.  
  751.     Several classes provided with NeXTSTEP do not belong to a specific
  752.     kit: Object (core of the runtime system, root of the general class
  753.     hierarchy), Storage, List (an abstract array), HashTable (to store
  754.     (key, object) associations), StreamTable (to write data to streams)
  755.     and NXStringTable (to store (key, string) associations).
  756.  
  757.     Application Kit
  758.  
  759.     The Application Kit defines a set of Objective-C classes and
  760.     protocols, C functions, and assorted constants and data types that
  761.     are used by virtually every NeXTSTEP application.  The pith of the
  762.     Kit are the tools it provides for implementing a graphical,
  763.     event-driven user interface:
  764.  
  765.         The Application Kit provides classes---most notably Window and
  766.         View---that make drawing on the screen exquisitely succinct.
  767.         Much of the unromantic work that's involved in
  768.         drawing---communicating with hardware devices and screen
  769.         buffers, clearing areas of the screen before drawing,
  770.         coordinating overlapping drawing areas---is taken care of for
  771.         you, letting you concentrate on the much more gratifying task of
  772.         supplying code that simply draws.  And even this task is
  773.         assisted by many of the other classes and a number of C
  774.         functions that provide drawing code for you.
  775.  
  776.         The Application Kit makes event handling extremely simple.  The
  777.         Responder class, from which many of the Kit's classes inherit,
  778.         defines a mechanism by which the user's actions are passed to
  779.         the objects in your application that can best respond to them.
  780.         The Application class, which inherits from Responder,
  781.         establishes the low-level connections that makes this system
  782.         possible.  It provides methods that inform your application of
  783.         watershed events, such as when the user makes the application
  784.         active and inactive, and when the user logs out or turns off the
  785.         computer.
  786.  
  787.     By using these tools, you bless your application with a look and
  788.     feel that's similar to other applications, making it easier for the
  789.     user to recognize and use.
  790.  
  791.     (Introduction from the NeXTSTEP General Reference, "Application Kit"
  792.     reprinted with permission.  Copyright (c) 1993 NeXT Computer, Inc.
  793.     All rights reserved.)
  794.  
  795.     Database Kit
  796.  
  797.     The Database Kit provides a comprehensive set of tools, classes, and
  798.     protocols for building applications that use a high-level
  799.     entity-relationship model to manipulate database servers such as
  800.     those provided by Oracle or Sybase.  The kit provides services that
  801.     include:
  802.  
  803.         Communication with client-server databases.
  804.  
  805.         Modeling properties (attributes and relationships) of each
  806.         database.
  807.  
  808.         Record management and buffering.
  809.  
  810.         Data flow between record managers and the application user
  811.         interface.
  812.  
  813.         User interface objects for display and editing.
  814.  
  815.     (Introduction from the NeXTSTEP General Reference, "Database Kit"
  816.     reprinted with permission.  Copyright (c) 1993 NeXT Computer, Inc.
  817.     All rights reserved.)
  818.  
  819.     Distributed Objects
  820.  
  821.     The Distributed Objects system provides a relatively simple way for
  822.     applications to communicate with one another by allowing them to
  823.     share Objective-C objects, even amongst applications running on
  824.     different machines across a network.  They are useful for
  825.     implementing client-server and cooperative applications.  The
  826.     Distributed Objects system subsumes the network aspects of typical
  827.     remote procedure call (RPC) programming, and allow an application to
  828.     send messages to remote objects using ordinary Objective-C syntax.
  829.  
  830.     The Distributed Objects system takes the form of two classes,
  831.     NXConnection and NXProxy.  NXConnection objects are primarily
  832.     bookkeepers that manage resources passed between applications.
  833.     NXProxy objects are local objects that represent remote objects.
  834.     When a remote object is passed to your application, it is passed in
  835.     the form of a proxy that stands in for the remote object; messages
  836.     to the proxy are forwarded to the remote object, so for most intents
  837.     and purposes the proxy can be treated as though it were the object
  838.     itself.  Note that direct access to instance variables of the remote
  839.     object isn't available through the proxy.
  840.  
  841.     (Introduction from the NeXTSTEP General Reference, "Distributed Objects"
  842.     reprinted with permission.  Copyright (c) 1993 NeXT Computer, Inc.
  843.     All rights reserved.)
  844.  
  845.     Indexing Kit
  846.  
  847.     The Indexing Kit is a set of programmatic tools for managing data,
  848.     especially the large amounts of data characteristic of information
  849.     intensive applications.  Much as the Application Kit provides a
  850.     framework for a graphical interface, the Indexing Kit provides a
  851.     framework for data management.
  852.  
  853.     The Indexing Kit supplies facilities for building custom databases
  854.     and for searching the UNIX file system.  Key benefits include
  855.     guaranteed data integrity, excellent performance, thread-safe
  856.     operation, tight integration with the NeXTSTEP programming
  857.     environment, and the ability to efficiently store and retrieve
  858.     Objective-C objects and unstructured data like text, sound, and
  859.     images.
  860.  
  861.     The Indexing Kit consists of:
  862.  
  863.         A transaction-oriented foundation for storing and retrieving
  864.         persistent data, using virtual memory mapping for efficient
  865.         random access to parts of a file without reading or writing the
  866.         entire file. Transactions guarantee data integrity on persistent
  867.         storage media, and are also used to manage concurrent access to
  868.         shared data.
  869.  
  870.         Fast sequential and associative access to stored data.
  871.         Associative access is untyped, in that the programmer defines
  872.         the data types of keys and their ordering by means of a
  873.         comparison function or a format string.
  874.  
  875.         A simple data management capability based on the Objective-C
  876.         run-time system.  Records can be moved efficiently between
  877.         working memory and the storage substrate in the form of
  878.         Objective-C objects.  Multiple indexes can be built over
  879.         programmer-defined attributes, so that records can be ordered
  880.         and retrieved by the values of their indexed attributes.
  881.  
  882.         A general query processing facility, including a declarative
  883.         query language and its interpreter.  Queries can be applied to
  884.         individual objects, to collections of objects, or to the
  885.         attribute/value lists produced by Indexing Kit's customizable
  886.         text processing tools.
  887.  
  888.         High-level file system searching facilities based on the
  889.         supporting layers described above, including fast literal
  890.         searching of file contents.
  891.  
  892.     (Introduction from the NeXTSTEP General Reference, "Indexing Kit"
  893.     reprinted with permission.  Copyright (c) 1993 NeXT Computer, Inc.
  894.     All rights reserved.)
  895.  
  896.     Mach Kit
  897.  
  898.     The Mach Kit provides an object-oriented interface to some of the
  899.     features of the Mach operating system.  At this time, it is most
  900.     useful to applications that make use of the Distributed Objects
  901.     system, since these applications rely upon Mach's message sending
  902.     abilities to transport objects, ports, and data between processes.
  903.     The Mach Kit may also be useful for drivers and multi threaded
  904.     applications.  The Mach Kit provides several classes and protocols,
  905.     listed below.
  906.  
  907.     (Introduction from the NeXTSTEP General Reference, "Mach Kit"
  908.     reprinted with permission.  Copyright (c) 1993 NeXT Computer, Inc.
  909.     All rights reserved.)
  910.  
  911.     NetInfo Kit
  912.  
  913.     The NetInfo Kit is a collection of classes and a single function
  914.     used to provide a connection to and interface with NetInfo domains.
  915.     The NetInfo Kit provides classes for basic interface with a domain
  916.     as well as specialized panels.
  917.  
  918.     (Introduction from the NeXTSTEP General Reference, "NetInfo Kit"
  919.     reprinted with permission.  Copyright (c) 1993 NeXT Computer, Inc.
  920.     All rights reserved.)
  921.  
  922.     3D Kit
  923.  
  924.     The 3D Graphics Kit enables NeXTSTEP applications to model and
  925.     render 3-dimensional scenes.  Much as the Application Kit's 2D
  926.     graphics capabilities are based on the Display PostScript
  927.     interpreter, the 3D Kit's capabilities are based on the Interactive
  928.     RenderMan renderer.  There are both similarities and differences in
  929.     the inner workings of the two implementations.
  930.  
  931.     One similarity is that both are implemented with a client-server
  932.     model, in which client applications send drawing code to the Window
  933.     Server, which does the actual drawing.  Another similarity is that
  934.     N3DCamera---the 3D Kit's View---generates all drawing code, both 2D
  935.     and 3D, when its drawSelf: method is invoked.  This keeps the
  936.     Application Kit's display mechanism intact for both PostScript and
  937.     RenderMan drawing.
  938.  
  939.     One difference in the implementations is in the code generated for
  940.     drawing. For 2D drawing, a View sends PostScript code to the Window
  941.     Server's Display PostScript interpreter.  For 3D drawing, a View
  942.     sends RenderMan Interface Bytestream (RIB) code to the Window
  943.     Server's Interactive RenderMan renderer.
  944.  
  945.     (Introduction from the NeXTSTEP General Reference, "3D Graphics Kit"
  946.     reprinted with permission.  Copyright (c) 1993 NeXT Computer, Inc.
  947.     All rights reserved.)
  948.  
  949.     Sound Kit
  950.  
  951.     The Sound Kit is designed to provide both low- and high-level access
  952.     to sound hardware on workstations running NeXTSTEP, including
  953.     support for a wide variety of sound formats, real-time mixing and
  954.     compression.  The Sound Kit consists of five general categories of
  955.     objects:
  956.  
  957.         Sound Device Objects
  958.     
  959.         Sound Device objects, like NXSoundIn and NXSoundOut,
  960.         wrap the low-level hardware and sound drivers into
  961.         simple, extensible packages.
  962.  
  963.         Sound Streams
  964.  
  965.         Sound Stream objects, like NXPlayStream or NXRecordStream,
  966.         allow the sound output of many simultaneous programs to be
  967.         mixed, scaled, and processed before being sent out the Sound
  968.         objects.
  969.  
  970.         The Sound Object
  971.  
  972.         The Sound object is NeXTSTEP's fundamental sound data
  973.         storage and playback/recording facility.
  974.  
  975.         The SoundView Object
  976.  
  977.         NeXTSTEP's Sound View is a graphical display of sound data
  978.         that interacts well with the NeXTSTEP GUI.
  979.  
  980.         The Sound Meter Object
  981.  
  982.         The Sound Meter displays the current running amplitude of a
  983.         playing or recording sound (in mono), much like volume
  984.         meters on amplifiers or tape decks.
  985.  
  986.     In addition to this library, NeXT provides two sets of sound driver
  987.     and sound access functions.
  988.  
  989.     NXLiveVideoView
  990.  
  991.     The NXLiveVideoView class provides API for interactive display of
  992.     live video on the screen of a NeXTdimension Computer.  The
  993.     NXLiveVideoView class specification provides a complete discussion
  994.     of the NeXTdimension Computer's video capabilities and the API
  995.     provided by NXLiveVideoView.
  996.  
  997.     (Introduction from the NeXTSTEP General Reference, "Video"
  998.     reprinted with permission.  Copyright (c) 1993 NeXT Computer, Inc.
  999.     All rights reserved.)
  1000.  
  1001.     Applications
  1002.  
  1003.     There are several classes which solely exist to enable the
  1004.     programmer to add functionality to specific existing NEXTSTEP
  1005.     applications:
  1006.  
  1007.         IBPalette, IBInspector
  1008.  
  1009.         These classes allow developers to expand the functionality
  1010.         of the Interface Builder application, creating their own
  1011.         palettes of objects that can be dragged into an interface,
  1012.         and inspectors to set and view the attributes of those
  1013.         objects.
  1014.  
  1015.         Layout
  1016.  
  1017.         This class allows developers to add their own modules to the
  1018.         Preferences application.
  1019.  
  1020.         WMInspector
  1021.  
  1022.         This class allows developers to add their own file contents
  1023.         inspectors to the Workspace Manager application.
  1024.  
  1025.     Other
  1026.  
  1027.     Before NeXTSTEP 3.0, MusicKit was distributed as part of NEXTSTEP.
  1028.     MusicKit is now maintained and made available by CCRMA (see the
  1029.     entry under `Public Domain Kits').  Also until the advent of
  1030.     NeXTSTEP 3.0, PhoneKit was part of NeXTSTEP.  PhoneKit classes
  1031.     provided easy to ISDN connections.
  1032.  
  1033.     Contact
  1034.  
  1035.     NeXT Computer, Inc.
  1036.     900 Chesapeake Drive
  1037.     Redwood City, CA 94063
  1038.     tel: +1 800 848 NEXT
  1039.     fax: +1 415 780 2801
  1040.     email: NeXTanswers@NeXT.COM
  1041.  
  1042. FSF
  1043.  
  1044.     Object
  1045.  
  1046.     Object is the root class which comes as part of the Objective-C
  1047.     runtime library provided with the GNU CC compiler.
  1048.  
  1049.     GNU Objective-C Class Library
  1050.  
  1051.     The GNU Objective C Class Library (libobjects) is a library of
  1052.     general-purpose, non-graphical Objective C objects written by
  1053.     R. Andrew McCallum.  What `libg++' is to GNU's C++, `libobjects' is
  1054.     to GNU's Objective C.
  1055.  
  1056.     The library features collection objects for maintaining groups of
  1057.     objects and C types, streams for I/O to various destinations, coders
  1058.     for formating objects and C types to byte streams, ports for network
  1059.     packet transmission, distributed objects (remote object messaging),
  1060.     pseudo-random number generators, and time handling facilities.
  1061.  
  1062.     * The heirarchy of collection objects are similar in spirit to
  1063.       Smalltalk's collections.  A deep inheritance heirarchy provides
  1064.       good uniformity of method names across different collection
  1065.       classes.  All collections can hold simple C types (such as int's
  1066.       and floats) as well as Objects.  The collection classes include
  1067.       simple collections (Set, Bag), collections with contents
  1068.       accessible by unordered keys (Dictionary, MappedCollector),
  1069.       collections with ordered contents (Array, LinkedList, Stack,
  1070.       Queue, Heap, BinaryTree, RBTree, SplayTree, GapArray).  There is
  1071.       also a DelegatePool object that can forward messages it receives
  1072.       to an arbitrary number of delegate objects.
  1073.  
  1074.     * Stream objects provide a consistent interface for reading and
  1075.       writing bytes.  `StdioStream' objects work with files, file
  1076.       descriptors, FILE pointers and pipes to/from
  1077.       executables. `MemoryStream' objects work with memory buffers that
  1078.       grow automatically as needed.  For all Stream objects there are
  1079.       methods for writing/reading arbitrary n-length buffers,
  1080.       newline-terminated lines, and printf-style strings.
  1081.  
  1082.     * Coders provide a formatted way of writing to Streams.  After a
  1083.       coder is initialized with a stream, the coder can encode/decode
  1084.       Objective C objects and C types in an architecture-independent
  1085.       way.  The currently available concrete coder classes are
  1086.       `BinaryCoder', for reading and writing a compact stream of
  1087.       illegible bytes, and `TextCoder', for reading and writing
  1088.       human-readable structured textual representation (which you can
  1089.       also process with `perl', `awk', or whatever scripting language
  1090.       you like).
  1091.  
  1092.       Coders and streams can be mixed and matched so that programmers can
  1093.       choose the destination and the format separately.
  1094.  
  1095.     * The distributed object support classes are `Connection', `Proxy',
  1096.       `ConnectedCoder', `Port' and `SocketPort'.  This version of the
  1097.       distributed objects only works with sockets.  A Mach port back-end
  1098.       should be on the way.
  1099.  
  1100.       [NOTE: The GNU distributed object facilities have the same
  1101.       ease-of-use as NeXT's; be warned, however, that they are not
  1102.       compatible with each other.  They have different class
  1103.       heirarchies, different instance variables, different method names,
  1104.       different implementation strategies and different network message
  1105.       formats.  You cannot communicate with a NeXT NXConnection using a
  1106.       GNU Connection.  NXConnection creates NXProxy objects for local
  1107.       objects as well as remote objects; GNU Connection doesn't need and
  1108.       doesn't create proxies for local objects.  NXProxy asks it's
  1109.       remote target for the method encoding types and caches the
  1110.       results; GNU Proxy gets the types directly from the local GNU
  1111.       "typed selector" mechanism and has no need for querying the remote
  1112.       target or caching encoding types.  The NXProxy for the remote root
  1113.       object always has name 0 and, once set, you cannot change the root
  1114.       object of a NXConnection; the GNU Proxy for the remote root object
  1115.       has a target address value just like all other Proxy's, and you
  1116.       can change the root object as many times as you like.  See the
  1117.       "lacking-capabilities" list below for a partial list of things
  1118.       that NXConnection can do that GNU Connection cannot.]
  1119.  
  1120.       Here is a partial list of what the current distributed objects
  1121.       system can do:
  1122.  
  1123.           * It can pass and return all simple C types, including char*, float
  1124.             and double, both by value and by reference.
  1125.           * It can pass structures by value and by reference, return
  1126.             structures by reference.  The structures can contain arrays.
  1127.           * It obeys all the type qualifiers: oneway, in, out, inout, const.
  1128.           * It can pass and return objects, either bycopy or with proxies.
  1129.             An object encoded multiple times in a single message is properly
  1130.             decoded on the other side.
  1131.           * Proxies to remote objects are automatically created as they are
  1132.             returned.  Proxies passed back where they came from are decoded
  1133.             as the correct local object.
  1134.           * It can wait for an incoming message and timeout after a
  1135.             specified period.
  1136.           * A server can handle multiple clients.
  1137.           * The server will ask its delegate before making new connections.
  1138.           * The server can make call-back requests of the client, and keep
  1139.             it all straight even when the server has multiple clients.
  1140.           * A client will automatically form a connection to another client
  1141.             if an object from the other client is vended to it. (i.e. Always
  1142.             make a direct connection rather than forwarding messages twice,
  1143.             once into the server, from there out to the other client.)
  1144.           * The server will clean up its connection to a client if the client
  1145.             says goodbye (i.e. if the client connection is freed).
  1146.           * When the connection is being freed it will send a invalidation
  1147.             notification message to those objects that have registered for
  1148.             such notification.
  1149.           * Servers and clients can be on different machines of different
  1150.             architectures; byte-order and all other architecture-dependent
  1151.             nits are taken care of for you.  You can have SPARC, i386, m68k,
  1152.             and MIPS machines all distributed-object'ing away together in
  1153.             one big web of client-server connections!
  1154.  
  1155.       Here is a partial list of what the current distributed objects
  1156.       system does *not* do:
  1157.  
  1158.           * Run multi-threaded.
  1159.           * Detect port deaths (due to remote application crash, for example)
  1160.             and do something graceful.
  1161.           * Send exceptions in the server back to the client.
  1162.           * Return structures by value.
  1163.           * Use Mach ports, pass Mach ports, pass Mach virtual memory.
  1164.           * Send messages more reliably than UDP.  It does detect reply
  1165.             timeouts and message-out-of-order conditions, but it's reaction
  1166.             is simply to abort.
  1167.           * Claim to be thoroughly tested.
  1168.  
  1169.     Getting It, and Compiling It
  1170.  
  1171.         The library is available by anonymous ftp at URL:
  1172.          ftp://prep.ai.mit.edu/pub/gnu/libobjects-0.1.0.tar.gz
  1173.         Since `prep' is heavily loaded, you are
  1174.         encouraged to use GNU mirror sites.
  1175.  
  1176.         The most recent (not necessarily tested) snapshots of the
  1177.         library will be placed at `ftp://alpha.gnu.ai.mit.edu/gnu'.
  1178.  
  1179.         The library requires gcc 2.6.1 or higher.  The library does not
  1180.         work with the NEXTSTEP 3.2 compiler because that version of
  1181.         NeXT's cc cannot handle nested functions.  Until a later release
  1182.         from NeXT, NEXTSTEP users will have to install gcc.  Also,
  1183.         temporarily, the library does not work with the NeXT Objective C
  1184.         runtime library.
  1185.  
  1186.         The library has been successfully compiled and tested with the
  1187.         following configurations: mips-sgi-irix5.2 sparc-sun-sunos4.1.3
  1188.         m68k-next-nextstep3.0.
  1189.  
  1190.         Some previous snapshots of the library worked with these
  1191.         configurations, but they haven't been tested recently:
  1192.         i386-unknown-linux i386-sun-solaris2.4 i386-unknown-sysv4.0
  1193.         sparc-sun-solaris2.3.
  1194.  
  1195.         It is known not to work with: alpha-dec-osf.
  1196.  
  1197.     Now and Future
  1198.  
  1199.         The current version is 0.1; the low number indicates that the
  1200.         library is still in flux.  A version coming soon will include
  1201.         String objects and better allocation/dealocation conventions.
  1202.  
  1203.     GNUStep
  1204.  
  1205.         The `libobjects' library already contains many of the GNUStep
  1206.         common classes: List, HashTable, Storage, NXStringTable.  In the
  1207.         future it will also contain the foundation kit classes for
  1208.         GNUStep.  Progress is already being made on this front.
  1209.  
  1210.     Contact
  1211.  
  1212.         Andrew McCallum
  1213.         mccallum@gnu.ai.mit.edu
  1214.  
  1215.     Contact
  1216.  
  1217.     Free Software Foundation
  1218.     675 Massachusetts Avenue
  1219.     Cambridge, MA  02139
  1220.     +1-617-876-3296
  1221.  
  1222.  
  1223. Third Party Kits
  1224.  
  1225.     Hot Technologies
  1226.  
  1227.     BARCODEKIT
  1228.  
  1229.         BarCodeKit is a comprehensive collection of object palettes for
  1230.         creating international standard bar codes.  BarCodeKit allows
  1231.         both developers and organizations to quickly add bar coding to
  1232.         custom NEXTSTEP applications.  By combining the power of object
  1233.         orientation and PostScript into a comprehensive library of bar
  1234.         code symbologies, BarCodeKit represents the state of the art in
  1235.         bar code technology.  Developers can seamlessly add bar coding to
  1236.         an existing application in a matter of minutes by using any of
  1237.         the 35 pretested and reusable objects in the BarCodeKit library
  1238.         of palettes.  Previously, adding bar coding to an application
  1239.         meant weeks or months of development, incompatibility with
  1240.         different bar code readers and the use of costly proprietary bar
  1241.         code printers.
  1242.  
  1243.         The BarCodeKit features a full range of bar code symbologies
  1244.         including Code 3 of 9, Code 39 Extended, UPC-A, UPC-E, HRI, NDC,
  1245.         EAN-8, EAN-13, JAN-8, JAN-13, ISBN, ISSN, SICI, SISAC, POSTNET,
  1246.         ABC, FIM, BRM, Interleaved Two of Five, MSI, Codabar, Code 11,
  1247.         Code 93, Code 128, Code 16K and Code 49.  It complies to
  1248.         international, national, military and commercial bar coding
  1249.         standards including EAN, JAN, CEN, ANSI, MIL, USS and HIBCC.
  1250.         Furthermore, it provides developers with flexibility; bar codes
  1251.         created using the kit can be scaled and rotated to fit a
  1252.         specific area on a label or document and saved in EPS, EPSI (EPS
  1253.         with interchange bitmap preview for non Display PostScript
  1254.         computers), or TIFF formats.  BarCodeKit is an excellent
  1255.         complement to NEXTSTEP's Application Kit and Database Kit It was
  1256.         nominated for a Best of Breed Award by the editors of NeXTWORLD
  1257.         Magazine.
  1258.  
  1259.     SERIALPORTKIT
  1260.  
  1261.         SerialPortKit is a fundamental class library and palette that
  1262.         makes communication with serial peripherals easy to add into
  1263.         your custom NEXTSTEP applications without any of the drawbacks
  1264.         of other solutions.  You can use SerialPortKit to communicate
  1265.         with a variety of serial peripherals such as modems, printers,
  1266.         terminals, audio/video equipment, bar code readers, magnetic
  1267.         stripe readers, controllers and data acquisition devices.  The
  1268.         SerialPortKit contains a single SerialPort class which
  1269.         interfaces to our SerialPortServer. Additional classes for
  1270.         specific peripherals are available in our SerialPeripheralsKit
  1271.         or through our consulting service.
  1272.  
  1273.         You can easily incorporate the SerialPortKit into your custom
  1274.         applications due to its professionally designed and truly
  1275.         object-oriented programming interface. The included Interface
  1276.         Builder palette, source code examples, on-line indexed reference
  1277.         manuals and tutorial further removes the tedious task of
  1278.         traditional serial port programming.  Requires SerialPortServer
  1279.         or SerialPortServer Lite which are available also from Hot
  1280.         Technologies.
  1281.  
  1282.     Contact
  1283.  
  1284.         Hot Technologies
  1285.         75 Cambridge Parkway, Suite E-504
  1286.         Cambridge, MA 02142-1238 USA
  1287.         tel: + 1 617 252 0088
  1288.         fax: + 1 617 876 8901
  1289.         email: info@hot.com (NeXTmail)
  1290.  
  1291.     Berkeley Productivity Group
  1292.  
  1293.     BPG BLOCKS
  1294.  
  1295.         BPG BLOCKS is an open extensible manufacturing framework which
  1296.         supports a variety of applications including factory definition,
  1297.         real-time tracking, real-time scheduling, short-term planning,
  1298.         shift scheduling, production planning and capacity analysis.
  1299.         BPG BLOCKS creates a virtual reality which represents the real
  1300.         factory including the people, machines, material, processes,
  1301.         their dynamics and interactions.  BPG BLOCKS is based on an easy
  1302.         to understand design where every software object represents
  1303.         either a real-world entity, or an important concept in the
  1304.         manufacturing domain.  BPG BLOCKS' object-oriented manufacturing
  1305.         model mirrors the real world, captures numerous manufacturing
  1306.         details accurately, supports commonly used abstractions, and
  1307.         allows decisions to be made based on aggregate information.  BPG
  1308.         BLOCKS forms the basis for building custom applications which
  1309.         meet the unique needs of your particular manufacturing
  1310.         facility.
  1311.  
  1312.     Objective-C Views
  1313.  
  1314.         Objective-C Views is a user interface class library for
  1315.         Microsoft Windows.
  1316.  
  1317.     Contact
  1318.  
  1319.         Christopher Lozinski
  1320.             BPG
  1321.             35032 Maidstone Court
  1322.             Newark, CA 94560
  1323.             tel: +1 510 795-6086
  1324.             fax: +1 510 795-8077
  1325.             email: info@bpg.com
  1326.  
  1327.  
  1328.     M. Onyschuk and Associates Inc.
  1329.  
  1330.     OBJECT:Math
  1331.  
  1332.         OBJECT:Math is a comprehensive set of tools and 23 Objective-C
  1333.         classes used to add extensible math and string handling to your
  1334.         custom and commercial applications:
  1335.  
  1336.         Compiler---The OBJECT:Math Compiler converts math and string
  1337.         expressions (as might be typed into a spreadsheet cell,
  1338.         plotting package, etc.) into Objective-C objects.
  1339.  
  1340.         Unbundler---The OBJECT:Math Unbundler object allows
  1341.         end-users to extend their OBJECT:Math applications with
  1342.         custom-built or third-party OBJECT:Math function bundles.
  1343.  
  1344.         User Interface Objects---OBJECT:Math comes complete with a
  1345.         Lotus Improv style function picker, a variable editor, and
  1346.         objects used to display OBJECT:Math expression trees and
  1347.         other tree structures.
  1348.  
  1349.         As product sources are available the product may even be of
  1350.         interest to non-NeXT Objective-C programmers.
  1351.  
  1352.     Contact
  1353.  
  1354.         Mark Onyschuk
  1355.         M. Onyschuk and Associates Inc.
  1356.         tel: +1 416 462 3954
  1357.         email: ask-oa@plexus.guild.org
  1358.  
  1359.  
  1360.     Stream Technologies Inc.
  1361.  
  1362.     Store
  1363.  
  1364.         Store is an Object Oriented User Level Virtual File System.
  1365.         It is described extensively in `Store - Object Oriented Virtual
  1366.         File System' by Timo Lehtinen, which is available by anonymous
  1367.         FTP from ftp.sti.fi:/pub/sti/doc/papers/store.ps.
  1368.  
  1369.     Contact
  1370.  
  1371.         Stream Technologies Inc.
  1372.         Valkj\"arventie 2
  1373.         SF-02130 Espoo
  1374.         Finland
  1375.         tel: +358 0 4357 7348
  1376.         fax: +358 0 4357 7340
  1377.         email: info@sti.fi
  1378.  
  1379.  
  1380. GPL Kits
  1381.  
  1382.    objcX
  1383.  
  1384.     An alpha version of an GNU Objective-C class library for X/Motif
  1385.     Windows is available via anonymous ftp from
  1386.  
  1387.         ftp.slac.stanford.edu:pub/sources/objcX-0.84.tar.gz.
  1388.  
  1389.     For lack of a good witty name, the library is called objcX.  The
  1390.     library requires gcc 2.6.3 or later and libobjects 0.1.0 or later.
  1391.  
  1392.     Because we built this library to support porting NeXTSTEP
  1393.     applications to X/Motif and because our GUI programming experience
  1394.     has been with NeXTSTEP, this class library has a strongly
  1395.     resemblance to NeXT's AppKit.  However, it is only a Objective-C
  1396.     wrapper to Motif widgets and does not support Display PostScript,
  1397.     rich text, pasteboard, drag and drop, services or many other things
  1398.     associated with the NeXTSTEP environment that are not available
  1399.     under X windows.
  1400.  
  1401.     From version 0.8, the nib translator is part of the objcX
  1402.     distribution, as well as some examples of using objcX.
  1403.  
  1404.     These announcements are also a call for help.  The library and the
  1405.     translator program could use much more work in two areas...
  1406.  
  1407.      - first the library could be flushed out with more features to
  1408.        support larger applications
  1409.  
  1410.      - second, I would like to contribute the library to the GNU
  1411.        project. But it is based on Motif widgets which is not free
  1412.        software.  Thus, work is needed to replace Motif widgets with
  1413.        widgets based on free software.
  1414.  
  1415.     To stay informed, join the mailing list gnustep-l@netcom.com by
  1416.     sending a subscription email to gnustep-l-request@netcom.com.
  1417.  
  1418.     Contact
  1419.  
  1420.         Paul F. Kunz    Paul_Kunz@slac.stanford.edu (NeXT mail ok)
  1421.         Stanford Linear Accelerator Center, Stanford University
  1422.         Voice: (415) 926-2884   (NeXT) Fax: (415) 926-3587
  1423.  
  1424.  
  1425.     Tcl/Objective-C Interface Library
  1426.  
  1427.     A library of Objective-C objects and support functions for
  1428.     communication between Objective-C and Tcl/Tk.  From Tcl you can send
  1429.     messages to Objective-C objects and get textual representations of
  1430.     what's returned.  Thus it provides a way to interactively type
  1431.     messages and see the results, all inside the rich structure of the
  1432.     Tcl scripting language---almost an Objective-C interpreter.  The
  1433.     library also provides an Objective-C object that will forward all of
  1434.     its messages to the Tcl interpreter in textual format.
  1435.  
  1436.     The library does NOT provide:
  1437.       * Handling arguments of non-atomic C types.
  1438.       * Tk widgets based NeXTSTEP AppKit objects.
  1439.       * The ability to create new Objective-C classes
  1440.         or methods from Tcl.
  1441.  
  1442.     The library is available by anonymous ftp at
  1443.         ftp.cs.rochester.edu:pub/libcoll/libtclobjc-1.0.tar.gz
  1444.  
  1445.     The library requires gcc (2.5.8 or higher) or NeXT's cc and tcl-7.3.
  1446.     If you have tk-3.6, the library can be configured to use it.  If you
  1447.     have libreadline, the library can be configured to use it.  Gcc and
  1448.     libreadline are available at any of the GNU archive sites; tcl and
  1449.     tk are available at ftp.cs.berkeley.edu.
  1450.  
  1451.     Contact
  1452.  
  1453.         R. Andrew McCallum            ARPA: mccallum@cs.rochester.edu
  1454.         Computer Science Department   UUCP: uunet!cs.rochester.edu!mccallum
  1455.         University of Rochester       VOX: (716) 275-2527
  1456.         Rochester, NY  14627-0226     FEET: CSB  Rm. 625
  1457.  
  1458.     Tiggr's Objective-C Library
  1459.  
  1460.     Tiggr's Objective-C Library, or tobjc for short, is a basic
  1461.     Objective-C library, whose functionality is based on Lisp.
  1462.  
  1463.     tobjc provides the following classes: LispObject, LispVector,
  1464.     Cons, Double, Integer, String, AVLTree, THashTable, StringTable,
  1465.     Trie, Lex, LexC and LexDFG.  Furthermore, tobjc includes a
  1466.     program to extract documentation from Objective-C source files.
  1467.  
  1468.     All classes are a subclass of LispObject.  The LispObject class
  1469.     provides its allocation routines and garbage collection (through
  1470.     class abstraction) to its subclasses.
  1471.  
  1472.     tobjc was undergoing continuous development.  Test releases can
  1473.     be obtained by anonymous FTP to `ftp.es.ele.tue.nl' as
  1474.     `/pub/tiggr/tobjc-x.xx.tar.gz', where `x.xx' is some version
  1475.     indication.  It is by no means finished yet, but certainly
  1476.     useful (I have used it for developing a VHDL->ASCIS DFG compiler),
  1477.     or at least interesting.
  1478.  
  1479.     I have been working on a new version which can handle messages sent
  1480.     to nil by setting something called the `objc_nil_class'.  This means
  1481.     that that particular class can receive messages while `self == nil',
  1482.     i.e. it is possible to make `[nil listp]' return YES.  If you're
  1483.     interested, mail me for a copy (it is not good enough to be released
  1484.     through ftp yet).
  1485.  
  1486.     Contact
  1487.  
  1488.         Pieter J. `Tiggr' Schoenmakers
  1489.         email: tiggr@es.ele.tue.nl
  1490.         tel: +31 40 123484
  1491.         fax: +31 40 128616
  1492.  
  1493.  
  1494. Public Domain Kits
  1495.  
  1496.     Various authors
  1497.  
  1498.     MiscKit
  1499.  
  1500.         [Abridged press release].
  1501.  
  1502.         Update to Kit of Free Objective-C Objects Is Now Available
  1503.  
  1504.         PROVO, UT, Feb 9, 1995 -- A new maintenance release of the
  1505.         MiscKit has just been publically released.  It contains many new
  1506.         objects and fixes all of the problems reported since the
  1507.         previous release. The MiscKit may be obtained via ftp to any of
  1508.         the following sites:
  1509.  
  1510.         ftp://ftp.cs.orst.edu/software/NeXT/sources/classes/MiscKit1.4.1.s.gnutar.gz
  1511.         ftp://ftp.et.byu.edu/next/misckit/MiscKit1.4.1.s.gnutar.gz
  1512.         ftp://ftp.informatik.uni-muenchen.de/pub/comp/platforms/next/Developer/objc/misckit/MiscKit1.4.1.s.gnutar.gz
  1513.  
  1514.         There are also accompanying binary packages built for various
  1515.         architectures available only at:
  1516.  
  1517.         ftp://ftp.et.byu.edu/next/misckit/MiscKit1.4.1.b.NIHS.gnutar.gz
  1518.         ftp://ftp.et.byu.edu/next/misckit/MiscKit1.4.1.b.NI.gnutar.gz
  1519.  
  1520.         The byu site always has the most recent official MiscKit
  1521.         distribution available in /pub/next/misckit and older versions
  1522.         are archived in /pub/next/misckit/old.
  1523.  
  1524.         The MiscKit is an easy to install kit consisting of Objective-C
  1525.         objects, Interface Builder palettes, bundles, and other useful
  1526.         programming resources.  All the resources in the MiscKit have
  1527.         been donated by various Internet personalities for the benefit
  1528.         of other NEXTSTEP programmers.
  1529.  
  1530.         Objects include data structures (string, tree, stack, queue,
  1531.         priority queue, linked list), interface widgets (find panel,
  1532.         textfield, button and slider subclasses, clock and calendar
  1533.         views, icon wells, progress pie/bar), macros, other useful
  1534.         objects (lock file, log file, time, stopwatch, serial port,
  1535.         colors, subprocess, remote subprocess, file), frameworks for
  1536.         building complex interfaces (MiscSwapKit, MiscInspectorKit,
  1537.         InfoMenuKit) and even some useful example applications...plus
  1538.         much more!
  1539.  
  1540.         To make the MiscKit more attractive to developers, use of the
  1541.         MiscKit resources is absolutely free of charge, no matter how
  1542.         the resources are used.  Redistribution of the MiscKit is also
  1543.         encouraged.  Many developers are reluctant to use objects which
  1544.         are under the GNU "Copyleft".  As a result, the MiscKit has its
  1545.         own license which allows developers to reuse the code freely,
  1546.         even in commercial projects.  Everything possible has been done
  1547.         to encourage the use of the MiscKit to speed development
  1548.         efforts.
  1549.  
  1550.         Any developer who has generally useful objects, palettes, or
  1551.         other programming resources and would like to donate them to the
  1552.         MiscKit effort is welcome to do so.  Contact
  1553.         Don_Yacktman@byu.edu for information on how to prepare a MiscKit
  1554.         submission.  By making a submission to the MiscKit, a developer
  1555.         can avoid the hassles of packaging up a formal distribution of
  1556.         their resources and in turn help add to a growing centralized
  1557.         pool of useful resources.
  1558.  
  1559.         Several MiscKit-based mailing lists are also available.  The
  1560.         first list is for those who are interested in participating in
  1561.         the development of the MiscKit.  Anyone who is interested in
  1562.         following the discussion should send mail to
  1563.         misckit-request@byu.edu to be placed on the list.  Send mail to
  1564.         misckit@byu.edu to post messages to this list.  The second
  1565.         MiscKit mailing list is for distributing announcements of new
  1566.         MiscKit releases.  Anyone who would like to receive e-mail
  1567.         notification of new MiscKit releases should send mail to the
  1568.         MiscKit administrator, Don_Yacktman@byu.edu, and request to be
  1569.         placed on the MiscKit release list.  Anyone on the development
  1570.         list already receives notification of new releases and should
  1571.         therefore not ask to be added to the release list.  Two other
  1572.         lists are mentioned in the MiscKit's top level README.rtf file.
  1573.  
  1574.         The MiscKit has evolved from the DAYMiscKit and several objects
  1575.         released over the past few years by Don Yacktman and other
  1576.         USENET personalities.
  1577.  
  1578.     Contact
  1579.  
  1580.         For more information or to be placed on the MiscKit discussion
  1581.         list, contact the kit administrator, Don Yacktman, by sending
  1582.         e-mail to Don_Yacktman@byu.edu.
  1583.  
  1584.     CCRMA
  1585.  
  1586.     MusicKit
  1587.  
  1588.         The Music Kit provides tools for designing music
  1589.         applications. These tools address three topics: music
  1590.         representation, performance, and synthesis (digital sound
  1591.         generation and processing).  The Objective-C classes defined in
  1592.         the Music Kit fall neatly into these three areas.
  1593.  
  1594.         The design goal of the Music Kit is to combine the interactive
  1595.         gestural control of MIDI with the precise timbral control of
  1596.         MUSIC 5-type systems in an extensible, object-oriented
  1597.         environment. To this end, the Music Kit is capable of fully
  1598.         representing MIDI.  The Music Kit accepts MIDI in and can send
  1599.         MIDI out through the two serial ports at the back of the
  1600.         computer. Nonetheless, the Music Kit isn't limited by the MIDI
  1601.         specification; for example, its resolution of frequency and
  1602.         amplitude is much finer than MIDI's highly quantized values.
  1603.  
  1604.         The Music Kit generates sounds by sending synthesis instructions
  1605.         to the DSP.  The generality of the synthesis software far
  1606.         surpasses that of commercial synthesizers.  While most
  1607.         synthesizers employ only one type of synthesis-the Yamaha DX-7
  1608.         uses only frequency modulation, for example-the Music Kit can
  1609.         implement virtually any sound synthesis strategy.  And since the
  1610.         synthesis engine (the DSP) and the control stream are brought
  1611.         together in a single high-performance computer, the Music Kit
  1612.         makes possible an unprecedented level of expressive control.
  1613.         (from Documentation/MusicKit+DSP/General/SoundMusicDSP.rtfd)
  1614.  
  1615.         MusicKit used to be supplied by NeXT as part of NeXTSTEP (pre
  1616.         3.0).  It is now maintained by CCRMA and available in two
  1617.         packages:
  1618.  
  1619.         ftp://ccrma-ftp.stanford.edu/pub/NeXT/MusicKit_4.1.1.pkg.tar
  1620.  
  1621.             NI-fat Class library, header files, documentation,
  1622.             programming examples, and a suite of applications
  1623.             (size = 13MB).
  1624.  
  1625.           ftp://ccrma-ftp.stanford.edu/pub/NeXT/MusicKitSource_4.1.1.pkg.tar
  1626.  
  1627.             Source of the MusicKit class library (size = 5MB).
  1628.  
  1629.     Contact
  1630.  
  1631.         email: musickit@ccrma.stanford.edu
  1632.  
  1633.  
  1634. ADMINISTRATIVIA
  1635.  
  1636.     The information in this file comes AS IS, WITHOUT ANY WARRANTY.  You may
  1637.     use the information contained in this file or distribute this file, as
  1638.     long as you do not modify it, make money out of it or take the credits.
  1639.  
  1640.     All trademarks appearing in this file are owned by their respective
  1641.     owner.  To increase the information content in this file, any indication
  1642.     to that effect is not present in the FAQ other than in this paragraph.
  1643.  
  1644. The first version of this FAQ was written by Bill Shirly, helped by the
  1645. feedback and information given to him by a lot of people.  The current
  1646. version is maintained by Tiggr, supported by feedback from Glen Diener,
  1647. Christopher Lozinski, Sean Luke and a lot of other people.  Mail your bug
  1648. reports, comments, suggestions and additions to tiggr@es.ele.tue.nl.
  1649.  
  1650. A World Wide Web hypertext version of this FAQ is maintained by Brian Harvey
  1651. (theharv@csld.ucr.edu) and can be found at:
  1652.     http://csld.ucr.edu/NeXTSTEP/objc_faq.html
  1653. Archive-name: Objective-C/sample
  1654. Version: $Id: sample.preamble,v 1.1.1.1 1995/01/02 11:58:30 tiggr Exp $
  1655.  
  1656.  
  1657.         A simple sample
  1658.         Objective-C program
  1659.  
  1660.  
  1661. This is the third part in a series of three informational postings
  1662. concerning comp.lang.objective-c.  This article presents a simple program
  1663. written in Objective-C.  The program consist of several files which are
  1664. contained in a shar file (see instructions below on how to unpack).  [Note,
  1665. from version 2.3 of this file, the sample has been changed in order to
  1666. reduce the number of compiler warnings (down to 1, which is in there for
  1667. explanatory purposes) and to reflect the use of `+alloc' and `-init' instead
  1668. of `+new'.]
  1669.  
  1670. The early version of this FAQ was compiled by Bill Shirley, with the aid of
  1671. many people.  The current version is being maintained by Tiggr, aided by a
  1672. lot of people, including Paul Sanchez and Bill Shirley.
  1673.  
  1674. A World Wide Web hypertext version of this FAQ is maintained by Brian Harvey
  1675. (theharv@csld.ucr.edu) and can be found at:
  1676.     http://csld.ucr.edu/NeXTSTEP/objc_faq.html
  1677.  
  1678. Send your suggestions, additions, bug reports, comments and fixes to
  1679. `tiggr@es.ele.tue.nl'.
  1680.  
  1681.  
  1682. #---------------------------------- cut here ----------------------------------
  1683. # This is a shell archive.  Remove anything before this line,
  1684. # then unpack it by saving it in a file and typing "sh file".
  1685. #
  1686. # Wrapped by Pieter Schoenmakers <tiggr@cobra> on Mon Jan  2 12:58:50 1995
  1687. #
  1688. # This archive contains:
  1689. #    objc-sample    
  1690. #
  1691. # Existing files will not be overwritten.
  1692. # Error checking via wc(1) will be performed.
  1693.  
  1694. LANG=""; export LANG
  1695. PATH=/bin:/usr/bin:$PATH; export PATH
  1696.  
  1697. echo mkdir - objc-sample
  1698. mkdir objc-sample
  1699.  
  1700. if test -f objc-sample/COPYRIGHT
  1701. then
  1702.     echo Ok to overwrite existing file objc-sample/COPYRIGHT\?
  1703.     read answer
  1704.     case "$answer" in
  1705.     [yY]*)    echo Proceeding;;
  1706.     *)    echo Aborting; exit 1;;
  1707.     esac
  1708.     rm -f objc-sample/COPYRIGHT
  1709.     if test -f objc-sample/COPYRIGHT
  1710.     then
  1711.         echo Error: could not remove objc-sample/COPYRIGHT, aborting
  1712.         exit 1
  1713.     fi
  1714. fi
  1715. echo x - objc-sample/COPYRIGHT
  1716. cat >objc-sample/COPYRIGHT <<'@EOF'
  1717. This copyright notice applies to all source files distributed in the
  1718. comp.lang.objective-c FAQ: `A Simple Sample Objective-C program'.
  1719.  
  1720. Copyright (C) 1993 Paul J. Sanchez and Bill Shirley
  1721. Copyright (C) 1994 Pieter J. Schoenmakers
  1722.  
  1723. The `simple sample Objective-C program' is free software; you can
  1724. redistribute it and/or modify it under the terms of the GNU General Public
  1725. License as published by the Free Software Foundation; either version 2, or
  1726. (at your option) any later version.
  1727.  
  1728. The `simple sample Objective-C program' is distributed in the hope that it
  1729. will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty
  1730. of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
  1731. Public License for more details.
  1732.  
  1733. You should have received a copy of the GNU General Public License
  1734. along with GNU Emacs; see the file COPYING.  If not, write to
  1735. the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
  1736. @EOF
  1737. set `wc -lwc <objc-sample/COPYRIGHT`
  1738. if test $1$2$3 != 19150944
  1739. then
  1740.     echo ERROR: wc results of objc-sample/COPYRIGHT are $* should be 19 150 944
  1741. fi
  1742.  
  1743. chmod 644 objc-sample/COPYRIGHT
  1744.  
  1745. if test -f objc-sample/Char.h
  1746. then
  1747.     echo Ok to overwrite existing file objc-sample/Char.h\?
  1748.     read answer
  1749.     case "$answer" in
  1750.     [yY]*)    echo Proceeding;;
  1751.     *)    echo Aborting; exit 1;;
  1752.     esac
  1753.     rm -f objc-sample/Char.h
  1754.     if test -f objc-sample/Char.h
  1755.     then
  1756.         echo Error: could not remove objc-sample/Char.h, aborting
  1757.         exit 1
  1758.     fi
  1759. fi
  1760. echo x - objc-sample/Char.h
  1761. cat >objc-sample/Char.h <<'@EOF'
  1762. #import <objc/Object.h>
  1763.  
  1764. @interface Char: Object
  1765. {
  1766.   int value;
  1767. }
  1768.  
  1769. -init: (int) x;
  1770. -report;
  1771.  
  1772. @end
  1773. @EOF
  1774. set `wc -lwc <objc-sample/Char.h`
  1775. if test $1$2$3 != 111498
  1776. then
  1777.     echo ERROR: wc results of objc-sample/Char.h are $* should be 11 14 98
  1778. fi
  1779.  
  1780. chmod 644 objc-sample/Char.h
  1781.  
  1782. if test -f objc-sample/Char.m
  1783. then
  1784.     echo Ok to overwrite existing file objc-sample/Char.m\?
  1785.     read answer
  1786.     case "$answer" in
  1787.     [yY]*)    echo Proceeding;;
  1788.     *)    echo Aborting; exit 1;;
  1789.     esac
  1790.     rm -f objc-sample/Char.m
  1791.     if test -f objc-sample/Char.m
  1792.     then
  1793.         echo Error: could not remove objc-sample/Char.m, aborting
  1794.         exit 1
  1795.     fi
  1796. fi
  1797. echo x - objc-sample/Char.m
  1798. cat >objc-sample/Char.m <<'@EOF'
  1799. #import <stdio.h>
  1800. #import "Char.h"
  1801.  
  1802. @implementation Char
  1803. {
  1804.   int value;
  1805. }
  1806.  
  1807. - init: (int) x
  1808. {
  1809.   [super init];        // In case the parent class is doing
  1810.               // something special in its init...
  1811.   value = x;
  1812.   return self;
  1813. }
  1814.  
  1815. - report
  1816. {
  1817.   printf("   %c", value);
  1818.   return self;
  1819. }
  1820.  
  1821. @end
  1822. @EOF
  1823. set `wc -lwc <objc-sample/Char.m`
  1824. if test $1$2$3 != 2347279
  1825. then
  1826.     echo ERROR: wc results of objc-sample/Char.m are $* should be 23 47 279
  1827. fi
  1828.  
  1829. chmod 644 objc-sample/Char.m
  1830.  
  1831. if test -f objc-sample/Float.h
  1832. then
  1833.     echo Ok to overwrite existing file objc-sample/Float.h\?
  1834.     read answer
  1835.     case "$answer" in
  1836.     [yY]*)    echo Proceeding;;
  1837.     *)    echo Aborting; exit 1;;
  1838.     esac
  1839.     rm -f objc-sample/Float.h
  1840.     if test -f objc-sample/Float.h
  1841.     then
  1842.         echo Error: could not remove objc-sample/Float.h, aborting
  1843.         exit 1
  1844.     fi
  1845. fi
  1846. echo x - objc-sample/Float.h
  1847. cat >objc-sample/Float.h <<'@EOF'
  1848. #import <objc/Object.h>
  1849.  
  1850. @interface Float: Object
  1851. {
  1852.   float value;
  1853. }
  1854.  
  1855. -initFloatValue: (float) x;
  1856. -report;
  1857.  
  1858. @end
  1859. @EOF
  1860. set `wc -lwc <objc-sample/Float.h`
  1861. if test $1$2$3 != 1114113
  1862. then
  1863.     echo ERROR: wc results of objc-sample/Float.h are $* should be 11 14 113
  1864. fi
  1865.  
  1866. chmod 644 objc-sample/Float.h
  1867.  
  1868. if test -f objc-sample/Float.m
  1869. then
  1870.     echo Ok to overwrite existing file objc-sample/Float.m\?
  1871.     read answer
  1872.     case "$answer" in
  1873.     [yY]*)    echo Proceeding;;
  1874.     *)    echo Aborting; exit 1;;
  1875.     esac
  1876.     rm -f objc-sample/Float.m
  1877.     if test -f objc-sample/Float.m
  1878.     then
  1879.         echo Error: could not remove objc-sample/Float.m, aborting
  1880.         exit 1
  1881.     fi
  1882. fi
  1883. echo x - objc-sample/Float.m
  1884. cat >objc-sample/Float.m <<'@EOF'
  1885. #import <stdio.h>
  1886. #import "Float.h"
  1887.  
  1888. @implementation Float
  1889. {
  1890.   float value;
  1891. }
  1892.  
  1893. -initFloatValue: (float) x
  1894. {
  1895.   [super init];
  1896.   value = x;
  1897.   return self;
  1898. }
  1899.  
  1900. -report
  1901. {
  1902.   printf ("%4.1f", value);
  1903.   return self;
  1904. }
  1905.  
  1906. @end
  1907. @EOF
  1908. set `wc -lwc <objc-sample/Float.m`
  1909. if test $1$2$3 != 2231215
  1910. then
  1911.     echo ERROR: wc results of objc-sample/Float.m are $* should be 22 31 215
  1912. fi
  1913.  
  1914. chmod 644 objc-sample/Float.m
  1915.  
  1916. if test -f objc-sample/Makefile
  1917. then
  1918.     echo Ok to overwrite existing file objc-sample/Makefile\?
  1919.     read answer
  1920.     case "$answer" in
  1921.     [yY]*)    echo Proceeding;;
  1922.     *)    echo Aborting; exit 1;;
  1923.     esac
  1924.     rm -f objc-sample/Makefile
  1925.     if test -f objc-sample/Makefile
  1926.     then
  1927.         echo Error: could not remove objc-sample/Makefile, aborting
  1928.         exit 1
  1929.     fi
  1930. fi
  1931. echo x - objc-sample/Makefile
  1932. cat >objc-sample/Makefile <<'@EOF'
  1933. # This Makefile assumes you have GNU gcc 2.3 or better and a suitable
  1934. # runtime library with object support.  It also works on a NeXT.
  1935. # Don't know about Stepstone.
  1936.  
  1937. .SUFFIXES: .o .m
  1938. .m.o:
  1939.     $(CC) -c $(CFLAGS) $<
  1940.  
  1941. # Use this on a NeXT
  1942. #CC=        cc
  1943. #LIBS=        
  1944. # Use this with GNU CC on a non-NeXT,
  1945. # and avoid the GCC moaning on using #import.
  1946. CC=        gcc -Wno-import
  1947. LIBS=        -lobjc
  1948. LDFLAGS=    -L/usr/local/lib -L/usr/gnu/lib
  1949.  
  1950. CFLAGS=        -Wall -g
  1951. OFILES=        main.o Node.o Queue.o Stack.o Float.o Char.o
  1952.  
  1953. demo: $(OFILES)
  1954.     $(CC) $(CFLAGS) $(LDFLAGS) -o demo $(OFILES) $(LIBS)
  1955.  
  1956. clean:
  1957.     rm -f $(OFILES) demo
  1958.     
  1959. Char.o : Char.m Char.h 
  1960.  
  1961. Float.o : Float.m Float.h 
  1962.  
  1963. Node.o : Node.m Node.h 
  1964.  
  1965. Queue.o : Queue.m Queue.h Node.h 
  1966.  
  1967. Stack.o : Stack.m Stack.h Node.h 
  1968.  
  1969. main.o : main.m Queue.h Node.h Stack.h Float.h
  1970. @EOF
  1971. set `wc -lwc <objc-sample/Makefile`
  1972. if test $1$2$3 != 37127783
  1973. then
  1974.     echo ERROR: wc results of objc-sample/Makefile are $* should be 37 127 783
  1975. fi
  1976.  
  1977. chmod 644 objc-sample/Makefile
  1978.  
  1979. if test -f objc-sample/Node.h
  1980. then
  1981.     echo Ok to overwrite existing file objc-sample/Node.h\?
  1982.     read answer
  1983.     case "$answer" in
  1984.     [yY]*)    echo Proceeding;;
  1985.     *)    echo Aborting; exit 1;;
  1986.     esac
  1987.     rm -f objc-sample/Node.h
  1988.     if test -f objc-sample/Node.h
  1989.     then
  1990.         echo Error: could not remove objc-sample/Node.h, aborting
  1991.         exit 1
  1992.     fi
  1993. fi
  1994. echo x - objc-sample/Node.h
  1995. cat >objc-sample/Node.h <<'@EOF'
  1996. #import <objc/Object.h>
  1997.  
  1998. @interface Node : Object
  1999. {
  2000.   id next;
  2001.   id data;
  2002. }
  2003.  
  2004. -init: anItem;        // create a Node and store anItem in it
  2005. -free;            // free a Node and return the item in it
  2006. -next;            // report the id of the next node after this one
  2007. -setNext: aNode;    // make the next node be aNode
  2008.  
  2009. @end
  2010. @EOF
  2011. set `wc -lwc <objc-sample/Node.h`
  2012. if test $1$2$3 != 1456295
  2013. then
  2014.     echo ERROR: wc results of objc-sample/Node.h are $* should be 14 56 295
  2015. fi
  2016.  
  2017. chmod 644 objc-sample/Node.h
  2018.  
  2019. if test -f objc-sample/Node.m
  2020. then
  2021.     echo Ok to overwrite existing file objc-sample/Node.m\?
  2022.     read answer
  2023.     case "$answer" in
  2024.     [yY]*)    echo Proceeding;;
  2025.     *)    echo Aborting; exit 1;;
  2026.     esac
  2027.     rm -f objc-sample/Node.m
  2028.     if test -f objc-sample/Node.m
  2029.     then
  2030.         echo Error: could not remove objc-sample/Node.m, aborting
  2031.         exit 1
  2032.     fi
  2033. fi
  2034. echo x - objc-sample/Node.m
  2035. cat >objc-sample/Node.m <<'@EOF'
  2036. #import <objc/Object.h>
  2037. #import "Node.h"
  2038.  
  2039. @implementation    Node: Object
  2040.  
  2041. -init: anItem
  2042. {
  2043.   self = [super init];
  2044.   next = 0;
  2045.   data = anItem;
  2046.   return self;
  2047. }
  2048.  
  2049. -free
  2050. {
  2051.   id tmp = data;
  2052.   [super free];
  2053.   return tmp;
  2054. }
  2055.  
  2056. -next
  2057. {
  2058.   return next;
  2059. }
  2060.  
  2061. -setNext: aNode
  2062. {
  2063.   next = aNode;
  2064.   return self;
  2065. }
  2066.  
  2067. @end
  2068. @EOF
  2069. set `wc -lwc <objc-sample/Node.m`
  2070. if test $1$2$3 != 3249299
  2071. then
  2072.     echo ERROR: wc results of objc-sample/Node.m are $* should be 32 49 299
  2073. fi
  2074.  
  2075. chmod 644 objc-sample/Node.m
  2076.  
  2077. if test -f objc-sample/Queue.h
  2078. then
  2079.     echo Ok to overwrite existing file objc-sample/Queue.h\?
  2080.     read answer
  2081.     case "$answer" in
  2082.     [yY]*)    echo Proceeding;;
  2083.     *)    echo Aborting; exit 1;;
  2084.     esac
  2085.     rm -f objc-sample/Queue.h
  2086.     if test -f objc-sample/Queue.h
  2087.     then
  2088.         echo Error: could not remove objc-sample/Queue.h, aborting
  2089.         exit 1
  2090.     fi
  2091. fi
  2092. echo x - objc-sample/Queue.h
  2093. cat >objc-sample/Queue.h <<'@EOF'
  2094. #import <objc/Object.h>
  2095. #import "Node.h"
  2096.  
  2097. @interface Queue: Object
  2098. {
  2099.   id head;
  2100.   id tail;
  2101.   unsigned qsize;
  2102. }
  2103.  
  2104. -empty;            // clear out all contents of the Queue
  2105. -put: anItem;        // put anItem on the Queue
  2106. -get;            // return the item on top of the Queue
  2107. -(unsigned int) size;    // tell us the current size of the Queue
  2108.  
  2109. @end
  2110. @EOF
  2111. set `wc -lwc <objc-sample/Queue.h`
  2112. if test $1$2$3 != 1655319
  2113. then
  2114.     echo ERROR: wc results of objc-sample/Queue.h are $* should be 16 55 319
  2115. fi
  2116.  
  2117. chmod 644 objc-sample/Queue.h
  2118.  
  2119. if test -f objc-sample/Queue.m
  2120. then
  2121.     echo Ok to overwrite existing file objc-sample/Queue.m\?
  2122.     read answer
  2123.     case "$answer" in
  2124.     [yY]*)    echo Proceeding;;
  2125.     *)    echo Aborting; exit 1;;
  2126.     esac
  2127.     rm -f objc-sample/Queue.m
  2128.     if test -f objc-sample/Queue.m
  2129.     then
  2130.         echo Error: could not remove objc-sample/Queue.m, aborting
  2131.         exit 1
  2132.     fi
  2133. fi
  2134. echo x - objc-sample/Queue.m
  2135. cat >objc-sample/Queue.m <<'@EOF'
  2136. #import "Queue.h"
  2137.  
  2138. @implementation    Queue
  2139.  
  2140. -empty
  2141. {
  2142.   while([self size])
  2143.     [[self get] free];
  2144.   return self;
  2145. }
  2146.  
  2147. -put: anItem
  2148. {
  2149.   if (tail)
  2150.     tail = [[tail setNext : [[Node alloc] init: anItem]] next];
  2151.   else
  2152.     head = tail = [[Node alloc] init: anItem];
  2153.   ++qsize;
  2154.   return self;
  2155. }
  2156.  
  2157. -get
  2158. {
  2159.   id contents;
  2160.   id old_head = head;
  2161.  
  2162.   head = [head next];
  2163.   contents = [old_head free];
  2164.   if (--qsize == 0)
  2165.     tail = head;
  2166.   return contents;
  2167. }
  2168.  
  2169. -(unsigned) size
  2170. {
  2171.   return qsize;
  2172. }
  2173.  
  2174. @end
  2175. @EOF
  2176. set `wc -lwc <objc-sample/Queue.m`
  2177. if test $1$2$3 != 3975486
  2178. then
  2179.     echo ERROR: wc results of objc-sample/Queue.m are $* should be 39 75 486
  2180. fi
  2181.  
  2182. chmod 644 objc-sample/Queue.m
  2183.  
  2184. if test -f objc-sample/README
  2185. then
  2186.     echo Ok to overwrite existing file objc-sample/README\?
  2187.     read answer
  2188.     case "$answer" in
  2189.     [yY]*)    echo Proceeding;;
  2190.     *)    echo Aborting; exit 1;;
  2191.     esac
  2192.     rm -f objc-sample/README
  2193.     if test -f objc-sample/README
  2194.     then
  2195.         echo Error: could not remove objc-sample/README, aborting
  2196.         exit 1
  2197.     fi
  2198. fi
  2199. echo x - objc-sample/README
  2200. cat >objc-sample/README <<'@EOF'
  2201. This directory contains the complete code for the "Simple Sample Objective-C
  2202. program" described in the comp.lang.objective-c FAQ.  If you have a suitable
  2203. compiler, use the supplied Makefile.  Otherwise, program output can be found
  2204. in the file "output".
  2205.  
  2206. You should probably read "main.m" first.  It is very heavily annotated.
  2207.  
  2208. Also note and read the file COPYRIGHT.
  2209. @EOF
  2210. set `wc -lwc <objc-sample/README`
  2211. if test $1$2$3 != 855366
  2212. then
  2213.     echo ERROR: wc results of objc-sample/README are $* should be 8 55 366
  2214. fi
  2215.  
  2216. chmod 644 objc-sample/README
  2217.  
  2218. if test -f objc-sample/Stack.h
  2219. then
  2220.     echo Ok to overwrite existing file objc-sample/Stack.h\?
  2221.     read answer
  2222.     case "$answer" in
  2223.     [yY]*)    echo Proceeding;;
  2224.     *)    echo Aborting; exit 1;;
  2225.     esac
  2226.     rm -f objc-sample/Stack.h
  2227.     if test -f objc-sample/Stack.h
  2228.     then
  2229.         echo Error: could not remove objc-sample/Stack.h, aborting
  2230.         exit 1
  2231.     fi
  2232. fi
  2233. echo x - objc-sample/Stack.h
  2234. cat >objc-sample/Stack.h <<'@EOF'
  2235. #import <objc/Object.h>
  2236. #import "Node.h"
  2237.  
  2238. @interface Stack: Object
  2239. {
  2240.   id stack;
  2241.   unsigned int stack_size;
  2242. }
  2243.  
  2244. -empty;                // clear out all contents of the Stack
  2245. -put: anItem;            // put anItem on the Stack
  2246. -get;                // return the item on top of the Stack
  2247. -(unsigned) size;        // tell us the current size of the Stack
  2248.  
  2249. @end
  2250. @EOF
  2251. set `wc -lwc <objc-sample/Stack.h`
  2252. if test $1$2$3 != 1553318
  2253. then
  2254.     echo ERROR: wc results of objc-sample/Stack.h are $* should be 15 53 318
  2255. fi
  2256.  
  2257. chmod 644 objc-sample/Stack.h
  2258.  
  2259. if test -f objc-sample/Stack.m
  2260. then
  2261.     echo Ok to overwrite existing file objc-sample/Stack.m\?
  2262.     read answer
  2263.     case "$answer" in
  2264.     [yY]*)    echo Proceeding;;
  2265.     *)    echo Aborting; exit 1;;
  2266.     esac
  2267.     rm -f objc-sample/Stack.m
  2268.     if test -f objc-sample/Stack.m
  2269.     then
  2270.         echo Error: could not remove objc-sample/Stack.m, aborting
  2271.         exit 1
  2272.     fi
  2273. fi
  2274. echo x - objc-sample/Stack.m
  2275. cat >objc-sample/Stack.m <<'@EOF'
  2276. #import "Stack.h"
  2277.  
  2278. @implementation    Stack
  2279.  
  2280. -empty
  2281. {
  2282.   while([self size])
  2283.     [[self get] free];
  2284.   return self;
  2285. }
  2286.  
  2287. -put: anItem
  2288. {
  2289.   stack = [[[Node alloc] init: anItem] setNext : stack];
  2290.   ++stack_size;
  2291.   return self;
  2292. }
  2293.  
  2294. -get
  2295. {
  2296.   id contents;
  2297.   id old_stack = stack;
  2298.  
  2299.   stack = [stack next];
  2300.   contents = [old_stack free];
  2301.   --stack_size;
  2302.   return contents;
  2303. }
  2304.  
  2305. -(unsigned) size
  2306. {
  2307.   return stack_size;
  2308. }
  2309.  
  2310. @end
  2311. @EOF
  2312. set `wc -lwc <objc-sample/Stack.m`
  2313. if test $1$2$3 != 3557407
  2314. then
  2315.     echo ERROR: wc results of objc-sample/Stack.m are $* should be 35 57 407
  2316. fi
  2317.  
  2318. chmod 644 objc-sample/Stack.m
  2319.  
  2320. if test -f objc-sample/main.m
  2321. then
  2322.     echo Ok to overwrite existing file objc-sample/main.m\?
  2323.     read answer
  2324.     case "$answer" in
  2325.     [yY]*)    echo Proceeding;;
  2326.     *)    echo Aborting; exit 1;;
  2327.     esac
  2328.     rm -f objc-sample/main.m
  2329.     if test -f objc-sample/main.m
  2330.     then
  2331.         echo Error: could not remove objc-sample/main.m, aborting
  2332.         exit 1
  2333.     fi
  2334. fi
  2335. echo x - objc-sample/main.m
  2336. cat >objc-sample/main.m <<'@EOF'
  2337. /* main.m - comp.lang.objective-c simple sample Objective-C program.  */
  2338.  
  2339. // This is a comment, just like the previous line.  Everything to the right
  2340. // of a double slash is ignored.
  2341.  
  2342. /* Classes are the one real extension which Objective-C adds to C.  A class
  2343.    is a description of a collection of data, like a C structure, and the
  2344.    methods by which that data may be accessed or manipulated.  Instances of
  2345.    a class are called objects, and methods are invoked by sending messages
  2346.    to either the class itself, to produce objects, or to those objects.  The
  2347.    recipient of a message is called a "receiver".  The form of a message is:
  2348.  
  2349.     [receiver method andMaybeSomeArguments]
  2350.  
  2351.    the receiver and method components are mandatory, as are the square
  2352.    brackets surrounding the message.  Additional arguments may or may not be
  2353.    present, depending upon the method definition.  Messages may appear
  2354.    anywhere a statement is allowed in C.
  2355.  
  2356.    The first thing we do is bring in some include files, as in C.  On the
  2357.    NeXT, it is customary to use the "import" statement which guarantees that
  2358.    the file isn't included more than once.  Using GNU CC this is not all
  2359.    that nice sinds it generates a huge warning for every file being
  2360.    compiled.  So, since it does not really matter, we'll stick to
  2361.    `#include'.  */
  2362.  
  2363. #import <stdio.h>
  2364. #import <objc/Object.h>
  2365. #import "Queue.h"
  2366. #import "Stack.h"
  2367.  
  2368. /* That brought in class definitions for Objects, Queues, and Stacks.  The
  2369.    Object class is the basis for all other classes, which is why it gets
  2370.    brought in first.  It provides basic functional behavior which is
  2371.    inherited by all derived classes.  All user created classes normally have
  2372.    Object somewhere in their ancestry.
  2373.  
  2374.    Queue and Stack are classes of our own construction, and provide FIFO and
  2375.    LIFO storage capabilities, respectively.  I'm not going to go into
  2376.    implementation details here.  It's irrelevant how they work, all that is
  2377.    important is that they both respond to 'put:' and 'get'.  If you want to
  2378.    inspect them, look into the Queue.m, Stack.m, Queue.h and Stack.h files.
  2379.  
  2380.    A simple Class definition follows.  It inherits directly from the base
  2381.    class "Object".  This gives it lots of nice properties, not the least of
  2382.    which is the ability to be referenced by any pointer of the generic
  2383.    object type "id".  All objects can be pointed to by any id variable, and
  2384.    the default return type from methods is id.  This allows messages to be
  2385.    embedded in other messages, either as receivers or arguments.
  2386.  
  2387.    An Int object allocates space for a single integer.  The "report" message
  2388.    causes it to report its value.  Everything between the @implementation
  2389.    and the @end is part of the class definition.
  2390.  
  2391.    Note - It is *highly* unusual to have a class implementation in your main
  2392.    program.  Since the object is fully defined before it gets used, no
  2393.    interface description is required.  There is nothing illegal about doing
  2394.    things this way, but it is so unusual that the compiler will produce a
  2395.    warning for this class.  The Int class implementation is here solely for
  2396.    expository purposes.  */
  2397.  
  2398. @implementation Int: Object    // Int is derived from Object
  2399. {
  2400.     int value;        // This is the data portion.  Like a struct.
  2401. }
  2402.  
  2403. /* The following are the method definitions.  A `+' prefix means it is a
  2404.    factory method, i.e., how to manufacture instances of the class.  The
  2405.    body of the method is between braces, like a C function.
  2406.  
  2407.    This class doesn't define any factory methods.  It relies on the +alloc
  2408.    method defined in class Object.  For examples of factory methods, look at
  2409.    the +new method defined in the Stack or Queue implementations.
  2410.  
  2411.    Self is a special variable, which refers to the object currently being
  2412.    manipulated.  Super refers to the parent class of self.  The following
  2413.    method asks the parent class (Object) to hand us a new instance, which
  2414.    becomes self.  Then we update the instance variables and return a pointer
  2415.    to the new object.
  2416.  
  2417.    It is standard for methods that do not need to return any special value
  2418.    to instead return self.  This allows for a nested syntax of method calls.
  2419.  
  2420.    The "-" in front of init means that it's an instance method, i.e.,
  2421.    something a particular object should respond to.  */
  2422.  
  2423. -init: (int) i
  2424. {
  2425.   /* We're overriding the `-init' of our superclass, but we add
  2426.      functionality instead of replacing it.  Therefore, first call the
  2427.      `-init' of our superclass.  */
  2428.   [super init];
  2429.   value = i;
  2430.   return self;
  2431. }
  2432.  
  2433. -report
  2434. {
  2435.   printf ("%4d", value);
  2436.   return self;
  2437. }
  2438.  
  2439. @end
  2440.  
  2441. /* We have implemented Float and Char classes more traditionally, using
  2442.    separate files for the interface (.h) and implementation (.m).  The Float
  2443.    and Char objects are like the Int object, but with the obvious difference
  2444.    that they work with floats and characters.  We include the interface
  2445.    definitions at this point.  */
  2446.  
  2447. #import "Float.h"
  2448. #import "Char.h"
  2449.  
  2450. /* If you inspect those files, note polymorphism -- methods have same
  2451.    names as in the Int class.  */
  2452.  
  2453. int main (void)
  2454. {
  2455.     /* First create instances of "Stack" and "Queue" data structures.  */
  2456.     id queue = [[Queue alloc] init];
  2457.     id stack = [[Stack alloc] init];
  2458.     int i, reply;
  2459.     
  2460.     fprintf (stderr, "Include the Char class in the demo? (y/n): ");
  2461.  
  2462.     /* Anything not matching `y.*' means no.  */
  2463.     reply = getchar ();
  2464.  
  2465.     for (i = 5; i > -6; --i)
  2466.       {
  2467.     /* Depending on which version of the demo we're running, we
  2468.        alternately put Ints and Floats onto the queue and stack, or
  2469.        Ints, Floats, and Chars.  */
  2470.     if (reply == 'y')
  2471.       {
  2472.         /* If I is odd we put an Int on the queue and a Char on the
  2473.            stack.  If I is even we put an Char on the queue and a Float
  2474.            on the stack.
  2475.  
  2476.            Since there is more than one method `-init:' and since
  2477.            `+alloc' returns a plain, typeless, `id', the compiler
  2478.            doesn't know the type of the object returned by alloc.  An
  2479.            explicit cast (i.e. static type indication) ensures that the
  2480.            compiler knows which `init:' is invoked---the one accepting a
  2481.            char or the other one accepting an int.
  2482.  
  2483.            Another solution, which avoids the static type indication, is
  2484.            to put typing information on the method in the method's name.
  2485.            This is done for the Float class.  */
  2486.         id my_char = [(Char *) [Char alloc] init: 'm' + i];
  2487.  
  2488.         if (i & 1)
  2489.           {
  2490.         [queue put: [(Int *) [Int alloc] init: i]];
  2491.         [stack put: my_char];
  2492.           }
  2493.         else
  2494.           {
  2495.         [queue put: my_char];
  2496.         [stack put: [[Float alloc] initFloatValue: i]];
  2497.           }
  2498.           }
  2499.     else
  2500.       {
  2501.         /* If I is odd we put an Int on the queue and a Float on the
  2502.            stack.  If I is even we put a Float on the queue and an Int
  2503.            on the stack.  */
  2504.             [queue put: ((i & 1)
  2505.              ? [(Int *) [Int alloc] init: i]
  2506.              : [[Float alloc] initFloatValue: i])];
  2507.             [stack put: ((i & 1)
  2508.              ? [[Float alloc] initFloatValue: i]
  2509.              : [(Int*) [Int alloc] init: i])];
  2510.     }
  2511.     }
  2512.  
  2513.     while ([queue size] && [stack size])
  2514.       {
  2515.     /* The following illustrates run-time binding.  Will report be
  2516.        invoked for a Float object or an Int object?  Did the user elect
  2517.        for Char objects at run time?  We don't know ahead of time, but
  2518.        with run-time binding and polymorphism it works properly.  The
  2519.        burden is on the class implementer rather than the class user.
  2520.  
  2521.        Note that the following lines remain unchanged, whether we are
  2522.        using the Char class or not.  The queue and stack hand us the
  2523.        next object, it reports itself regardless of its type, and then
  2524.        it frees itself.  */
  2525.  
  2526.     printf ("queue:");
  2527.     [[[queue get] report] free];
  2528.     printf (", stack:");
  2529.     [[[stack get] report] free];
  2530.     putchar('\n');
  2531.       }
  2532.   return 0;
  2533. }
  2534. @EOF
  2535. set `wc -lwc <objc-sample/main.m`
  2536. if test $1$2$3 != 19712617780
  2537. then
  2538.     echo ERROR: wc results of objc-sample/main.m are $* should be 197 1261 7780
  2539. fi
  2540.  
  2541. chmod 644 objc-sample/main.m
  2542.  
  2543. if test -f objc-sample/output
  2544. then
  2545.     echo Ok to overwrite existing file objc-sample/output\?
  2546.     read answer
  2547.     case "$answer" in
  2548.     [yY]*)    echo Proceeding;;
  2549.     *)    echo Aborting; exit 1;;
  2550.     esac
  2551.     rm -f objc-sample/output
  2552.     if test -f objc-sample/output
  2553.     then
  2554.         echo Error: could not remove objc-sample/output, aborting
  2555.         exit 1
  2556.     fi
  2557. fi
  2558. echo x - objc-sample/output
  2559. cat >objc-sample/output <<'@EOF'
  2560. Output from demo, excluding Char class:
  2561.  
  2562. Include the Char class in the demo? (y/n): n
  2563. queue:   5, stack:-5.0
  2564. queue: 4.0, stack:  -4
  2565. queue:   3, stack:-3.0
  2566. queue: 2.0, stack:  -2
  2567. queue:   1, stack:-1.0
  2568. queue: 0.0, stack:   0
  2569. queue:  -1, stack: 1.0
  2570. queue:-2.0, stack:   2
  2571. queue:  -3, stack: 3.0
  2572. queue:-4.0, stack:   4
  2573. queue:  -5, stack: 5.0
  2574.  
  2575. Output from demo, including Char class:
  2576.  
  2577. Include the Char class in the demo? (y/n): y
  2578. queue:   5, stack:   h
  2579. queue:   q, stack:-4.0
  2580. queue:   3, stack:   j
  2581. queue:   o, stack:-2.0
  2582. queue:   1, stack:   l
  2583. queue:   m, stack: 0.0
  2584. queue:  -1, stack:   n
  2585. queue:   k, stack: 2.0
  2586. queue:  -3, stack:   p
  2587. queue:   i, stack: 4.0
  2588. queue:  -5, stack:   r
  2589. @EOF
  2590. set `wc -lwc <objc-sample/output`
  2591. if test $1$2$3 != 29111679
  2592. then
  2593.     echo ERROR: wc results of objc-sample/output are $* should be 29 111 679
  2594. fi
  2595.  
  2596. chmod 644 objc-sample/output
  2597.  
  2598. chmod 755 objc-sample
  2599.  
  2600. exit 0
  2601.