タグ付けされた質問 「deprecation」

6
<b>および<i>タグが非推奨になったのはなぜですか?
この質問は、私の大学の授業で出てきました。教授は、それがより説明したという答えを与えたが、それがあるかのように思える&lt;b&gt;し、&lt;i&gt;その意味ではなく、明示的であり、より入力しやすい&lt;strong&gt;と&lt;em&gt;。 これらのタグの廃止の公式の議論は何でしたか?
98 html  deprecation 

3
Web SQLデータベースが非推奨になったのはなぜですか?
ハイブリッドAndroidアプリを作成しています。 最初にlocalStorageを使用することに決めました。2日間を費やした後、非常に奇妙であることに気づいたため、削除しました。 次に、indexedDBを選択しました。今日の1日を費やして実際にGoogle Chromeで出力を取得した後、AndroidアプリのWebView内で実行されていません。 また、Web SQLデータベースは廃止されたため、まったく使用しませんでした。とにかく、PhoneGapはまだWeb SQLを使用しており、Androidのブラウザーがそれをサポートしていることに気づきました。 そもそもWeb SQLが廃止されたのはなぜですか?また、今すぐWeb SQLを使用することをお勧めしますか?

12
期限に達した後、廃止されたコードがコンパイルされないようにする[終了]
私のチームでは、大きなモノリシックプロジェクト(クラス全体、メソッドなど)で多くの古いものを削除しています。 そのクリーニングタスクの間に、私はいつもよりも一種の注釈やライブラリの凝ったものがあるのか​​と思っていました@Deprecated。これにより@FancyDeprecated、特定の日付が過ぎた後に古い未使用コードをクリーンアップしていない場合、プロジェクトのビルドが成功しなくなります。 インターネットで検索してみましたが、以下に説明する機能を持つものは見つかりませんでした。 特定の日付の前に削除する予定のコードに配置するための注釈または類似のもの その日付の前にコードがコンパイルされ、すべてが正常に動作します その日以降、コードはコンパイルされず、問題について警告するメッセージが表示されます 私はユニコーンを探していると思います...どのプログラム言語にも同様の技術はありますか? 計画として、BIは、「デッドライン」で失敗し始めるコードの単体テストでマジックを作成する可能性を考えています。これについてどう思う?より良いアイデアはありますか?


1
本番コードで名前が間違っている関数を処理する方法は?
最近、GitHubでPythonライブラリに出会いました。ライブラリは素晴らしいですが、関数名に1つの明白なタイプミスが含まれています。dummy_fuction()それがあるべきときにそれを呼び出しましょうdummy_function()。この関数は間違いなく「インザワイルド」であり、組み込みシステムで使用される可能性が最も高くなります。 最初に思い浮かぶのは、正しい名前の関数の2番目のバージョンを追加し、次のリリースの最初のバージョンに非推奨の警告を追加することです。 3つの質問: 上記のアプローチは、意図しない結果をもたらす可能性がありますか? この種の問題に対する標準的なアプローチはありますか? 非推奨の警告はいつまで残しておくべきですか?

2
Pythonでユニバーサル改行モードが非推奨になったのはなぜですか?
私はちょうどことに気づいユニバーサル改行ファイル操作の機能は、その方法アウトになるようです。 Python 3.5 openのmodeパラメーターのドキュメントには、非推奨であることが示されています。 'U' ユニバーサル改行モード(非推奨) 少なくともPython 3.2までさかのぼりopen、mode引数の使用法を文書化するときに、同様の「後方互換性のみ」の警告が含まれています。 'U' ユニバーサル改行モード(後方互換性のため。新しいコードでは使用しないでください) Python 2.7でも、同様の警告がのドキュメントに記載されていますio.open。 この理由は何ですか?
26 python  io  deprecation 

1
同期を廃止し、待機して通知する時間ですか?
synchronizedを使用するよりも使用することが望ましい単一のシナリオ(古代のJVMとの互換性以外)がありますLockか?誰でも新しいシステムを使用しwaitたりnotify、新しいシステム上で正当化することはできますか? 実装でそれらのいずれかを使用する必要があるアルゴリズムはありますか? この問題に触れた以前の質問がありますが、これをもう少し詳しく見ていきたいと思いdeprecateます。新しい施設で解決されたtrapや落とし穴、注意事項は非常に多くあります。すぐにそれらを陳腐化する時が来るかもしれないと感じています。

3
社内スクリプト言語を廃止するための移行戦略
社内で多くのことに使用するスクリプト言語があります。これは、動的ラベルがシステム全体に普及しているチューリング完全言語になるための単純な評価ステートメントとして始まりました。 問題は、このために設計されたことはなく、それが表示されることです。開発環境は貧弱であり、作成されたスクリプトはテスト可能ではなく、現在でも言語の正式な定義はありません。 言語のユーザーの間で高まる感情は、それが仕事を終え、手放す時が来たと感じていますが、既存のコードベースを新しいソリューションに考案することに移行するという困難な課題に直面しています。この議論は、移行の考えに反して使用されます。 同様の状況に直面したことがありますか?もしそうなら、古いものの使用を止めて新しいものを宣伝するためにどのような戦略を使いましたか? 最後に1つ(Moronsに感謝)、これらのスクリプトの多くは文書化されておらず、まだアクティブに使用されていますが、元の目的は失われています。スクリプトは顧客サイトでもシステムをカスタマイズするために使用されるため、文字通り数千のこれらのスクリプトがあり、その大部分はソース管理またはバージョン管理メカニズムの対象ではありません。 受け入れられた答え。 これは難しい選択です。モロンとオリバーのハイブリッドのいくらかが最良であると私は思うが、すべての答えは良いと健全なアドバイスでした。 私は結局オリバーズを受け入れることになりました。なぜなら、それがより高く受け入れられる最も良いチャンスである(ha!政治!)古いスクリプト環境を、新しい環境に統合できる呼び出し可能なステートメントにパッケージ化すると、迅速で簡単なアップグレードパスが得られます。 完了したら、警告を表示したり、古いスクリプトの編集や作成を禁止したりして、新しいスクリプトの作成を制御し、新しい言語に強制的に移行させることができます。 入力ありがとうございます!
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.