>From: "Brad Pierce" <Brad.Pierce@synopsys.com> >Just a short note about your last point -- > >The existing built-in enum method 'next()' needn't be a backward >compatibility problem for a new keyword 'enum'. See friendly amendment >in bullet 11 here ><http://www.eda-stds.org/sv/sv-champions/hm/att-0340/pierce_email_vote_F >eb2308.txt> . Can it be done? Well, yes. But that does not make it a good idea. It is clearly an ugly kludge, and such things tend to lead to problems. Some specific problems: 1. It requires special rules in the BNF and in parsers. That makes the BNF harder to read and understand, and more prone to errors. It makes parsers more prone to bugs. 2. It requires care to ensure that there is no ambiguity between the two meanings of the keywords. And every time you add another such special case, the complexity of the interactions with the previous special cases becomes greater. 3. Some of the built-in data types, such as mailboxes and semaphores, are considered to be classes and can be extended to create derived classes. What if we wanted to go back and do the same for enums? You would be unable to replace the next() method with your own version, since it is a reserved word. Unless you also wanted to add next() to the BNF for declaring a method. The ugliness in the BNF grows... 4. I'm not sure you can do operator binding to the next() function, since most operators are already defined for enums via autocasting to their base integral type. But if you can, or if you could derive a new type from enums as in 3 above, and wanted to be able to bind an operator to next(), you would then need to add next() to the BNF for operator binding. The ugliness just keeps growing... That was just off the top of my head. Clean design avoids problems; bad design invites them. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Mar 18 14:01:42 2008
This archive was generated by hypermail 2.1.8 : Tue Mar 18 2008 - 14:05:04 PDT