ksand@Apple.COM (Kent Sandvik) (01/05/91)
In article <14545@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Incidentally, MacAppers -- please ignore the example programs shipped >by Apple. They are very small and do not scale well. If you adopt the >unit strategy of the example programs, in which everything knows about >the applications and document subclasses and those subclasses know >about everything else, you will not be able to expand beyond a few >source files or do much information hiding or code reusability. I don't think that the intention with the MacApp samples was to create huge scalable applications. Instead they try to show how to extend the *MacApp* framework. It is up to the developer to create own object hierarchies and attach these to the MacApp framework in strategic suitable places. >Instead, the strategy to use is: Your application and document >subclasses do know about everything, but hardly anything knows about >them. They are "master controllers" which are unknown to most of the >things they control. This will lead to a lot of USES in the units >dealing with document and application subclasses, but a manageable >number elsewhere. That's exactly the current trend with application frameworks. Isolate and connect at few places - sort of data abstraction in the class level. The perfect case is where you could develope the user interface separately from the the application grunt class hierarchy, and attach these together as the last step. Regards, Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++, anything less is BCPL..."
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (01/06/91)
Kent Sandvik writes in a message to All
KS> That's exactly the current trend with application frameworks.
KS> Isolate and connect at few places - sort of data abstraction
KS> in the class level. The perfect case is where you could develope
KS> the user interface separately from the the application grunt
KS> class hierarchy, and attach these together as the last step.
It should not be necessary for the Application/document classes to know about
everything: why should they? If they know about a class, and THAT class knows
about some class that it uses, the interface for the second class need not specify
a subclass, merely the parent (hopefully something already in MacAPP), THEN
the implementation section of the second class should use the Unit of the sub-class
and typecast the parent class var to the sub-class. This speeds up compile times
by a factor of 2 or more.
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgtim@hoptoad.uucp (Tim Maroney) (01/06/91)
In article <14545@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>Incidentally, MacAppers -- please ignore the example programs shipped >>by Apple. They are very small and do not scale well. If you adopt the >>unit strategy of the example programs, in which everything knows about >>the applications and document subclasses and those subclasses know >>about everything else, you will not be able to expand beyond a few >>source files or do much information hiding or code reusability. In article <47760@apple.Apple.COM> ksand@Apple.COM (Kent Sandvik) writes: >I don't think that the intention with the MacApp samples was to >create huge scalable applications. Instead they try to show how to >extend the *MacApp* framework. It is up to the developer to create >own object hierarchies and attach these to the MacApp framework in >strategic suitable places. I would think that an example program for a class library ought to show a good style of use for the class library, not just to show that, hey, it actually does compile and run.... Examples are to emulate. >>Instead, the strategy to use is: Your application and document >>subclasses do know about everything, but hardly anything knows about >>them. They are "master controllers" which are unknown to most of the >>things they control. This will lead to a lot of USES in the units >>dealing with document and application subclasses, but a manageable >>number elsewhere. >That's exactly the current trend with application frameworks. Isolate >and connect at few places - sort of data abstraction in the class >level. I'm glad to know that I'm in tune with the latest thinking. I do wish, however, that some attempt had been made to communicate this thinking together with the class library, instead of forcing me to discover it myself. Not only did I have to figure it out rather painfully over a period of months, I had to contest with a fellow programmer who learned MacApp from Apple's course and the example programs, who would always say, "But look, in the example programs this is how the units are connected; that's how Apple wants you to do it." Please, let's get some examples that reflect a good class style. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "It is better to be a human being dissatisfied than a pig satisfied; better to be Socrates dissatisfied than a fool satisfied." -- John Stuart Mill, UTILITARIANISM (1863)
ksand@Apple.COM (Kent Sandvik) (01/07/91)
In article <14582@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <47760@apple.Apple.COM> ksand@Apple.COM (Kent Sandvik) writes: >>That's exactly the current trend with application frameworks. Isolate >>and connect at few places - sort of data abstraction in the class >>level. >I'm glad to know that I'm in tune with the latest thinking. I do wish, >however, that some attempt had been made to communicate this thinking >together with the class library, instead of forcing me to discover it >myself. >Not only did I have to figure it out rather painfully over a period of >months, I had to contest with a fellow programmer who learned MacApp >from Apple's course and the example programs, who would always say, >"But look, in the example programs this is how the units are connected; >that's how Apple wants you to do it." Well, I learned this OOPS strategy at an Apple MacApp training course :-). >Please, let's get some examples that reflect a good class style. Anyway, good constructive criticism is always healthy, I will discuss this with other DTS engineers concerning future MacApp example source code. Regards, Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++, anything less is BCPL..."
ksand@Apple.COM (Kent Sandvik) (01/07/91)
In article <34241.27875335@stjhmc.fidonet.org> Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes: >Kent Sandvik writes in a message to All > >KS> That's exactly the current trend with application frameworks. >KS> Isolate and connect at few places - sort of data abstraction >KS> in the class level. The perfect case is where you could develope >KS> the user interface separately from the the application grunt >KS> class hierarchy, and attach these together as the last step. > >It should not be necessary for the Application/document classes to know about >everything: why should they? If they know about a class, and THAT class knows >about some class that it uses, the interface for the second class need not specify >a subclass, merely the parent (hopefully something already in MacAPP), THEN >the implementation section of the second class should use the Unit of the sub-class >and typecast the parent class var to the sub-class. This speeds up compile times >by a factor of 2 or more. > > >Lawson The original thread in this discussion was why MacApp sample code does not make use of isolated application class libraries. I assume that the comment above is just a 'yes-it-is-bad' comment. I tried to find some kind of a statement that contradicts the earlier comments, alas did not find anything. To continue with this discussion, Object Design is a fairly new area to explore, and as long as we try to explore new methodogies the whole field will evolve. As long as we lock ourselves to old, proven methologies we will have a stagnation in the evolution of Object oriented systems. I'm sure that there will be more exploration with states inside frameworks, persistancy and other exotic aspects that only a few dares to test today, and they will be 'common sense' in five years time. Maybe some parts of MacAapp today seems to be wrong, but at least someone tried to create the first workable framework in the first place. And as anything else, MacApp and MacApp application design is still evolving. Regards, Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++, anything less is BCPL..."
tim@hoptoad.uucp (Tim Maroney) (01/07/91)
In article <34241.27875335@stjhmc.fidonet.org> Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes: >It should not be necessary for the Application/document classes to know about >everything: why should they? If they know about a class, and THAT class knows >about some class that it uses, the interface for the second class need not specify >a subclass, merely the parent (hopefully something already in MacAPP), THEN >the implementation section of the second class should use the Unit of the sub-class >and typecast the parent class var to the sub-class. This speeds up compile times >by a factor of 2 or more. Typecasting is an ugly thing, and one would hope that good object code would be able to get along without it in most cases. Sure, you can reduce dependencies just by making every field of type TObject, and typecasting as needed, but that's pretty nasty. Nor does it help to decouple classes from each other (i.e., more reusable). If anything, the typecasting solution makes them more interdependent. What would really help would be partial type binding in Object Pascal, so that only fields that are used need to be of a known type. This creates problems with the binding of structure offsets, which could be solved either through a smarter link phase or by the ability to declare forward classes (so that their sizes are known at the time their owning class is declared). -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "American women, especially some of those on the net, might profit by being less concerned with their careers and more concerned with getting a good, old fashioned roll in the hay." -- William J. Fallon, wjf@cbnews.att.com, on soc.women (also uses the alias Walter J. Ficklestein)
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (01/09/91)
Kent Sandvik writes in a message to All
KS> The original thread in this discussion was why MacApp sample
KS> code does not make use of isolated application class libraries.
KS> I assume that the comment above is just a 'yes-it-is-bad' comment.
KS> I tried to find some kind of a statement that contradicts the
KS> earlier comments, alas did not find anything
Perhaps I jumped into the middle of a long-running thread and simply reiterated
someone else's post. However, my comment was directed at the idea that one should
make the application class "all-knowing" --that it was not necessary, even made
compile times excruciatingly slow.
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.org