Issue 1313: Keyword identifiers (04) (obv-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced the concept of "keyword identifiers" in an effort to avoid breaking existing IDL specifications. It specifies that a keyword identifier is a word that is treated as a keyword only when used in a keyword context, and is otherwise treated as a regular identifier. 4) Finally, the keyword identifier approach gives the impression that IDL extensions can be made at no cost, which is simply not true. Resolution: Revised Text: Actions taken: May 8, 1998: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Thu, 07 May 1998 17:44:17 -0400 To: obv-rtf@omg.org, issues@omg.org From: Steve Vinoski Subject: let's lose keyword identifiers The Objects By Value (OBV) Specification (orbos/98-01-18) introduced the concept of "keyword identifiers" in an effort to avoid breaking existing IDL specifications. It specifies that a keyword identifier is a word that is treated as a keyword only when used in a keyword context, and is otherwise treated as a regular identifier. As a solution, keyword identifiers create a significant long-term penalty in order to correct a short-term problem. They raise more issues than they solve: 4) Finally, the keyword identifier approach gives the impression that IDL extensions can be made at no cost, which is simply not true. Submitters to future OMG RFPs will see keyword identifiers as a no-cost back door by which they can extend IDL as they see fit. While the presence of the OMG Architecture Board would hopefully prevent such extensions unless absolutely necessary, it cannot prevent them all. For example, if an RFP that promises to provide highly-desirable new features receives responses that all add new keyword identifiers, the non-technical pressures to adopt the submissions so as to make the technology available as quickly as possible may force the AB to compromise and adopt new IDL keyword identifiers. The more keyword identifiers that are added, the more severe the problems described above will become. Proposal: Drop keyword identifiers completely. Add new IDL keywords that reflect the new capabilities offered by OBV. Choose these keywords so that they minimize the breaking of existing IDL specifications while remaining meaningful as keywords. Jeff Mischkinsky wrote: >Taken from the CORBA 2.2 spec: > struct foo > { > long value; > sequence chain; > } >We don't think it's a real good idea to break/invalidate customers' >existing code, examples that are used in the CORBA spec, etc. This is like saying, "Well, we want to add "foo" as a new IDL keyword, but it will break lots of IDL, so let's invent a convoluted context-sensitive grammar to solve the problem instead." The following table lists the existing OBV keyword identifiers (from section 5.4.1, page 5-43 of orbos/98-01-18) in the left column and the proposed new IDL keywords to replace them in the right column: value --> valuetype ValueBase --> ValueBase (no change) safe --> safebase custom --> custom (no change) public --> public (no change) init --> initializer abstract --> abstract (no change) supports --> supports (no change) As the table shows, the "value," "safe," and "init" keyword identifiers are changed because of the high degree of probability that they are already used in existing IDL specifications. The "custom" keyword may also be in use but is not changed because it implies precisely the right meaning for custom valuetypes. Section 5.4.1 of the OBV Specification should be changed to reflect the new keywords. Section 5.4.2, which specifies what keyword identifiers are, should be completely dropped. Other sections of the OBV Specification should also be carefully edited to replace all occurrences of obsolete keyword identifiers with the appropriate new keywords proposed above. Note that ORB vendors can modify their IDL compilers to start issuing warnings about these new keywords if they detect their usage in existing IDL, thus giving customers time to convert their IDL before OBV comes along and these identifiers become official keywords. This is a short-term penalty, but it is far less costly than the long-term pain that would be caused by the adoption of keyword identifiers. Finally, I might note that despite the fact that the ANSI/ISO C++ committees added a number of new keywords in making the C++ standard, I know of absolutely *nobody* in the C++ user community who had their code broken by the addition of the new keywords. I'm not saying that not a single line of C++ code anywhere was broken, just that the effects were minimal, as there is far more C++ code in the world than there is IDL. I think therefore that the OBV submitters vastly overestimated the degree to which existing IDL will be broken by adding new keywords. --steve