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

From: Arturo Salz <Arturo.Salz_at_.....>
Date: Wed Nov 21 2007 - 16:39:50 PST
Gord,

 

Some comments inlined below.

 

            Arturo

 

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Wednesday, November 21, 2007 11:39 AM
To: Arturo Salz
Cc: Neil.Korpusik@Sun.com; SV_EC List
Subject: Re: [sv-ec] Mantis 1584 - defaults for virtual methods

 

The problem is what does "the same default" mean?

 

For constant values this is meaningful.  For non-constant

defaults, this becomes much more difficult to describe.

Particularly since there is an open question of whether

something like:

     function void f(int x; int y = x;)

should be legal.

 

IMHO what you wrote should not be legal, that is, bind a default
argument to

a formal argument. The scope of default arguments is outside the
function.

At least that's how I interpret the LRM:

 

The default_value is an expression. The expression is evaluated in the
scope containing

the subroutine declaration each time a call using the default is made.

 

If so, then overrides in very useful scenarios becomes

exceedingly difficult to determine.

 

So, I don't think that defining it to be "the same" is Ok.

 

I don't see what is the complication. The "same" means precisely that:
"the same". That is 

straightforward for constants (or literals). For variables or
expressions, it means the same

variables (or expressions) and bound to the same objects.

 

Arturo Salz wrote:

> 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.

 

 

I don't understand what you are claiming.

 

Are you claiming that the default value is part of the type?  Certainly

that isn't the case.

 

I'm saying that a user that overrides a method AND its default
argument(s) is expecting

that when the overridden method is called the overridden default also be
used. So in that

sense, the default is very much a part of the type. What other
expectation could a user

have when writing something like the following:

 

class B;

    virtual task F( int a = 3 ); ... endtask

endclass

 

class C extends B;

    virtual task F( int a = 5 ); ... endtask

endclass

 

Just taking default value 3 when calling C::F() is simply wrong.

 

I don't see that (2) is any different than (5) other than an

error check.  (2) says "ignore a change in the default";

(5) says "make sure the defaults are the same".

 

We don't disagree. I did say (5) is similar to (2). But the subtle
distinction is important.

It's not just that the compiler will check it - that becomes the
semantics of the language.

 

Or are you claiming that you can start with no default and provide

one later?  That certainly isn't compliant with current LRM text.

 

            No. I'm not claiming that.

 

I could live with a variant of (2) that says "take the first

default" and ignore the rest but since "the same" is so badly

defined for non-constant values, I don't think that is

acceptable as is.

 

That makes it easier for implementers. But, as I wrote above, that could
hardly be the

user's expectation. Quietly replacing the argument with no indication is
just asking for

trouble. I prefer to just make it illegal to change the argument. 

 

Gord.

 

 

> 

> 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.
Received on Wed Nov 21 16:49:01 2007

This archive was generated by hypermail 2.1.8 : Wed Nov 21 2007 - 16:49:44 PST