【PHP】下らねぇ質問はここに書き込みやがれ 15

!extend::vvvvv:1000:512
!extend::vvvvv:1000:512
★スレ立て時 ↑ が3行以上になるようコピペ

PHPに関する質問スレです

前スレ
【PHP】下らねぇ質問はここに書き込みやがれ 14
http://2chb.net/r/tech/1663659983/

次スレは>>980以降

---

VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

PHPで20桁の整数演算をしよう！

GMPでも使ってろ

遅れたが纏めて一応返しておく
(なお前後してる部分もあるので、まず全部読む方がいいかも
※はその時にはそう思ってたが、後になって違うと判明した部分
思考の過程を残した方が参考になると思うので残しておく)

> そのため、ここは一度戦略的に撤退し、次の好機をうかがうことにしました
この判断はあり、というか普通はそうする
理由は俺らプログラマにとっての資産＝時間をかけて作ったもの＝ソースコードであり、
自分のソースコ
ード＝他の誰にも任せられず、『自分でやるしかない事に注力すべき』だから
onigurumaの新機能はいつか誰かが使えるようにしてくれるから、後回しでいい
典型的には既に回答されてるとおり、956,959でラップし、とりあえず自分のソースコ
ードを完成させてしまい、
その後やはり速度等で問題がある場合、
つまり自分で解決しないと先に進まない状況になって初めて今回のように自分で対応し、
その後ソースコ
ードを差し替える
だから最低限は「差し替えが簡単なソースコ
ードにしておく」事で、今回は自然とそうなるので問題はない

今回のような話は試行錯誤的で、
やってても終わりが見えないが、終わるときにはいきなり終わるので、
「もうちょっとで行けそう」的にズルズルと無限に時間を食う事はよくある
なので、一旦本筋に戻る、というのは正しい

ただ、(時間に余裕があるのなら)それでもやり続けるのも正しいが
出来ない≒多くの場合、何らかの技術/知識的に問題があるので出来ない、なので、
全方向的に首を突っ込むだけでも色々蓄積はしていく(とはいえ効率が悪いかもだが)
やれる事を繰り返してても慣れるだけで、本質的な部分では上達しない

> php_mbregex.c の 473行目のエラー処理が実行されます
> PHP Warning: mb_ereg_replace(): mbregex compile err: undefined callout name in /home/user1/test.php on line 7
onigurumaがphp_mbsgringから見て正しく構成されているかをチェックしてるだけの様に見える
渡す正規表現のエンコードがphp_mbstring側(多分utf-8)と一致してるか等のチェックだと(この時点では)推測する
多分onigurumaのコンパイル時に指定出来るのではないかと(でもonigurumaもutf-8がデフォな気はするが)
という見当でonigurumaソースを見てみる
(なおソースコードは10/24にダウンロードしてた oniguruma-43a8c3f3daf263091f3a74019d4b32ebb6417093)

mbstring.c:472: onig_error_code_to_str(err_str, err_code, &err_info);
　より、
php-8.3.12\ext\mbstring>grep -n -r onig_error_code_to_str *　で出てこないので

oniguruma>grep -n -r onig_error_code_to_str *　で(他多数だが)
src/regerror.c:293:onig_error_code_to_str(UChar* s, int code, ...)

oniguruma>grep -n -r "undefined callout name" * では
src/regerror.c:186: p = "undefined callout name"; break;

src/regerror.c:186付近を見ると ONIGERR_UNDEFINED_CALLOUT_NAME なので、
>grep -n -r ONIGERR_UNDEFINED_CALLOUT_NAME * すると(他多数だが)
src/regparse.c:1750: return ONIGERR_UNDEFINED_CALLOUT_NAME;
関数は get_callout_name_id_by_name なので中身を確認すると callout_name_find 結果がNULLの時だと分かる
src/regparse.c:1414: callout_name_find も確認すると、

・GlobalCalloutNameTable がnullか、
・onig_st_lookup_callout_name_table でNULLが返される時にこのエラー

ちなみに ONIGENC_IS_ASCII_COMPATIBLE_ENCODING の時には ONIG_ENCODING_ASCII にして再度検索してるから、
utf-8ならエラーにはならないはずだが、はて？
まあネタ元は GlobalCalloutNameTable らしいので
oniguruma>grep -n -r GlobalCalloutNameTable *
14件出るが全部このファイル内なので確認すると、どうやら
src/regparse.c:1501: callout_name_entry で作っているらしい
てっきり定数で与えられてる物を違うエンコーディングで検索して失敗してるのかと思いきや、
見る限り毎回全部作り直してるっぽいので、これって正規表現内の名前付きキャプチャ(?<Name>x)のことか？(※勘違い)
ただ、無ければ毎回登録してるだけなので、これが検索失敗するのはそもそもおかしい
(＝だからこそ mbregex compile err: なわけだが)
なお関数は #ifdef USE_ST_LIBRARY によって登録の仕方が変わっており、ここで食い違ってるのかも？(※間違い)
oniguruma>grep -n -r USE_ST_LIBRARY * で(他多数)
src/regint.h:93:#define USE_ST_LIBRARY
なのだがこれは(このファイルがインクルードされる限り)毎回必ず#defineされてる
となると、fprintfでデバッグする気なら、

・regparse.cの1511行目付近で、実際に登録しようとしているnameを出力させる
(例：fprintf(file, "%s %d %s: %.*s", __FILE__, __LINE__, __func__, len, name); と書けるらしい)
・regparse.cの1747行目付近で、実際に検索しているnameを出力させる
(例：fprintf(file, "%s %d %s: 0x%16x: %.*s", __FILE__, __LINE__, __func__, (int)GlobalCalloutNameTable, (int)(name_end-

name), name);)

まあ何を登録/検索しようとしてるか分かれば見当は付くはず(※後に完全に見当付いたが)
おそらく登
録時と検
索時でエンコが違ってて検
索失敗してると推測する

> W, D, S, P などのオプションの追加を検討する必要があります
フラグの追加は php_mbregex.c 内 _php_mb_regex_init_options に追加するだけだから楽勝ではあるが、
問題は php 側をコンパイルする必要がある点だな
なお(良いか悪いかはさておき)、通すだけなら

default:
zend_value_error("Option \"%c\" is not supported", c);
return false;


の部分でエラーにするのを止めて、つまりどんなフラグでも通過させるようにする方が楽
(ただ現状の構成では上記をコメントアウトだけでは駄目で、全部case文で書いて|=ONIG_OPTION*する必要があるが)
というか、俺は952時点ではそうなってると思っていた。つまり、
> 普通はそのエラー自体もライブラリ、つまりonigurumaやpeclに判定させて、throwさせるものだから(952)
と言ったのは、上記ポリシーで全部渡した上で、
onigurumaから「そんなフラグはない」とエラーを返させてそれをphpにそのまま返す、
とした方が、onigurumaのアップデートをタダで受け取れるから
(onigurumaに合わせてphpをアップデートする必要がない＝php側での仕事が減る
『自分でやるしかない事に注力すべき』と言ったとおり、
oniguruma側がやってくれるのなら任せた方が良い、と俺は考えるが、
現状のphpはそうなってないし、何かしら理由はあるのだろう
ちなみにこの構成の場合、フラグをONIG_OPTION_*で構造体に設定して渡すのではなく、フラグ文字列として渡し、
oniguruma内にあるフラグ文字列=>ONIG_OPTION_*変換器に通す(onigurumaが単体で動くのならこのルーチンは内部にある)
この場合、onigurumaのフラグ定義で動作するようになり、
phpの古いフラグと被ってる場合に問題なるが、(＝php側でフラグ名の再定義が出来ない)
見る限りpreg_replace(つまりpcre)と合わせる気もないみたいだし、
oniguruma自身も普通のフラグ名で作られてるようなので、
そのまま通してしまった方が俺はいいとは思うんだがな)
(※とは思ったがonigurumaにはフラグが死ぬほどあるのね…)

> oniguruma 付属のテスト用ファイル /sample/callout.c では (*FAIL) と (*SKIP) が問題なく動きます
> RUBY オプションを ONIGURUMA オプションで上書きし、実行時の syntax に RUBY を指定した状態で
> (*FAIL) と (*SKIP) が正常に機能します
つまりonigurumaは正常にコンパイル出来ている

> onig_init();
については947自身で答えが出てるのでよしとして、

> それが使われているのではないか」という仮説を立てています
結局の所、新しくコンパイルしたdllが使われてるか断定出来ないからだと思うが、
上記の通り、エラー吐いてる箇所(＝そこを通ってると確実に言える場所)にfprintf仕込んでしまえば、
fprintf出力されれば、新しくコンパイルした物、そうでなければ古いまま、と断定出来る
とはいえ他のかなり高級な方法
> oniguruma 6.9.9 で Fix されたバグが直っているのを確認しました
で解決したのでよしだが

> このテストファイルのコ-ドを php_mbregex.c に移植して動かしてみました
これは php側のコンパイル環境も立ち上げたって事？
ならfprintfはphp側にも仕込めるようになるが、あまり手を広げすぎても収拾付かなくなるから、
とりあえず上記oniguruma側でfprintf仕込んで何を検索しようとして失敗してるのか確認した方がいいと思う
(※なおやらなくても見当付いたが)
少なくともoniguruma単体で動かせるのなら、
どういう正規表現を与えたら何を登録/検索してるかは確実に引き出せるし、
同じ正規表現をphpから与えた場合と比較も出来るし

まあ、でも一旦956,959で回避するのもありよ
好きな方でどうぞ

ちなもうちょっといけるかと思って callout_name_entry を呼び出し元の onig_set_callout_of_name を
oniguruma>grep -n -r onig_set_callout_of_name * すると(他多数)
doc/CALLOUTS.API.ja:98:# int onig_set_callout_of_name(OnigEncoding enc, OnigCalloutType type, ,,,
doc/SYNTAX.md:786:function set in `onig_set_callout_of_name()` will be invoked, passing the given name
が引っかかるのだが何ぞこれ？

SQLiteと同様に、onigurumaはユーザーC関数を登
録して正規表現内から呼び出せたりするのか？
phpにはこのインタフェースはなさそうだが
というかこの辺はそちらの方が詳しいはず
と思って SYNTAX.md の方見たら
> 29. ONIG_SYN_OP2_ASTERISK_CALLOUT_NAME (enable (*name))
なのでまんま君が使いたい機能か
となると(*FAIL)(*SKIP)は CALLOUTS.BUITIN に定義されてるはずなので、この定義の検索を失敗している事になる
この辺を調べようとするが、
mbstring>grep -n -r "FAIL\\W" *
mbstring>grep -n -r "SKIP\\W" *　は共にまさかのヒット無し
mbstring>grep -n -r FAIL *
mbstring>grep -n -r SKIP *　を共に確認するも、無い
php-8.3.12\ext\mbstring>grep -n -r "FAIL\W" *
php-8.3.12\ext\mbstring>grep -n -r "SKIP\W" *　で同様にphp側も確認するが、無い

つまり、(*SKIP)(*FAIL)自体の定義が見あたらない
仕方ないので callout_name_find から onig_st_lookup_callout_name_table を辿ると、onig_st_lookup を呼んでいる
ところがこれも定義が見あたらない
まあCの場合はマクロで相当な事が出来るのでよくよく探してみれば出てくるかもだが

なのでこちらは、現状、
・(*SKIP)(*FAIL)の定義自体を見つけられない(が、どこかにあるはず)
　ありがちなのは'SKIP'ではなく、最速の s[i]=='S' && s[i+1]=='K' ... とかの可能性で、
　これも一応探したが、ない…
　高速化の為に探索部分と一体化してて、grep等では探せないのかも…
・(*SKIP)(*FAIL)を探しに行っている関数 onig_st_lookup の定義が見つからない(が、これもどこかに定義されてるはず)
　マクロで書き換えててgrepではヒットしない場合もあるが、一般的にはこれはあまりないはず…
という感じ

上記 fprintf については、
・$pattern = "....(*SKIP)(*FAIL)|[^あ]";を与えた場合、
　'SKIP'と'FAIL'が検索される(と予想)
　そして onig_set_callout_of_name 内
　callout_name_entry 内
　callout_name_find 内
　onig_st_lookup_callout_name_table 内
　onig_st_lookup で検索されるが、検索に失敗する
　(そして onig_st_lookup の定義が見あたらない…)
・何故検索に失敗するのかは、上記fprintfで確定するはずだが、
　もしかするとphpがutf-8でonigurumaがutf-16なのか？
・(*MyFunc)とかやりたいのなら諦めた方がいい
　php側のインタフェースがまるでないので、先は長い
　そこを俺が書いてやるぜ！という勇者ならphp側も歓迎はするだろうが
　(C書けてもonigurumaの仕様を熟知してないと書けない部分だし)

というわけで自身の探索経過と比較してくれれば、辿り方等も分かってくると思う
ちな、ささっと分かるなら、再記すると

・(*SKIP)(*FAIL)の定義部分
・onig_st_lookup の定義部分

を見つけてくれれば確認する

ごめん間違ってた(>>11)

×　> mbstring>grep -n -r FAIL *
○ > oniguruma>grep -n -r FAIL * のつもりが、やってなかった

やればぞろぞろ出てきたので、また続き報告します

oniguruma/regexec.c:6399: onig_builtin_fail が(*FAIL)の定義
oniguruma/regexec.c:6433: onig_builtin_skip が(*SKIP)の定義
なのは分かった

これらを呼び出してるところは、grep -n -r onig_builtin_fail * では出てこない
そこで、(これはC知ってないと無理だが、)
oniguruma>grep -n -r '#define' * | egrep -v '#define *[A-Z]' で小文字マクロを確認、onig_を付けてるケースが多いので、(※2)
oniguruma>grep -n -r builtin * とすると
src/regint.h:989:/* for definition of builtin callout */
src/regint.h:995: onig_builtin_ ## func, 0, 0, 0, 0, 0);\
src/regint.h:1004: onig_builtin_ ## func, 0, 0, 0, 0, 0);\
src/regint.h:1013: onig_builtin_ ## func, 0, 0, 0, 0, 0);\
src/regint.h:1022: onig_builtin_ ## func, 0, (na), (ts), 0, 0); \
src/regint.h:1031: onig_builtin_ ## func, 0, (nts), (ts), (nopts), (opts));\
src/regint.h:1040: onig_builtin_ ## func, 0, (na), (ts), 0, 0);\
src/regint.h:1049: onig_builtin_ ## func, 0, (nts), (ts), (nopts), (opts));\
となり、マクロで呼び出してる

なので、定義自体は存在してて、呼び出し部もある
だから(*SKIP)(*FAIL)の文字列から検索出来てないだけ

ありがとうございます、規制に引っかかったのでとりあえずこちらに書きました
2chb.net/r/mango/1715675838/333

向こうにも書きましたがもう調べて頂かなくて大丈夫です、すみません..

同様に onig_st_lookup を探す
oniguruma>grep -n -r st_lookup * で
src/regint.h:241:#define st_lookup onig_st_lookup
src/st.c:237:st_lookup(st_table* table, register st_data_t key, st_data_t* value)
と分かる
中身見たら FIND_ENTRY を呼んでおり、これはすぐ上 src/regint.h:224:#define FIND_ENTRY で定義されてる
ちなみにすぐ下 src/regint.h:271:st_insert(register st_table* table, register st_data_t key, st_data_t value)
で毎回エンコードに合わせて作ってる雰囲気

なのでやはり、phpとonigurumaの正規表現のエンコ
ードが異なってて検索失敗かと
ありがちなのは、'SKIP'を
php:utf8で 0x53,0x4b,0x49,0x50 と送信
oniguruma: utf-16LEで、0x53,0x00,0x4b,0x00,0x49,0x00,0x50,0x00 を期待
とかで検索ミスかと

多分onigurumaをコンパイルする際に『phpとやりとりする』（＝APIの)正規表現の文字エンコ
ードを決められる
多分コンパイルオプションにあるから確認してみて
なおこれは対象文字列のエンコ
ードとは違うので注意
phpで言うと、
mb_ereg_replace(
string $pattern, <- 今問題になってるエンコ
ードはこれと
string $replacement, <- これ
string $string, <- onigurumaが様々なエンコ
ードに対応出来てる、というのはこれ
?string $options = null
)

実際のエンコ
ードを確認したければ、fprintf を仕込めばいい
面倒ならありがちなのを(といってもほぼutf-8のはずだが)全部試して動く奴を探してもいい
既に書いてるが、多分 utf-8(php)とutf-16(oniguruma)で空振りしてると予想
よろしく頑張ってちょ

(※2): シングルクオートになってるのはdos窓だとイマイチ動かなかったのでunix環境(cygwin)に切り替えたから
　多分知ってるだろうから問題ないと思うが、意味無いところで疑問に思われても無駄なので念のため

>>15
了解、今から読む
とりあえず書いたので全部落としておく

>>15
読んだ
> あなたのような優秀な方を空回りさせてしまうのは申し訳無さすぎますので..
これは気にする必要ない
俺は「たまには他人のコードも読むべき」と認識してるから、機会見つけて読んでるだけ
一人で読んでても仕様とか知らんしハマるので、他人がいるときに合わせて読んでるだけだから
実際君はかなり仕様を知ってるし、結果的に辿りやすくなってる

> oniguruma には自分で任意の (*hoge) を作って oniguruma に登録することが
> 出来るという機能があります
あーやっぱこれ目当てですか

> そこで php_mbregex.c の中で任意の (*hoge) を作って oniguruma に登録し、
> test.php を実行して任意の (*hoge) が正規表現のパーツとして認識されるか
> どうかを確認したところ、ちゃんと認識されました
さらっと書いてるけどこれは結構ハードル高いはず、まあ動いたのならすごいが

> なので、(*hoge) の名前が文字化けして見つからないという訳ではなさそうです
orz、ハズレか…

> PHPでこの機能が使えているということは FAIL や SKIP も自前で
> 登録し直して使うことが出来るようになるかも知れません
まあ既に動いているのなら行けるはずではあるが、本来は書くのはエグいはず
コピペで移植してしまえであれば、
src/regint.h:989 の辺りから定義をコピペして php_mbreegxをコンパイルしてしまえば
php_mbregexがonigurumaとのキメラになるが動けば使えるはず

まあ頑張ってちょ

ぶっちゃけ理解が全然追いついてないので明日またじっくり読ませて頂きますね
今日はありがとうございました

> なので、定義自体は存在してて、呼び出し部もある
> だから(*SKIP)(*FAIL)の文字列から検索出来てないだけ

ここが問題の核心ですね、どんなラスボスが潜んでいるのやら..

また規制のためこちらへ
2chb.net/r/mango/1715675838/334-335n

昨日のレス把握完了です、これからお返事書きます(時間かかるかもです)

phperですがjsp＋java案件に入りました
直近の課題として、phpとの差異に四苦八苦してます

まず大きな問題としては、今までほぼ手続き型のphpしか触っていなかったのでオブジェクト指向でのJavaに苦戦してること（今まではユーザー定義関数群を1ファイル内に記述して適宜各画面で読み込んでいたに過ぎず、継承やclass・フィールド・メソッドといった経験をしてこなかったこと）

次いで、jsp→サーブレットの仕組みや処理の流れを落とし込めていないこと。jspそのものはphpファイルのようにスクリプトを埋め込めることは理解しましたが、コンパイルや、そしてサーブレットに渡してゴニョゴニョするんやで❤の辺りから頭から煙出てます。

次いで、Javaとphpの記述の違いに悩んでる事。例として文字列の比較や、型宣言など。

諸先輩方はどんな風にして他言語をphp基準に身につけたか、そのほか叱咤激励あれば教えて欲しく投稿しました

ちなみに前スレからのonigurumaのやり取りは見させてもらっていてとても有益な内容のやり取りだと感じてます

その上で「このスレなら頼りになる人が居るぞ！」や「皆はどんな風にしてphpから他言語を学んでいったのか」という情報交換が出来そうなので投稿しました。

不躾で恐れ入りますが何卒宜しくお願い致します

あ、私の件はもう解決したと言って良い状態なのでお構いなく..
私より >>23 さんを優先してあげてください、ありがとうございました〜

コマンドラインに現在時刻を出力するプログラムで(Windows+cmd)

while(1){
echo date('H:i:s').PHP_EOL;
sleep(1);
}

これだと改行して延々と表示されます
改行せずに1行で更新し続けたいときはどうすればいいですか？
なんか制御文字入れたら出来たような気がするのですが忘れてしまいました

私は>23ですが、こんなのどうでしょう
コードベタ書きは書き込み制限あるので一部ホワイトスペース入れたりお茶濁してるので適宜変換したください

�@
while (1) {
echo "\r" . date('H:i:s');
sleep(1);
}


�A
while (1) {
echo date('H:i:s')."\r";
flush();
sleep(1);
}


やってる事はほぼ同じですが、お役に立てれば嬉しいです

>>26
確認できました！どうもありがとうございます
DELあたりが怪しいと0x08をどうにかしたら…
なんて思ってましたが見当違いだったようで(ﾉ∀`)

>27
解決できたようで良かったです！
もしJava経験あれば私>23なのでアドバイスください！笑

NGスレ06 にお返事を書いてましたが連投規制なのか続きを書けなくなりました
2chb.net/r/mango/1715675838/334-n

書けない間についに問題の核心部分を突き止められました！
原因は oniguruma で廃止された onig_init(); を php_mbregex.c で使っていたことでした
github.com/php/php-src/blob/84400eefbb6f09ca7de971f49a86ab26520dfff3/ext/mbstring/php_mbregex.c#L115

PHPを知らない私は PHP_MINIT_FUNCTION(mb_regex) の MINI の部分を見て

「これはバージョン番号が小さい(=古い) oniguruma を使うときのものだな、きっと」

と思ってしまったのが大間違いでした。ググったところ、この関数は
「モジュールがロードされたときに最初に呼び出される関数」だそうです.....(T_T)

ということで新しい初期化関数の onig_initialize() を使った書き方に直したところ、
(*FAIL) や (*SKIP) がPHP上で正常に動作しました

onig_initialize() ※ これは引数が２つ必要なので注意です
github.com/kkos/oniguruma/blob/f6723fd940b993b39b1535f71c8695867a5e92d1/doc/API.ja#L6

onig_initialize() 周りのコ-ドは oniguruma/sample/callout.c からそのままコピペしました
github.com/kkos/oniguruma/blob/f6723fd940b993b39b1535f71c8695867a5e92d1/sample/callout.c#L189

こんなことで2週間もスレを占領してしまってすみませんでした..
超優秀な方には感謝感謝です、他の方もありがとうございました！ とても勉強になりました！

良かったら>>23 さんにも教えてあげて下さい、がんばれ23さん！！！

EOLの意味を理解しているのか聞いてみたい

clsコマンドでもいけそう、以前のログ全部消えるけどｗ
linuxfan.info/clear-command-prompt

End Of Life

エターナル オオイタ ライフ

変数名ってなんでローマ字は駄目って言われるんですか？
日本人しか触らない日本のシステムなんだからわざわざ英語名にしなくても日本人全員が理解できるローマ字でいいと思うんですが
ましてやドメインに関わるものなら固有名詞に近いものまであるのにローマ字でなく英語にこだわる理由が分かりません
現場のリーダーに同じことを聞いたらローマ字だと問題あるかもしれないからと言われてそれ以上は聞けませんでした

大人になったらわかるよ

長い表記で更に人目でわかりにくいしデメリットしかなくない？

日本人なのになんで分かりにくいローマ字を使うのだ
分かりやすくするなら漢字と平仮名とカタカナを使いたまえ

ちなみにonigurumaはメタ文字として使う文字を好きに変えられるのだが
試しに \ の代わりに ゑ にしたらちゃんと動いたよ
日本語で書く正規表現が作れそうでwktk

>34
ローマ字記法（ヘボン式・日本式・訓令式）の事かな？結露から言うと、その命名規則にしてる現場もあるよ。特にレガシーな業務システム（2000年から2010年辺り）の現場で多い。例えばh o s y u U n y o（保守運用）とかs y a i n B a n g o u（社員番号）とか。

問題点と言えば、
・現場でしか使用されていない特殊な専門用語や業務用語を変数名にすると引き継いだプログラマーは初見で変数の意味を理解できない
・記述が長くなる
・ヘボン式や日本式の違いで誤記が発生する。例として社員なら　s h a i n、s y a i n など
・英語話者プログラマーが読めない
・エディタのコード補完機能が使えない。多くのエディタは汎用的な命名の予測変換や補完を行ってくれるため。

>34 一般的にプログラムはチームで書くことが多くて、「誰が見ても分かる」が原則。この「誰が見ても分かる」がポイントで、もし内輪だけで使うプログラムならローマ字表記でも良いと思う。一方で、プログラマーが入れ替わる現場や英 語話者の居るグローバルなチームならローマ字表記不可。

他の理由には、開発されたプログラムそのものも大概は英 語圏で作られている。その為変数や定数の命名もベースは英 語圏から発生していて、その命名は汎用的に使用できるようになってる。よって上記同様、ローマ字表記法は汎用的ではない。

最後の理由としてプログラムは様々な箇所で引用される。作成されたプログラムが信頼に足りる素晴らしい内容なら、多方面で引用され関数やメソッドやA P Iとして汎用される。そのため英 語話者が読んで意味が通じないならそれはプログラムとしては良くてもソースコ ー ドとして通じない。 こんなところでしょうかねー。早い話オープン ソースにしようものならローマ字表記法は絶対出来ないですしねw 逆に1人だけで使うプログラムとか、内輪だけの限られた世界でしか使用しないプログラムならローマ字表記でも良いと思いますよ。

一番最悪なのはローマ字でファイルやクラス設定して途中から名称変わったせいでどのクラス参照して良いんだかわからなくなるパターン

aiに聞いたほうがはやい

次回、

「ヘボン式至上主義者と訓令式至上主義者の仁義なきソース手直しバトル」

ご期待下さい

異常を ijo と ijou のどちらにするかも悩ましいですよ