Neil, there was earlier discussion that led to this (see Mantis 1584). The previous discussion indicated agreement that 8.19 should change as I address in (1) and (2). That is why we need to have the discussion and why 1584 is on the priority list for 2008 -- adopting either (1) or (2) would be incompatible with the 8.19 text and such a change must be in this LRM or else compatibility issues will be exacerbated. As I noted in my original post, of (1) and (2), (2) is less disruptive since it will accept later defaults and just ignore them. If the consensus is to retain 8.19 (which is unlikely based on earlier discussion), then the question of whether (3) or (4) should apply is still open. Gord. Neil Korpusik wrote: > Hi Gord, > > In 8.19 there is the following paragraph. > > Virtual methods provide prototypes for the methods that later override them, i.e., all of the information generally > found on the first line of a method declaration: the encapsulation criteria, the type and number of arguments, > and the return type if it is needed. Later, when subclasses override virtual methods, they shall follow > the prototype exactly by having matching return types and matching argument names, types, and directions. > It is not necessary to have matching default expressions, but the presence of a default must match. > > > This seems to imply that option 1) is not backward compatible. > If I am allowed to specify a default value in the override, I > would assume that the default specified in the override is what > would be used when the overridden version of the method is > executed. > > > Neil > > > > > Gordon Vreugdenhil wrote On 11/20/07 01:54 PM,: >> All, >> >> As a group, EC has yet to come to a definite conclusion on how >> to handle defaults in virtual method overrides. >> >> There are four choices that I think make sense: >> 1) disallow defaults in an override >> 2) ignore defaults in an override >> 3) use the defaults based on the static type of the object reference >> 4) use the defaults based on the actual type of the object >> >> >> I think that previous discussion indicated some preference for (1). >> Given the current LRM text, I think that (2) is more compatible >> in that the absence or presence of a default could have a semantic >> difference from current code but would be structurally compatible. >> Either (3) or (4) is defensible based on the current LRM text. >> >> Can we come to consensus on this? If so, I'd be willing to >> write up a proposal. >> >> I have a preference for (2), would accept (3) or (4), and >> would likely be slightly opposed to (1) due to compatibility >> concerns (unless defaults in overrides use was just deprecated >> rather than completely removed). Between (3) and (4) there are >> interesting philosophical questions about designers versus users >> of a class, but after consideration I would likely prefer (3) >> over (4) in that space. >> >> Gord. > > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Nov 20 15:34:36 2007
This archive was generated by hypermail 2.1.8 : Tue Nov 20 2007 - 15:34:48 PST