🚀 go-pugleaf

In article <1992Apr11.041914.10574@stb.info.com> michael@stb.info.com (Michael Gersten) writes:
>In article <1992Mar25.153419.16666@sinix.UUCP> dhg@sinix.UUCP (David Griffith) writes:
>>Yes, I was wondering about this too, but from a different angle. The power
>>of NeXTStep would be greatly enhanced if you could "add value" to the
>>standard app kit objects such that all applications would inherit the
>>new functionality *without* recompilation. That way, developers could
>>sell value added versions of NeXTStep objects.
>
>I thought that Objective C allowed you to override parts of a class. So you
>could override the alloc, init, and free methods, and make sure that
>you set up a delegate that handled any new keystrokes.
>
>Or am I missing something very basic?

Yes! I said *without* recompilation! This is the key point: to alter the
functionality of binary apps.

Let's take an example. Suppose you subclass the Text object and you override
the char or field filter to provide some emacs keyboard editing commands
(this may not work, but it's just an example). Well fine, that works for
any application *you* build using this new object. But what if you want
Edit to inherit this snazzy new feature? It can't. The Text object that
Edit uses is stuck inside Edit.

What I want to see is shiny hard black objects, not sticky objects, not
objects that are glued into the binary. If you bought a car and you
could not even open the bonnet and replace the spark plugs, you would not
be happy.

Now I'm going into the realms of fantasy here, but this is what I want
to see: I have something like IB that lets me open up Edit and examine
the objects inside. Ah ha! There is the standard Text object. And there,
as a *separate* object is (say) a subclassed version of Text that Edit
uses. The links between these objects are well defined. Now I take my
special subclass of Text that does the extra emacs stuff and I insert
it between these two objects. Edit's subclass of Text then just
automagically inherits the new fuctionality. Or even better would be for
the "standard" Text object not to reside inside Edit at all, but to be
a remote object that provides this service. Then you just bung your
subclass on top of the remote Text object and *all* apps inherit
the new features. (I know I'm mixing up classes and objects here, but
the principle is the same).

Enough dreaming. Did any of that make any sense?

Dave Griffiths