I'm wondering what the point of marking modules as scheduled for deprecation really is - at least the way that we've been doing it. I can understand marking a module as scheduled for deprecation if there's a planned replacement but no actual replacement yet in order to warn programmers that that module will be going away. However, at present, we seem to be using it to just tell programmers to use a replacement which actually does exist. That being the case, why are we marking them as scheduled for deprecation rather than just deprecating them? Having the pragma tell people what to use instead is certainly good, but I don't quite get why we've been marking modules as scheduled to be deprecated when we have a clear replacement for them and are telling programmers to use the replacement. Why aren't we actually deprecating them and then just using the pragma to indicate which module to use instead?

- Jonathan M Davis

Jonathan M Davis wrote:
> I'm wondering what the point of marking modules as scheduled for deprecation
> really is - at least the way that we've been doing it. I can understand marking
> a module as scheduled for deprecation if there's a planned replacement but no
> actual replacement yet in order to warn programmers that that module will be
> going away. However, at present, we seem to be using it to just tell programmers
> to use a replacement which actually does exist. That being the case, why are we
> marking them as scheduled for deprecation rather than just deprecating them?
> Having the pragma tell people what to use instead is certainly good, but I don't
> quite get why we've been marking modules as scheduled to be deprecated when we
> have a clear replacement for them and are telling programmers to use the
> replacement. Why aren't we actually deprecating them and then just using the
> pragma to indicate which module to use instead?
> 

Because it allows users to update their code on their own schedule, rather than ours. It's very annoying to have your builds break for reason X when you are hard at work developing Y.

On Friday 14 January 2011 23:57:05 Walter Bright wrote:
> Jonathan M Davis wrote:
> > I'm wondering what the point of marking modules as scheduled for deprecation really is - at least the way that we've been doing it. I can understand marking a module as scheduled for deprecation if there's a planned replacement but no actual replacement yet in order to warn programmers that that module will be going away. However, at present, we seem to be using it to just tell programmers to use a replacement which actually does exist. That being the case, why are we marking them as scheduled for deprecation rather than just deprecating them? Having the pragma tell people what to use instead is certainly good, but I don't quite get why we've been marking modules as scheduled to be deprecated when we have a clear replacement for them and are telling programmers to use the replacement. Why aren't we actually deprecating them and then just using the pragma to indicate which module to use instead?
> 
> Because it allows users to update their code on their own schedule, rather than ours. It's very annoying to have your builds break for reason X when you are hard at work developing Y.

True, but isn't that what -d is for?

- Jonathan M Davis

Jonathan M Davis wrote:
> On Friday 14 January 2011 23:57:05 Walter Bright wrote:
> 
>> Jonathan M Davis wrote:
>> 
>>> I'm wondering what the point of marking modules as scheduled for
>>> deprecation really is - at least the way that we've been doing it. I can
>>> understand marking a module as scheduled for deprecation if there's a
>>> planned replacement but no actual replacement yet in order to warn
>>> programmers that that module will be going away. However, at present, we
>>> seem to be using it to just tell programmers to use a replacement which
>>> actually does exist. That being the case, why are we marking them as
>>> scheduled for deprecation rather than just deprecating them? Having the
>>> pragma tell people what to use instead is certainly good, but I don't
>>> quite get why we've been marking modules as scheduled to be deprecated
>>> when we have a clear replacement for them and are telling programmers to
>>> use the replacement. Why aren't we actually deprecating them and then
>>> just using the pragma to indicate which module to use instead?
>>> 
>> Because it allows users to update their code on their own schedule,
>> rather than ours. It's very annoying to have your builds break for
>> reason X when you are hard at work developing Y.
>> 
>
> True, but isn't that what -d is for?
>
> 

Deprecation is a multi-stage process. I don't want to make them change their makefiles without warning.

On Saturday 15 January 2011 00:49:10 Walter Bright wrote:
> Jonathan M Davis wrote:
> > On Friday 14 January 2011 23:57:05 Walter Bright wrote:
> >> Jonathan M Davis wrote:
> >>> I'm wondering what the point of marking modules as scheduled for deprecation really is - at least the way that we've been doing it. I can understand marking a module as scheduled for deprecation if there's a planned replacement but no actual replacement yet in order to warn programmers that that module will be going away. However, at present, we seem to be using it to just tell programmers to use a replacement which actually does exist. That being the case, why are we marking them as scheduled for deprecation rather than just deprecating them? Having the pragma tell people what to use instead is certainly good, but I don't quite get why we've been marking modules as scheduled to be deprecated when we have a clear replacement for them and are telling programmers to use the replacement. Why aren't we actually deprecating them and then just using the pragma to indicate which module to use instead?
> >> 
> >> Because it allows users to update their code on their own schedule, rather than ours. It's very annoying to have your builds break for reason X when you are hard at work developing Y.
> > 
> > True, but isn't that what -d is for?
> 
> Deprecation is a multi-stage process. I don't want to make them change their makefiles without warning.

So, essentially, the idea is to annoy them with pragma messages for a while, giving them warning that they're going to have to either add -d to their makefiles soon or change their code. Then you actually deprecate the stuff, so they if they didn't take the time to change either their makefiles or their code, their code won't compile anymore. And then finally, you remove the deprecated item entirely, so if they haven't changed their code by then, it won't compile.

I figured that just deprecating and then removing the symbol in question was plenty, but if we really want that extra step where they're effectively getting warnings before it becomes an error, then that's how we'll do it I guess. I just didn't see much point in just a message rather than actually deprecating the symbol or module.

- Jonathan M Davis

Jonathan M Davis wrote:
>
>
> So, essentially, the idea is to annoy them with pragma messages for a while,
> giving them warning that they're going to have to either add -d to their
> makefiles soon or change their code. Then you actually deprecate the stuff, so
> they if they didn't take the time to change either their makefiles or their code,
> their code won't compile anymore. And then finally, you remove the deprecated
> item entirely, so if they haven't changed their code by then, it won't compile.
> 

Yes.

On Sat, 2011-01-15 at 00:49 -0800, Walter Bright wrote:
[ . . . ]
> Deprecation is a multi-stage process. I don't want to make them change their makefiles without warning.

Nor their SCons files, Waf files, or CMake files.  I know the Go developers assume everyone uses Make and only Make, but there are more modern and better alternatives for build.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110115/de9e780e/attachment.pgp>