Sean Kelly wrote:
> Walter Bright wrote:
>> Sean Kelly wrote:
>>> How does "override:" work with other properties used as labels?  Is it disabled when public/protected/private is next used in the same way?
>>
>> It adds to them.
> 
> So is there anyway to disable "override:" once set?

No.

On Sun, 05 Aug 2007 11:47:18 -0700, Walter Bright wrote:

> I want to continue a bit in the Overloading/Inheritance thread which is getting a little long, on a closely related issue which I find to be important, but so rarely referred to that I had to come up with a name for it - hijacking.

I'm just wondering what the NSA is making of this discussion :)

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

> This is a very hard problem to isolate yet can be easily remedied by the compiler. The request was first made two or three years back, and once or twice since then: you make the "override" keyword *required*.
>

I'm for this. I feel funny when I don't use "override".

Walter Bright wrote:
> eao197 wrote:
>> Eiffel has same feature for more than 20 years and it really works :)
> 
> Eiffel has many good ideas, but we must be careful thinking of Eiffel as an endorsement, as it failed to catch on. I think one reason it failed is because of the syntax.
My suspicion of the reason that Eiffel failed to catch on is the personality and resultant policies of the designer.  It took a long time for SmallEiffel to be released...and it's policies aren't that friendly, either, even though it IS GPL software.

OTOH, IMNSHO, Eiffel did make a few serious mistakes.  One of them was in forbidding two different functions (essentially the same) to be distinguished by their argument list, but not by their name.  BAD decision.

So you're right when you say "be careful", but don't attribute most of the failure of Eiffel to it's design.  Other factors predominated.

Note that D already had three branches DMD1, DMD2, and gdc. And that they share a lot of the same code (which keeps duplicate effort to a minimum).

If you want to copy organization policies, copy from Python, but Eiffel had very many good ideas that a compiler language could benefit from.  (I'm not as convinced by modern versions of Eiffel as I was by the earlier ones...but then I've basically stopped following it, because it kept breaking all of it's libraries with each new release.  And it never did become as easy to link to C as D already is.  [Now if only there was a decent way to manage C++ linkage.])

Derek Parnell wrote:
> On Sun, 05 Aug 2007 11:47:18 -0700, Walter Bright wrote:
> 
>> I want to continue a bit in the Overloading/Inheritance thread which is getting a little long, on a closely related issue which I find to be important, but so rarely referred to that I had to come up with a name for it - hijacking.
> 
> I'm just wondering what the NSA is making of this discussion :)

Hopefully, they'll analyze the site, get excited about D, and use D for their next generation software!

Charles D Hixson wrote:
> So you're right when you say "be careful", but don't attribute most of the failure of Eiffel to it's design.  Other factors predominated.

For a complex thing like a language, it can be really hard to pin down why it failed. Ask n different people, and you'll get n different answers. What turned me off was the syntax. It just means we have to be extra careful about adopting features from a failed language.

The further a feature is from mainstream convention in at least one successful language, the more nervous I get about it.

kris wrote:
> In other words, I go to the trouble of adding override for the benefit of manual auditing. The compiler ought to be helping me with that task?

I'll put it in as a warning in the next update, and we can try it out.

Reply to Walter,

> Derek Parnell wrote:
> 
>> On Sun, 05 Aug 2007 11:47:18 -0700, Walter Bright wrote:
>> 
>>> I want to continue a bit in the Overloading/Inheritance thread which
>>> is getting a little long, on a closely related issue which I find to
>>> be important, but so rarely referred to that I had to come up with a
>>> name for it - hijacking.
>>> 
>> I'm just wondering what the NSA is making of this discussion :)
>> 
> Hopefully, they'll analyze the site, get excited about D, and use D
> for their next generation software!
> 


Fat chance, most of D's advantages don't exist in under ~5000 LOC and anything over that and the NSA won't touch it. Besides there isn't 20+ years of best practices in how to right secure software in D (as this is in C)

Sorry

BCS wrote:
> Reply to Walter,
> 
>> Derek Parnell wrote:
>>
>>> On Sun, 05 Aug 2007 11:47:18 -0700, Walter Bright wrote:
>>>
>>>> I want to continue a bit in the Overloading/Inheritance thread which
>>>> is getting a little long, on a closely related issue which I find to
>>>> be important, but so rarely referred to that I had to come up with a
>>>> name for it - hijacking.
>>>>
>>> I'm just wondering what the NSA is making of this discussion :)
>>>
>> Hopefully, they'll analyze the site, get excited about D, and use D
>> for their next generation software!
> 
> Fat chance, most of D's advantages don't exist in under ~5000 LOC and anything over that and the NSA won't touch it. Besides there isn't 20+ years of best practices in how to right secure software in D (as this is in C)

I'd think DBC would be a perk, if nothing else.  Assuming the NSA currently uses C, that is.


Sean

Chris Nicholson-Sauls wrote:
 > I don't think we really need a non-override keyword, and I wouldn't want
> 'final' to be given that effect either ('final override' should be a valid attribute), or any other existing attributes... so our options are:
> 
> #1 - Add some sort of "plain" specifier, or a way to un-set a 'foo:' attribute.  Maybe '!foo:' or similar.
> 
> #2 - Make a point of using 'override { ... }' instead.
> 
> ....I think I prefer #2.
> 
> -- Chris Nicholson-Sauls

#3 - Use default:

override:
	void foo() {}
	void bar() {}

default:
	void baz() {}

But then again, maybe in this case we should just use override {} or reorder methods.