This is various-AppKit-objects in view mode; [Up]
Date: Sun 20-Apr-1989 21:26:07 From: Unknown Subject: various AppKit objects Recently, I wasted hours upon hours of my time trying to get FormCells in my application to do what I wanted. I finally gave up totally, and replaced every last one of them with TextFieldCells and drew titles next to them. Has anyone else gotten the idea that perhaps there are too many kinds of objects in the Application Kit? FormCell vs. TextFieldCell is just one nasty example. They should be combined into one type of cell that has titles (the only discernable benefit of FormCells) plus everything that TextFieldCells have, or at least change FormCell to inherit from TextFieldCell instead of directly from ActionCell. I also object to the duplication caused by the existance of Cells (and, to a lesser extent, Controls). The AppKit would be much simpler to understand and program in if the Cell and Control classes did not exist. It might be a little less "efficient" to implement this way, but human efficiency is more important than a computer's "efficiency." In some cases, e.g. Form, there was a well-intentioned idea to implement something useful but a Form (basically, a Matrix of FormCells with some added hooks) is significantly less useful than a Matrix of TextFieldCells. The latter can either do everything a FormCell does or can give a reasonable simulation. We could abolish the Form class as well, and put the title stuff into Matrix so it's useful for other entities as well! I recognize it's too late to see this happen, but at least I hope to see the relatively simple change of having FormCell inherit from TextFieldCell... Mark Crispin / P.O. Box 2652 / Seattle, WA 98111-2652 / (206) 842-2385 mrc@Tomobiki-Cho.CAC.Washington.EDU / MRC@WSMR-SIMTEL20.Army.Mil 450cc Rebel pilot -- a step up from 250cc's!!! kisha no kisha ga kisha de kisha-shita...tabesaserarenakerebanaranakattarashii >From: paul@phoenix.Princeton.EDU (Paul Lansky)
Date: Sun 21-Apr-1989 15:26:48 From: Unknown Subject: Re: various AppKit objects In article <1675@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: > > Has anyone else gotten the idea that perhaps there are too many >kinds of objects in the Application Kit? FormCell vs. TextFieldCell >is just one nasty example. They should be combined into one type of >cell that has titles (the only discernable benefit of FormCells) plus >everything that TextFieldCells have, or at least change FormCell to >inherit from TextFieldCell instead of directly from ActionCell. At the developer camp that I attended, NeXT folk made a point of saying how large and unwieldy the Mac Toolbox is (400 or so calls, I think they said), and by contrast how the App kit is made of but a few dozen flexible, extensible object classes. Well, to have your interface perform 400 different tasks, you need 400 ways of saying so, be it by 400 unique calls or by a few dozen object classes, each with a bunch of methods. In my opinion, the object-oriented approach is much more readable, writable, and extendable. Of course, when the original tools (e.g., TextFieldCell vs FormCell) are not well organized, defined, and delineated, we lose out. > I also object to the duplication caused by the existance of Cells >(and, to a lesser extent, Controls). The AppKit would be much simpler >to understand and program in if the Cell and Control classes did not >exist. It might be a little less "efficient" to implement this way, >but human efficiency is more important than a computer's "efficiency." > > In some cases, e.g. Form, there was a well-intentioned idea to >implement something useful but a Form (basically, a Matrix of >FormCells with some added hooks) is significantly less useful than a >Matrix of TextFieldCells. The latter can either do everything a >FormCell does or can give a reasonable simulation. We could abolish >the Form class as well, and put the title stuff into Matrix so it's >useful for other entities as well! Agreed. It seems that many decisions were based on efficiency -- You have class A that does everything, and class a that does somethings, but faster. Maybe they had the right idea, or maybe they were optimizing the wrong thing. It would be interesting to know NeXT's reasoning behind the current App Kit arangement. When you (Mark and others) find problems like these, do you report them to NeXT? I must admit that I have been delinquent in keeping NeXT abreast of all of the conerns that I and my constituency have, other than those that are very specific (bugs/features). I guess I've been too busy waiting for 0.9:-) > I recognize it's too late to see this happen, but at least I hope >to see the relatively simple change of having FormCell inherit from >TextFieldCell... A lot could be changed by 1.0. Objects could be added to the App Kit and others (e.g., cells and controls) removed. Objects removed could be placed in a supplemental kit for people that are relying on them. >Mark Crispin / P.O. Box 2652 / Seattle, WA 98111-2652 / (206) 842-2385 >mrc@Tomobiki-Cho.CAC.Washington.EDU / MRC@WSMR-SIMTEL20.Army.Mil >450cc Rebel pilot -- a step up from 250cc's!!! >kisha no kisha ga kisha de kisha-shita...tabesaserarenakerebanaranakattarashii Mark Feldman >From: mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.