| |
awaitjs文とhidemaru.notifyAwaitメソッドの追加についてですが、
これはかなりアンチパターンになる懸念があります。
特に、秀丸のマクロスロット枠が1つしかないため、悪影響が大きくなっていくと思
います。
JavaScriptの非同期処理を活用することで、
限られた「1つのマクロスロット枠」を「時間的に占有することなく」、
事実上の並列処理に近いことが可能となっています。
しかし、「awaitjs文やhidemaru.notifyAwait」のような単純な道具が存在すると、
(これが安易にhideamruGlobalをJavaScriptで使用するベストプラクティスだと誤解
される恐れもあり)
その結果、マクロスロット枠が数秒から十数秒間占有するマクロを制作する可能性が
高まると思います。
(配布物だけではなく、個々人が制作するものもそうです)
このような状況では、非同期から一瞬同期を呼ぶ他のマクロの処理が崩壊しやすくな
るのではないでしょうか。
「マクロスロット枠が1つしかない」という点は、秀丸の大きな弱点であり、
今さら変更することは難しいと思いますが、
この弱点を軽減する方向性でJavaScriptの非同期はうまく機能してきました。
本来、「安易にマクロ枠を巻き込んでwaitブロックする」ような行為は避けるべきで
す。
そんなことをすれば、「UIや編集ペイン」が「wait中」機能しなくなります。
何らかの処理が完了した際に、どうしてもマクロ枠の機能が一瞬必要であれば
postExecMemoryやpostExecFileを実行するという過渡期の形は、
hidemaruGlobalのネイティブ関数が増えるに従って[同期への手戻り＝マクロ枠の占
領]が減少し、
マクロ枠を必要としなくなる、ある意味理想的な形でした。
しかし、awaitjs文とhidemaru.notifyAwaitメソッド みたいなのが出てくると
結構暗雲垂れ込むと思います。
(javascriptがず〜っと決してユーザーに提供しないほどの「実行枠１つ」という形
態ではアンチパターンな機能です)
|
|