将来を見越してというか、「公開してしまった約束は死ぬまで守れ！！！！！＞＜＃ 」ってオレンジが普段いろんな話題で言いまくってることそのまんまかも＞＜
約束を死ぬまで守るために隠蔽して、あとでなにかあってもエミュレートして互換性を保てるようにする＞＜
互換性を保てなくなったら「私は目先のことしか考えていませんでした」って札を下げて土下座して謝る＞＜
orange
さんがブースト
orange
さんがブースト
https://mstdn.maud.io/@orumin/102455097216663974
私は15年前に自我がなかったのでよく知らないけど、構文の一貫性とか、後から値のセットで validation を付けたくなった場合などのことを考えると、その可能性のあるものは最初から関数の getter / setter を用意しておくべきだろうという立場
orange
さんがブースト
そう，昔 Java で論争されてたときも，validation とかのために，あとカプセル化の観点から setter/getter は全てのメンバに付けるべきでメンバは全て private でやれという話があって，これに対して，絶対 setter/getter を付けるべきとかじゃなくて，フィールド外出しでいいやつは setter/getter つける必要ないし，setter/getter が本当に必要なときにはもうちょっと気の利いた命名できる場合がほとんどでしょ，という反論があって，私は後者の立場だった
Java嫌いな点もう一個あった！＞＜； 符号無し整数型が無い事＞＜
ていうか、プロパティでは無い単なる習慣でしかないgetter setterって、存在意義謎だし、プロパティが無かった事がオレンジがストレスすぎてJavaを本格的には使えなかった2大理由のひとつ＞＜
（もうひとつの理由は演算子のオーバーロードが無くてBigIntegerみたいなのが愉快な事になってしまうこと＞＜）
Delphi / C# 方式プロパティが好きな人、呼ばれる側が賢くあってほしいみたいな発想があるのかもしれない＞＜（サンプル数1）
オレンジの場合で、（Delphi / C# での）プロパティが返すものを予め準備するか否かはケースバイケースで、例えば最初に呼ばれた時に用意して、次回からはキャッシュしたやつを返す、再計算が必要な時にも用意したり用意しなかったりする
みたいに、呼ばれる側が自動でいい感じにいろいろしたい時は、むしろプロパティじゃなきゃ気持ち悪い＞＜
手動でそういうの制御できるようにもしたい時には設定用のプロパティを作ったり、明示的に準備させるメソッドを用意したりする＞＜
オレンジ的には隠蔽するんだから、重いかもしれない可能性も含めて隠蔽される（隠蔽されてしまうけどそういうもの）みたいな考えだった＞＜
orange
さんがブースト
そういうのを含めてストレージの隠蔽をするために getter, setter を定義するのでしょう。じゃなかったらフィールド外出しでいい
orange
さんがブースト
あれはインデクサ、または引数付きプロパティ
orange
さんがブースト
orange
さんがブースト
Dictionary をストレージとする getter はあります。例えば JSON を辞書に変換したものをバックに持ち、それが持っているであろうフィールドをメソッドとして提供するなどが考えられます。裏側を動的なデータ構造にしつつ、メソッドとして提供することはあるかと
orange
さんがブースト
C# の文脈だと
public string this[string key] {
return this.dict[key];
}
が存在するので別名を付けたくないモチベーションはある
表記ゆれが＞＜；
平均tじゃなく最大値、最小値だってそうだよね＞＜
「そういうの一切プロパティにするな」ってそれプロパティ畑（？）の人っぽくない＞＜（プロパティー畑（？）であるDelphiが好きな人です＞＜）
例えば平均値を返すプロパティは存在していいのかみたいな話・・・？＞＜（「呼ばれてから平均を調べる可能性があるならプロパティにして欲しくない」みたいな話かも？＞＜）
そういう話じゃなく、実際の処理が重いかどうか、場合によっては予め返すものを用意してるか否かがみたいなのが不安なのが問題って話じゃないの・・・？＞＜
- ＠orange_in_space
2017年 4月に登録
