🚀 go-pugleaf

In article <4l3auv$jnt@onramp.arc.nasa.gov>,
Hugh LaMaster <lamaster@viking.arc.nasa.gov> wrote:
>In article <goochb.334.0015B418@rwi.com>, 
>goochb@rwi.com (William D. Gooch) writes:
>
>|> Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
>|>  
>|> >The OO arena is a philosophical one. I don't particularly subscribe to the  
>|> >view
>|> >that there ought to be a naive correspondence between software entities and
>|> >some ``real world'' entities,  ....
>|> 
>|> Nor do I.  The (apparently widespread) idea that such correspondence 
>|> is in some way significant to the basis of object-oriented <whatever>
>|> is, IMO, a gross misconception.  Object technology has a sound basis 
>|> without it, and in programming, one is rarely modelling the "real world"
>|> directly (except in UI, when building upon spatio-temporal "real world"
>|> metaphors to bridge the gap between the abstractions a program is 
>|> based on and the user, and even then, the models used are abstract).
>
>OTOH, it is interesting that it is in GUI/window development that 
>O-O methods have been *generally* regarded (even by skeptics) as most 
>successful.  So, perhaps, there is some significance after all to such 
>correspondence.  At least, if what you care about is actual productivity,

I don't think that there is any Real-World Correspondence at work in the GUI
arena. In real life, there are no widgets, events or callbacks.

The reason OO works, perhaps, is that GUIs are constructed in ways that map
easily into the OO paradigm.  An element of asynchronous notification is
dominant in any decent GUI programming interface. In a procedural language, it
may be done using queues, callbacks and such. It maps naturally onto object
message passing (which basically hides callback functions anyway in something
like C++).

The user can (or should be able to most of the time) interact with any element
of the GUI rather than being forced to interact procedurally. The application
can design objects that are triggered by the GUI, and even combine the
interface and functional elements into one object.

Since object instances have their own private data, it's easy to spin off
multiple instances of the same widget without sharing state. Doing it in a
language like C means moving all the static variables of the corresponding
module into a dynamically allocated structure.  (Big ordeal, huh?) 

>rather than an O-O religious experience.  Now, in some applications,
>the GUI is 99% of the app, but in others, I can assure you that it is
>less than 1%.  It may simply be the case that O-O methods are more 
>effective, pragmatically speaking, for the former case than for the
>latter.  Why insist on applying the same techniques to every problem?

I would agree that the OO methods are effective, but they are probably overkill
for GUI design. I suspect that OO is _easy_ to _apply_ in GUI development,
because it is basically fluff work that can be done easily in just about _any_
design paradigm and language. You don't have to contemplate a complicated
taxonomy or get into any deep OO hair pulling, so if you are using OO for GUI
design, it must look like the greatest thing since sliced bread.
-- 
I'm not really a jerk, but I play one on Usenet.