orange @[email protected]

というか私がライブラリ作るときはアプリケーションの性質を想定せず「ライブラリ自体がどうあるべきか」を考えて作るので、その場合はプレイヤーはライブラリが単独で使い物になるレベルに到達するまでは手をつけない

アプリを作るときどこからライブラリにするかは場合によるのでなんとも言えないけど、基本的に音楽プレイヤーは “汎用的でない” ものなので、汎用的でないアプリケーションのために過度に「早すぎる抽象化」を施した実装をしたくないという気持ちがある

あと、そもそも音楽プレイヤーの文脈であれば「エントリとして選択できるものはだいたい決まっている」か「任意の key-value pairs を扱える」のどちらかの仕様であると思われるので、形式やファイルごとのメタデータの構造差はアプリケーション側のスキーマ設計で完全に吸収される

たぶんその辺りはアプリケーションかライブラリかで相当変わる

デザパタ自体は既に定まってしまった残念な言語仕様に対する workaround 的な面があるので仕方ないっちゃ仕方ないんだけど、「デザパタがあって素晴らしい！ デザパタを使いましょう！」みたいにさもデザパタが正の存在であるかのように喧伝する連中が鬱陶しすぎる (暴言)

ネットワーク経由のデータとかを扱いたい可能性を考えると -File よりは -Handle か -Uri かな

や、音楽プレイヤーの文脈で言うならさらに Sound は再生しながらストリーミング読み込みという感じになりそうなので、波形データの部分的読み出しやデコードを担当する SoundStream みたいな型を用意することになるだろうけど。

内部的にファイルハンドルとかファイルパスのみを持つようなやつを MusicHandle とか MusicFile と命名しといて、

MusicFile::meta(&mut self) -> Music
MusicFile::sound(&mut self) -> Sound

みたいな感じの API にするかなぁ。
&mut なのは std::fs::File は読み込みでも変更されるから

たぶんここで MusicMeta や MusicInfo という名前にはしない

だったら

struct Sound {
channels: u8,
len: Duration,
repeat: bool,
waveform: Vec<u8>,
}
struct Music {
title: Option<String>,
artist: Vec<String>,
// ...
}
という感じかなぁ (Sound あるいはそのハンドルが Music に含まれるかは要件次第)

channels とか len とか repeat がメタデータだと思ってたけど、曲のメタデータの話か