Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!usc!pollux.usc.edu!papa
From: papa@pollux.usc.edu (Marco Papa)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Mutual Exclude Gadgets
Keywords: Gadgets
Message-ID: <22023@usc.edu>
Date: 29 Dec 89 04:44:21 GMT
References: <947@lpami.wimsey.bc.ca>
Sender: news@usc.edu
Organization: Felsina Software, Los Angeles, CA
Lines: 100

In article <947@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>In <9147@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes:
>>WRONG!  Under no circumstances should you help yourself to a field that
>>the system reserves for possible future use.  If we were to implement
>>mutual exclusion using this field, yet you were using the field for
>>your own implementation, how well do you think the two would co-exist?
>>
>>Not very well at all.
>
>Whoa!  That field is specified, in the latest includes I have, as being the
>proper place to specify gadget mutual exclude. It is most definitely NOT
>specified as being reserved, nor are there any warnings against using it as a
>gadget mutual exclude field. While I fully realize that gadget mutual exclude
>does not work in the current release, that is completely beside the point.

Sorry, Larry, but here I have to agree with CBM. That field has been documented
as "NOT IMPLEMENTED" from the first release of the AutoDocs, to the last one
I have (the ones for 1.3).  It has NEVER been listed for "private application
use" as you (and the other guy) seem to imply it is.  The fact that it is
not implemented, means that if you set it, that won't have any result
with this release.

>>The rule is simple:  Make sure all unused or reserved fields are properly
>>initialized (normally to all zeros).
>
>Yes, the rule _is_ simple, but that field is NOT specified as unused or
>reserved.  For the rule to work, it must work both ways.  You cannot reasonably
>expect to leave fields lying around that are not marked as untouchable and just
>sort of hope that nobody will use them.  

CBM has always documented it as "reserved" for toggling gadgets at the
"system" level, if and when they'll be implemented.  The fact that currently
the use of the field is NOT imeplemented, does not give YOU the freedom
to fool with it at will, and then expect that future releases will always
work the same.  Most data structures (including Gadgets) have "user defined"
fields at the end of them.  That's where you can fool with.  In any case it is
very easy to build "custom user gadgets", with whatever additional fields 
you want by creating your own modified structure:

struct MyGadget {
	struct Gadget gad;
	long extension1;
	char *extension2;
	BOOL togglegad;
}

This is portable, and will work with future releases as well.

>Worse, you cannot reasonably specify a
>field as being for a particular purpose and hope to defend yourself when
>someone uses it for that purpose.

using the MutualExclude field  according to "your own specification", since
"no" specification from CBM exists (at the moment) is suicidal.  Especially
when you've been warned.

>Do you reserve the right to make GRELBOTTOM suddenly mean GRELRIGHT, or to
>change the call to OpenLibrary() to DoIO()?  Correctly written operating
>systems do what the documentation says they do.  

C'mon, larry. Give us a break.  GRELBOTTOM and OpenLibrary ARE documented.
MutualExclude is not and has been reserved for future use.

>The proper thing to do in the case of this
>particular bug is to either implement this field for its originally intended
>purpose, leave it alone and let the authors use it for their own mutual exclude
>routines, or to document it as being reserved, and wait a reasonable length of
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>time (a few releases perhaps), before using it for something else.
 
If you were doing "serious" Amiga programming (i.e. if you had gotten the 
AutoDocs from CBM as a certified or commercial developer), you would know
that it IS reserved.

>All through the includes, one can find reserved and private fields. ROM
>Stompers and Structure Twiddlers have been duly warned about the consequences
>of messing with them. 'Proper Programmers' do not mess with them, but they
>might be using a field DEFINED BY CBM to do what they see as perfectly
							      ^^^^^^^^^
>legitimate operations, fully within the letter and spirit of the documented
 ^^^^^^^^^^^^^^^^^^^^^
>guidelines.

Using a "system field" for user-defined operations is NOT a "legitimate"
use of that field.  A comment like the one above really makes me wonder
what kind of programmer you are.  You probably need a system liker MS-Windows,
where you CAN'T see almost any system fields, so that you can't mess with them
directly.

>This is not a flame... yet. It is a vehement plea for sanity. There are enough
>programs out there already that purposely or inadvertently violate the rules.

Really?  You're message promotes "insanity", IMHO. Programs that either
purposely or inadvertently violate the "rules" should be BASHED as much as
one can.  No prisoners taken :-)

-- Marco Papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Xerox sues somebody for copying?" -- David Letterman
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=