|
|
1.1 root 1: {\rtf0\ansi{\fonttbl\f4\fnil Times-Roman;\f6\ftech Symbol;\f1\fmodern Courier;\f5\fmodern Ohlfs;}
2: \paperw13680
3: \paperh13680
4: \margl360
5: \margr360
6: {\colortbl;\red0\green0\blue0;}
7: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\f4\b0\i0\ulnone\fs24\fc0\cf0 Copyright
8: \f6 �
9: \f4 1994 by NeXT Computer, Inc. All Rights Reserved.\
10:
11: \pard\fs48\li1440\fc0\cf0 \
12: Preliminary 4.0 Release Notes: \
13: Objective-C Run-Time System (objc-142)\
14:
15: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fs28\li1440\fc0\cf0 \
16: \
17: \
18:
19: \pard\tx1800\li1440\fc0\cf0 This file contains information about the following topics:\
20: \
21: � New features\
22: � Implementation changes\
23: � Incompatible changes\
24: � Organizational changes\
25: \
26: \
27:
28: \pard\b\fs36\fc0\cf0 Implementation Changes
29: \fs28 \
30:
31: \pard\tx1800\b0\li1440\fc0\cf0 \
32:
33: \pard\b\li720\fc1\cf1 Method Caches
34: \b0 \
35:
36: \pard\tx1800\li1440\fc1\cf1 \
37:
38: \pard\tx1800\li1440\fc0\cf0 The datastrucuture for the method cache has changed, from using pointers to objc_method strucutures, to being an array of objc_cache_bucket structures. Programs depending on this subtle change deserve to break.\
39:
40: \pard\tx1800\li1440\fc0\cf0 \
41: \
42: \
43: \
44:
45: \pard\b\fs36\fc1\cf1 Notes Specific to NEXTSTEP 3.0
46: \fs28\fc0\cf0 \
47:
48: \fs36 New Features
49: \fs28 \
50:
51: \pard\tx1800\li1440\fc0\cf0 \
52:
53: \b0 The following are new features that have been added to the Objective-C common classes for release 3.0.\
54: \
55: << New string classes are NeXT internal only! >>\
56: \
57:
58: \pard\b\li720\fc1\cf1 String Classes
59: \b0 \
60:
61: \pard\tx1800\li1440\fc1\cf1 \
62: New string classes:\
63: \
64: � NXString\
65: � NXMutableString\
66: � NXSimpleReadOnlyString\
67: � NXReadOnlyString\
68: � NXReadOnlySubstring\
69: � NXReadWriteString\
70: � NXUniquedString\
71: � NXConstantString\
72: \
73: Also
74: \pard\tx1040\tx2100\tx3160\tx4220\tx5280\tx6320\tx7380\tx8440\tx9500\tx10560\fc1\cf1 NXCharacterSet
75: \pard\tx1800\li1440\fc1\cf1 and the header file
76: \f1\fs26 objc/unichar.h
77: \f4\fs28 .\
78: \
79: The Objective-C runtime provides runtime support for literal NXConstantString objects statically allocated by the compiler. To create such a string, use
80: \b @""
81: \b0 .\
82: \
83: In 3.0, the string classes are private and for internal use only. They hold 8-bit characters, and the definition of
84: \i character
85: \i0 in the API refers to these 8-bit quantities. In 4.0, the strings will store Unicode characters and the definition of
86: \i character
87: \i0 in the API will refer to 16-bit unichars. Thus the character array argument to methods such as
88: \b initFromCharacters:length:
89: \b0 will change between the two releases.\
90: \
91: Methods such as
92: \b initFromCString:
93: \b0 and
94: \b initFromCString:length:
95: \b0 will continue to take zero-terminated C-strings and counted C-strings, respectively. Thus if you are writing code that creates NXStrings from C-strings and the code will remain the same in 4.0, you should use these method rather than
96: \b initFromCharacters:length:
97: \b0 . Methods such as
98: \b cStringLength
99: \b0 and
100: \b getCString:
101: \b0 (or, for convenience,
102: \b cStringCopy
103: \b0 ) can be used to return C-strings back from NXString. \
104: \
105: NXStrings written out to typedstreams (with
106: \b write:
107: \b0 ) in 3.0 should read back correctly in 4.0. The 8-bit characters will be interpreted as a NeXTstep string and converted to Unicode. On systems using EUC, such as the 4.0 version of the current Japanese system, the 8-bit C-strings generated and used by NXString will be interpreted as EUC strings. Thus the
108: \b cStringLength
109: \b0 method should be used when extracting C-strings from NXString.\
110: \
111: The more interesting string classes include:\
112: \
113: � NXString\
114: The abstract superclass for read-only strings. Subclassers need to define at least three methods (see header file) to create a fully usable string class of their own. API which accepts read-only strings will probably take the form:\
115: \
116: - setStringValue:(NXString *)aString\
117: \
118: � NXReadOnlyString\
119: Reference-counted concrete subclass of NXString. Used in most cases where read-only strings are needed. Reference counting works in conjunction with the
120: \b copy
121: \b0 and
122: \b free
123: \b0 methods; thus this class provides a very inexpensive copy operation.\
124: \
125: � NXMutableString\
126: Subclass of NXString and the abstract superclass for read-write strings. Subclassers need to define at least four methods (three of which are for NXString) to create a fully usable read-write string class of their own. API which wants read-write strings will probably text the form:\
127: \
128: changeStringToLowerCase (NXMutableString *aString)\
129: \
130: � NXReadWriteString\
131: Reference-counted concrete subclass of NXMutableString. Other subclasses of NXMutableString might be necessary if the array-based implementation of NXReadWriteString doesn't prove efficient enough for some tasks. Like NXReadOnlyString, the reference counting works in conjunction with the
132: \b copy
133: \b0 and
134: \b free
135: \b0 methods; editing the string exhibits copy on write behavior.\
136: \
137: \
138:
139: \fc0\cf0 << NXMapTable is NeXT internal only! >>\
140: \
141:
142: \pard\b\li720\fc1\cf1 NXMapTable
143: \b0 \
144:
145: \pard\tx1800\li1440\fc1\cf1 \
146: NXMapTable is a another flavor of hashtable. NXMapTable allows hashing of arbitrary associations. Its API is modeled after that of NXHashTable. Both modules allow manipulations of hash tables, and both grow automatically as the number of elements in the table grows. However NXMapTable is easier to use for associations, while NXHashTable is easier to use for set operations. Also, NXMapTable does not fragment memory, but performance degrades quickly when hashed elements collide. NXHashTable on the other hand allocates a list per collision, and is therefore more memory intensive, but more resilient to collisions.\
147: \
148: \
149:
150: \pard\b\li720\fc1\cf1 New Classes Protocol and NXBundle
151: \b0 \
152:
153: \pard\tx1800\li1440\fc1\cf1 \
154: See << Where are these documented? >> for complete documentation of these new classes.\
155: \
156: \
157:
158: \pard\b\li720\fc1\cf1 New Runtime Functions
159: \b0 \
160:
161: \pard\tx1800\li1440\fc1\cf1 \
162: The function
163: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\b\fc1\cf1 objc_lookUpClass
164: \pard\tx1800\li1440\fc1\cf1 (
165: \b0 ) has been added to the Objective-C runtime functions. Just like
166: \b objc_getClass()
167: \b0 , this function returns the class for a given name. However, if the class is not present,
168: \b objc_lookUpClass()
169: \b0 returns
170: \b nil
171: \b0 rather than considering this to be an error condition.\
172: \
173: The function
174: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\b\fc1\cf1 sel_registerName
175: \pard\tx1800\li1440\fc1\cf1 (
176: \b0 ) has also been added to allow new selectors to be registered with the Objective-C runtime. Like
177: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\b\fc1\cf1 sel_getUid
178: \pard\tx1800\li1440\fc1\cf1 ()
179: \b0 , this function gets the selector associated with a given name. However, if there is no selector for that name already present in the system,
180: \b sel_registerName(
181: \b0 ) allocates a new selector rather than returning
182: \b nil
183: \b0 .\
184: \
185: \
186:
187: \pard\b\li720\fc1\cf1 Thread-Safe Objective-C Runtime System
188: \b0 \
189:
190: \pard\tx1800\li1440\fc1\cf1 \
191: The Objective-C runtime has been made safe for use in multi-threaded programs. Since complete thread-safety requires that a lock be acquired every time a message is sent (which increases the time required to send a message by a factor of approximately three), the thread safety features must be explicitly enabled using the new function
192: \b objc_setMultithreaded()
193: \b0 .\
194: \
195: \
196:
197: \pard\b\li720\fc1\cf1 Thread-Safe Exception Handling
198: \b0 \
199:
200: \pard\tx1800\li1440\fc1\cf1 \
201: The exception handling system provided in
202: \f1\fs24 objc/error.h
203: \f4\fs28 has been made unconditionally thread safe.\
204: \
205: \
206:
207: \pard\b\li720\fc1\cf1 Debugging Interface
208: \b0 \
209:
210: \pard\tx1800\li1440\fc1\cf1 \
211: The Object class now implements a method to assist in debugging when using
212: \b gdb
213: \b0 (see
214: \b Debugger.rtf
215: \b0 for information on how to use this feature from
216: \b gdb
217: \b0 ). The
218: \b printForDebugger:
219: \b0 method in the Object class prints the name of the receiver's class and the address of the receiver. Classes should override this method to print a more useful description of themselves for debugging purposes.\
220: \
221: \
222:
223: \pard\b\li720\fc1\cf1 Improved Detection of Messaging Freed Objects
224: \b0 \
225:
226: \pard\tx1800\li1440\fc1\cf1 \
227: The Objective-C runtime can now detect messages which are sent to objects which have been freed. An error will be reported when this problem is detected. Note that this detection is possible only in the interval between when the object is freed and when the freed space is reused for some new purpose.\
228: \
229: \
230: \
231:
232: \pard\b\fs36\fc1\cf1 Notes Specific to NEXTSTEP 3.0
233: \fs28\fc0\cf0 \
234:
235: \fs36 Implementation Changes
236: \fs28 \
237:
238: \pard\tx1800\li1440\fc0\cf0 \
239: \
240:
241: \pard\li720\fc1\cf1 Copy Methods
242: \b0 \
243:
244: \pard\tx1800\li1440\fc1\cf1 \
245: In release 2.0, Object's
246: \b copy
247: \b0 and
248: \b copyFromZone:
249: \b0 methods were implemented independently. In order to support copying, an object had to implement both methods. In release 3.0, Object's
250: \b copy
251: \b0 method has been changed to call
252: \b copyFromZone:
253: \b0 from the object's zone:\
254:
255: \pard\tx1800\tx2160\tx2520\tx2880\fi-360\li1800\fc1\cf1 \
256:
257: \f1\fs24 - copy \
258: \{\
259: return [self copyFromZone: [self zone]];\
260: \}\
261:
262: \pard\tx1040\tx2100\tx3160\tx4220\tx5280\tx6320\tx7380\tx8440\tx9500\tx10560\fc1\cf1 \
263:
264: \pard\tx1800\f4\fs28\li1440\fc1\cf1 With this change, an object need only implement the
265: \b copyFromZone:
266: \b0 method to support copying using either method.\
267: \
268: The
269: \b copy
270: \b0 methods of the List, Storage and HashTable classes have been removed since they were identical to the
271: \b copy
272: \b0 method which they now inherit from Object.\
273:
274: \pard\tx1040\tx2100\tx3160\tx4220\tx5280\tx6320\tx7380\tx8440\tx9500\tx10560\fc1\cf1 \
275:
276: \pard\tx1800\b\li1440\fc0\cf0 \
277: \
278:
279: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\li720\fc0\cf0 New Objective-C Keyword
280: \b0\fc1\cf1 \
281:
282: \pard\tx1800\li1440\fc1\cf1 \
283: The release 3.0 Objective-C compiler implements the type
284: \b id
285: \b0 as a keyword of the language. For this reason,
286: \f1\fs26 objc/objc.h
287: \f4\fs28 no longer provides a typedef for
288: \b id
289: \b0 when compiling Objective-C programs. However, in order to allow
290: \f1\fs26 objc/objc.h
291: \f4\fs28 to be included by C programs without parse errors,
292: \f1\fs26 objc/objc.h
293: \f4\fs28 does still provide a typedef for
294: \b id
295: \b0 when the macro
296: \b __OBJC__
297: \b0 is not predefined by the compiler.\
298:
299: \pard\tx1040\tx2100\tx3160\tx4220\tx5280\tx6320\tx7380\tx8440\tx9500\tx10560\fc1\cf1 \
300: \
301: \
302:
303: \pard\b\fs36\fc1\cf1 Notes Specific to NEXTSTEP 3.0
304: \fs28\fc0\cf0 \
305:
306: \fs36 Incompatible Changes
307: \fs28 \
308:
309: \pard\tx1800\b0\li1440\fc0\cf0 \
310: \
311:
312: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\b\li720\fc0\cf0 Renamed
313: \pard\li720\fc0\cf0 Methods
314: \b0 \
315:
316: \pard\tx1800\li1440\fc0\cf0 \
317: The following methods in the Object class were renamed:\
318:
319: \fc1\cf1 \
320:
321: \f1\fs24 +
322: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 superClass
323: \pard\tx1800\li1440\fc1\cf1 \
324: -
325: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 superClass
326: \pard\tx1800\li1440\fc1\cf1 \
327: - isKindOfGivenName:\
328: - isMemberOfGivenName:\
329: -
330: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 methodDescFor:
331: \pard\tx1800\li1440\fc1\cf1 \
332: -
333: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 instanceMethodDescFor
334: \pard\tx1800\li1440\fc1\cf1 :\
335:
336: \f4\fs28 \
337: The new names are:\
338: \
339:
340: \f1\fs24 +
341: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 super
342: \pard\tx1800\li1440\fc1\cf1 c
343: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 lass
344: \pard\tx1800\li1440\fc1\cf1 \
345: -
346: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 super
347: \pard\tx1800\li1440\fc1\cf1 c
348: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 lass
349: \pard\tx1800\li1440\fc1\cf1 \
350: -
351: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 isKindOfClassNamed
352: \pard\tx1800\li1440\fc1\cf1 :\
353: -
354: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 isMemberOfClassNamed
355: \pard\tx1800\li1440\fc1\cf1 :\
356: -
357: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 descriptionForMethod:
358: \pard\tx1800\li1440\fc1\cf1 \
359: -
360: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 descriptionForInstanceMethod
361: \pard\tx1800\li1440\fc1\cf1 :\
362:
363: \f4\fs28\fc0\cf0 \
364: These new names are more descriptive of the method's function.\
365: \
366: The following methods in the Storage class were renamed:\
367:
368: \fc1\cf1 \
369:
370: \f1\fs24 - insert:(void *)anElement at:(unsigned)index\
371: - replace:(void *)anElement at:(unsigned)index\
372: - removeAt:(unsigned)index\
373:
374: \f4\fs28 \
375: The new names are:\
376: \
377:
378: \f1\fs24 - insertElement:(void *)anElement at:(unsigned)index\
379: - replaceElementAt:(unsigned)index with:(void *)anElement\
380: - removeElementAt:(unsigned)index\
381:
382: \f4\fs28 \
383: These new names are more compatible with the corresponding methods in the List class:\
384: \
385:
386: \f1\fs24 -
387: \pard\tx1040\tx2100\tx3160\tx4220\tx5280\tx6320\tx7380\tx8440\tx9500\tx10560\fc1\cf1 insertObject:anObject at:(unsigned)index
388: \pard\tx1800\li1440\fc1\cf1 \
389: - replaceObjectAt:(unsigned)index with:newObject\
390: -
391: \pard\tx1040\tx2100\tx3160\tx4220\tx5280\tx6320\tx7380\tx8440\tx9500\tx10560\fc1\cf1 removeObjectAt:(unsigned)index
392: \pard\tx1800\li1440\fc1\cf1 \
393:
394: \f4\fs28 \
395: Existing programs which use the old methods will continue to work correctly, and source code will still compile (although with warnings).\
396:
397: \fc0\cf0 \
398: \
399:
400: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\b\li720\fc0\cf0 Renamed
401: \pard\li720\fc0\cf0
402: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\li720\fc0\cf0 Functions
403: \pard\b0\li720\fc0\cf0 \
404:
405: \pard\tx1800\li1440\fc0\cf0 \
406: The functions
407: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\b\fc1\cf1 class_addInstanceMethods
408: \pard\tx1800\li1440\fc0\cf0 ()
409: \b0 and
410: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\b\fc1\cf1 class_addClassMethods
411: \pard\tx1800\li1440\fc0\cf0 ()
412: \b0 have been replaced by the single function
413: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\b\fc1\cf1 class_addMethods
414: \pard\tx1800\li1440\fc0\cf0 ()
415: \b0 , which better matches the single function
416: \b class_removeMethods()
417: \b0 .\
418: \
419: \
420:
421: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\b\li720\fc0\cf0 Objective-C Type Encoding Strings
422: \pard\b0\li720\fc0\cf0 \
423:
424: \pard\tx1800\li1440\fc0\cf0 \
425: The Objective-C type encodings have been expanded to contain additional information for Distributed Objects. One effect of these changes is that the type strings produced by
426: \b @encode
427: \b0 are no longer compatible with typedstreams when the encoded type is a struct. The new encoding for
428: \f1\fs24\fc1\cf1 struct foo \{int x, y;\};
429: \f4\fs28\fc0\cf0 is
430: \f1\fs24\fc1\cf1 "\{foo=ii\}"
431: \f4\fs28\fc0\cf0 , which is not recognized by typedstreams. It expects simply
432: \f1\fs24\fc1\cf1 "\{ii\}"
433: \f4\fs28\fc0\cf0 .\
434:
435: \pard\tx1040\tx2100\tx3160\tx4220\tx5280\tx6320\tx7380\tx8440\tx9500\tx10560\fc1\cf1 \
436: \
437: \
438:
439: \pard\b\fs36\fc1\cf1 Notes Specific to NEXTSTEP 3.0
440: \fs28\fc0\cf0 \
441:
442: \fs36 Known Problems
443: \fs28 \
444:
445: \pard\tx1800\b0\li1440\fc0\cf0 \
446: \
447:
448: \b\fc1\cf1 Problems with NXAllocErrorData()
449: \pard\li720\fc1\cf1 \
450:
451: \pard\tx1800\b0\li1440\fc0\cf0 \
452: The data allocated by
453: \b\fc1\cf1 NXAllocErrorData()
454: \b0\fc0\cf0 may be invalidated by subsequent calls to
455: \b\fc1\cf1 NXAllocErrorData()
456: \b0\fc0\cf0 . Do not rely on this data remaining valid across multiple calls. It is safe to use
457: \b\fc1\cf1 NXAllocErrorData()
458: \b0\fc0\cf0 so long as the data will only be used prior to the next call to
459: \b\fc1\cf1 NXAllocErrorData()
460: \b0\fc0\cf0 . If you need more complex allocation patterns, you should use
461: \b\fc1\cf1 malloc()
462: \b0\fc0\cf0 to allocate the data and implement your own mechanism to free this data. One possibility is to register the data to be freed in your main event loop.\
463:
464: \b\fc1\cf1 \
465: \
466: \
467:
468: \pard\fs36\fc1\cf1 Notes Specific to NEXTSTEP 3.0
469: \fs28\fc0\cf0 \
470:
471: \fs36 Organizational Changes
472: \fs28 \
473:
474: \pard\tx1800\b0\li1440\fc0\cf0 \
475: \
476:
477: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\b\li720\fc0\cf0 Moved Header Files
478: \pard\b0\li720\fc0\cf0 \
479:
480: \pard\tx1800\li1440\fc0\cf0 \
481: The header file
482: \f1\fs26 zone.h
483: \f4\fs28 has been moved to
484: \f1\fs26 objc/zone.h
485: \f4\fs28 .\
486: \
487:
488: }
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.