アカウント名:
パスワード:
この手のリファクタリングは往々にして事実上のfork、そして旧製品を超えられない。
極度にカオス化した悪しき旧製品はバクすら仕様(バグに依存してる別製品が存在する)と化してるので様々な不条理も含めて完全コピーが必要(何もしない方がマシ)という自己矛盾に陥る。
リファクタリングでバクを出すなんてカバだなあ。ちゃんとサイ設計しなよ。
牧歌的にみんな #include <linux/xxx.h> で ok、を越える様な修正提案には遠い様に読める。
リポジトリを clone して、少し読んでみる。依存関係は整理される。だけどコードの背景にある決まりの複雑さは増す。一例を取り上げてみる。今まで、
#include <linux/kref.h>
と書けば、kref 関係の一切合切を使える様になった。まぁ、普通の発想だと思う。だけど、提案されている修正は、
#include <linux/kref.h> /* kref に関係している型しか使えない。※1 */#include <linux/kref_types.h> /* kref に関係している型しか使えない(型しか使わない) */#include <linux/kref_api.h> /* kref に関係している一切合切(型定義と関数)を使える */
※1 移行作業緩和措置として CONFIG_FAST_HEADERS を「定義しなければ」、今まで通り #include <linux/kref.h> で一切合切使える。
で、この流儀は当然のように drivers/* にも適応される。linux kernel を少しでも読んだことがあるなら、linux kernel のヘッダにはこれは型定義?関数?初期化子?と悩む定義がてんこ盛りだ(コンパイラの機械的な解釈は一意だけどね)。
なんで、よほど強い強制でも無い限り、今まで #include <linux/kref.h> と書いてあったところが数学的に必要十分条件を満たすかどうかを検討せずに、 #include <linux/kref_api.h> と書き換えられるだけだと思う。特に driver 周りではね。
5 年もしたら、だれかが「なんで #include <linux/xxx_api.h> って書くの?無駄じゃね?」と言い出すだろう。
で、提案した修正でこの流儀が徹底されているかというと、徹底はされていない。例えば、include/linux/usb/composite.h は今まで通り、型定義と関数定義が仲良く header に入っている。一つのファイルを読めばどんな機能なのか一目瞭然だ。
一つの source code tree に 2 つの流儀が混在する状況が上手くいくのだろうか?自分が関わった project の全てでガチな統一コーディングルールが有ったし、無かったらルール屋さんが現れて、ルールを作って「これに従え」と、言い出していたな。ルールはメンバーの合議で決めてるプロセスを取っていたけど、まぁ、なんだ。誰か一人の好みを押し通すだけの儀式だったな。
今時マシンパワーで解決できること、あるいは Clang, LLVM の様に中間コード(仮想機械コード)に型情報を持たせて、リンケージ時とか object binary の高度利用で解決する方法を模索せずに、人力解決しようという流れが発生するのか...
うげ、思ってたのと違う。これ、他のコミッターが面倒だと思ったら無かったことになるかな。
リナックスはバザールでござ〜るからして、短慮な統制は邪魔にしかならないでしょうな。流儀が増えるだけ。無視ならまだマシ。LibreLinuxでも作ってそっちで挫折しとくのが一番無難かと。
これヘッダファイルの依存関係を整理してビルド速度を上げようってだけで、ビルド後に出力されるプログラムコードは同等のものにすることを目指してるんだけど…
目指してるけど、そうは行かない事が多いよねって元コメは言ってると思う。
ところが元コメではバグに言及しているため、バグを修正することが無意識のうちに前提としてある。
で、includeする順番が自由になったら、順番決め打ちを前提にしてたドライバとかバグるんだよなw
同じものを目指してると考えてたなら「旧製品を超えられない」「旧製品はバクすら仕様」なんて話が出てくるのはおかしい。
同じものが100点って前提なら、最善が旧製品と完全同一って意味になるので超えられるわけがない。100点満点で120点評価なんてものが現実にあるわけないだろw
ソースを整理するだけで超えるものを作ろうとなんてしていないプロジェクトなんだから
> 最善が旧製品と完全同一って意味になるので超えられるわけがない
が目標なんだよ。それなのに「旧製品を超えられない」なんて指摘をしているんだから元コメが理解していないのは明白じゃないか。
#if defiend(A__) && defined(B__)#include // #define C__#endif
のような文脈依存の依存関係を持っている場合はどういじっても既存コードへの影響が不可避ですからね。何もしてないのに壊れる老舗コードが出そうだなぁ。
わかる。コード汚いと書き直したくなる病が出てくるけど、大体はコードではなく現実が汚い。なんで書き直してもやっぱり汚い。もしくは汚い部分を扱えずに旧製品を超えられない。 今まで3回全面書き換えの場に立ち会ったけど、大失敗1、変わらず1、まあよくなった1ぐらいの結果だった。
> 大体はコードではなく現実が汚い。 それなんてみずぽ。
いわゆるRust病ってやつだな
> 大体はコードではなく現実が汚い。> なんで書き直してもやっぱり汚い。
これ大昔、Matz氏も同様の発言してたね。どの記事だったかな。
実験的フォークは、何かの知見を吐き出して終えればいいと思う何か新コーディング スタイルを生み出すかもね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
新Linuxの誕生である (スコア:0)
この手のリファクタリングは往々にして事実上のfork、そして旧製品を超えられない。
極度にカオス化した悪しき旧製品はバクすら仕様(バグに依存してる別製品が存在する)と化してるので
様々な不条理も含めて完全コピーが必要(何もしない方がマシ)という自己矛盾に陥る。
Re:新Linuxの誕生である (スコア:1)
リファクタリングでバクを出すなんてカバだなあ。ちゃんとサイ設計しなよ。
Re:新Linuxの誕生である (スコア:1)
牧歌的にみんな #include <linux/xxx.h> で ok、を越える様な修正提案には遠い様に読める。
リポジトリを clone して、少し読んでみる。
依存関係は整理される。だけどコードの背景にある決まりの複雑さは増す。一例を取り上げてみる。今まで、
#include <linux/kref.h>
と書けば、kref 関係の一切合切を使える様になった。まぁ、普通の発想だと思う。
だけど、提案されている修正は、
#include <linux/kref.h> /* kref に関係している型しか使えない。※1 */
#include <linux/kref_types.h> /* kref に関係している型しか使えない(型しか使わない) */
#include <linux/kref_api.h> /* kref に関係している一切合切(型定義と関数)を使える */
※1 移行作業緩和措置として CONFIG_FAST_HEADERS を「定義しなければ」、今まで通り #include <linux/kref.h> で一切合切使える。
で、この流儀は当然のように drivers/* にも適応される。linux kernel を少しでも読んだことがあるなら、linux kernel のヘッダにはこれは型定義?関数?初期化子?と悩む定義がてんこ盛りだ(コンパイラの機械的な解釈は一意だけどね)。
なんで、よほど強い強制でも無い限り、今まで #include <linux/kref.h> と書いてあったところが数学的に必要十分条件を満たすかどうかを検討せずに、 #include <linux/kref_api.h> と書き換えられるだけだと思う。特に driver 周りではね。
5 年もしたら、だれかが「なんで #include <linux/xxx_api.h> って書くの?無駄じゃね?」と言い出すだろう。
で、提案した修正でこの流儀が徹底されているかというと、徹底はされていない。例えば、include/linux/usb/composite.h は今まで通り、型定義と関数定義が仲良く header に入っている。一つのファイルを読めばどんな機能なのか一目瞭然だ。
一つの source code tree に 2 つの流儀が混在する状況が上手くいくのだろうか?自分が関わった project の全てでガチな統一コーディングルールが有ったし、無かったらルール屋さんが現れて、ルールを作って「これに従え」と、言い出していたな。ルールはメンバーの合議で決めてるプロセスを取っていたけど、まぁ、なんだ。誰か一人の好みを押し通すだけの儀式だったな。
今時マシンパワーで解決できること、あるいは Clang, LLVM の様に中間コード(仮想機械コード)に型情報を持たせて、リンケージ時とか object binary の高度利用で解決する方法を模索せずに、人力解決しようという流れが発生するのか...
Re: (スコア:0)
うげ、思ってたのと違う。
これ、他のコミッターが面倒だと思ったら無かったことになるかな。
Re: (スコア:0)
リナックスはバザールでござ〜るからして、
短慮な統制は邪魔にしかならないでしょうな。
流儀が増えるだけ。無視ならまだマシ。
LibreLinuxでも作ってそっちで挫折しとくのが一番無難かと。
Re: (スコア:0)
これヘッダファイルの依存関係を整理してビルド速度を上げようってだけで、ビルド後に出力されるプログラムコードは同等のものにすることを目指してるんだけど…
Re: (スコア:0)
目指してるけど、そうは行かない事が多いよねって元コメは言ってると思う。
Re: (スコア:0)
ところが元コメではバグに言及しているため、バグを修正することが無意識のうちに前提としてある。
Re:新Linuxの誕生である (スコア:1)
includeする順番変えるだけでブートしなくなるようなバグは直すプロジェクトだよ
Re: (スコア:0)
で、includeする順番が自由になったら、順番決め打ちを前提にしてたドライバとかバグるんだよなw
Re: (スコア:0)
同じものを目指してると考えてたなら「旧製品を超えられない」「旧製品はバクすら仕様」なんて話が出てくるのはおかしい。
Re: (スコア:0)
同じものが100点って前提なら、最善が旧製品と完全同一って意味になるので超えられるわけがない。
100点満点で120点評価なんてものが現実にあるわけないだろw
Re: (スコア:0)
ソースを整理するだけで超えるものを作ろうとなんてしていないプロジェクトなんだから
> 最善が旧製品と完全同一って意味になるので超えられるわけがない
が目標なんだよ。
それなのに「旧製品を超えられない」なんて指摘をしているんだから元コメが理解していないのは明白じゃないか。
Re: (スコア:0)
#if defiend(A__) && defined(B__)
#include // #define C__
#endif
のような文脈依存の依存関係を持っている場合は
どういじっても既存コードへの影響が不可避ですからね。
何もしてないのに壊れる老舗コードが出そうだなぁ。
Re: (スコア:0)
わかる。
コード汚いと書き直したくなる病が出てくるけど、大体はコードではなく現実が汚い。
なんで書き直してもやっぱり汚い。もしくは汚い部分を扱えずに旧製品を超えられない。
今まで3回全面書き換えの場に立ち会ったけど、
大失敗1、変わらず1、まあよくなった1ぐらいの結果だった。
Re: (スコア:0)
> 大体はコードではなく現実が汚い。
それなんてみずぽ。
Re: (スコア:0)
いわゆるRust病ってやつだな
Re: (スコア:0)
> 大体はコードではなく現実が汚い。
> なんで書き直してもやっぱり汚い。
これ大昔、Matz氏も同様の発言してたね。どの記事だったかな。
Re: (スコア:0)
実験的フォークは、何かの知見を吐き出して終えればいいと思う
何か新コーディング スタイルを生み出すかもね