orange @[email protected]

「書き方によって速度が変わる」べきでは無いのであれば、プロパティでもメソッドでもメソッドのなんか名前の付け方がどう（？）でも変わるべきではないんだから、つまり「プロパティは軽くなければならない（？）けどメソッドは重くてもいい」みたいに考えることもおかしくない・・・？＞＜

？＞＜

賢くないからこその戒めであり枷かも＞＜
「（メンテめんどくさい；；　こんな目先しか考えなてない仕様にするんじゃなかった；；　次に何か作る時はちゃんと作ろう；；）」って＞＜

内向きと外への約束ってきっぱり分けて考えていれば自然にそうなるはず＞＜
動的型付け環境が「そんなもの好む人が本当にいるなんて信じられない！！！＞＜」って思うのも、「外への約束がそんな曖昧でいいの！？＞＜；　ていうか何も約束してないじゃん！？＞＜；」って所かも＞＜

将来を見越してというか、「公開してしまった約束は死ぬまで守れ！！！！！＞＜＃ 」ってオレンジが普段いろんな話題で言いまくってることそのまんまかも＞＜
約束を死ぬまで守るために隠蔽して、あとでなにかあってもエミュレートして互換性を保てるようにする＞＜
互換性を保てなくなったら「私は目先のことしか考えていませんでした」って札を下げて土下座して謝る＞＜

Java嫌いな点もう一個あった！＞＜； 符号無し整数型が無い事＞＜

ていうか、プロパティでは無い単なる習慣でしかないgetter setterって、存在意義謎だし、プロパティが無かった事がオレンジがストレスすぎてJavaを本格的には使えなかった2大理由のひとつ＞＜
（もうひとつの理由は演算子のオーバーロードが無くてBigIntegerみたいなのが愉快な事になってしまうこと＞＜）

Delphi / C# 方式プロパティが好きな人、呼ばれる側が賢くあってほしいみたいな発想があるのかもしれない＞＜（サンプル数1）

オレンジの場合で、（Delphi / C# での）プロパティが返すものを予め準備するか否かはケースバイケースで、例えば最初に呼ばれた時に用意して、次回からはキャッシュしたやつを返す、再計算が必要な時にも用意したり用意しなかったりする
みたいに、呼ばれる側が自動でいい感じにいろいろしたい時は、むしろプロパティじゃなきゃ気持ち悪い＞＜
手動でそういうの制御できるようにもしたい時には設定用のプロパティを作ったり、明示的に準備させるメソッドを用意したりする＞＜

オレンジ的には隠蔽するんだから、重いかもしれない可能性も含めて隠蔽される（隠蔽されてしまうけどそういうもの）みたいな考えだった＞＜

x平均tじゃなく
o平均じゃなく