11日目に、クジラ飛行机さまによる「なでしこで手軽に使えるライブラリを作るには?」
の中で、過去にワタクシが作った「旧暦変換プラグイン」を紹介いただきました!
これは、なでしこ1の旧暦変換とは異なり、歴史上使用されていた実際の暦と合うよう文献データを元に西暦から旧暦、和暦への変換、和暦から西暦への変換などを行うもので、遠いムカシに思いを馳せる人以外にはあまり需要のないシロモノですが、一応2099年までの、なでしこv1相当の旧暦と、二十四節気や七十二候、干支、九星、六曜などの歴註も取得出来るようになっていて、現代の暦を作る場合にも役立つかもしれないものになっています。
ところが、これを機にちょっとなでしこを最新版にしておきましょうかねーと思ったところ、なんとエラーが出て全く動かないことが分かりました😱️
なでしこがバージョンアップしたら、過去作が動かなくなることありがち💧️
普通のプログラムなら、旧バージョンのまま使い続けてもいいけど、プラグイン(ライブラリ)の場合は、新しく作るプログラムにも取り込んで使うものだから、直さなければなりませんねえ。
とりあえず初っ端から「修正ユリウス日取得」がNaNになっちゃうぅ~。
修正ユリウス日が取得できないと、なにもできないんですよよよ~ん😭️
旧暦変換プラグインの修正
いつから動かなくなったのか
- v3.4.5までは問題なく動いている。
- v3.4.9で
[実行時エラー]main(345行目): ReferenceError: await is not definedのエラー。 - v3.4.11からはエラーは出さずに
[object Promise]が返ってくるようになっている。
今は、v3.7.10の時代ですから、こりゃまた結構前からでしたねぇ~😅
連文?
ちなみに345行目は何かというと、グレゴリオ暦で修正ユリウス日を取得する命令の中の、
日付は日付を英数半角変換して、「/」を「/」に置換。
これは、修正ユリウス日を取得する際の日付が全角文字でも大丈夫なように置換したってだけのもので、英数半角変換しただけじゃ「/」が半角にならないようだったので、このような連文になっています。
なでしこには第一引数を省略した場合に、自動的に前の関数の返り値「それ」を補うという素敵仕様があり、さらに「~して」でつないでいくと、前の命令の結果を引き継ぎながら次々に命令を実行していける連文の機能があって、より日本語っぽい記述ができるようになっているんです❣️
v3.4.11の修正内容に、イベント内に連文を記述した時に非同期構文のエラーが出る問題を修正と、連文にかかわるのがあるので、やっぱりこの連文があやしい?
でも、この連文の記述自体は問題なく通るようです。
日付は「2025/12/01」。
日付は日付を英数半角変換して、「/」を「/」に置換。
日付を表示。# 2025/12/01
もちろん関数の中に入れて使っても、取り込んで使ってもだいじょぶでした。
イベント関係ないしね。
修正ユリウス日取得G
Gは何かっていうと、グレゴリオ暦での修正ユリウス日取得です。
なでしこv1にある修正ユリウス日取得はコレで、現代の暦はグレゴリオ暦なので、現在を生きる人間にとってはこれで十分。
しかし、遠い過去に思いを馳せたい人にとっては十分ではありません。
グレゴリオ暦が採用されるのは1582/10/15のことで、それ以前はユリウス暦がつかわれていました。グレゴリオ暦とユリウス暦では修正ユリウス日を取得するための計算式が異なります。
この起点となる「1582/10/15」の修正ユリウス日を定数として「グレゴリオ暦開始」に定める、初っ端の部分からしてエラーになってるんです😭️
定数 グレゴリオ暦開始=「1582/10/15」の修正ユリウス日取得G。
グレゴリオ暦開始を表示。# -100840
●(日付を|日付の|日付で|日付から)修正ユリウス日取得G
日付は日付を英数半角変換して、「/」を「/」に置換。
日付を「/」で区切る。
変数 [y,m,d]=それ。
もし、y=0ならば、空で戻る。
もし、y<0ならば、y=y+1。
もし、m≦2ならば、
y=y-1。m=m+12。
ここまで。
(FLOOR(365.25*y))+FLOOR(y/400)-FLOOR(y/100)+FLOOR(30.59*(m-2))+d-678912で戻る。
ここまで。
あれれ? ちゃんとでる!
そして、修正ユリウス日取得Jも問題ありませんよ。
定数 元号未制定時期=「701/05/02」の修正ユリウス日取得J。
元号未制定時期を表示。# -422781
# 西暦を全てユリウス暦として修正ユリウス日を取得する。
●(日付を|日付の|日付で|日付から)修正ユリウス日取得J
日付は日付を英数半角変換して、「/」を「/」に置換。
日付を「/」で区切る。
変数 [y,m,d]=それ。
もし、y=0ならば、空で戻る。
もし、y<0ならば、y=y+1。
もし、m≦2ならば、
y=y-1。m=m+12。
ここまで。
(FLOOR(365.25*y))+FLOOR(30.59*(m-2))+d-678914で戻る。
ここまで。
どゆこと?!
修正ユリウス日取得
与えられた日付がグレゴリオ暦開始よりも前か後かで、JかGかを振り分けるだけのお仕事です。
改めてみると、頭悪そう過ぎるコードになってますが、そこは気にしないでください。
ともかくコレを加えたら、おぶじぇくとぷろみすです。
おっかしいですよねー? まだ使っているのは修正ユリウス日取得Gだけで、修正ユリウス日取得は通っていないんですよ?
定数 グレゴリオ暦開始=「1582/10/15」の修正ユリウス日取得G。
グレゴリオ暦開始を表示。# [object Promise]
●(日付を|日付の|日付で|日付から)修正ユリウス日取得
日付は日付を英数半角変換して、「/」を「/」に置換。
日付を「/」で区切る。変数 y=それ[0]。
もし、y=0ならば、空で戻る。
変数 グレゴリオ暦=いいえ。
もし、グレゴリオ暦開始≦(日付の修正ユリウス日取得G)ならば、グレゴリオ暦=はい。
もし、グレゴリオ暦=はいならば、
日付の修正ユリウス日取得Gで戻る。
違えば、もし、グレゴリオ暦=いいえならば、
日付の修正ユリウス日取得Jで戻る。
違えば、
空で戻る。
ここまで。
ここまで。
●(日付を|日付の|日付で|日付から)修正ユリウス日取得G
日付は日付を英数半角変換して、「/」を「/」に置換。
日付を「/」で区切る。
変数 [y,m,d]=それ。
もし、y=0ならば、空で戻る。
もし、y<0ならば、y=y+1。
もし、m≦2ならば、
y=y-1。m=m+12。
ここまで。
(FLOOR(365.25*y))+FLOOR(y/400)-FLOOR(y/100)+FLOOR(30.59*(m-2))+d-678912で戻る。
ここまで。
順番?!
なんか知らんが、修正ユリウス日取得Gと修正ユリウス日取得の順番を入れ替えたら動いた?!
どうゆうことなんです? 関数って、順番が変わったら動いたり動かなくなったりするとかそうゆうものじゃなくないですか?🤔️
定数 グレゴリオ暦開始=「1582/10/15」の修正ユリウス日取得G。
グレゴリオ暦開始を表示。# -100840
●(日付を|日付の|日付で|日付から)修正ユリウス日取得G
日付は日付を英数半角変換して、「/」を「/」に置換。
日付を「/」で区切る。
変数 [y,m,d]=それ。
もし、y=0ならば、空で戻る。
もし、y<0ならば、y=y+1。
もし、m≦2ならば、
y=y-1。m=m+12。
ここまで。
(FLOOR(365.25*y))+FLOOR(y/400)-FLOOR(y/100)+FLOOR(30.59*(m-2))+d-678912で戻る。
ここまで。
●(日付を|日付の|日付で|日付から)修正ユリウス日取得
日付は日付を英数半角変換して、「/」を「/」に置換。
日付を「/」で区切る。変数 y=それ[0]。
もし、y=0ならば、空で戻る。
変数 グレゴリオ暦=いいえ。
もし、グレゴリオ暦開始≦(日付の修正ユリウス日取得G)ならば、グレゴリオ暦=はい。
もし、グレゴリオ暦=はいならば、
日付の修正ユリウス日取得Gで戻る。
違えば、もし、グレゴリオ暦=いいえならば、
日付の修正ユリウス日取得Jで戻る。
違えば、
空で戻る。
ここまで。
ここまで。
そして、大本の旧暦変換プラグインの中で、このように修正ユリウス日取得の順序を入れ替えてみましたが、やはりダメでした。
やっぱり連文?!
そんな中、修正ユリウス日取得の冒頭の三行は、必ず通るGでもJでも行われているんだから不要じゃないですか? と消してみたところ、なんと修正ユリウス日取得が先にあった場合でも動くようになりました。
大本の旧暦変換プラグインで、この部分だけ修正してもダメだったのですが、やはり連文に原因があるんじゃ?! と思い、すべて連文を使わず、
日付は日付を英数半角変換。
日付は「/」を「/」に置換。
としたところ、動きました。ええぇ~💧️
大本の旧暦変換プラグインで、引数に西暦を取っている命令すべてにこのくだりがあります。そのすべてをこのように、連文を使わない形に置換したところ直りました!
最初に連文疑ったのに、とんだ回り道をしてしまったぜ😓️
これで全部直ったかと思いきや、和暦西暦変換が出来ず、
元号年=元号年の「年」を空に置換して、それを英数半角変換。
もエラーになっていました。
やはりこれも連文ですね。
ほかにもまだあるかなー?
連文すべてがダメってわけでもないようなんですが・・・
なおった?
とりあえず、ちょっとお試しした限りではもう大丈夫そう?
一応直りましたが、ナゾ解明! とはいきませんでした。
そうそう、関数の順番で、動いたり動かなかったりするナゾ現象もありますしね!
連文のナゾ現象
こんなかんじです
Aを表示。
Bを表示。
●A
a=30に5を足して2を掛ける。
「A関数内:」&aを表示。
aを戻す。
ここまで。
●B
b=30に5を足して2を掛ける。
「B関数内:」&bを表示。
bを戻す。
ここまで。
結果はこうなります。
A関数内:70
70
[object Promise]
B関数内:70
Aは正常ですがBは関数内よりも先にobject Promiseが返ってるっぽい?
そしてこれは、「=」または「は」で代入した時に発生し、A、Bのどちらかでも、代入文を用いて代入した場合には大丈夫でした。
けつろん
だれか賢い人たすけて!w
連文は安心して使えないと困りますよねぇ~。