www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [Suggestion] More deprecation features

reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
Now that most of the rusty old deprecation bugs have finally been squashed 
(if you'll excuse the mixed metaphor), here are a few ideas I've had for a 
while for taking the concept of deprecation further.


1. Sometimes it's useful to deprecate something, but keep it for internal 
use.  So effectively it's private, except if compiling with -d, in which 
case it will be public.  The notation might look something like

    private deprecated public void qwert() { ... }

The error message on trying to use it from outside might look something like

    qwert.d(42): function qwert is deprecated for public access

Other combinations of access levels would be similarly allowed, of which 
these make sense IMM:

    private deprecated package
    private deprecated protected *
    private deprecated public *
    private deprecated export *
    package deprecated public *
    package deprecated export *
    protected deprecated public
    protected deprecated export
    public deprecated export

Overriding of methods with the asterisked protection settings would be 
allowed only if the derived class method is also deprecated (or -d is 
specified).  To declare a method with the same name and parameters in a 
derived class, without specifying either the deprecated attribute or the -d 
switch, would be an error.  This is necessary to the principle of 
deprecation, i.e. code that compiles without -d doesn't change its behaviour 
when -d is specified, and existing code can still compile.

Of course, implementing this would affect how attributes are parsed.  I 
suppose the best idea would be to treat each possible case of the word 
"deprecated" immediately between two protection attributes as a protection 
attribute in its own right in terms of the way they override each other.


2. A means of deprecating callbacks.  That is, deprecating overriding of a 
method rather than using it.  This makes sense as callbacks are going to 
want replacing from time to time, just as callforwards :-) are.  The base 
class would keep its calls to the method, so that old code will still work, 
but new or modernised code would not be overriding it anymore.

(This would be provided at least to some extent by idea 1....)


3. Deprecating modules.  Currently, the compiler doesn't allow modules to be 
declared as deprecated.  A module being deprecated may signify:

- that the whole API area that it is there to support is deprecated, either 
because it's an obsolete technology or because it's been superseded by 
another module

- that the module has been renamed, and all the old one does is imports the 
new one for compatibility

- that it was used for development/testing purposes and is no longer needed


4. Deprecated imports.  So effectively, any attempt to use anything from the 
imported module would throw a deprecation error, unless a non-deprecated 
import of the same module is also visible from the scope where the use 
occurs.  This might be to prevent the compiler error that would otherwise be 
caused by importing a deprecated module for use by deprecated code.  Or to 
phase out a public import that was figured to be a bad idea.


Comments?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 16 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Stewart Gordon Wrote:


 Now that most of the rusty old deprecation bugs have finally been squashed 
 (if you'll excuse the mixed metaphor), here are a few ideas I've had for a 
 while for taking the concept of deprecation further.
 
 
 1. Sometimes it's useful to deprecate something, but keep it for internal 
 use.  So effectively it's private, except if compiling with -d, in which 
 case it will be public.  The notation might look something like
 
     private deprecated public void qwert() { ... }
 
 The error message on trying to use it from outside might look something like
 
     qwert.d(42): function qwert is deprecated for public access
 
 Other combinations of access levels would be similarly allowed, of which 
 these make sense IMM:
 
     private deprecated package
     private deprecated protected *
     private deprecated public *
     private deprecated export *
     package deprecated public *
     package deprecated export *
     protected deprecated public
     protected deprecated export
     public deprecated export
 
 Overriding of methods with the asterisked protection settings would be 
 allowed only if the derived class method is also deprecated (or -d is 
 specified).  To declare a method with the same name and parameters in a 
 derived class, without specifying either the deprecated attribute or the -d 
 switch, would be an error.  This is necessary to the principle of 
 deprecation, i.e. code that compiles without -d doesn't change its behaviour 
 when -d is specified, and existing code can still compile.
 
 Of course, implementing this would affect how attributes are parsed.  I 
 suppose the best idea would be to treat each possible case of the word 
 "deprecated" immediately between two protection attributes as a protection 
 attribute in its own right in terms of the way they override each other.
 
 
 2. A means of deprecating callbacks.  That is, deprecating overriding of a 
 method rather than using it.  This makes sense as callbacks are going to 
 want replacing from time to time, just as callforwards :-) are.  The base 
 class would keep its calls to the method, so that old code will still work, 
 but new or modernised code would not be overriding it anymore.
 
 (This would be provided at least to some extent by idea 1....)
 
 
 3. Deprecating modules.  Currently, the compiler doesn't allow modules to be 
 declared as deprecated.  A module being deprecated may signify:
 
 - that the whole API area that it is there to support is deprecated, either 
 because it's an obsolete technology or because it's been superseded by 
 another module
 
 - that the module has been renamed, and all the old one does is imports the 
 new one for compatibility
 
 - that it was used for development/testing purposes and is no longer needed
 
 
 4. Deprecated imports.  So effectively, any attempt to use anything from the 
 imported module would throw a deprecation error, unless a non-deprecated 
 import of the same module is also visible from the scope where the use 
 occurs.  This might be to prevent the compiler error that would otherwise be 
 caused by importing a deprecated module for use by deprecated code.  Or to 
 phase out a public import that was figured to be a bad idea.
 
 
 Comments?
 
 Stewart.
 
 -- 
 My e-mail address is valid but not my primary mailbox.  Please keep replies 
 on the 'group where everybody may benefit. 
 


All good ideas, but I fear that it's simply too much complication to make it 
worth doing.
Jul 17 2008
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:g5ofbp$teb$1 digitalmars.com...
<snip excessive quoting>

 All good ideas, but I fear that it's simply too much complication to make 
 it
 worth doing.


If you consider each of my ideas individually, _then_ which do you think are 
simple enough to be worth doing?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 17 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Stewart Gordon Wrote:


 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:g5ofbp$teb$1 digitalmars.com...
 <snip excessive quoting>

 All good ideas, but I fear that it's simply too much complication to make 
 it
 worth doing.


 
 If you consider each of my ideas individually, _then_ which do you think are 
 simple enough to be worth doing?
 
 Stewart.
 
 -- 
 My e-mail address is valid but not my primary mailbox.  Please keep replies 
 on the 'group where everybody may benefit. 
 


Idea 1 -- A workaround has already been posted for that one.

Idea 2-- I don't get this one. By "callback" do you mean deprecating the 
virtualitry/overridability of a function. I don't think I've ever needed to do 
that.

Idea 3 -- Okay, that one (deprecating modules) is cool enough; I'm down.

Idea 4 -- If you need to deprecate private imports, your modules are too 
big. Public imports seem to be sort of iffy to me anyway (except for an 
"all" module), but is your idea that:

module a;
public struct Foo { };
----
module b;
deprecated public import a;
----
module c;
import b;
Foo foo; // <-- deprecation error here

Then why can't module c just change it to:
----
module c;
import a;
Foo foo;

Unless the public import was exposing some internal functionality...? It just
seems like bad design in the first place if you need this.
Jul 17 2008
next sibling parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:g5onid$1s64$1 digitalmars.com...
<snip>

 Idea 1 -- A workaround has already been posted for that one.

 Idea 2-- I don't get this one. By "callback" do you mean deprecating the
 virtualitry/overridability of a function. I don't think I've ever needed 
 to do
 that.


Effectively yes.  I think I've wanted to do this for SDWF on occasion.


 Idea 3 -- Okay, that one (deprecating modules) is cool enough; I'm down.

 Idea 4 -- If you need to deprecate private imports, your modules are too
 big.


You mean bloated with deprecated stuff that should've been deleted ages ago, 
or what?


 Public imports seem to be sort of iffy to me anyway (except for an
 "all" module), but is your idea that:

 module a;
 public struct Foo { };
 ----
 module b;
 deprecated public import a;
 ----
 module c;
 import b;
 Foo foo; // <-- deprecation error here


Yes.


 Then why can't module c just change it to:
 ----
 module c;
 import a;
 Foo foo;


Suppose I acquire the code of an application written using some library. 
Now suppose that the library has been updated since the application was 
written.  The library author wanted to deprecate some public imports, but 
because D doesn't currently let you do this, removed them instead.  Then I 
cannot compile the application without going through its modules working out 
how to fix the masses of undefined symbols.  If the imports were merely 
deprecated, I would need only to add the -d switch in the makefile or 
whatever.


 Unless the public import was exposing some internal functionality...? It 
 just
 seems like bad design in the first place if you need this.


If that's the case, it's a bigger problem than just a public import.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 17 2008
prev sibling parent reply "Koroskin Denis" <2korden gmail.com> writes:
On Fri, 18 Jul 2008 04:19:25 +0400, Robert Fraser  
<fraserofthenight gmail.com> wrote:


 Stewart Gordon Wrote:


 "Robert Fraser" <fraserofthenight gmail.com> wrote in message
 news:g5ofbp$teb$1 digitalmars.com...
 <snip excessive quoting>

 All good ideas, but I fear that it's simply too much complication to  


 make

 it
 worth doing.


 If you consider each of my ideas individually, _then_ which do you  
 think are
 simple enough to be worth doing?

 Stewart.

 --
 My e-mail address is valid but not my primary mailbox.  Please keep  
 replies
 on the 'group where everybody may benefit.


 Idea 1 -- A workaround has already been posted for that one.

 Idea 2-- I don't get this one. By "callback" do you mean deprecating the
 virtualitry/overridability of a function. I don't think I've ever needed  
 to do
 that.

 Idea 3 -- Okay, that one (deprecating modules) is cool enough; I'm down.

 Idea 4 -- If you need to deprecate private imports, your modules are too
 big. Public imports seem to be sort of iffy to me anyway (except for an
 "all" module), but is your idea that:

 module a;
 public struct Foo { };
 ----
 module b;
 deprecated public import a;
 ----
 module c;
 import b;
 Foo foo; // <-- deprecation error here

 Then why can't module c just change it to:
 ----
 module c;
 import a;
 Foo foo;

 Unless the public import was exposing some internal functionality...? It  
 just
 seems like bad design in the first place if you need this.


A better idea would be to declare the *module* as deprecated:

old_stuff.d:
~~~~~~~~~~~~
deprecated module old_stuff;
...
Jul 18 2008
parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Koroskin Denis" <2korden gmail.com> wrote in message 
news:op.uehmf1v3enyajd proton.creatstudio.intranet...
<snip excessive quote>

 Unless the public import was exposing some internal functionality...? It 
 just
 seems like bad design in the first place if you need this.


 A better idea would be to declare the *module* as deprecated:


<snip>

A better idea than what, exactly?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 18 2008
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Stewart,


 Now that most of the rusty old deprecation bugs have finally been
 squashed (if you'll excuse the mixed metaphor), here are a few ideas
 I've had for a while for taking the concept of deprecation further.
 
 1. Sometimes it's useful to deprecate something, but keep it for
 internal use.  So effectively it's private, except if compiling with
 -d, in which case it will be public.  The notation might look
 something like
 
 private deprecated public void qwert() { ... }
 
 The error message on trying to use it from outside might look
 something like
 
 qwert.d(42): function qwert is deprecated for public access
 
 Other combinations of access levels would be similarly allowed, of
 which these make sense IMM:
 
 private deprecated package
 private deprecated protected *
 private deprecated public *
 private deprecated export *
 package deprecated public *
 package deprecated export *
 protected deprecated public
 protected deprecated export
 public deprecated export
 Overriding of methods with the asterisked protection settings would be
 allowed only if the derived class method is also deprecated (or -d is
 specified).  To declare a method with the same name and parameters in
 a derived class, without specifying either the deprecated attribute or
 the -d switch, would be an error.  This is necessary to the principle
 of deprecation, i.e. code that compiles without -d doesn't change its
 behaviour when -d is specified, and existing code can still compile.
 
 Of course, implementing this would affect how attributes are parsed.
 I suppose the best idea would be to treat each possible case of the
 word "deprecated" immediately between two protection attributes as a
 protection attribute in its own right in terms of the way they
 override each other.
 
 2. A means of deprecating callbacks.  That is, deprecating overriding
 of a method rather than using it.  This makes sense as callbacks are
 going to want replacing from time to time, just as callforwards :-)
 are.  The base class would keep its calls to the method, so that old
 code will still work, but new or modernised code would not be
 overriding it anymore.
 
 (This would be provided at least to some extent by idea 1....)
 
 3. Deprecating modules.  Currently, the compiler doesn't allow modules
 to be declared as deprecated.  A module being deprecated may signify:
 
 - that the whole API area that it is there to support is deprecated,
 either because it's an obsolete technology or because it's been
 superseded by another module
 
 - that the module has been renamed, and all the old one does is
 imports the new one for compatibility
 
 - that it was used for development/testing purposes and is no longer
 needed
 
 4. Deprecated imports.  So effectively, any attempt to use anything
 from the imported module would throw a deprecation error, unless a
 non-deprecated import of the same module is also visible from the
 scope where the use occurs.  This might be to prevent the compiler
 error that would otherwise be caused by importing a deprecated module
 for use by deprecated code.  Or to phase out a public import that was
 figured to be a bad idea.
 
 Comments?
 
 Stewart.
 



Another solution would be to rename the old function (foo -> foo_int) patch 
up all internal references and then make a deprecated wrapper function or 
alias to make the external calls work. That patch up should be doable because 
if you don't have that code in hand. it probably isn't internal.
Jul 17 2008
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"BCS" <ao pathlink.com> wrote in message 
news:55391cb32f4938cab635e371a9d8 news.digitalmars.com...
<snip excessive quote>

 Another solution would be to rename the old function (foo -> foo_int) 
 patch up all internal references and then make a deprecated wrapper 
 function or alias to make the external calls work.


Yes, that's one way of achieving some cases of idea 1....


 That patch up should be doable because if you don't have that code in 
 hand. it probably isn't internal.


What do you mean by this?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 17 2008
parent BCS <ao pathlink.com> writes:
Reply to Stewart,


 "BCS" <ao pathlink.com> wrote in message
 news:55391cb32f4938cab635e371a9d8 news.digitalmars.com... <snip
 excessive quote>
 

 Another solution would be to rename the old function (foo -> foo_int)
 patch up all internal references and then make a deprecated wrapper
 function or alias to make the external calls work.
 


 Yes, that's one way of achieving some cases of idea 1....
 

 That patch up should be doable because if you don't have that code in
 hand. it probably isn't internal.
 


 What do you mean by this?
 


excluding the cases of code going from export to public the programmer who 
is deprecating the old function more than likely also maintains any code 
that legitimately should have access to the new non deprecated version.
Therefor 
they can patch up the names them self. For that one exception, that above 
trick would be a breaking change.


 Stewart.
Jul 17 2008
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2008-07-16 21:18:01 -0400, "Stewart Gordon" <smjg_1998 yahoo.com> said:


 3. Deprecating modules.  Currently, the compiler doesn't allow modules 
 to be declared as deprecated.  A module being deprecated may signify:
 
 - that the whole API area that it is there to support is deprecated, 
 either because it's an obsolete technology or because it's been 
 superseded by another module
 
 - that the module has been renamed, and all the old one does is imports 
 the new one for compatibility
 
 - that it was used for development/testing purposes and is no longer needed


I'm with you with that one. You can deprecate everything within a 
module, but if you have a module which just pose as a group of public 
imports and you want to deprecate that, then you're somewhat stuck if 
you can't deprecate the module itself.

    module foo;

    public import bar.a;
    public import bar.b;

So yeah, I think modules should be allowed to be deprecated.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jul 17 2008
prev sibling next sibling parent reply Don <nospam nospam.com.au> writes:
Stewart Gordon wrote:

 Now that most of the rusty old deprecation bugs have finally been 
 squashed (if you'll excuse the mixed metaphor), here are a few ideas 
 I've had for a while for taking the concept of deprecation further.
 
 
 1. Sometimes it's useful to deprecate something, but keep it for 
 internal use.  So effectively it's private, except if compiling with -d, 
 in which case it will be public.  The notation might look something like
 
    private deprecated public void qwert() { ... }
 
 The error message on trying to use it from outside might look something 
 like
 
    qwert.d(42): function qwert is deprecated for public access
 
 Other combinations of access levels would be similarly allowed, of which 
 these make sense IMM:
 
    private deprecated package
    private deprecated protected *
    private deprecated public *
    private deprecated export *
    package deprecated public *
    package deprecated export *
    protected deprecated public
    protected deprecated export
    public deprecated export
 
 Overriding of methods with the asterisked protection settings would be 
 allowed only if the derived class method is also deprecated (or -d is 
 specified).  To declare a method with the same name and parameters in a 
 derived class, without specifying either the deprecated attribute or the 
 -d switch, would be an error.  This is necessary to the principle of 
 deprecation, i.e. code that compiles without -d doesn't change its 
 behaviour when -d is specified, and existing code can still compile.
 
 Of course, implementing this would affect how attributes are parsed.  I 
 suppose the best idea would be to treat each possible case of the word 
 "deprecated" immediately between two protection attributes as a 
 protection attribute in its own right in terms of the way they override 
 each other.
 
 
 2. A means of deprecating callbacks.  That is, deprecating overriding of 
 a method rather than using it.  This makes sense as callbacks are going 
 to want replacing from time to time, just as callforwards :-) are.  The 
 base class would keep its calls to the method, so that old code will 
 still work, but new or modernised code would not be overriding it anymore.
 
 (This would be provided at least to some extent by idea 1....)
 
 
 3. Deprecating modules.  Currently, the compiler doesn't allow modules 
 to be declared as deprecated.  A module being deprecated may signify:
 
 - that the whole API area that it is there to support is deprecated, 
 either because it's an obsolete technology or because it's been 
 superseded by another module
 
 - that the module has been renamed, and all the old one does is imports 
 the new one for compatibility
 
 - that it was used for development/testing purposes and is no longer needed
 
 
 4. Deprecated imports.  So effectively, any attempt to use anything from 
 the imported module would throw a deprecation error, unless a 
 non-deprecated import of the same module is also visible from the scope 
 where the use occurs.  This might be to prevent the compiler error that 
 would otherwise be caused by importing a deprecated module for use by 
 deprecated code.  Or to phase out a public import that was figured to be 
 a bad idea.
 
 
 Comments?
 
 Stewart.
 


Suppose there was version(deprecated), which is set only if -d is used 
on the command line. Wouldn't that let you do most of these things?

Eg, point 3 and 4:

module reallyold;
version(deprecated) {
import anotherdeprecatedmodule;
} else static assert(0, "This module is deprecated");

Sure, it's a bit ugly, but it's simple and would give a lot of 
flexibility. BTW this could be added to D1.0.
Jul 18 2008
next sibling parent reply superdan <super dan.org> writes:
Don Wrote:


 Stewart Gordon wrote:

 Now that most of the rusty old deprecation bugs have finally been 
 squashed (if you'll excuse the mixed metaphor), here are a few ideas 
 I've had for a while for taking the concept of deprecation further.
 
 
 1. Sometimes it's useful to deprecate something, but keep it for 
 internal use.  So effectively it's private, except if compiling with -d, 
 in which case it will be public.  The notation might look something like
 
    private deprecated public void qwert() { ... }
 
 The error message on trying to use it from outside might look something 
 like
 
    qwert.d(42): function qwert is deprecated for public access
 
 Other combinations of access levels would be similarly allowed, of which 
 these make sense IMM:
 
    private deprecated package
    private deprecated protected *
    private deprecated public *
    private deprecated export *
    package deprecated public *
    package deprecated export *
    protected deprecated public
    protected deprecated export
    public deprecated export
 
 Overriding of methods with the asterisked protection settings would be 
 allowed only if the derived class method is also deprecated (or -d is 
 specified).  To declare a method with the same name and parameters in a 
 derived class, without specifying either the deprecated attribute or the 
 -d switch, would be an error.  This is necessary to the principle of 
 deprecation, i.e. code that compiles without -d doesn't change its 
 behaviour when -d is specified, and existing code can still compile.
 
 Of course, implementing this would affect how attributes are parsed.  I 
 suppose the best idea would be to treat each possible case of the word 
 "deprecated" immediately between two protection attributes as a 
 protection attribute in its own right in terms of the way they override 
 each other.
 
 
 2. A means of deprecating callbacks.  That is, deprecating overriding of 
 a method rather than using it.  This makes sense as callbacks are going 
 to want replacing from time to time, just as callforwards :-) are.  The 
 base class would keep its calls to the method, so that old code will 
 still work, but new or modernised code would not be overriding it anymore.
 
 (This would be provided at least to some extent by idea 1....)
 
 
 3. Deprecating modules.  Currently, the compiler doesn't allow modules 
 to be declared as deprecated.  A module being deprecated may signify:
 
 - that the whole API area that it is there to support is deprecated, 
 either because it's an obsolete technology or because it's been 
 superseded by another module
 
 - that the module has been renamed, and all the old one does is imports 
 the new one for compatibility
 
 - that it was used for development/testing purposes and is no longer needed
 
 
 4. Deprecated imports.  So effectively, any attempt to use anything from 
 the imported module would throw a deprecation error, unless a 
 non-deprecated import of the same module is also visible from the scope 
 where the use occurs.  This might be to prevent the compiler error that 
 would otherwise be caused by importing a deprecated module for use by 
 deprecated code.  Or to phase out a public import that was figured to be 
 a bad idea.
 
 
 Comments?
 
 Stewart.
 


 
 Suppose there was version(deprecated), which is set only if -d is used 
 on the command line. Wouldn't that let you do most of these things?
 
 Eg, point 3 and 4:
 
 module reallyold;
 version(deprecated) {
 import anotherdeprecatedmodule;
 } else static assert(0, "This module is deprecated");
 
 Sure, it's a bit ugly, but it's simple and would give a lot of 
 flexibility. BTW this could be added to D1.0.


fuckin' a. by the same token i needed version(unittest) to include shit only if
unit testing is on. i could also use version(function), version(class),
version(struct), and version(module) to figure out from inside a mixin whether
it is being expanded inside a function, class, struct, and respectively module.
but i guess this is wishful thinkin' shit.
Jul 18 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
superdan Wrote:

 by the same token i needed version(unittest)


That one, at least, is already there.
Jul 18 2008
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to superdan,


 version(function),
 version(class)
 version(struct)
 version(module)
 


I think version is not the correct place to put this, however I do think 
it would be nice to have this ability.

OTOH

<Not tested>

static if(is(this) && is(typeof(this) _ == class))  // ~ version class

static if(is(this) && is(*this) && is(typeof(*this) _ == struct)  // ~ version 
struct

static if(!is(this)) // ~ version none of the above

</Not tested>
Jul 18 2008
prev sibling parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"superdan" <super dan.org> wrote in message 
news:g5qal4$o49$1 digitalmars.com...
<snip>

 fuckin' a.  by the same token i needed version(unittest) to include
 shit only if unit testing is on.  i could also use
 version(function), version(class), version(struct), and
 version(module) to figure out from inside a mixin whether it is
 being expanded inside a function, class, struct, and respectively
 module.  but i guess this is wishful thinkin' shit.


You can detect classes and structs at least, using is(typeof(this) == class) 
and is(typeof(*this) == struct).  I don't know about the others.  And that 
said, these would also pass within a method of a class or struct, but this 
at least distinguishes it from module or module-level function scope.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 18 2008
prev sibling parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Don" <nospam nospam.com.au> wrote in message 
news:g5pfl7$1cfr$1 digitalmars.com...
<snip excessive quote>

 Suppose there was version(deprecated), which is set only if -d is used on 
 the command line. Wouldn't that let you do most of these things?


Let's see ....

For idea 1, I suppose you could do

    version (deprecated) {
        public void deprecatedlyPublicFunction() { ... }
    } else {
        private void deprecatedlyPublicFunction() { ... }
    }

but quite a bit of duplication of code would be involved.  OK, so you could 
make them both wrap a third function, but it's still a long way round.

I guess the workaround that's already been mentioned would work better.  The 
notation I proposed for deprecation-dependent protection attributes would 
make for more concise code than either idiom.

For idea 2 ....

    version (deprecated) {
        final void callback() { ... }
    } else {
        void callback() { ... }
    }

That said, some of the above comments probably apply here as well.


 Eg, point 3 and 4:

 module reallyold;
 version(deprecated) {
 import anotherdeprecatedmodule;
 } else static assert(0, "This module is deprecated");

 Sure, it's a bit ugly, but it's simple and would give a lot of 
 flexibility. BTW this could be added to D1.0.


Not sure about this.

But if we had version (deprecated), I guess we could do away with deprecated 
as an attribute altogether.  Indeed we'd have to, in order to free up the 
keyword so that it can be a version identifier.

But having deprecated as an attribute does have some use: it enables 
compiler messages to be more to the point than if we just deprecated stuff 
by versioning it out.  Consequently, expanding the built-in concept of 
deprecation would be an improvement to the language.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 18 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Stewart Gordon Wrote:

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 

 Idea 4 -- If you need to deprecate private imports, your modules are too
 big.


 
 You mean bloated with deprecated stuff that should've been deleted ages ago, 
 or what?
 

 Public imports seem to be sort of iffy to me anyway (except for an
 "all" module), but is your idea that:

 module a;
 public struct Foo { };
 ----
 module b;
 deprecated public import a;
 ----
 module c;
 import b;
 Foo foo; // <-- deprecation error here


 
 Yes.
 

 Then why can't module c just change it to:
 ----
 module c;
 import a;
 Foo foo;


 
 Suppose I acquire the code of an application written using some library. 
 Now suppose that the library has been updated since the application was 
 written.  The library author wanted to deprecate some public imports, but 
 because D doesn't currently let you do this, removed them instead.  Then I 
 cannot compile the application without going through its modules working out 
 how to fix the masses of undefined symbols.  If the imports were merely 
 deprecated, I would need only to add the -d switch in the makefile or 
 whatever.


Can you explain a situation in which this would not be covered by 
deprecating the modules themselves rather than the public import 
thereof? Public imports in general seem like a very bad code design for an 
API to me. They're nice to have in the language (for internal stuff that's 
selectively publicly imported or "all" modules), but publicly importing an 
entire module for your API seems like a bad decision.

There's a workaround, anyway. Just privately import it and declare 
deprecated aliases to the members of the public import that you want to 
export.
Jul 18 2008
parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:g5qo45$22q6$1 digitalmars.com...
<snip>

 Can you explain a situation in which this would not be covered by
 deprecating the modules themselves rather than the public import
 thereof?


Huh?  If you could deprecate modules without deprecating imports of them, 
then what would deprecating a module do at all?

You seem to be completely missing the point of deprecated imports.

Scenario 1:

Module A has a public import of module B.  Both modules are in the same 
library.  An application using the library imports module A, and while at it 
uses something in B.

The library author then decides that A should not publicly import B after 
all.  Deprecating B is not an option, as B is still needed - all that's 
wanted is to get it out of what comes with importing A.  The right course of 
action is therefore to deprecate A's import of B.  The application can still 
use B, it just needs to import it directly.  Meanwhile, the application can 
still be compiled using -d, since doing so activates the deprecated import.

Module A might also itself use something in B, in which case it can 
privately import B in addition to the deprecated public import.

Scenario 2:

Module A contains some deprecated, no longer maintained functions that 
depend on module B in the same library.  It's time to deprecate B. 
Obviously, A needs to keep its import of B so that A's deprecated functions 
can still work.  It does this by using a deprecated import.

The point is to support the principle that deprecated stuff can still depend 
on other deprecated stuff, for good reasons.  Here, the principle is applied 
twice: the deprecated functions in A depend on A's deprecated import of B, 
which in turn depends on deprecated module B.

A non-deprecated import of B would, OTOH, be an illegal dependency of 
something non-deprecated on something deprecated.


 Public imports in general seem like a very bad code design for an
 API to me. They're nice to have in the language (for internal stuff that's
 selectively publicly imported or "all" modules), but publicly importing an
 entire module for your API seems like a bad decision.


That's exactly why someone might want to deprecate such a decision.


 There's a workaround, anyway. Just privately import it and declare
 deprecated aliases to the members of the public import that you want to
 export.


That would alter the fully qualified names of the imported symbols....

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 18 2008