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