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

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.

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

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

superdan Wrote:
> by the same token i needed version(unittest)

That one, at least, is already there.

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>

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