Walter Bright wrote:
> 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>.
> 

I don't think the mainstream opinion in Java is that checked exceptions are a good ideia.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Regan Heath wrote:
> Walter Bright wrote:
>> 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.
> 
> My vote was, and still is, for 'override' to be mandatory.
> 
> Regan
Me too. Note that since you can use 'override { }' or 'override:', it's less onerous than putting 'virtual' in front of every function in C++.

"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. 

Walter Bright wrote:
> 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>.

Hmmmm... even I think that requiring the override keyword is okay,
and I am not exactly known to be a discipline and bondage fanatic. ^^

Regards, Frank

Don Clugston wrote:
> Me too. Note that since you can use 'override { }' or 'override:', it's less onerous than putting 'virtual' in front of every function in C++.

How does "override:" work with other properties used as labels?  Is it disabled when public/protected/private is next used in the same way?


Sean

"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 ;) ).

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.

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.

Bruno Medeiros wrote:
> Walter Bright wrote:
>> 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>.
>>
> 
> I don't think the mainstream opinion in Java is that checked exceptions are a good ideia.

It's not a great analogy, because there are very good technical arguments against checked exceptions. But I do remember prominent Java people promoting checked exceptions as a great idea, while in their own code they'd subvert them because they were just too annoying.

I also think that mainstream Java has evolved its understanding of checked exceptions.

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