Issue 444: 6.6.4 Pragma Directives for RepositoryId Para 1 - objection (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Conforming compilers should ignore pragmas that are not defined. in this spec, and that they do not explicitly support. Portable applications should only use pragmas defined in this spec. Resolution: The proposal in the summary is unreasonably restrictive, and would disallow use of other pragmas i Revised Text: Append the following sentences to Para 1 of section 8.6.4 Actions taken: November 26, 1996: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Fri, 03 Jul 1998 10:19:58 -0400 From: Jonathan Biggar Organization: Floorboard Software To: jis@fpk.hp.com, orb_revision@omg.org Subject: My votes for Vote #1 I vote yes on all issues, except for the following (with explanations): #116 It would be good to have an example in the spec, since this is a constant source of questions. If noone wants to write an example, then just change my vote to yes. #444 I think what the issue proposal was trying to say is that conforming compilers may support additional non-standard pragmas, but must ignore any pragma that the compiler does not understand without issuing an error (a warning would be ok). -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: jon@floorboard.com Date: Wed, 08 Jul 1998 11:58:16 -0700 From: Jonathan Biggar To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: My votes for Vote #1 References: <359CE88E.F339D36E@floorboard.com> <35A0E8C0.5F8B2779@fpk.hp.com> Jishnu Mukerji wrote: > > Jonathan Biggar wrote: > > #444 I think what the issue proposal was trying to say is that > > conforming compilers may support additional non-standard pragmas, > but > > must ignore any pragma that the compiler does not understand > without > > issuing an error (a warning would be ok). > > Want to propose a sentence or two for insertion at an appropriate > place?:-) Here you go: Conforming IDL compilers may support additional non-standard pragmas, but must not refuse to compile IDL source containing non-standard pragmas that are not understood by the compiler. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: jon@floorboard.com Date: Wed, 15 Jul 1998 13:58:51 -0700 From: Jonathan Biggar To: Jishnu Mukerji CC: T E Rutt , Javier Lopez-Martin , orb_revision@omg.org, Michi Henning Subject: Re: Tom Rutt vote on Core vote2 (actually Vote 3) References: <199807151528.LAA29142@holta.ho.lucent.com> <35ACE0B0.C5C10149@fpk.hp.com> Jishnu Mukerji wrote: > > Issue 665: accept non-name comparison for equivalent operation, > but do not accept > > looseness of statement proposed for item 4. Vote for non-name > comparison > > is contingent on adding the following > > sentence after the proposed non-name comparison change in item 4: > > " > > If they are not empty, they must include the same identifier > > as used in the IDL source defining the type for that IR. > > " > > > > I think I could live with that, since I believe that was the intent, > but let me consult my TypeCode expert > Javier. Javier, what do you think? I disagree with the proposed change. The IFR text is clear that names can differ from IFR to IFR, so this change is inconsistent with that text. > > Issue 999: > > The sentence in para 1 from the IR stating "It does not matter > what format is used for any particular > > RepositoryId." Seems to imply that other id formats are allowed > for the repository id. This new change is > > very restrictive.. How can we evolve with such a restrictive > sentence. It is also in conflict with the > > proposed resolution for Issue 444. I don't understand the objection. My reading of that sentence is that it means to say that each IDL construct in an IDL source file has its own RepositoryId, and each construct can have a RepositoryId format specified independently of the other IDL constructs in the same file. > > Issue 444 has the following proposed revision: > > Append the following sentences to Para 1 of section 8.6.4 > > > > "Conforming IDL compilers may support additional non-standard > pragmas, > > but must not refuse to compile IDL source containing non-standard > > pragmas that are not understood by the compiler." > > I think we should let the 444 resolution stand as is, and try to > figure out a consensus on 999, with or > without that restrictive sentence. Voters, any opinions? I don't see how 444 conflicts with 999 at all. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org