This is README_Future.rtf in view mode; [Download] [Up]
MOKit docs, Copyright ©1992, 1993, 1994 by Mike Ferris. All Rights Reserved. By Mike Ferris -- February 5th, 1994 MOKit Ideas for the Future MOClassVariable - Optional inheritance of values from superclasses for subclasses that do not set a value. - Support for non-object values. MODocumentWell - Make it a control - Make it adhere to View's autoDisplay/update protocol - Redo as part of a hierarchy of well objects for all different kinds of things. MOString - Efficiency - Really, it would be good to start from scratch with MOString and do it like NXImage. That is, separate the representation from the front-end object and provide several representations. The representation back-end classes would provide different trade-offs of in terms of performance, memory, and any other relevant issues. The user could choose what type of backing was appropriate for a given string. Representations would be provided for say MOString like performance where the memory dynamically tracks the length of the string exactly (compact but not good for strings that change alot), dynamic buffers that would grow by some percentage when needed, but never shrink (unless told to explicitly), fixed length allocated buffers, fixed length static buffers, and the list could go on. The hard part of this would be to design the api between the front and back ends. Once that was done backends could be created as needed and there could even be multiple front ends if needed for different types of things that were basically string based, but not really strings. - Is it worth it to do anything to the string class if Next will eventually provide one? Document stuff - Might be a good idea to separate the running of the save panel from saveAs:, but then again, this is pretty nitpicky. - A new MODocController subclass for multi-view documents would be nice. Two types of multi-view documents should be supported. First, the kind that has no top-level window (that is, the controller itself would have no nib, no window, but the views would). Second, there's the multi-view document that has a top-level window (like Dataphile, or Improv). In this second type, the controller would have a window (usually some kind of summary of the existing views I would think), and each view would also have a window. Both of these cases should be able to be handled with one subclass of MODocController. - MODocController should support documents that require a file or directory to save in from the start (ie no such thing as untitled). For instance, ProjectBuilder requires you to name new projects right at the start. - Support for window-less document controllers should be tested. Support for managerless controllers, ditto. - Undo support. - Filter service support. Open panels should allow any type filterable to a type that the document class can read. - Pasteboard support. - Services support.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.