View mode: basic / threaded / horizontal-split · Log in · Help
August 06, 2007
Re: Hijacking
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?
August 06, 2007
Re: Hijacking
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
August 06, 2007
Re: Hijacking
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
August 06, 2007
Re: Hijacking
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.
August 06, 2007
Re: Hijacking
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
August 06, 2007
Re: Hijacking
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
August 06, 2007
Re: Hijacking
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
August 06, 2007
Re: Hijacking
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
August 06, 2007
Re: Hijacking
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.
August 06, 2007
Re: Hijacking
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.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home