• Robert Fraser <fraserofthenight gmail.com> Jul 18 2008
• "Stewart Gordon" <smjg_1998 yahoo.com> Jul 18 2008

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.

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