June 06, 2013
On Wed, 05 Jun 2013 20:49:00 -0400, deadalnix <deadalnix@gmail.com> wrote:

> On Wednesday, 5 June 2013 at 20:01:06 UTC, Kapps wrote:
>> Anders Hejlsberg talks about why they decided to use final by default in C# at http://www.artima.com/intv/nonvirtualP.html. See the Non-Virtual is the Default section. They do this *because* they saw the drawbacks of Java's virtual by default and were able to learn from it.
>>
>
> The first point : Anders Hejlsberg: There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue.
>
> It is blatantly false. Maybe it was true at the time, I don't know, but I find quite disturbing that the first argument is 100% moot.

This was circa 2003.  Look at the state of Java from then.  And also consider that when the *decision* was made to make non-virtual the default, was considerably before then.

-Steve
June 06, 2013
On Thursday, 6 June 2013 at 00:49:55 UTC, Walter Bright wrote:
> 4. none means final and non-overriding.

BTW be sure not to remove the final keyword, since having it to undo a "virtual:" will still be useful to at least of us.
June 06, 2013
On Thursday, 6 June 2013 at 01:00:36 UTC, Steven Schveighoffer wrote:
> This was circa 2003.  Look at the state of Java from then.  And also consider that when the *decision* was made to make non-virtual the default, was considerably before then.
>
> -Steve

This is why I wrote that this may have been true in the past. Nevertheless, it is completely false today.

History also showed us that C# introduced way to revirtualize method, for several purposes like mock. We can't simple take this argument and don't look at it with the light of history.

The history shows that out of 3 point, only one remains valid, and this is the one about properties. Ironically, this is the one that do not apply to D (in its current shape) as we don't have an proper property.
June 06, 2013
On Wednesday, June 05, 2013 17:49:17 Walter Bright wrote:
> I think we accomplish this in a simpler way:
> 
> 1. 'virtual' means a method is an "introducing" one.
> 2. 'override' means a method overrides a base virtual function with a final
> function.
> 3. 'override virtual' means override with a non-final function.
> 4. none means final and non-overriding.

I would have expected something more like

1. 'virtual' means a method is an "introducing" one.
2. 'override' means override with a non-final function.
3. 'final override' means a method overrides a base virtual function with a
final function.
4. 'final' by itself both mean final and non-overriding.

I think that it would be confusing for final to be implied if virtual is not used with override, and I'd argue that virtual should only go on the "introducing" one. Doing so will mean less anotation, will be less confusing IMHO, and will break less code. If override by itself means override non-final, then every case of override that we currently have is valid, and all that needs to be changed is that introducing functions will need to be marked as virtual. Then the only real changes are

1. Functions not marked with virtual or override are final. 2. Introducing functions must be marked with virtual.

What you're suggesting would be a larger change, and I don't see how it would be better.

- Jonathan M Davis
June 06, 2013
On 2013-06-06 01:14:08 +0000, "Jonathan M Davis" <jmdavisProg@gmx.com> said:

> On Wednesday, June 05, 2013 17:49:17 Walter Bright wrote:
>> I think we accomplish this in a simpler way:
>> 
>> 1. 'virtual' means a method is an "introducing" one.
>> 2. 'override' means a method overrides a base virtual function with a final
>> function.
>> 3. 'override virtual' means override with a non-final function.
>> 4. none means final and non-overriding.
> 
> I would have expected something more like
> 
> 1. 'virtual' means a method is an "introducing" one.
> 2. 'override' means override with a non-final function.
> 3. 'final override' means a method overrides a base virtual function with a
> final function.
> 4. 'final' by itself both mean final and non-overriding.
> 
> I think that it would be confusing for final to be implied if virtual is not
> used with override, and I'd argue that virtual should only go on the
> "introducing" one.

I concur. I don't think "override" and "virtual" should be allowed together on the same function. Here's a few reasons.

Let "virtual" mean "create a new slot in the vtable". With that in mind, "virtual override" makes no sense: you can't make a new vtable slot and override it in the same class.

If the function is already virtual, there's much less to gain by making it automatically final at the first override. It's very likely that it can be overridden again safely, and it probably can't be optimized into calling it statically most of the time since otherwise it wouldn't have been made virtual in the first place.

There's also the consideration that adding/removing/reordering virtual functions change the ABI, while doing the same for overridden function does not. By only using "virtual" when allocating vtable slots, you're making it easier to recognize changes which are likely to break already compiled code.

P.S.: while implementing this change, please make sure private and package functions can be virtual.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

June 06, 2013
On Wed, Jun 05, 2013 at 09:14:08PM -0400, Jonathan M Davis wrote:
> On Wednesday, June 05, 2013 17:49:17 Walter Bright wrote:
> > I think we accomplish this in a simpler way:
> > 
> > 1. 'virtual' means a method is an "introducing" one.
> > 2. 'override' means a method overrides a base virtual function with a final
> > function.
> > 3. 'override virtual' means override with a non-final function.
> > 4. none means final and non-overriding.
> 
> I would have expected something more like
> 
> 1. 'virtual' means a method is an "introducing" one.
> 2. 'override' means override with a non-final function.
> 3. 'final override' means a method overrides a base virtual function with a
> final function.
> 4. 'final' by itself both mean final and non-overriding.
[...]

Yeah, I think requiring 'override virtual' is a bit counterintuitive. Generally speaking, if I'm overriding a virtual method, then I'm also planning to expose the same API (i.e. a virtual method) to my derived classes, so it should also be virtual in turn. Overriding a virtual method with a final method is something exceptional (i.e. at the leaf nodes of the tree of overridden methods), so it should be the one that requires explicit specification.

As for no specification, I thought the whole point was to have it default to final? So 'final' should be optional in this case.


T

-- 
It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall
June 06, 2013
On Thursday, 6 June 2013 at 01:14:23 UTC, Jonathan M Davis wrote:
> I would have expected something more like
>
> 1. 'virtual' means a method is an "introducing" one.
> 2. 'override' means override with a non-final function.
> 3. 'final override' means a method overrides a base virtual function with a
> final function.
> 4. 'final' by itself both mean final and non-overriding.
>
[...]

Yes I agree that's much more intuitive.

Also having ability for methods to individually opt out of a virtual: or final: block will be nice to have.

eg

virtual:

   void a();
   final void b();

...

This should satisfy everyone since you'll easily be able to make a class virtual by default or final by default (more or less).

--rt

June 06, 2013
On Thursday, 6 June 2013 at 05:19:32 UTC, H. S. Teoh wrote:
>> 1. 'virtual' means a method is an "introducing" one.
>> 2. 'override' means override with a non-final function.
>> 3. 'final override' means a method overrides a base virtual function with a final function.
>> 4. 'final' by itself both mean final and non-overriding.


> As for no specification, I thought the whole point was to have it
> default to final? So 'final' should be optional in this case.

I see your point, but when I override a virtual it will usually always be with another virtual unless for some reason I wanted to explicitly state final. That's how it's always been done in other languages that I'm aware of, and switching to final by default on overrides will likely be a source of frustration.

--rt
June 06, 2013
On Thursday, 6 June 2013 at 05:31:21 UTC, Rob T wrote:
> Yes I agree that's much more intuitive.
>
> Also having ability for methods to individually opt out of a virtual: or final: block will be nice to have.
>
> eg
>
> virtual:
>
>    void a();
>    final void b();
>
> ...
>
> This should satisfy everyone since you'll easily be able to make a class virtual by default or final by default (more or less).
>

The other way around break less code and achieve the same result.

I still don't understand how that C# interview shifted the discussion that much. Only 3 argument are provided, one that have been made obsolete by compiler technology, one that have been invalidated by actual usage (hopefully, C# being in a VM, this could be fixed by providing tooling that patch the bytecode, which isn't an option in D) and one that do not apply to D.
June 06, 2013
On Wednesday, June 05, 2013 22:17:49 H. S. Teoh wrote:
> On Wed, Jun 05, 2013 at 09:14:08PM -0400, Jonathan M Davis wrote:
> > On Wednesday, June 05, 2013 17:49:17 Walter Bright wrote:
> > > I think we accomplish this in a simpler way:
> > > 
> > > 1. 'virtual' means a method is an "introducing" one.
> > > 2. 'override' means a method overrides a base virtual function with a
> > > final
> > > function.
> > > 3. 'override virtual' means override with a non-final function.
> > > 4. none means final and non-overriding.
> > 
> > I would have expected something more like
> > 
> > 1. 'virtual' means a method is an "introducing" one.
> > 2. 'override' means override with a non-final function.
> > 3. 'final override' means a method overrides a base virtual function with
> > a
> > final function.
> > 4. 'final' by itself both mean final and non-overriding.

> As for no specification, I thought the whole point was to have it default to final? So 'final' should be optional in this case.

Yes. It appears that I typed #4 too quickly, so maybe that's what's confusing you. It should say

4. 'final' by itself and none both mean final and non-overriding.

So, the _only_ things that would change would be

1. virtual would now be required on the "introducing" function to make it virtual.

2. Functions without virtual or override would now be implicitly final and non- virtual.

- Jonathan M Davis