From: linton@marktwain.rad.sgi.com (Mark Linton)
Subject: Re: Can C++ / X empower us to make great apps for the 90's?
Keywords: nn
Reply-To: linton@marktwain.rad.sgi.com (Mark Linton)
Organization: sgi
Date: Fri, 10 Apr 1992 23:34:47 GMT

In article <1992Apr8.060832.9260@sfc.sony.com>, berger@sfc.sony.com (Bob Berger) writes:
|> I want to treat my GUI objects (widgets, structured graphics, etc) as
|> first class objects. I want to create modified versions of existing
|> widgets through OO techniquies like inheretance using the OO language
|> mechanisms, not kludge toolkit mechanisms.

I don't understand what you are referring to as a "kludge".

|> The NeXTstep Appkit has a relatively simple set of objects to draw
|> from, but it seems to be surprisingly complete when you see how easy
|> it is to plug the different objects together and build more complex
|> objects that you can then easily share and reuse to incrementally
|> build up your applications.

If you have any insights into the kinds of objects that ought
to be in InterViews and are not there, let me know.
I don't believe the AppKit (yet) has the power of glyph compositions
or Unidraw.

|> The Interface builder make it easy to explore the appkit and
|> incrementally build up your application. You can try out the
|> application at any time during the development cycle without
|> recompiling the changes in the interface. You also can extend the
|> palete of objects from within the builder, making it easy to share and
|> reuse your extended toolkit.
|> 
|> The dynamic-binding of the Objective C extensions to the NeXTstep C++
|> compiler seem to be a key to allowing for the easy sharing, reuse and
|> incremental development process. The fact that the NeXTstep compiler
|> (and gcc-2.x) allows for the mixing of Objective C and C++ (and of
|> course C) in one program now allows the PROGRAMMER (as opposed to the
|> language designer!) to choose the level of binding (static or dynamic)
|> as appropriate for the application.

I agree that interface builders are a good thing and the Next one
is quite nice.  I believe that dynamic loading is the important feature
missing from most C++ environments; I'm less convinced that
I need to be able to get "method not defined for this object" errors.

|> My goal here is not so much to praise NeXT. But to remind all of us
|> C++ / X folks that we are not living up to the promise of the OO
|> paradigm. The current C++ / X environments are not making it that much
|> easier to stand on the shoulders of people who have done the
|> foundation work. We still keep finding ourselves reinventing the
|> wheel, starting each project from first principles.

I agree and disagree.  C++ programming environments
are disappointing, but with respect to building applications
we are much better off today with glyphs and Unidraw than we were
several years ago.

|>It would also be nice if our toolkits could be designed for
|> flexiblitiy and technical excellence with less religious dogma and CEO
|> egos involved!

No argument here.

|> NeXTstep on top of mainstream Unix's and hardware platforms in a form
|> that would allow for mixing NeXTstep applications and existing X
|> applications would be a fine first step IMHO.

Unfortunately, Next has chosen to hold onto Mach and DPS
in their 486 port and that makes the offering less attractive.
I agree that they would have a more attractive product to me
if it were layered above the OS/window system.