JavaScriptには「Date」という時刻を表すためのオブジェクトがありますが、タイムゾーンの扱いが難しかったり、APIが直感的ではなかったりするなどの問題がありました。こうした問題を解決した新たな時刻表示用オブジェクト「Temporal」が登場し、ブラウザへの実装作業が進められています。
また、TemporalではAPIの混乱しがちな仕様が修正されています。Dateでは月を設定したり表示したりする際、1月を「0」とし、12月を「11」とする仕様でしたが、Temporalでは見た目通り1月を「1」、12月を「12」として表示・設定可能です。
その他、Temporalオブジェクトは全て変更不可のため、予期せぬ副作用によるバグが発生しなくなりました。
⇧「変更不可」ということは「イミュータブル（immutable）」なオブジェクトとして扱えるということですか。
配列とかのインデックスなんかは、「0」始まりだったり「1」始まりだったり、どっちだっけとハッキリしないことが多くて困りますが、「月」が「0」始まりは人間からしてみたら違和感でしか無かったと思うのだけど、既存のシステムの改修とか影響範囲が大きそうではありますな...
Rubyのクラス名とクラスファイル名の命名規則の関係性が知りたいんだが...
前回に引き続き、「Ruby」の話になるのですが、
のどちらによる縛りなのかが分からないのだけど、「Oxidized」の「拡張modelクラス」の動作確認で、
- クラス名
- クラスファイル名
で「命名」のフォーマットを合わせないとエラーになるという事象に遭遇した。
どういうことかというと、
| クラスファイル名 | |||
|---|---|---|---|
| アンダースコアあり | アンダースコアなし | ||
| クラス名 | アンダースコアあり | ✅ | ✖ |
| アンダースコアなし | ✖ | ✅ | |
⇧ どちらかに統一すると、エラーにならないで済むのだが、片方だけ「アンダースコア」付きの名前だとエラーになるという...
意味が分からな過ぎて、最早、笑うしかないんだが...
まぁ、「Ruby」のドキュメントにこのあたりの「命名規則」についての話が見当たらないので、
のどちらが影響しているのかが分からないのだが、
『我々はその謎を解き明かすべくジャングルの奥地へと向かった』のであった...
⇧「Oxidized」のissueによると、「ハイフン」は確実に利用できないと、「Oxidized」を開発・メンテナンスしている方が仰っておりました。
Wikipediaで「Naming convention（programing）」が公開されていたので、確認してみたのだが、2025年1月31日（金）時点では「Ruby」についての記載が無かった...
頑張って広大なネットの情報の海を漁っていたところ、
⇧ stackoverflowによると、「Ruby」に限った話であれば、特に「命名規則」のようなものは無いらしい、と仰っておられる方がおりました。
ということは、stackoverflowの回答が正しいと仮定すると、
- クラス名
- クラスファイル名
の「命名規則」を統一しないことでエラーになるという事象は、「Oxidized」による縛りっぽいということになりますと...
とは言え、「Oxidized」は「Ruby」製のライブラリなので、「Oxidized」の実装で「Ruby」の標準ライブラリを活用して「命名規則」を制御しているのかも知れないが、一般的に期待されている使い方を「Oxidized」がしているのかが分らんので、利用者側からしたらどうしようもないのだが、裏切られたというか、罠を仕掛けられた気分にはなる...
とりあえず、
⇧ stackoverflowで推奨されている「Ruby Style Guide」を確認した限りでは、
| No | 項目 | Ruby Style Guideの推奨する命名規則 |
|---|---|---|
| 1 | クラス名 | キャメルケース（camel case） |
| 2 | ファイル名 | スネークケース（snake case） |
とあるのだが...
失望感と徒労感とで精神的に参ることこの上ないのだが、「Oxidized」は我が道を行くといった感じで、「Ruby Style Guide」の推奨する「命名規則」をガン無視していることは何となく分かった。
しかしながら、何故に、「Oxidized」では「Ruby Style Guide」の推奨する「命名規則」を無視するという行動に走ったのかという意図は全くもって分らんのだが...
情報が錯綜し過ぎていて、五里霧中といった状態で正しい情報が何なのかを判断する術が無いのだが、「Ruby Style Guide」に準じるのがセオリーであるとするのが一般的であると仮定するのであれば、
- クラス名
- キャメルケース（camel case）
- ファイル名（クラスファイル名も含むと思われる）
- スネークケース（snake case）
とするのが普通であって、「Oxidized」の流儀が異端であり「マイノリティ（Minority）」であるということになるんかね？
「Oxidized」がどういった思想でいるのかは知る術が無いので理解することは到底不可能なのだが、特有の「命名規則」を設けているのならば、「Oxidized」内部の人間だけにとって周知な情報であるのは無意味な気がするので「Oxidized」のドキュメントに「命名規則」について明記するようにしておいて欲しいところだが...
公開しているライブラリである以上、内輪に閉じた世界でだけ通じる情報になってしまっていると、問い合わせが増えるだけだから、巡り巡って自分たちのタスクを増やすことになってしまう気がするんですがね...
どちらにしろ、公式の「Ruby」のドキュメントで、
- クラス名
- クラスファイル名
の「命名規則」の関係性については言及して欲しい気はする...
一応、Wikipediaの情報が正しいのであれば、
クラス名はアルファベットの大文字から始めるという制約があり、日本語などの非ASCII文字のみでクラス名を定義する方法がない。
⇧ とあるので、公式のドキュメントの方で「Ruby」に関わる「命名規則」は体系的に整理して記載しておいて欲しい...
⇧ 内部的に「C言語」を利用しているっぽいので、「C言語」に精通している人でないと読解できる気がしませんしな...
ちなみに、「メモリ安全性」の高いプログラミング言語への移行の話が出て1年ぐらいになろうとしているのだが、
アメリカ・ホワイトハウスの国家サイバー局長室(ONCD)が、開発者に対し、C++やC言語といったプログラミング言語からRustやC#などのメモリ安全性が確保されたプログラミング言語への移行を勧めています。
ホワイトハウスが開発者に対しC++やC言語からRustやJavaなどのメモリ安全性に優れたプログラミング言語への移行を勧める - GIGAZINE
ホワイトハウスはセキュリティの強化のために2024年2月26日にメモリ安全性が確保されたプログラミング言語の仕様を推奨する声明を発表しました。なお、アメリカ国家安全保障局(NSA)はメモリ安全なプログラミング言語としてRustやC#、Go、Java、Ruby、Swiftを(PDFファイル)挙げています。
ホワイトハウスが開発者に対しC++やC言語からRustやJavaなどのメモリ安全性に優れたプログラミング言語への移行を勧める - GIGAZINE
⇧ 内部で利用されている「C言語」はノーカウントらしい...
まぁ、「Python」とかでもパフォーマンスを求める場合は「Cython」とかで「C言語」の実装を導入していく話があるらしいので...
⇧ コメントの内容が真実であるならば、「Python」と「C言語」の癒着が半端ない...ズブズブやんけ...
話が脱線しましたが、まぁ、「Oxidized」の他に代替できるものが無さそうなので消去法で致し方なく利用していることから「Ruby」を利用せざるを得ないのですが、公式のドキュメントの情報が少なくて「暗黙知」の多過ぎる「Ruby」を積極的に利用しようという気になることは無さそうですな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
