🚀 go-pugleaf

000000

Gee, I guess I can't just junk these threads after all.

OK, let me give the most authoritative position on the MutualExclude field.
Someday, when I phase out and others phase in, perhaps the philosophies
communicated herein will change, but I can assure you that my description
of the MutualExclude use field is final.

First, whenever there is such obvious confusion, the God of Compatibility
decrees that we can't just start using a field like Gadget.MutualExclude
and try to say "I told you so" if you didn't use it like we decided
you should have.

Any system use of that field can only be made if a new clearly reserved
indicator (such as a Flag bit) declares that the new interpretation is
to be made.

Now, a flag bit is no more explicitly decreed reserved than many other
confusing fields, but the obvious call on Flag fields is that unused
bits are reserved and should be zero.  I hope this point requires no
debate, and it illustrates how all "ex post facto" decrees have to be
ultimately a judgement call.

It turns out that Gadget.MutualExclude *is* used in V1.4, for something
completely incompatible, but only if you set the GadgetType field
to a completely new value (CUSTOMGADGET).  In this case, the MutualExclude
field points to you gadget's callback hook, or Class structure.
Note that programs doing anything crazy or random with this field will
not be affected.

On to other points.  Dan Riley explained perfectly why it is AOK to
package a user-sized structure (such as Gadget or MenuItem) in a larger
structure.  Again, we'd need to have some reserved bits or values specify
that a longer interpretation of these structures is to be used.

As for the comment in intuition.h, it's still in there because I never
got a bug report for it.  How many people bitching about it have sent
in a report?  (No answers need be posted.)  I'm glad to see Mike
make a note to himself, and I'd better find out he also mailed a note
to cbmvax!bugs (and I'll be checking the date! ;^)

As for Larry Phillip's position, I think you are standing on logically
firm ground, from your analysis, but I think you should have developed
a much more paranoid and conservative style after years of working
with Intuition.  An extended structure would be better, from a safety-zen
point of view, but since there are some bytes to be saved and this
particular case is so bizzare, it's a close call.

In general, though, an apparently sound deduction about what is
reserved, what will, or what will not happen in order to be spared
the *inconvenience* of using a package/extension, should probably set
off bells in your head and red flags in your heart.  Likewise relying
on "side effects."

I presume that Marco was just trying to communicate the "good zen" of
steering as clear as possible from the many gray areas in Intuition.
On this philosophical point, I agree, but I have to scowl rather harshly
at his continuing indulgence in being a dickhead.  I guess we have
to adjust for people's net personalities.

What else is there?  Oh yes, mutual exclusion of gadgets.  Right.
Mike and others point out SOME of the problems with the "envisioned"
mutual exclude design.  I think you'll like the replacement.

In the meantime, you can try to get Peter's excellent AmigaMail article
(AmigaMail and AmigaMail/Market are much improved, by the way, so you
might consider re-upping if you gave up on them before), or my description
in the V1.2 Intuition Enhancer documentation (which Peter argues is
one notch too restrictive, but at least now he can see why I've
grown a little conservative).

Sure do love them Gadgets!  That's why I keep rewriting them ...

	    jimm
	Intuition Guy

-- 
--------------------------------------------------	- opinions by me
"This voice console is a *must*.  I press Execute. 
 `Hello, I know that you've been feeling tired.
  I bring you love and deeper understanding.' "		-lyrics by Kate Bush