orange @[email protected]

つまりらりおさんの例示で言うと

struct Sound {
channels: u8,
len: Duration,
repeat: bool,
waveform: Vec<u8>,
　metadata: Audiometadata, // ←こんな感じの構造にする場面の時にDataとかInfoみたいな単語がつく命名が出てくるかも＞＜
}

それで言うと、Sound構造体にメタデータ型へのハンドルがあるみたいな構造がオレンジ方式かも＞＜

それってつまり単一の型で表す(.net frameworkではそうなってる事が多い気がする)か、またはハンドルはハンドルでメタデータはメタデータで完全にバラバラの型を作りハンドルとメタデータの関係性の表現には型システムを使用しないって発想じゃん？＞＜

「複雑化を防ぐためにひとつの型が持つプロパティ等の数が極端に増えすぎないようにしたい」＆「ハンドルとメタデータの関係も型で表現したい」ってなるとオレンジ方式になる気がするというかそういう考え/場面でそうしてる＞＜

オレンジの事例の音楽そのものって、再生可能なオーディオデータのクラスで、生のデータ(を持つバイト列やストリームのクラス)や長さの情報やチャンネル数等は持ってるかも＞＜
でも、メタデータはメタデータであるので別って発想でそのクラスにベタに曲名プロパティとかアーティストプロパティみたいなのとかキーバリューなメタデータリスト等を直接置いたらごちゃっとしそうだから、ベタに置くのは避けたかも＞＜

Infoとかそれはメタ情報(？)であるって単語等を型名につけない文化圏、例えばオーディオプレイヤーアプリ作る時に、曲名とかの情報をどういう構成でどういう風に扱ってどう命名するのか謎＞＜
オレンジは曲クラスが曲名等情報クラスを持ってるみたいな構成にして、曲名等情報クラスの名前はInfoかなにか忘れたけどなんかそういう「これはメタ情報である」的な命名してたような記憶ある＞＜

x「『
o『
＞＜；

ていうか、Infoとかついてないのは「『そのもの』であって、『そのもの』では無くそれに関する情報のみしか持ってない物は例外的である(ので、Infoなりなんなりつけて注意喚起する)って、OOP的発想・・・？＞＜

オレンジはわりとHogeDataとかHogeInfo的な型名多用してるかも＞＜；
ハンドルを含むような物がHogeとしてあってそれとは別に同じ対象のハンドルを含まないものが必要な場合にはHogeInfoとか使うかも＞＜

このツイートの人、ビジネス上のパートナーをオンライン飲み会に誘いそう＞＜