On Thu, Oct 28, 2010 at 01:21:22PM -0500, Andrei Alexandrescu wrote:
> I agree that we should add a mention. Other opinions?

I'm meh on it. So I'll get a message when compiling... but what am I supposed to do about it?

So on one hand, until an alternative is given, people using it have to continue using it, warning or no warning.

On the other hand, it might keep people from getting caught up with it just to have it pulled out. So it might help them while being of no help nor serious hurt to me.

So I guess all in all it balances out to pro-warning, but I feel a replacement needs to be integrated quickly.

On Thu, 28 Oct 2010 14:21:22 -0400, Andrei Alexandrescu <andrei at erdani.com> wrote:

> I agree that we should add a mention. Other opinions?
>
> Andrei
>

I agree.

How about all the other parts that are intended to be deprecated but haven't been flaged as such?  Same question applies.  The json code shouldn't be singled out.

On Thu, 28 Oct 2010, Andrei Alexandrescu wrote:

> I agree that we should add a mention. Other opinions?
> 
> Andrei
> 
> On 10/28/10 2:14 CDT, Brian Schott wrote:
> > The DMD 2.050 beta zip contains no mention of std.json being scheduled for eventual replacement. Is it really a good idea to have another release with this code included and no warning that it will eventually go away?
> > 

Some of the items I recall are:

std.bind (There was something related to this, might have been removal)
std.boxer (std.variant)
std.date (std.datetime)
std.conv (std.convert)
std.socket/stream (going to have a new design)
std.xml (redesign, removal until good replacement?)
std.json

At least some mention of what will happen to these should be placed in the documentation.


On Thu, Oct 28, 2010 at 1:49 PM, Brad Roberts <braddr at puremagic.com> wrote:
> How about all the other parts that are intended to be deprecated but haven't been flaged as such? ?Same question applies. ?The json code shouldn't be singled out.
>
> On Thu, 28 Oct 2010, Andrei Alexandrescu wrote:
>
>> I agree that we should add a mention. Other opinions?
>>
>> Andrei
>>
>> On 10/28/10 2:14 CDT, Brian Schott wrote:
>> > The DMD 2.050 beta zip contains no mention of std.json being scheduled for eventual replacement. Is it really a good idea to have another release with this code included and no warning that it will eventually go away?
>> >
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>



-- 
Liberty means responsibility. That is why most men dread it. ? - George Bernard Shaw

Please don't remove std.xml until we have a replacement.

On 28 okt 2010, at 23:11, Jesse Phillips wrote:

> Some of the items I recall are:
> 
> std.bind (There was something related to this, might have been removal)
> std.boxer (std.variant)
> std.date (std.datetime)
> std.conv (std.convert)
> std.socket/stream (going to have a new design)
> std.xml (redesign, removal until good replacement?)
> std.json
> 
> At least some mention of what will happen to these should be placed in the documentation.
> 
> 
> On Thu, Oct 28, 2010 at 1:49 PM, Brad Roberts <braddr at puremagic.com> wrote:
>> How about all the other parts that are intended to be deprecated but haven't been flaged as such?  Same question applies.  The json code shouldn't be singled out.
>> 
>> On Thu, 28 Oct 2010, Andrei Alexandrescu wrote:
>> 
>>> I agree that we should add a mention. Other opinions?
>>> 
>>> Andrei
>>> 
>>> On 10/28/10 2:14 CDT, Brian Schott wrote:
>>>> The DMD 2.050 beta zip contains no mention of std.json being scheduled for eventual replacement. Is it really a good idea to have another release with this code included and no warning that it will eventually go away?
>>>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
> 
> 
> 
> -- 
> Liberty means responsibility. That is why most men dread it.
>   - George Bernard Shaw
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

Le 2010-10-29 ? 5:36, Jacob Carlborg a ?crit :

> Please don't remove std.xml until we have a replacement.
> 
> On 28 okt 2010, at 23:11, Jesse Phillips wrote:
> 
>> Some of the items I recall are:
>> 
>> std.bind (There was something related to this, might have been removal)
>> std.boxer (std.variant)
>> std.date (std.datetime)
>> std.conv (std.convert)
>> std.socket/stream (going to have a new design)
>> std.xml (redesign, removal until good replacement?)
>> std.json
>> 
>> At least some mention of what will happen to these should be placed in the documentation.

Here's a suggestion for how to proceed when deprecating entire modules. First, I would suggest to not deprecate a module (mark its content as deprecated) before we have a replacement, but we can still schedule the above modules for deprecation with a note in the documentation.

Once a module has a replacement, the new module replaces the older one. The older one is moved to the std.relic.* package with its content marked as deprecated. This keeps things simple if you need to continue using the older module: you have to 1) add "relic" to a few imports and 2) add the deprecated compiler flag.

By deprecating and moving the module at the same time, these two steps are done together at the same time, so it's less trouble for someone who wants to continue to use the old one. By not deprecating things before the new module is available, you're making it possible to immediately  use the new module as soon as someone hits a compilation error due to a deprecated/moved API.

For instance, right now std.boxer could be moved to to std.relic.boxer, its content flagged as deprecated, and its documentation mentioning std.variant as its replacement. Then later, perhaps in a year or two, it could be purged from Phobos altogether.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

Actually I remembered that I have forked std.xml so for me it's ok if it will be removed.

On 29 okt 2010, at 11:36, Jacob Carlborg wrote:

> Please don't remove std.xml until we have a replacement.
> 
> On 28 okt 2010, at 23:11, Jesse Phillips wrote:
> 
>> Some of the items I recall are:
>> 
>> std.bind (There was something related to this, might have been removal)
>> std.boxer (std.variant)
>> std.date (std.datetime)
>> std.conv (std.convert)
>> std.socket/stream (going to have a new design)
>> std.xml (redesign, removal until good replacement?)
>> std.json
>> 
>> At least some mention of what will happen to these should be placed in the documentation.
>> 
>> 
>> On Thu, Oct 28, 2010 at 1:49 PM, Brad Roberts <braddr at puremagic.com> wrote:
>>> How about all the other parts that are intended to be deprecated but haven't been flaged as such?  Same question applies.  The json code shouldn't be singled out.
>>> 
>>> On Thu, 28 Oct 2010, Andrei Alexandrescu wrote:
>>> 
>>>> I agree that we should add a mention. Other opinions?
>>>> 
>>>> Andrei
>>>> 
>>>> On 10/28/10 2:14 CDT, Brian Schott wrote:
>>>>> The DMD 2.050 beta zip contains no mention of std.json being scheduled for eventual replacement. Is it really a good idea to have another release with this code included and no warning that it will eventually go away?
>>>>> 
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>> 
>> 
>> 
>> 
>> -- 
>> Liberty means responsibility. That is why most men dread it.
>>  - George Bernard Shaw
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> -- 
> /Jacob Carlborg
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg