警察学校教官 訓練に本物のナイフ 新人を誤って刺す 岡山 | NHKニュース
https://www3.nhk.or.jp/news/html/20190717/k10011995331000.html
警察学校教官 訓練に本物のナイフ 新人を誤って刺す 岡山 | NHKニュース
https://www3.nhk.or.jp/news/html/20190717/k10011995331000.html
This account is not set to public on notestock.
これは単なる正論ですが、コストは文法や命名を介した暗黙の了解にするよりも文書化する方が望ましいです
後からアクセス制限をかけることが絶対にないと確信・断言できるメンバ変数なら外出ししてもいいと思うけど、ライブラリでそういうのってなかなかないのではと思う
public メンバーとして、あとでバリデーション追加しようみたいな案件に対応できないから最初から getter, setter にしておけ、が OOP 的隠蔽 way だと思ってる
ちゃーしゅーねこさんがラーメン食べたらチャーシュー共食いになるんじゃないの
そう，昔 Java で論争されてたときも，validation とかのために，あとカプセル化の観点から setter/getter は全てのメンバに付けるべきでメンバは全て private でやれという話があって，これに対して，絶対 setter/getter を付けるべきとかじゃなくて，フィールド外出しでいいやつは setter/getter つける必要ないし，setter/getter が本当に必要なときにはもうちょっと気の利いた命名できる場合がほとんどでしょ，という反論があって，私は後者の立場だった
フィールド外出しだと mutability の制御とか validation とかかけられないことがあるから、そのために getter と setter が用意されるものだと思っていた (C++er 並感)
15 年ぐらい前に Java 界隈で不要かどうか論争されてた setter/getter のやつ
私がとらえてる setter/getter はまさしくそのフィールド外出しでいいじゃん，と言われる場合の謎のメソッドのことだと思ってた
僕の言う getter は GetHoge であり Hoge {get;} だよ、同義だよ
ミズタマリコネクターが言ってるgetter/setterはC#でプロパティとは別に作るGet***/Set***であるという話っぽい?
ただ getter が () => T で setter が (value: V) => void であるべきというのに基くとgetterではない
そういうのを含めてストレージの隠蔽をするために getter, setter を定義するのでしょう。じゃなかったらフィールド外出しでいい
プロパティとほぼ同等なのはそうだけどえーそれも getter って言うんですか……になってる
This account is not set to public on notestock.
@orumin {"a":1} に対して、 GetA を提供するという意味で、 Find("a") を提供するという意味ではありません
で，私はそれの話をしてたので，さっき言うたとおり C# での話と私が言ってる話が文脈ズレてそう
Java とかで言う getter のことがたぶん C# のプロパティだと思うんだけど
This account is not set to public on notestock.
もちろん、その処理自体は O(1) であることが期待されるし、そうでない構造をバックに持つべきではないですが
例えば BTreeDictionary<K, V> を作ったとして、 btdict["Foo"] とするのは自然じゃない? みたいな (書いてて話がズレてる気がしてきました)
Dictionary をストレージとする getter はあります。例えば JSON を辞書に変換したものをバックに持ち、それが持っているであろうフィールドをメソッドとして提供するなどが考えられます。裏側を動的なデータ構造にしつつ、メソッドとして提供することはあるかと
なんか OOP 一般で言われる setter/getter の話と C# で言われる setter/getter の話は微妙に文脈が違っててそれが混ざってるのかもしれない
C# の文脈だと
public string this[string key] {
return this.dict[key];
}
が存在するので別名を付けたくないモチベーションはある
さっきも書いたけどそういうのは lookup とかそういう別名がちゃんと付けられるはずで，基本的に setter/getter ってただのフィールドアクセスだと思ってたのだけれども
100倍遅いのはデータ構造が悪いけど、でも getter の中身がフィールドアクセスとは限らない、例えば Dictionary のルックアップなこともあるでしょ？
@akahana そんなん自分で決めりゃいいんだよ。自分が動いてる方向を前ってことにしちまえば後退も前向きな逃避ってことでいいじゃん
@akahana 別に目的地を決める必要なんてないでしょ。好きにやりたいことやってけばいいじゃん
This account is not set to public on notestock.
kernel って単一のクソデカいクラスみたいなもんだな，と思いながら kernel の内部状態を増やしたり消したりいじったりしてブッ壊してる
public readonly なメンバつくりたくなる気持ちはわかる
そういうユーティリティメソッドは良いけど，getter が getter としてしか命名できないようなメソッドをわざわざ手動で実装するようになったらちょっと考えたほうがいいんじゃないかなという気持ち
そういうのは普通クラスが持つデータの中から特定のデータを検索したりするメソッドとしてたとえば find() とかみたいな名前になるはずだから getter になはらんのでは
getterはきちんと実装したら便利だ。
クラスの中にある何かのArrayListから必要なものを引っ張ってくるとかを想定した時、a=b.mottekoi("hoge")みたいな実装ができたら見た目にも良いしオブジェクト指向的にも分かりよい
getter, setter が必要か、わからないから必要なのであって、そういう意味で自動実装プロパティというのは正解
単純に代入するだけの挙動の setter や単純に値を読み取るだけの getter はむしろ不要だろと思っています（Java のように言語だったり，あるいはプロジェクトでコーディングルールが決まってるのならその限りではない
setter 以前に，a.b = f() とかしたければ a.f() になるように実装すべきでは，という話ですね
確かに、Kotlinならsetterでも定義しろになるのは分かる。
しかしこんなことのためにsetter付けるべきなのか迷うところだ
こういうとき wandbox で PoC とか書くと伝わりやすくて便利だけど Swift あるのに Kotlin ないのか
クラスのメンバを変更する挙動ならメンバ関数とかとして実装されるべきで設計がアレになってるのではという気がしなくもないけど，まあ個人の一存でクラスを変えられるかはしらないし，具体的なコード見ないと断言もできないので無責任な意見です
既に確保されているクラスのメンバー変数に入れないと使えないから、val (a, b) = func() という選択肢はないかな。
というか、確保済みの変数a.bに対して、(a,b)=0みたいなことやってみたけど当然ながらダメだった。
C 言語で POSIX な API を叩くときやりがちなヤツだけど，代入と条件判定は分けたほうがいいようにしか思えない
それならなおさら
val (a, b) = func()
みたいなやりかたのほうがよい気がする
あきさんの語彙がどんどん崩壊しているのでインターネットはよくないことがわかる
fooX = fooY = 0;
ぐらいなら書きたくならなくもないけど無くても大して困らないなあ
a=b=0 みたいな書き方，同時代入ではなく代入文を nest してるだけだし評価順で誤解を招いてバグを生む元凶にもなる気がする
悲報 Kotlinでは複数の変数に同時代入できない
a = b = 0
みたいなことができない。
ついでにSwiftも同じらしい。
D言語におけるライフタイムと所有権と借用 - Qiita https://qiita.com/lempiji/items/e114dcdfdeeed2e9064c
