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 [email protected] http://michelf.com/ _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
