Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!van-bc! From: lphillips@lpami.wimsey.bc.ca (Larry Phillips) Newsgroups: comp.sys.amiga.tech Subject: Re: Mutual Exclude Gadgets Keywords: Gadgets Message-ID: <953@lpami.wimsey.bc.ca> Date: 28 Dec 89 18:40:26 GMT Lines: 114 Return-Path: To: van-bc!rnews In <9166@cbmvax.commodore.com>, mks@cbmvax.commodore.com (Michael Sinz - CATS) writes: >In article <947@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>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. 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. > >Ahh, but you must understand that the field is for SYSTEM use for that purpose. >Lets say you do it via a pointer to a special field that you invent. But I don't want to use it as a pointer to anything. I want to use it as it was intended to be used, as bit significant indicators to gadgets to be unselected. > How will the system, once (if) mutual exclude is implemented, know what to do > with that field? Is it a pointer, a magic value, junk? Ahh... well, that's the whole point of my objections, isn't it? The clear implication in everything I have read is that CBM had planned on implementing mutual exclude, and had planned on doing so via this field, and in the way documented in every include since before 1.0. > This is a *SYSTEM* field and that in itself says that if you don't use the > system function (and, right now there is none) you *MUST* respect the fact that > the field is unavailable to you. Good point, and I _can_ see the rationale. I did not interpret anything in any of the warnings in the documentation to include this. I did make some assumptions that seemed perfectly reasonable, based upon the nature of this particular circumstance, and the 'YET' in 'not yet implemented'. It makes me wonder though, how many others have made the same assumptions, and how many programs will break. Worth thinking about. >>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. It is an unfortunate fact of >>life that bugs can happen. 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. > >No, we don't change things that are defined to work. Mutual Exclude field >could be seen as a reserved field for future work. I think you might want to consider putting that warning in the includes, and associate it with anything that doesn't currently work. When I write code, I try to follow the rules. If and when I go outside the rules, I expect that my code will break. When I go outside the rules inadvertently, I tend to be surprised that it doesn't work. The more explicit the rules are, the more it is explained why, the less problem there will be with broken software. It is in CBM's best interests to promote good software in any way they can. > That is, we may, at one point, have hoped to add mutual exclude via that >field but have now noticed that that would not be the best way to handle that >so we change it so that the field is something more important. (Maybe even >mutual exclude) But, since there is no current mutual exclude using that field, >there is no way you can know what type of value needs to be in that field. Right. I do see that, now that you mention it, but the way it reads, and has always read to me is that it is a function that will someday be imnplemented in a well defined (and already defined) way. My mistake. I think it's a natural mistake though, and one that others could easily make. > In that way, the field is just an empty that you need to keep that way until >you know what type of values will do things. This is much like the bits in the >gadget flags. You don't set bets that are not defined yet. It may not change >the way it works now, but when that bit gets used, what will you do then? What >will the gadget do? I see these as completely different. Undefined bits are inviolate in my book too, and I do leave them alone. What bothers me is that the MutualExclude bits are defined, in both the assembler and C includes. >>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. > >Again, we have not yet defined HOW, so you can not define it youself unless >you really wish to BREAK when we do define it. If the definition comes out >be a "Pointer to the Mutual Exclude function that gets passed, in D0 the >gadget ID and A0 the gadget address" and you used it as a pointer to a >MX data array or a bit field, POOF, your program goes and executes random >data at stange addresses. YOU blow up, and it would have been YOUR fault. Well, again, I took those bits as being defined, and the HOW as being defined. The only thing I saw as undefined was the WHEN, which could have even been 'never'. Changing the meaning of the field is changing the meaning of the field, regardless of whether it is being used as MutualExclude or as something else entirely, and what the meaning is changed to has no bearing on the matter. I figured that in the interim, we could provide our own functionality, in a manner that would not break if the MutualExclude was implemented. I think you will break more than a few programs in 1.4, and some will be broken because of this particular field. Yes, you can blame the programmer, there is nothing to prevent you from doing that, but I see CBM as sharing that blame in this case. -larry -- " All I ask of my body is that it carry around my head." - Thomas Alva Edison - +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+