Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!apple!oliveb!amiga!cbmvax!peter
From: peter@cbmvax.commodore.com (Peter Cherna)
Newsgroups: comp.sys.amiga.tech
Subject: Re: User Extensions to System Structures
Message-ID: <9216@cbmvax.commodore.com>
Date: 5 Jan 90 01:13:29 GMT
References: <"90-01-04-21:33:00.95*UK4H"@DKAUNI2.BITNET>
Reply-To: peter@cbmvax.commodore.com (Peter Cherna)
Organization: Commodore, West Chester, PA
Lines: 90

In article <"90-01-04-21:33:00.95*UK4H"@DKAUNI2.BITNET> UK4H@DKAUNI2.BITNET ("JAE") writes:
>Hi usenet! (this is my first time here, but who cares...)

Welcome.

>The recent discussion about mutualExclude striked a chord in me.
>One thing that was said (I can't remeber who said it) was about
>those 'user' fields in various (all?) intuition/exec etc. structures.
>I agree with those who say that one should use these fileds for
>one's own purposes instead of using ANY fields in a system struct.
>
>Now: what if two programs (independend ones) want to share, say,
>a window. Both want to link some private information to the
>window.
>Unnecessary? Well, I can't think of an application right now, but
>I'm almost sure there is one.
>Anyway, what will happen. Both will user that 'userExt' field
>(I don't know real name now). Both will write something to it.
>Well, who's last is lucky in that case.

The UserData field clearly belongs to the owner of the structure.
Which program allocated the structure or opened the window, etc.?
ONLY that program has the right to the UserData structure, and may
well be using it.  Any other independent program has no business using
the UserData field.  Counterexamples welcome (though I doubt any exist).

This would be a good place to reiterate an important point:

	In general, programs which mess with things that don't belong
	with them suffer from several problems:

	1)  The "I hadn't thought of that" syndrome.  With the number
	    of Amigas out there, it's only a matter of time before
	    someone has a set-up the author didn't consider.  Guru.

	2)  The software upgrade blues.  A user gets the new release of
	    Workbench or some other product, and lo-and-behold, the
	    neat utility stops working.  What happened?  Something
	    the author of the utility was assuming ain't true anymore
	    in the new version.  Guru.  Whose fault?  Usually the author's.

	3)  Mix-and-match chaos.  Ask a PC owner about combining TSR's
	    (programs like SideKick that stay resident in their computer).
	    Which ones work together?  In what order must they be run?
	    Guru.  Guru.  Guru.

From the system end, we try to anticipate the kinds of needs programmers
will have, and make those kinds of data and services available in
a system-integrated way.  If we came up short for your unique application,
ask us.  We can (and have in the past) provide more features and data in
future releases of the OS.  If you can't wait, perhaps we can provide
a method that you can use today that will still work with the next release.

>What I'm thinkin' of is some standard userExtension struct. Just like
>
>  struct userExtension {
>    struct userExtension *nextExt;
>    LONG id;
>  }
>
>The id field must just be uniq. This would best be accomplished by
>providing a (system) function 'AddExtension'. Oh, give a C func head:
>
>  BOOL AddUserExtension(root,userExt);
>    struct userExtension **root;  /*points to the field in struct*/
>    struct userExtension *userExt;  /*points to node to add*/

One clear problem here is we don't usually have a longword free in most
of the structures that are already defined.  Many of the structures can't
be readily extended for a variety of reasons.  We certainly can't change
the meaning of any existing UserData fields, at least not without some
kind of new flag in the structure which means that this structure's
UserData field is the new extensible kind.  So a given application
could never count on (say) all the windows having this kind, as opposed to
the old (keep your hands off) kind.

>I'd really like to hear any comments from anyone...

Interesting idea, all the same.

>                                             bye, JAE
>
>Juergen A. Erhard
>eMail: uk4h@dkauni2.bitnet
>phone: (GERMANY) 0721/591602

--
     Peter Cherna, Software Engineer, Commodore-Amiga, Inc.
     {uunet|rutgers}!cbmvax!peter    peter@cbmvax.cbm.commodore.com
My opinions do not necessarily represent the opinions of my employer.