アカウント名:
パスワード:
理想に近い仕様変更では?
いや、平成32年とかより、明治5年の改暦以前の和暦変換をちゃんと実装してほしい。明治元年閏卯月三日(慶應義塾が三田に出来た日)とか。
天保暦だけに対応すればいいって訳でもないのでキリがない
# ユリウス日から算出するのを考えましたが挫折しました
.NET Framework ver.2.0までバックポートとなるとテスト工数を考えると頭痛が痛くなる人はいるかもしれない。4以上か、せめてWin7に載ってった3.5までにしてほしかったかも。
そこまでアップデートされて困るならそもそもアップデートを止めた方がいいのでは。。。
ソース読めばわかるが、3.5以前への変更はOptionalだから心配ない。
3.5は2.0以上を包括しているから、3.5固有の機能以外は2.0対応=3.5対応
2.0と3.5は動作環境が同じなのでしょうがない2.0と3.5はCLRのバージョンが同じで3.5環境で2.0で作ったソフトが動くので
既定が従来の動作でない点と4.5.2以前の動作をプロセスごとに変更できない点が残念
仕様変更だからあかん。仕様変更のおかげで以前はエラーで転けてたアプリがちゃんと動くようになった! やったね! みたいなのは、趣味の日曜プログラミングぐらいでしかあり得ない。変なのを食わせても西暦に変換してくれる関数を別途追加すれば良かった。
昭和65年がエラーになる仕様をどうしても維持したいのなら、AppConfigに設定を追加する必要があるが、たいした手間でもなかろう。
大半のシステムは、今回のMicrosoftの対応のおかげで、ソースコード変更なし、再テストのみで済むのではないか。
じゃあ、AppConfigに設定を追加するだけで済んだぁ! やったね!から、どうやって、新たに追加された「はみ出た入力でもきちんと変換できる機能」を使うプログラムに移行していくおつもりで?
どこに設定を追加しなきゃならないかを調べようとしたら、どうせ、全ソースに全文検索かけるような手間が必要なわけで、そこで新APIへ置換してしまっても手間は変わらない。
AppContext に値を設定するだけなら
> どこに設定を追加しなきゃならないかを調べようとしたら、どうせ、全ソースに全文検索かけるような手間が必要なわけで、そこで新APIへ置換してしまっても手間は変わらない。
とかいった手間は別に必要ないような.4.5.2 以前向けのレジストリへの設定も,ソースのリンク先見るだけで判りますよ.
こいつプログラム書いたことないだろ
「そんなローカルの古臭い風習までいちいち面倒見るわけがねえだろうがボケェ!西暦を使え!!どうしても使いたいなら自分で実装しろ!!!」って言って、西暦以外に対応しないのが普通の社会を作る後押しをしてくれるのが理想
元号発表を直前にすることで西暦の後押しをしようとした(◎本会議談)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
なにをもって面倒といっている? (スコア:0)
理想に近い仕様変更では?
Re:なにをもって面倒といっている? (スコア:1)
いや、平成32年とかより、明治5年の改暦以前の和暦変換をちゃんと実装してほしい。
明治元年閏卯月三日(慶應義塾が三田に出来た日)とか。
Re: (スコア:0)
天保暦だけに対応すればいいって訳でもないのでキリがない
# ユリウス日から算出するのを考えましたが挫折しました
Re: (スコア:0)
.NET Framework ver.2.0までバックポートとなるとテスト
工数を考えると頭痛が痛くなる人はいるかもしれない。
4以上か、せめてWin7に載ってった3.5までにしてほしかったかも。
Re:なにをもって面倒といっている? (スコア:1)
そこまでアップデートされて困るならそもそもアップデートを止めた方がいいのでは。。。
Re:なにをもって面倒といっている? (スコア:1, 参考になる)
ソース読めばわかるが、3.5以前への変更はOptionalだから心配ない。
Re: (スコア:0)
3.5は2.0以上を包括しているから、3.5固有の機能以外は2.0対応=3.5対応
Re: (スコア:0)
2.0と3.5は動作環境が同じなのでしょうがない
2.0と3.5はCLRのバージョンが同じで
3.5環境で2.0で作ったソフトが動くので
Re: (スコア:0)
既定が従来の動作でない点と4.5.2以前の動作をプロセスごとに変更できない点が残念
Re: (スコア:0)
仕様変更だからあかん。
仕様変更のおかげで以前はエラーで転けてたアプリがちゃんと動くようになった! やったね! みたいなのは、趣味の日曜プログラミングぐらいでしかあり得ない。
変なのを食わせても西暦に変換してくれる関数を別途追加すれば良かった。
Re: (スコア:0)
やっぱりこれ元号発表しない政府(とそんな政府を支持する愚民ども)に対する嫌がらせでしょ。
Re: (スコア:0)
昭和65年がエラーになる仕様をどうしても維持したいのなら、AppConfigに設定を追加する必要があるが、たいした手間でもなかろう。
大半のシステムは、今回のMicrosoftの対応のおかげで、ソースコード変更なし、再テストのみで済むのではないか。
Re: (スコア:0)
じゃあ、AppConfigに設定を追加するだけで済んだぁ! やったね!
から、どうやって、新たに追加された「はみ出た入力でもきちんと変換できる機能」を使うプログラムに移行していくおつもりで?
どこに設定を追加しなきゃならないかを調べようとしたら、どうせ、全ソースに全文検索かけるような手間が必要なわけで、そこで新APIへ置換してしまっても手間は変わらない。
Re: (スコア:0)
AppContext に値を設定するだけなら
> どこに設定を追加しなきゃならないかを調べようとしたら、どうせ、全ソースに全文検索かけるような手間が必要なわけで、そこで新APIへ置換してしまっても手間は変わらない。
とかいった手間は別に必要ないような.
4.5.2 以前向けのレジストリへの設定も,ソースのリンク先見るだけで判りますよ.
Re: (スコア:0)
こいつプログラム書いたことないだろ
Re: (スコア:0)
「そんなローカルの古臭い風習までいちいち面倒見るわけがねえだろうがボケェ!西暦を使え!!どうしても使いたいなら自分で実装しろ!!!」って言って、西暦以外に対応しないのが普通の社会を作る後押しをしてくれるのが理想
Re: (スコア:0)
元号発表を直前にすることで西暦の後押しをしようとした(◎本会議談)