タグ付けされた質問 「backward-compatibility」

14
プログラミング言語の後方互換性とその欠陥の修正を維持する
まず、いくつかのコンテキスト(ほとんどの人が知っているもの): すべての一般的なプログラミング言語には明確な進化があり、ほとんどの場合バージョンによってマークされます。Java5、6、7など、PHP 5.1、5.2、5.3などがあります。新しいバージョンをリリースすると、新しいAPIが利用可能になり、バグが修正され、追加されます新しい機能、新しいフレームワークなどです。全体として:それは良いことです。 しかし、言語(またはプラットフォーム)の問題はどうでしょうか?言語に何か問題がある場合、開発者はそれを回避するか(可能であれば)、それと共存することを学びます。 現在、これらの言語の開発者は、それらの言語を使用するプログラマーから多くのフィードバックを得ています。そのため、時間(およびバージョン番号)が経過するにつれて、これらの言語の問題はゆっくりと、しかし確実に消えていくことになります。まあ、そうでもない。どうして?下位互換性、それが理由です。しかし、これはなぜですか?より具体的な状況については、以下をお読みください。 私の質問を説明できる最善の方法は、PHPを例として使用することです。 PHPは何千人もの人々に愛され、嫌われています。すべての言語には欠陥がありますが、明らかにPHPは特別です。このブログ投稿をご覧ください。PHPのいわゆる欠陥の非常に長いリストがあります。今、私はPHP開発者ではありません(まだ)が、すべてを読み通しており、そのリストの大きな部分が実際の問題であると確信しています。(潜在的に主観的であるため、すべてではありません)。 さて、もし私がPHPを積極的に開発している人の1人であれば、これらの問題を1つずつ解決したいと思っています。ただし、それを行うと、言語の特定の動作に依存するコードが新しいバージョンで実行されると壊れます。2語で要約すると、後方互換性です。 私が理解していないのは、なぜPHPの下位互換性を保つ必要があるのか​​ということです。これらの問題をすべて修正したPHPバージョン8をリリースした場合、「このバージョンでは古いコードを実行しないでください!」という大きな警告を出すことはできませんか? 非推奨と呼ばれるものがあります。私たちは何年もそれを持っていて、それはうまくいきます。PHPのコンテキスト:最近の人々がどのようにmysql_*関数の使用を積極的に推奨していないか(そして代わりにmysqli_*PDO を推奨するか)を見てください。廃止は機能します。使用できます。それを使うべきです。関数で機能する場合、言語全体で機能しないのはなぜですか? 私(PHPの開発者)がこれを行うとしましょう: これらのすべての欠陥を修正した新しいバージョンのPHP(たとえば8)を起動します 新しいプロジェクトは、そのバージョンの使用を開始します。これは、はるかに優れた、より明確な、より安全なものだからです。 ただし、古いバージョンのPHPを放棄しないように、更新プログラムをリリースし続け、セキュリティの問題、バグなどを修正します。これは、ここにリストしていない理由から理にかなっています。これは一般的な習慣です。たとえば、バージョン5.5.xに主に焦点を合わせていたにもかかわらず、OracleがMySQLのバージョン5.1.xを更新し続けた方法を見てください。 約3〜4年後、古いバージョンのPHPの更新を停止し、それらを消滅させます。この3年か4年で、ほとんどのプロジェクトはとにかくPHP 8に切り替えられるので、これは問題ありません。 私の質問は次のとおりです。これらの手順はすべて理にかなっていますか?それはとても難しいでしょうか?それができれば、どうしてできないのですか? はい、欠点は後方互換性を破ることです。しかし、それは支払う価値がありませんか?良い点として、3、4年後には、その問題の90%が修正された言語になります。その名前はその人気を保証します。 編集:OK新しい計画。

7
jQueryを更新するタイミング
この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 jQuery / jQuery UIの更新を推奨する場合 または言い換えると、jQuery / jQuery UIを更新するためのベストプラクティスは何ですか? 私は少なくとも1年以上かかる長いプロジェクトに取り組んでいます。その期間に、jQuery / jQuery UIは何度も更新されると確信しています。 更新プログラムがリリースされるたびに、jQuery / jQuery UIファイルを更新することをお勧めしますか?または、プロジェクトの最後まで特定のバージョンを使用する方が良いですか? 私はコードの変更を「壊す」ことを恐れており、アップデートがリリースされるたびに、すべてをテストする必要があります。それには時間がかかりすぎます。しかし、一方で、もし私が更新しなかったなら、後で私を後から噛ませるバグを恐れています。 プロジェクトはASP.MVCであり、jQueryを頻繁に使用しています。 何かご意見は?

1
(/ did)Bertrand Meyerは、サブクラス化が「閉じた」モジュールを拡張する唯一の方法だと考えるのはなぜですか?
MeyerのObject-Oriented Software Construction(1988)で、彼は次のようにオープン/クローズド原則を定義しています。 モジュールがまだ拡張可能であれば、モジュールは開いていると言われます。たとえば、フィールドに含まれるデータ構造にフィールドを追加したり、実行する一連の機能に新しい要素を追加したりすることができます。 モジュールは、他のモジュールで使用できる場合、閉じられていると言われます。これは、モジュールに明確に定義された安定した説明(情報隠蔽という意味でのインターフェース)が与えられていることを前提としています。 彼は言い​​続けます: モジュールを再度開く場合、古いバージョンに依存しているため、すべてのクライアントを再度開いて更新する必要があります。…[この問題]は、モジュールを新しい関数またはデータ要素によって拡張する必要があるたびに発生し、直接および間接クライアントの変更をトリガーします。...設計とプログラミングに対する古典的なアプローチでは、オープンとクローズの両方のモジュールを記述する方法はありません。 このジレンマに対するMeyerの解決策は、既存のクラスを変更してライブラリモジュールを拡張しないことです。代わりに、既存のクラスをサブクラス化する新しいモジュールを作成し、新しいクライアントがその新しいモジュールに依存するようにします。 今、1988年に、私はTurbo PascalとBlankenship Basicでおもちゃ(手続き)プログラムを書いていました、そして、21世紀の専門的な経験はJVM、CLR、および動的言語でしたので、Meyerの意味がわかりません「設計とプログラミングへの古典的なアプローチ」による。 Meyerのクライアントモジュールを再度開く必要がある理由の具体例(より多くのケースを必要とする、より多くのメンバーを含む列挙のswitchステートメント)は十分に合理的なようですが、ライブラリに機能を追加するたびにアサーションを正当化することはほとんどありませんモジュール、すべてのクライアントを更新する必要があります。 この主張が1988年に自明であると思われる歴史的な理由はありますか?たとえば、C静的ライブラリに関数またはデータ構造を追加すると、下位互換性のあるAPIでもクライアントを再コンパイルする必要があるようにレイアウトが変更されましたか?または、MeyerはAPIの下位互換性を強制するメカニズムについて本当に話しているだけですか?

13
後方互換性が必要ないと仮定して、C#または.Netの機能を停止しますか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 製品またはフレームワークは進化します。主に、ユーザーのニーズをキャッチし、新しいコンピューティングパワーを活用し、単純に改善するために行われます。製品によって主要な設計目標も変わる場合があります。C#または.netフレームワークも例外ではありません。ご覧のとおり、現在の第4バージョンは、第1バージョンとは大きく異なります。しかし、物事はこの進化の後方互換性に対する障壁となっています。 ほとんどのフレームワーク/製品では、下位互換性をサポートする必要がなければ機能が中断されます。あなたによると、C#/。netのこれらの機能は何ですか? 回答ごとに1つの機能をお知らせください。

3
ほとんどのユーザーにリーチするには、デスクトップアプリケーションにどのバージョンのJavaを使用すればよいですか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 ほとんどのエンドユーザーがJava 8よりも古いバージョンを使用していると想定するのは正しいですか?私のアプリケーションを使用するために人々に強制的にアップグレードさせたくないので、たとえそれが新しいバージョンの利点を自分に適用できない場合であっても、最初からJava 7または6を使用するように計画する必要があります開発者として?

3
変更に対してプログラミング言語をより安定(互換)にするメカニズムはありますか?
プログラミング言語は多数あります。それらのいくつかは成長し、非常に人気があります。人々はそのような言語をますます頻繁に使用します。そのような言語の創設者(または設立組織/コミュニティ)は、言語を改善するために変更を実装しようとする場合があります。しかし、下位互換性のために変更を加えるのが難しい場合があり、そのようないことは何年も言語にすでに存在しており、多くのユーザーによって使用されています。 言語設計段階で、言語設計者が下位互換性を破ることを恐れないように、より安定させるのに役立つアーキテクチャの原則や手順はありますか?

3
異なるバージョンのソフトウェア間でファイルの後方互換性を許可するための優れた設計とは何ですか?
異なるバージョンのソフトウェア間でファイルタイプの後方互換性を許可するための優れた設計とは何ですか? たとえば、Microsoftはどのようにして2007、2010、2013などの単語をすべての開いているdocxファイルに取得しますが、異なるエディションではより多くの/少ないデータを保存し、わずかに異なる方法でデータをすべて同じファイルタイプに保存できますあるバージョンで保存されたファイルは別のバージョンで開くことができますが、ファイルの特定の要素は古いバージョンでは使用できない可能性がありますか? つまり、それを行うための本当に明白な方法は、 private string openfile(string filename) { File.Open(filename) ... some logic that gets a header from the file that will never change switch (fileversion) case 2007: ..... case 2010 ..... case 2013 ..... } しかし、それは信じられないほどモノリシックで、あまり拡張性がなく、多くのコピー/貼り付けコードにつながる可能性があります。 だから私は、ファイルに存在する必要があるヘッダーなどの不変の構造、およびシリアル化/逆シリアル化に必要なメソッドを定義するすべてのバージョンのベースインターフェイスを使用することを考えていましたインターフェースを実装する新しいバージョンのクラスは古いバージョンを継承し、ファイルがほとんど同じであるため、変更されたもののみをオーバーライドします。 ファイルの構造についてはあまり気にしません。XMLを使用することは既に決まっているので、最初のスキーマは概して決定済みです。ただし、将来的には間違いなく変更されることになるので、これらの変更に容易に対応できるようにコードを設計できるようにしたいだけです。

2
.NET Frameworkの下位互換性とは何ですか?
MySQLのデータベースを使用して、.NET 4でWindowsアプリケーションを開発します。そのアプリケーションをデプロイするときは、クライアントに.NET 4フレームワークをインストールし、次に.NET Connector for MySQLをインストールするときは、.NETフレームワーク3.5が必要です。ただし、.NET 4はすでにインストールされています。.NET Frameworkには下位互換性がありませんでしたか? ディスクサイズが小さくない2つの.NETフレームワーク(3.5と4)をインストールします。後方互換性は正確にはどういう意味ですか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.