www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - deprecated statement

reply Vathix <chris dprogramming.com> writes:
How about allowing the deprecated keyword to be applied to a statement,  
which causes it to not require -d compiler switch nor complain if it uses  
a deprecated feature?

Scenario: say I want to deprecate the function onEvent() that the library  
calls when an event occurs. To fully support the deprecated function the  
library still has to call it. So now it means the library always has to  
have the -d switch even if the library user doesn't use onEvent().
Aug 10 2005
next sibling parent AJG <AJG_member pathlink.com> writes:
Hi,

How about allowing the deprecated keyword to be applied to a statement,  
which causes it to not require -d compiler switch nor complain if it uses  
a deprecated feature?

This sounds like a pretty good idea. Specially given the changing nature of D. Cheers, --AJG.
Aug 10 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Vathix wrote:
 How about allowing the deprecated keyword to be applied to a statement,  
 which causes it to not require -d compiler switch nor complain if it 
 uses  a deprecated feature?
 
 Scenario: say I want to deprecate the function onEvent() that the 
 library  calls when an event occurs. To fully support the deprecated 
 function the  library still has to call it. So now it means the library 
 always has to  have the -d switch even if the library user doesn't use 
 onEvent().

The problem is that deprecating a function doesn't stop someone from overriding it. And even if it did, allowing deprecated to be applied to statements in this way can easily be abused. Someone using your library will decide that the replacement API is "too much trouble" to learn, and just wrap the call in a deprecated statement, and then it would come as a nasty surprise when the deprecated feature is finally removed. OTOH if we didn't have this, then anyone finding that learning the replacement API is "too much trouble" will have to use the -d switch, which would encourage mere postponement of taking this trouble rather than forgetting alogether. Perhaps better would be: (a) provide some "deprecatedly public" notation - the function is deprecated from the API, but kept for internal use (b) provide a way to deprecate overriding of a function (c) if we are going to have deprecated statements, make them conditional compilation blocks switched on by the -d switch. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on on the 'group where everyone may benefit.
Aug 11 2005
parent reply Vathix <chris dprogramming.com> writes:
 (a) provide some "deprecatedly public" notation - the function is  
 deprecated from the API, but kept for internal use

That's kind of possible to do right now. Rename the function, add a protection attribute to it, and put in a deprecated function that calls the renamed one. Internally use the renamed one.
 (b) provide a way to deprecate overriding of a function

I'd say it should work like other deprecated features: require -d to allow it. If the compiler doesn't do this now, it probably should.
 (c) if we are going to have deprecated statements, make them conditional  
 compilation blocks switched on by the -d switch.

I was thinking of that too.. it seems to be a good solution. I could compile a lib with -d to support a deprecated feature that calls a deprecated event function, and users of the lib wouldn't need -d unless they used the deprecated event function.
Aug 13 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Vathix wrote:
 (a) provide some "deprecatedly public" notation - the function is  
 deprecated from the API, but kept for internal use

That's kind of possible to do right now. Rename the function, add a protection attribute to it, and put in a deprecated function that calls the renamed one. Internally use the renamed one.

True. So the deprecatedly public notation would syntactic sugar for this idea. Maybe something like "private deprecated public" and similarly for protected and package. Of course this would require a change to how attributes are parsed....
 (b) provide a way to deprecate overriding of a function

I'd say it should work like other deprecated features: require -d to allow it. If the compiler doesn't do this now, it probably should.

Unless want to deprecate a function from a base class while keeping it as part of the API of one or two derived classes. The idea suggested above would *partly* achieve this, if we enforce that (except for protected deprecated public) such a function may not be overridden unless compiling with -d or the override is itself deprecated. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on on the 'group where everyone may benefit.
Aug 14 2005