On 2/25/2012 1:53 PM, deadalnix wrote:
> Le 25/02/2012 22:25, Timon Gehr a écrit :
>> By explicitly stating that he is aware of all the overloads:
>>
>> class B : A {
>> alias A.fun fun;
>> override void fun() { }
>> }
>>
>> Alternatively:
>>
>> class B : A{
>> override void fun()const{super.fun();}
>> override void fun() { }
>> }
>
> So, back to the example above, someone will have to go throw the whole codebase
> and add override void fun()const{super.fun();} all over the place to fix the
> broken code ?


No, he can use the alias version.

Le 25/02/2012 22:59, Walter Bright a écrit :
> On 2/25/2012 1:53 PM, deadalnix wrote:
>> Le 25/02/2012 22:25, Timon Gehr a écrit :
>>> By explicitly stating that he is aware of all the overloads:
>>>
>>> class B : A {
>>> alias A.fun fun;
>>> override void fun() { }
>>> }
>>>
>>> Alternatively:
>>>
>>> class B : A{
>>> override void fun()const{super.fun();}
>>> override void fun() { }
>>> }
>>
>> So, back to the example above, someone will have to go throw the whole
>> codebase
>> and add override void fun()const{super.fun();} all over the place to
>> fix the
>> broken code ?
>
>
> No, he can use the alias version.

What would it look like ?

On 2/24/2012 3:22 AM, deadalnix wrote:
> Le 17/02/2012 17:19, Andrei Alexandrescu a écrit :
>> On 2/17/12 8:13 AM, kenji hara wrote:
>>> I think the lack of 'override' keyword (filed as bug 3836) should
>>> become an error, without the phase of deprecating it. Otherwise
>>> following case will be allowed.
>>
>> Yes. Walter?
>>
>> Andrei
>
> I'm surprised this isn't even mentionned in http://drdobbs.com/blogs/cpp/232601305
>
> I definitively don't think that pushing stuff like that - I'm suspecting for ego
> reasons - ignoring some flaw of the idea is a good way to proceed. This even may
> be armfull for the language on the long run.
>
> With no override keyword, function can just explode on your face for no aparent
> reason in the source code you are lookign at. This isn't an issue we should ignore.
>
> This has a pretty simple solution : don't inherit thoses attributes of override
> isn't present. On the long run, don't allow override without override keyword ?

Not using override is currently deprecated. Eventually, it will be required.

Doing this precipitously breaks existing code without allowing people plenty of time to upgrade their code. This annoys people, and results in them considering D "unstable" and "unusable".

I know that some do not see it as a problem to regularly introduce breaking changes and pull the rug out from under people every month. But I think that is a recipe for disaster.

On 2/25/2012 2:16 PM, deadalnix wrote:
> Le 25/02/2012 22:59, Walter Bright a écrit :
>> On 2/25/2012 1:53 PM, deadalnix wrote:
>>> Le 25/02/2012 22:25, Timon Gehr a écrit :
>>>> By explicitly stating that he is aware of all the overloads:
>>>>
>>>> class B : A {
>>>> alias A.fun fun;
>>>> override void fun() { }
>>>> }
>>>>
>>>> Alternatively:
>>>>
>>>> class B : A{
>>>> override void fun()const{super.fun();}
>>>> override void fun() { }
>>>> }
>>>
>>> So, back to the example above, someone will have to go throw the whole
>>> codebase
>>> and add override void fun()const{super.fun();} all over the place to
>>> fix the
>>> broken code ?
>>
>>
>> No, he can use the alias version.
>
> What would it look like ?

class B : A {
 alias A.fun fun;
 override void fun() { }
}

On Friday, 24 February 2012 at 00:01:52 UTC, F i L wrote:

> Well then I disagree with Walter on this as well. What's wrong with having a "standard" toolset in the same way you have standard libraries? It's unrealistic to think people (at large) will be writing any sort of serious application outside of a modern IDE. I'm not saying it's Walters job to write IDE integration, only that the language design shouldn't cater to the smaller use-case scenario.
>
> Cleaner code is easier to read and, within an IDE with tooltips, makes little difference when looking at the hierarchy. If you want to be hard-core about it, no one is stopping you from explicitly qualifying each definition.

Debugger is the single tool in VisualStudio that i failed to replace in unix land.
I have tried many of them and they all sucked. They are either incomplete or crash too often. Command line gdb is not much of an option. The situation is so bad that looks like i need to go back to the VisualC++/gvim combo.

On 2/25/12 2:44 PM, Walter Bright wrote:
> On 2/25/2012 9:53 AM, deadalnix wrote:
>> And suddenly, the override doesn't override the same thing anymore.
>> Which is
>> unnacceptable.
>
> class A {
> void fun() const { }
> void fun() { }
> }
>
> class B : A {
> override void fun() { }
> }
>
> ----
>
> dmd -c foo
> foo.d(6): Error: class foo.B use of foo.A.fun() hidden by B is deprecated

Hm, the issue there is that now both overloads of fun must be overridden.

Andrei

On Saturday, February 25, 2012 18:11:27 Andrei Alexandrescu wrote:
> On 2/25/12 2:44 PM, Walter Bright wrote:
> > On 2/25/2012 9:53 AM, deadalnix wrote:
> >> And suddenly, the override doesn't override the same thing anymore.
> >> Which is
> >> unnacceptable.
> > 
> > class A {
> > void fun() const { }
> > void fun() { }
> > }
> > 
> > class B : A {
> > override void fun() { }
> > }
> > 
> > ----
> > 
> > dmd -c foo
> > foo.d(6): Error: class foo.B use of foo.A.fun() hidden by B is deprecated
> 
> Hm, the issue there is that now both overloads of fun must be overridden.

Except that that's already normally the case. If you had

class A
{
    void func(int i) {}
    void func(float i) {}
}

class B
{
    override void func(int i) {}
}

then the float version is not in B's overload set, and you have to add an alias.

class b
{
    alias A.func func;
    override void func(int i) {}
}

Though I suppose that the difference is that with const, it's giving you an error, and with this, it isn't. Perhaps that's what your concern is.

- Jonathan M Davis

On Feb 26, 2012 8:53 AM, "foobar" <foo@bar.com> wrote:
>
> That's analogous to saying that you don't want to depend on a lighter
since you can make your own fire by rubbing a stone with a wood stick. A lighter does tie you to a certain technology but loosing the lighter doesn't make for more productivity. Misuse of the tool or using the wrong one sure could hamper productivity but that's hardly the fault of technology.
>
No, its analogous to not using a lighter that only lights evergreens, and only works in Europe. Again, this is blatantly the view that there there is either notepad or vs, ignoring the masses of features of the editors in between. I've used vs, I don't find it to have many features - that I use - that vim doesn't.

> The above regarding MS is incorrect. MS has lots of automation and is far
better at it than *nix systems are. Its Powershell is superior to the *nix "everything is a file" ideology and there were several attempts to copy the concept to *nix with Python and Ruby.

Im not even sure what you're getting at here, I didn't realise powershell had an ideology, I don't think bash does either. And sure powershell, a nonstandard add-on, is good. Try automating something that wasn't made by microsoft though, try doing administration of it remotely without rdp.
>
>>
>> Programming a craft as much as it is a process. I tend to liken it to carpentry, you have set steps, you design and plan and build etc, but there's creativity there. As such, programmers (I've found) tend to pick an environment that suits them best. I use a minimal system that I can configure and hack to my heart's content. My colleague uses a Macbook pro that he never shuts down. The designer here uses a Macbook Air. And we all work fine, there is no "One True Way" to make a chair, why should there be one for writing a program?
>>
>> My point is that the tools that programmers use, like compilers and linkers and parser-generators and build systems and deployment tools and source control and x and y and z and .... are going to be used by a wide range of people, in a wide range of environments, for a wide range of purposes, so they should keep in mind that maybe you /don't/ have a certain tool or feature available. So you make sure that the experience at the lowest common denominator, a vt100 terminal, is acceptable, maybe not perfect, but good enough, then you build from there. If that means that D is geared towards less typing, then good, especially if  you can do the extra typing and not break things. It /is/ possible to make everybody mostly happy, and that is by aiming at the people using `cat`* to program and hitting the people using VS along the way.
>>
>> * Programming using `cat` is not recommended.**
>> ** Even though /real/ programmers use `cat`
>>
>> --
>> James Miller
>
>
> I disagree. Simply put:
>
> +---------+         +---------+
> | Magic   |         | comfort |
> | happens |         |  zone   |
> | here!   |         +---------+
> +---------+
>
> Magic cannot happen here ^.

What on earth does this mean? In the context it seems to suggest that I should be struggling to learn a new environment if I want to do something amazing.

I'm guessing you meant that I should try something new, but that doesn't need to be the editor. It's far more interesting to try to build outside of my "comfort zone".

In fact, your grade-school platitude annoys me, it suggests that I'm stuck in my ways and avoiding new tech because I like my terminal. I started in IDEs, and worked my way down. I also have the most fun working outside my comfort zone and doing something new, spending hours looking at code going "why wont you work! Why do you hate me!" Then finally getting a breakthrough... amazing.

--
James Miller

On Sunday, 26 February 2012 at 01:18:55 UTC, James Miller wrote:
> On Feb 26, 2012 8:53 AM, "foobar" <foo@bar.com> wrote:
>>
>> That's analogous to saying that you don't want to depend on a lighter
> since you can make your own fire by rubbing a stone with a wood stick. A
> lighter does tie you to a certain technology but loosing the lighter
> doesn't make for more productivity. Misuse of the tool or using the wrong
> one sure could hamper productivity but that's hardly the fault of
> technology.
>>
> No, its analogous to not using a lighter that only lights evergreens, and
> only works in Europe. Again, this is blatantly the view that there there is
> either notepad or vs, ignoring the masses of features of the editors in
> between. I've used vs, I don't find it to have many features - that I use -
> that vim doesn't.

I see the analogy went over your head. Besides, what's wrong with a lighter that only works in Europe? Works perfectly fine for me! :)

>
>> The above regarding MS is incorrect. MS has lots of automation and is far
> better at it than *nix systems are. Its Powershell is superior to the *nix
> "everything is a file" ideology and there were several attempts to copy the
> concept to *nix with Python and Ruby.
>
> Im not even sure what you're getting at here, I didn't realise powershell
> had an ideology, I don't think bash does either. And sure powershell, a
> nonstandard add-on, is good. Try automating something that wasn't made by
> microsoft though, try doing administration of it remotely without rdp.
>>
>>>
>>> Programming a craft as much as it is a process. I tend to liken it to
>>> carpentry, you have set steps, you design and plan and build etc, but
>>> there's creativity there. As such, programmers (I've found) tend to
>>> pick an environment that suits them best. I use a minimal system that
>>> I can configure and hack to my heart's content. My colleague uses a
>>> Macbook pro that he never shuts down. The designer here uses a Macbook
>>> Air. And we all work fine, there is no "One True Way" to make a chair,
>>> why should there be one for writing a program?
>>>
>>> My point is that the tools that programmers use, like compilers and
>>> linkers and parser-generators and build systems and deployment tools
>>> and source control and x and y and z and .... are going to be used by
>>> a wide range of people, in a wide range of environments, for a wide
>>> range of purposes, so they should keep in mind that maybe you /don't/
>>> have a certain tool or feature available. So you make sure that the
>>> experience at the lowest common denominator, a vt100 terminal, is
>>> acceptable, maybe not perfect, but good enough, then you build from
>>> there. If that means that D is geared towards less typing, then good,
>>> especially if  you can do the extra typing and not break things. It
>>> /is/ possible to make everybody mostly happy, and that is by aiming at
>>> the people using `cat`* to program and hitting the people using VS
>>> along the way.
>>>
>>> * Programming using `cat` is not recommended.**
>>> ** Even though /real/ programmers use `cat`
>>>
>>> --
>>> James Miller
>>
>>
>> I disagree. Simply put:
>>
>> +---------+         +---------+
>> | Magic   |         | comfort |
>> | happens |         |  zone   |
>> | here!   |         +---------+
>> +---------+
>>
>> Magic cannot happen here ^.
>
> What on earth does this mean? In the context it seems to suggest that I
> should be struggling to learn a new environment if I want to do something
> amazing.
>
> I'm guessing you meant that I should try something new, but that doesn't
> need to be the editor. It's far more interesting to try to build outside of
> my "comfort zone".
>
> In fact, your grade-school platitude annoys me, it suggests that I'm stuck
> in my ways and avoiding new tech because I like my terminal. I started in
> IDEs, and worked my way down. I also have the most fun working outside my
> comfort zone and doing something new, spending hours looking at code going
> "why wont you work! Why do you hate me!" Then finally getting a
> breakthrough... amazing.
>
> --
> James Miller

The picture is both a simple fact of life and in our current discussion a response to the above attitude of "lowest common denominator". I'm suggesting that progress is made by progressing forward and not by retreating backwards.
Your agitated response suggests I hit a nerve. That's a sign that my post had an effect.

Le 26/02/2012 00:02, Walter Bright a écrit :
> On 2/24/2012 3:22 AM, deadalnix wrote:
>> Le 17/02/2012 17:19, Andrei Alexandrescu a écrit :
>>> On 2/17/12 8:13 AM, kenji hara wrote:
>>>> I think the lack of 'override' keyword (filed as bug 3836) should
>>>> become an error, without the phase of deprecating it. Otherwise
>>>> following case will be allowed.
>>>
>>> Yes. Walter?
>>>
>>> Andrei
>>
>> I'm surprised this isn't even mentionned in
>> http://drdobbs.com/blogs/cpp/232601305
>>
>> I definitively don't think that pushing stuff like that - I'm
>> suspecting for ego
>> reasons - ignoring some flaw of the idea is a good way to proceed.
>> This even may
>> be armfull for the language on the long run.
>>
>> With no override keyword, function can just explode on your face for
>> no aparent
>> reason in the source code you are lookign at. This isn't an issue we
>> should ignore.
>>
>> This has a pretty simple solution : don't inherit thoses attributes of
>> override
>> isn't present. On the long run, don't allow override without override
>> keyword ?
>
> Not using override is currently deprecated. Eventually, it will be
> required.
>
> Doing this precipitously breaks existing code without allowing people
> plenty of time to upgrade their code. This annoys people, and results in
> them considering D "unstable" and "unusable".
>
> I know that some do not see it as a problem to regularly introduce
> breaking changes and pull the rug out from under people every month. But
> I think that is a recipe for disaster.

True. This is why I stated « in the long run ». The solution to that is, IMO, a standard process to deprecate and replace a feature, with a known period of time, and a page on the website to annonce this.

Eventually, someday, the codebase will be that big that breaking changes will not be an option anymore.