View mode: basic / threaded / horizontal-split · Log in · Help
February 24, 2012
Re: Inheritance of purity
Le 18/02/2012 19:25, Walter Bright a écrit :
> On 2/18/2012 6:49 AM, kenji hara wrote:
>> After some thoughts, I agree that inheritance of pure @safe, and
>> nothrow is good feature.
>> But I disagree to const inference, because const attribute interacts
>> with overloadings.
>
> The const inheritance *only* happens if otherwise you'd get a covariance
> error. It does not change the meaning of any existing code that compiled
> successfully.

yes but then, if a method is added to the base class, you will have a 
changement of behavior of all overriden method, silently.

It means nasty bugs, an hours spent to go throw the whole codebase and 
review manually which method do we want to override in each cases.

The current state of D is very inconsistent on this topic and it lead to 
many quirks.
February 24, 2012
Re: Inheritance of purity
On 24/02/2012 11:03, David wrote:
> Am 24.02.2012 11:43, schrieb Walter Bright:
>> On 2/23/2012 4:01 PM, 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.
>>
>> Do you really want a language that the source code isn't readable or
>> browsable outside of an IDE?
>>
>> Like the switch from command line to GUI, perhaps there are some that
>> are ready to switch from text files to some visually graphy thingy for
>> source code. But D ain't such a language. I don't know what such a
>> language would look like. I've never thought much about it before,
>> though I heard there was a toy language for kids that you "programmed"
>> by moving boxes around on the screen.
>
> I think you mean Robot Karol, but this uses also a basic like syntax.

Sounds to me more like Scratch

http://en.wikipedia.org/wiki/Scratch_%28programming_language%29

A...
February 24, 2012
Re: Inheritance of purity
On 24/02/2012 10:43, Walter Bright wrote:
> Do you really want a language that the source code isn't readable or
> browsable outside of an IDE?
>
> Like the switch from command line to GUI, perhaps there are some that
> are ready to switch from text files to some visually graphy thingy for
> source code. But D ain't such a language. I don't know what such a
> language would look like. I've never thought much about it before,
> though I heard there was a toy language for kids that you "programmed"
> by moving boxes around on the screen.

You're probably thinking of Scratch, though there are such languages not 
aimed at kids, see Android App Inventor -

http://en.wikipedia.org/wiki/Google_App_Inventor

Having used both of these (and a couple of others if I recall) I'd 
happily take a text only language any day!

But then... I prefer a command line + text editor over GUI/IDE too ;)

-- 
Robert
http://octarineparrot.com/
February 24, 2012
Re: Inheritance of purity
On Fri, Feb 24, 2012 at 02:43:01AM -0800, Walter Bright wrote:
[...]
> Like the switch from command line to GUI, perhaps there are some that
> are ready to switch from text files to some visually graphy thingy for
> source code. But D ain't such a language. I don't know what such a
> language would look like. I've never thought much about it before,
> though I heard there was a toy language for kids that you "programmed"
> by moving boxes around on the screen.

That sounds like an awesome concept for a "programming" game. :-)


T

-- 
It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall
February 24, 2012
Re: Inheritance of purity
On Thu, Feb 23, 2012 at 10:08:40PM -0800, Jonathan M Davis wrote:
> On Thursday, February 23, 2012 21:50:27 H. S. Teoh wrote:
> > Oh? I thought *real* real programmers use a soldering iron, a pair
> > of tweezers, a magnifying glass, and really *really* steady hands...
> > Tricky things to program, those new-fangled nanometer-scale
> > microprocessors they make these days. :-P
> 
> Obligatory XKCD:
> 
> http://xkcd.com/378/
> 
> :)

+1 lolz


T

-- 
Study gravitation, it's a field with a lot of potential.
February 25, 2012
Re: Inheritance of purity
On 2/24/2012 10:29 AM, H. S. Teoh wrote:
> On Fri, Feb 24, 2012 at 02:43:01AM -0800, Walter Bright wrote:
> [...]
>> Like the switch from command line to GUI, perhaps there are some that
>> are ready to switch from text files to some visually graphy thingy for
>> source code. But D ain't such a language. I don't know what such a
>> language would look like. I've never thought much about it before,
>> though I heard there was a toy language for kids that you "programmed"
>> by moving boxes around on the screen.
>
> That sounds like an awesome concept for a "programming" game. :-)
>
>
> T
>

Graphics Shaders can be developed with a UI of this nature.

Just google around for the UDK material editor for an example.  As 
advanced as it is, it will look crude in a few more years too.
February 25, 2012
Re: Inheritance of purity
On 02/24/2012 01:41 PM, deadalnix wrote:
> Le 18/02/2012 19:25, Walter Bright a écrit :
>> On 2/18/2012 6:49 AM, kenji hara wrote:
>>> After some thoughts, I agree that inheritance of pure @safe, and
>>> nothrow is good feature.
>>> But I disagree to const inference, because const attribute interacts
>>> with overloadings.
>>
>> The const inheritance *only* happens if otherwise you'd get a covariance
>> error. It does not change the meaning of any existing code that compiled
>> successfully.
>
> yes but then, if a method is added to the base class, you will have a
> changement of behavior of all overriden method, silently.
>

No. The compiler will explode in your face.

> It means nasty bugs, an hours spent to go throw the whole codebase and
> review manually which method do we want to override in each cases.
>
> The current state of D is very inconsistent on this topic and it lead to
> many quirks.

Not at all.

Have you actually experienced such problems? D is explicitly designed to 
avoid this kind of scenarios.
February 25, 2012
Re: Inheritance of purity
On 24/02/12 11:43, Walter Bright wrote:
> On 2/23/2012 4:01 PM, 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.
>
> Do you really want a language that the source code isn't readable or
> browsable outside of an IDE?
>
> Like the switch from command line to GUI, perhaps there are some that
> are ready to switch from text files to some visually graphy thingy for
> source code. But D ain't such a language. I don't know what such a
> language would look like.

There are quite a few people who use LabVIEW at my work place. :)

https://en.wikipedia.org/wiki/LabVIEW

-Lars
February 25, 2012
Re: Inheritance of purity
Le 25/02/2012 12:40, Timon Gehr a écrit :
> On 02/24/2012 01:41 PM, deadalnix wrote:
>> Le 18/02/2012 19:25, Walter Bright a écrit :
>>> On 2/18/2012 6:49 AM, kenji hara wrote:
>>>> After some thoughts, I agree that inheritance of pure @safe, and
>>>> nothrow is good feature.
>>>> But I disagree to const inference, because const attribute interacts
>>>> with overloadings.
>>>
>>> The const inheritance *only* happens if otherwise you'd get a covariance
>>> error. It does not change the meaning of any existing code that compiled
>>> successfully.
>>
>> yes but then, if a method is added to the base class, you will have a
>> changement of behavior of all overriden method, silently.
>>
>
> No. The compiler will explode in your face.
>

class A {
    void fun() const { ... }
}

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

Now I change the class A to become :

class A {
    void fun() const { ... }
    void fun() { ... }
}

And suddenly, the override doesn't override the same thing anymore. 
Which is unnacceptable.
February 25, 2012
Re: Inheritance of purity
On 02/25/2012 06:53 PM, deadalnix wrote:
> Le 25/02/2012 12:40, Timon Gehr a écrit :
>> On 02/24/2012 01:41 PM, deadalnix wrote:
>>> Le 18/02/2012 19:25, Walter Bright a écrit :
>>>> On 2/18/2012 6:49 AM, kenji hara wrote:
>>>>> After some thoughts, I agree that inheritance of pure @safe, and
>>>>> nothrow is good feature.
>>>>> But I disagree to const inference, because const attribute interacts
>>>>> with overloadings.
>>>>
>>>> The const inheritance *only* happens if otherwise you'd get a
>>>> covariance
>>>> error. It does not change the meaning of any existing code that
>>>> compiled
>>>> successfully.
>>>
>>> yes but then, if a method is added to the base class, you will have a
>>> changement of behavior of all overriden method, silently.
>>>
>>
>> No. The compiler will explode in your face.
>>
>
> class A {
>      void fun() const { ... }
> }
>
> class B : A {
>      override void fun() { ... }
> }
>
> Now I change the class A to become :
>
> class A {
>      void fun() const { ... }
>      void fun() { ... }
> }
>
> And suddenly, the override doesn't override the same thing anymore.
> Which is unnacceptable.

You didn't try to actually compile this, did you? ;D
5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home