><https://twitter.com/orange_in_spacehttps://pawoo.net/@orange_in_space
https://mstdn.maud.io/@orumin/102455097216663974私は15年前に自我がなかったのでよく知らないけど、構文の一貫性とか、後から値のセットで validation を付けたくなった場合などのことを考えると、その可能性のあるものは最初から関数の getter / setter を用意しておくべきだろうという立場
そう,昔 Java で論争されてたときも,validation とかのために,あとカプセル化の観点から setter/getter は全てのメンバに付けるべきでメンバは全て private でやれという話があって,これに対して,絶対 setter/getter を付けるべきとかじゃなくて,フィールド外出しでいいやつは setter/getter つける必要ないし,setter/getter が本当に必要なときにはもうちょっと気の利いた命名できる場合がほとんどでしょ,という反論があって,私は後者の立場だった
Java嫌いな点もう一個あった!><; 符号無し整数型が無い事><
ていうか、プロパティでは無い単なる習慣でしかないgetter setterって、存在意義謎だし、プロパティが無かった事がオレンジがストレスすぎてJavaを本格的には使えなかった2大理由のひとつ><(もうひとつの理由は演算子のオーバーロードが無くてBigIntegerみたいなのが愉快な事になってしまうこと><)
Delphi / C# 方式プロパティが好きな人、呼ばれる側が賢くあってほしいみたいな発想があるのかもしれない><(サンプル数1)
オレンジの場合で、(Delphi / C# での)プロパティが返すものを予め準備するか否かはケースバイケースで、例えば最初に呼ばれた時に用意して、次回からはキャッシュしたやつを返す、再計算が必要な時にも用意したり用意しなかったりするみたいに、呼ばれる側が自動でいい感じにいろいろしたい時は、むしろプロパティじゃなきゃ気持ち悪い><手動でそういうの制御できるようにもしたい時には設定用のプロパティを作ったり、明示的に準備させるメソッドを用意したりする><
オレンジ的には隠蔽するんだから、重いかもしれない可能性も含めて隠蔽される(隠蔽されてしまうけどそういうもの)みたいな考えだった><
そういうのを含めてストレージの隠蔽をするために getter, setter を定義するのでしょう。じゃなかったらフィールド外出しでいい
あれはインデクサ、または引数付きプロパティ
もちろん、その処理自体は O(1) であることが期待されるし、そうでない構造をバックに持つべきではないですが
Dictionary をストレージとする getter はあります。例えば JSON を辞書に変換したものをバックに持ち、それが持っているであろうフィールドをメソッドとして提供するなどが考えられます。裏側を動的なデータ構造にしつつ、メソッドとして提供することはあるかと
x平均tじゃなくo平均じゃなく
C# の文脈だとpublic string this[string key] { return this.dict[key];}が存在するので別名を付けたくないモチベーションはある
表記ゆれが><;
平均tじゃなく最大値、最小値だってそうだよね><「そういうの一切プロパティにするな」ってそれプロパティ畑(?)の人っぽくない><(プロパティー畑(?)であるDelphiが好きな人です><)
例えば平均値を返すプロパティは存在していいのかみたいな話・・・?><(「呼ばれてから平均を調べる可能性があるならプロパティにして欲しくない」みたいな話かも?><)
そういう話じゃなく、実際の処理が重いかどうか、場合によっては予め返すものを用意してるか否かがみたいなのが不安なのが問題って話じゃないの・・・?><
さっきも書いたけどそういうのは lookup とかそういう別名がちゃんと付けられるはずで,基本的に setter/getter ってただのフィールドアクセスだと思ってたのだけれども
それ getter ではなくない
100倍遅いのはデータ構造が悪いけど、でも getter の中身がフィールドアクセスとは限らない、例えば Dictionary のルックアップなこともあるでしょ?
思考の /dev/null