Re: [sv-ec] Mantis 1584 - defaults for virtual methods

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.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.