On Thursday, 13 March 2014 at 00:37:42 UTC, Andrei Alexandrescu wrote:
> On 3/11/14, 11:36 PM, Steve Teale wrote:
>> On Tuesday, 11 March 2014 at 18:56:15 UTC, Indica wrote:
>>> I'd like to point out that Walter and Andrei can't do it all
>>> themselves. It takes a team and part of pulling it off is well defined
>>> goals and job descriptions with devoted people.
>>
>> This is one of the motivations for my remark. They both have probably
>> more tan enough to do without having to wade through the tremendous
>> volume of responses.
>
> I could use more tan, can't wait for the summer :o).
>
> I'm glad you brought this up and that there was some good discussion following it.
>
> Walter is a very nice man. He dislikes saying "no" to people on account of them getting mad at him or the language. So he'd rather not answer.
>
> Lately we figured that's actually worse because it creates frustration (the perception is the request/effort is ignored, not acknowledged and declined). So we set to become more decisive about things. You may have noticed in recent history that we started more often to set the foot on the ground on one topic or another.
>
> We hope that that is healthy for the community. It also means for us all to accept the reality that in matters of judgment we can't always do what others believe is best, and on occasion (hopefully not too often!) even not what would objectively be the best decision. What I'd like us to achieve and convey in future debates is that whatever decision we make, we are making it in full understanding of all involved arguments.
>
> The "perpetual design" stage of D has ended. We've made our bed, it's time to lie in it. I foresee only one more area of possible breakage - thread support, and hopefully only code that was already broken should cease to compile.
>
>
> Andrei

Appreciate the change. The increased clarity is helpful. Thanks.

Joseph

On 3/12/2014 8:49 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> The "perpetual design" stage of D has ended. We've made our bed, it's
>> time to lie in it.
>
> If you don't change your bed once in a while, it will start to smell. A
> language dies if it doesn't keep a subgroup of people for its design,
> and when necessarily its redesign.

Very true (see C++ and why D was needed ;) ), but of course the "perpetual design" stage of *D2* is over. I can certainly see an eventual D3 or D++ or E or whatever (with a smoother upgrade path than D1->D2), but not until D2 matures further.

At some point we have to dial back on breaking changes and let things settle before the next round of "bedding changes".

On Wednesday, 12 March 2014 at 11:59:45 UTC, Paulo Pinto wrote:
> On Wednesday, 12 March 2014 at 11:40:39 UTC, Manu wrote:
>
> It can also happen the other way if I mark a method virtual that used to be final, which was overloaded in a subclass, right?
>
> --
> Paulo

Not really. The way C# handles it (and I assume the way D would as well) is that shadowing a virtual method is a warning. If Bar derives from Foo and implements foobar(int), then at some point Foo decides to add foobar(int), Bar's foobar(int) will not be virtual but a warning will be given that it shadows Foo.foobar(int). You can then either mark it override, or you can mark it new to indicate that you are aware it shadows the method and don't want to overload it. So going from final to virtual is not a breaking change (but you will receive a warning until you acknowledge that you're shadowing the method), but going from virtual to final is a breaking change.

On Wednesday, March 12, 2014 17:37:37 Andrei Alexandrescu wrote:
> The "perpetual design" stage of D has ended. We've made our bed, it's time to lie in it. I foresee only one more area of possible breakage - thread support, and hopefully only code that was already broken should cease to compile.

Another major area which we've discussed changing (and agreed on - we just haven't actually managed to implement the changes) is removing toString, toHash, opEquals, and opCmp from Object to fix the const problem. That's likely to introduce breaking changes - well worth it IMHO, and hopefully it can be done with minimal disruption - but it's a pretty big change nonetheless

- Jonathan M Davis

On Wednesday, 12 March 2014 at 17:08:59 UTC, Andrei Alexandrescu wrote:
> On 3/12/14, 10:05 AM, monarch_dodra wrote:
>> On Wednesday, 12 March 2014 at 16:46:26 UTC, Andrei Alexandrescu wrote:
>>> On 3/12/14, 4:40 AM, Manu wrote:
>>>> Thank you.
>>>> There you go, it's not even hypothetical.
>>>
>>> I think the example given works against your argument.
>>>
>>> Andrei
>>
>> How so? The example was his argument verbatim.
>
> His argument assumed at core that the library designer knows better than the library user what the customization points are, and that most functions are virtual by mistake.
>
> Andrei

There were countless arguments to demonstrate that this *is* the case. If the developer had not considered whether the function is safe to be virtual, it's not safe. A change request could be made for exposing a customization point, but it is something that needs to be done explicitly by the library designer, not just override and hope that it works out. And of course, once you do expose it you're stuck with it and the design that supports it unless you want to break user code.

It would be interesting to scrape Github projects using Java (virtual by default) and C# (final by default) and see what the percentage of virtual functions is between each of them, as well as see how many easily statically noticed probable bugs there are (i.e., virtual property operating on a backing field which is then accessed directly by a different method in the base class) in each of them.

I used to believe that virtual was a better default, but these days I think the opposite. My reasoning is that inheritance is a very poor tool for code reuse. The way I see it now, inheritance is a tool for modelling "is a" relationships and variations on objects, but it's bad to use it in an API as a "to implement your business logic inherit here" thing.

You get much better code reuse out of functions, especially with generic programming. (D being the number one generic language with its templates and CTFE.) The more loosely coupled the data becomes from the business logic, the higher application quality appears to be and the more breakage decreases. Presenting an interface for a library whereby the types can automatically be overridden is a good way to lead people into writing code that's going to break later and may burden the library's implementer with supporting something he didn't know he'd need to support. (e.g. in Nowak's ZIP library.)

On 3/11/14, Steve Teale <steve.teale@britseyeview.com> wrote:
> What D needs at this point is a dictator.

You see these massive protests and overthrows of people who hold absolute power around the world, and you think D needs a dictator. I'm really baffled at some people.

On Wed, 12 Mar 2014 17:38:10 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/11/2014 2:28 PM, Michel Fortin wrote:
>> class Foo
>> {
>> final:
>>      void bar();
>>      void baz();
>>
>> virtual:
>>      void crack();
>>      void crunch();
>>
>> final:
>>      void dodge();
>>      void damp();
>>      virtual void divert();
>>      void doh();
>> }
>
> class Foo
> {
>    final
>    {
>       void bar();
>       void baz();
>    }
>
>       void crack();
>       void crunch();
>
>    final
>    {
>       void dodge();
>       void damp();
>       void divert();
>       void doh();
>    }
> }
>
> That said, there's still a case for !final.

Fixed it for you.

class Foo
{
  final
  {
     void bar();
     void baz();
  }

     void crack();
     void crunch();

  final
  {
     void dodge();
     void damp();
  }
     void divert();

  final void doh();
}

-Steve

"Walter Bright"  wrote in message news:lfqk3r$1rq$1@digitalmars.com... 

> class Foo
> {
>    final
>    {
>       void bar();
>       void baz();
>    }
> 
>       void crack();
>       void crunch();
> 
>    final
>    {
>       void dodge();
>       void damp();
>       void divert();
>       void doh();
>    }
> }
> 
> That said, there's still a case for !final.

This looks much worse with all the method bodies still in there.

On Wednesday, 12 March 2014 at 23:53:52 UTC, Walter Bright wrote:
>
> I rely on the fresh blood of unborn kittens.

I must try it. Sadly our youngest cat has disappeared over about 4 days now, and we're feeling worried.