Open lriki opened 2 years ago
Lumino の FileSystem の目的の半分は、アプリ開発でよく使用するユーティリティの提供。 エンコーディング指定のテキストファイル読み書きや、パターンマッチは std::filesystem には無いユーティリティである。
単純なファイルのコピーや削除であれば std::filesystem と機能的な差は無い。 ただし、短いパスの場合は Path 用の SSO が効くので、ln::String, ln::Path と併用する場合、全体的には std::filesystem より高速に動作する。
Lumino の多くの API は発生しうるエラーをロジックエラー（ユーザーではなくプログラマが悪い）と考え、assertion または例外(選択可能) を投げて通知する。 基本方針は「プログラムを止める」である。
しかしファイル操作（に限らずIO関係はそうだが）はどうしてもプログラムの外部の要素が絡むので、ユーザーエラーは避けられない。 他のラフに使える API と同じような感覚で使うべきではないだろう。
現状、システムに近いネイティブアプリでの導入がある。 ここではスクリプト言語のような感覚で使えてしまう API はかえって危険だろう。
そもそも FileSystem が必要なのか？
Lumino の FileSystem の目的の半分は、アプリ開発でよく使用するユーティリティの提供。 エンコーディング指定のテキストファイル読み書きや、パターンマッチは std::filesystem には無いユーティリティである。
単純なファイルのコピーや削除であれば std::filesystem と機能的な差は無い。 ただし、短いパスの場合は Path 用の SSO が効くので、ln::String, ln::Path と併用する場合、全体的には std::filesystem より高速に動作する。
動機
Lumino の多くの API は発生しうるエラーをロジックエラー（ユーザーではなくプログラマが悪い）と考え、assertion または例外(選択可能) を投げて通知する。 基本方針は「プログラムを止める」である。
しかしファイル操作（に限らずIO関係はそうだが）はどうしてもプログラムの外部の要素が絡むので、ユーザーエラーは避けられない。 他のラフに使える API と同じような感覚で使うべきではないだろう。
現状、システムに近いネイティブアプリでの導入がある。 ここではスクリプト言語のような感覚で使えてしまう API はかえって危険だろう。