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

Gord,

I believe we all agree that option (1) is too restrictive.

Option (2) is risky because we are simply ignoring an important part of
the type. For derived classes, the default decision would be made on the
wrong type.

Option (4) is arguably the correct thing to do but it requires run-time
default argument processing and poses code generation challenges. I'd be
opposed to this on the basis of implementation complexity.

Option (3) can be implemented in the compiler and is thus more rational
than (4), but it's risky because the decision is based on the "wrong"
type (like 2).

Given all these concerns, I believe there is another alternative,
similar to (2) but closer in spirit to the LRM. Lets call this option
(5):

Once a default is specified, that default is applied to all subclasses
(same as 2), AND, if any subclasses specify a default, they must specify
the same default.

This option ensures that the compiler maintains the consistency, and,
honestly, I think is the rational thing to do from both user and
implementer perspective.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Tuesday, November 20, 2007 3:34 PM
To: Neil.Korpusik@Sun.com
Cc: SV_EC List
Subject: Re: [sv-ec] Mantis 1584 - defaults for virtual methods

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.


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