Reply to Walter,

> kris wrote:
> 
>> There's a related problem where a public method is added to a
>> base-class A (as in your example) but where the signature is
>> *exactly* that of one existing in derived class B. If A actually
>> calls that new method internally, "bad things"tm will almost
>> certainly happen, since B never intended to effectively override the
>> newly-added method in A.
>> 
>> 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*.
>> 
>> When "override" is required, the compiler can easily trap this
>> related type of hijacking and avoid such nasty surprises.
>> 
> That is a good point. The reason I haven't added it is because I'm not
> sure how annoying it will be to have to always add the 'override'
> keyword. It might be one of those things like exception specifications
> where everyone says it's a good idea but guiltily hate in secret <g>.
> 
> Mitigating factors are private and final methods cannot be overridden.
> 

How hard would it be to put a command line flag on the 2.0 version that would turn it on?

BCS wrote:
> Reply to Walter,
> How hard would it be to put a command line flag on the 2.0 version that would turn it on?
[Compulsory override keyword, I presume]
Or rather, one to turn it off? ;-)

Regards, Frank

Reply to 0ffh,

> BCS wrote:
> 
>> Reply to Walter,
>> How hard would it be to put a command line flag on the 2.0 version
>> that
>> would turn it on?
> [Compulsory override keyword, I presume]
> Or rather, one to turn it off? ;-)
> Regards, Frank
> 

either

Regan Heath schrieb:

> My vote was, and still is, for 'override' to be mandatory.
> 
> Regan

As said in my posting http://www.digitalmars.com/d/archives/digitalmars/D/aliasing_base_methods_49572.html#N49577 , i still second that also.

On Mon, 06 Aug 2007 21:30:43 +0400, Walter Bright <newshound1@digitalmars.com> 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.

No, I don't think so. I spent last 1.5 month to study Eiffel. Eiffel syntax isn't a problem (moreover I think Eiffel/Ruby syntax is more attractive than old C curly braces tradition).

By main opinion the main Eiffel's problems are:

1. Only one paradim. Only OOP and only by following the Eiffel method.

2. Comand/query separation principle. For example, you can't do something with object and get the result, as in C++/D:

auto sent_result = mail_box.send_message(msg);

In Eiffel send_message must be command, and mail_box must have a query to retrive last send result:

local
	send_result: SEND_RESULT
do
	mail_box.send_message (msg)
	send_result := mail_box.last_send_result
	...
end

3. Very different exception mechanism. For example see my question about resouce cleanup in the case of exception: http://tech.groups.yahoo.com/group/eiffel_software/message/11062


But 'DesignByContract' and inheritance (and various forms of inheritance conflicts resolving) are really great part of Eiffel.

So I vote for mandatory 'override' keyword in D too.

-- 
Regards,
Yauheni Akhotnikau

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?
> 
> 
> Sean

Since there is no "not an override" keyword, I would wager there isn't.  (Unless for end of current scope, aye?  But even then...)

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

Nick Sabalausky wrote:
> "Rioshin an'Harthen" <rharth75@hotmail.com> wrote in message news:f974u9$9k1$1@digitalmars.com...
>> "Walter Bright" <newshound1@digitalmars.com> kirjoitti viestissä news:f95leh$hn4$1@digitalmars.com...
>>> It might be one of those things like exception specifications where everyone says it's a good idea but guiltily hate in secret <g>.
>> Exception specification *is* a good idea. Although I do hate it - try to remember what a specific method may throw when you write your code, especially if the error is ambiguous like "Unhandled exception" it's really irritating - but I hate unspecified exceptions even more, as the problem then is to even remember to put in the necessary try-catch-finally blocks.
> 
> Not to start a big big debate on it, but my own personal feeling on that (after having used a fair amount of it) is that the specification of exceptions belongs in generated documentation (whether javadoc-style or as part of the IDE as with "some_function() -> Called By..."). I normally prefer having to explicity specify things (yea, strong-typing fan here ;) ), but personally, I find it overkill in this case. (Not to mention it gave me flashbacks of writing C/C++ headers. j/k ;) ). 
> 
> 

I didn't mind it at first, in that the Java compiler would then let me know if I'd missed any potential exceptions...

...but when I noticed I was just adding 'throws A,B,C' to a lot of my methods, I decided it wasn't entirely a great thing afterall.  What would have been better, I think, would have been to make throws specifications /optional/.  A thing libraries should do, but which applications should be allowed to quietly "forget" most of the time. Java is the language of conventions, after all.

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls wrote:
> 
> #2 - Make a point of using 'override { ... }' instead.
> 
> ...I think I prefer #2.

Same here.  Using "override:" doesn't seem feasible in all but the simplest cases.


Sean

Frank Benoit Wrote:

> Regan Heath schrieb:
> 
> > My vote was, and still is, for 'override' to be mandatory.
> > 
> > Regan
> 
> As said in my posting http://www.digitalmars.com/d/archives/digitalmars/D/aliasing_base_methods_49572.html#N49577 , i still second that also.

votes++;

It's really not that hard and will catch a lot of errors. Plus, a good IDE can insert that stuff automatically.

Chris Nicholson-Sauls Wrote:

> Nick Sabalausky wrote:
> > "Rioshin an'Harthen" <rharth75@hotmail.com> wrote in message news:f974u9$9k1$1@digitalmars.com...
> >> "Walter Bright" <newshound1@digitalmars.com> kirjoitti viestissä news:f95leh$hn4$1@digitalmars.com...
> >>> It might be one of those things like exception specifications where everyone says it's a good idea but guiltily hate in secret <g>.
> >> Exception specification *is* a good idea. Although I do hate it - try to remember what a specific method may throw when you write your code, especially if the error is ambiguous like "Unhandled exception" it's really irritating - but I hate unspecified exceptions even more, as the problem then is to even remember to put in the necessary try-catch-finally blocks.
> > 
> > Not to start a big big debate on it, but my own personal feeling on that (after having used a fair amount of it) is that the specification of exceptions belongs in generated documentation (whether javadoc-style or as part of the IDE as with "some_function() -> Called By..."). I normally prefer having to explicity specify things (yea, strong-typing fan here ;) ), but personally, I find it overkill in this case. (Not to mention it gave me flashbacks of writing C/C++ headers. j/k ;) ).
> > 
> > 
> 
> I didn't mind it at first, in that the Java compiler would then let me know if I'd missed any potential exceptions...
> 
> ...but when I noticed I was just adding 'throws A,B,C' to a lot of my methods, I decided it wasn't entirely a great thing afterall.  What would have been better, I think, would have been to make throws specifications /optional/.  A thing libraries should do, but which applications should be allowed to quietly "forget" most of the time. Java is the language of conventions, after all.
> 
> -- Chris Nicholson-Sauls

I'd like it to be required in the method where the exception is thrown for checked exceptions, but not in any calling methods (they're just optional there). But I'm not too passionate about the point... I can live with 'em (they're a bit annoying, but I can see their advantages), and I can live without 'em.