ふらっと C#,C♯,C＃（初心者用） Part145

2019/10/07(月) 20:16:17.93

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part144
https://mevius.5ch.net/test/read.cgi/tech/1563258983/
■関連スレ
C#, C♯, C＃相談室 Part95
https://mevius.5ch.net/test/read.cgi/tech/1508168482/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2019/11/21(木) 14:55:41.36

surfaceをペンとで使ってるけどペンを画面に近づけるだけでボタンの色が変わったりしてるな

2019/11/21(木) 14:58:37.65

ペンはマウス扱いなんだろうけど
タッチはどうなんだろうな

2019/11/21(木) 15:03:46.75

そりゃ対応ペンは少し浮いた状態でも座標検知できるけど指は無理っしょ

2019/11/21(木) 15:06:06.00

APIによって色々
WM_POINTERなら全部別デバイスとして判別されてる
wpfにもタッチイベントあるんだからそれでやりゃいいやんと思うが

2019/11/21(木) 15:06:47.73

あるんだ
最近WPF始めたから知らんかった
まだまだ使えそうだな

2019/11/21(木) 15:36:34.05

>>761
ペンに特殊な仕掛けがあるわけじゃないと思うので、
ペンだろうが指だろうが同じだと思う
知らんけど

でも普通に静電容量式のタッチパネルでしょ？

2019/11/21(木) 15:39:50.86

一応Windows7からOSネイティブでタッチ操作に対応してるんだよね。

当時技術サンプルとして鯉が泳いでる池をタッチすると波紋が広がるスクリーンセーバーが
公開されてたけど、なぜかコードは非公開で意味ねえと思ったなw

2019/11/21(木) 15:52:09.65

>>758
GCではだめでした
TrimExcess()呼び出せばいいんですって、奥様

2019/11/21(木) 15:58:35.96

へぇーためになるわ

2019/11/21(木) 17:29:49.14

>>764
surfaceのペンをスマホに当てても使えないから指とは仕組みが違うのでは？

2019/11/21(木) 17:45:14.26

>>764
ペンは電池式で何らかの仕掛けがあります。
良く知りませんが、恐らく「交番電界（周波数が低い電磁波とも言える）」を
出している可能性が高いです。

2019/11/21(木) 17:48:28.33

>>769
もともとタッチパネルの方が交番電界を出しているので、それを相殺するような
逆位相の降板電界をタッチペンの方が出している、と考えられるようです。

2019/11/21(木) 18:08:29.79

テレパシーの実用化。

2019/11/21(木) 19:22:17.78

>>769
へー
静電容量式の原理から普通に考えればペン側に仕掛けが必要とは思えんけど、
よく分からんね。

接触しているかどうかの識別はCの大きさで判定するだけのはずだと思うんだけど

2019/11/21(木) 19:40:36.49

>>772
ペンは静電容量式に対応してないと反応しないよ
手袋とかでタッチしても反応しない

2019/11/21(木) 20:37:16.26

専用ペン使うのは電磁誘導方式でしょ。
静電容量とは根本的に違う。

2019/11/21(木) 20:57:25.88

>>773
対応って言ったって要するに導電性があるだけだよw
だから100均でも売ってる

>>774
surfaceってペン「も」使える設計だよね？

2019/11/22(金) 00:36:21.37

長い名前を持つクラスに、thisを返すメソッドがあるとします

　// 超長いクラス名
　class VeryLongLongClassName {

　　　// thisを返すメソッド
　　　VeryLongLongClassName Foo( ) {
　　　　　return this;
　　　}
　}

このとき、Foo()の定義につけるクラス名を省略、
あるいは置き換える方法はありますか？

たとえば以下のような形が理想です

　var Foo() { … }　// 型推論っぽく書けるとか
　__CLASS__ Foo() { … }　//自身のクラスを表す予約語とか

2019/11/22(金) 01:05:43.88

ないです。

2019/11/22(金) 01:10:47.79

>>776
外部との境界に var 型推論はムリ。それやると型を差し替えたときに影響が甚大になるため、型推論はローカルでしか許されない。
using エイリアスディレクティブで短い別名付けるとよいのではないかな。

2019/11/22(金) 01:39:19.16

ありがとうございます
ないですかー　残念

2019/11/22(金) 01:41:38.83

問題点や何がやりたいのかを言うと
違うアドバイスか得られることもあるぞ

2019/11/22(金) 01:41:47.12

インタフェースとか継承を考えても、thisで型推論するのは無理じゃない？

2019/11/22(金) 02:06:03.92

戻り値が特に必要ないメソッドはreturn thisにして繋げれるようにしておこうかなあと
return thisにするか同じクラスをnewするかはさておき

2019/11/22(金) 03:39:52.30

VisualStudio2017を使用

Form1にsplitContainer1を上下に分割して全面に貼ってあり、splitContainer1の下段側にリッチテキストボックス1をドッキングさせて貼ってあります。
このリッチテキストボックス1が、ScrollBarsプロパティ:Both、WardWrapプロパティ:false

このリッチテキストボックス1に縦と横幅を超えるテキスト表示をした時、
縦のスクロールバーは普通に表示されるけど、水平のほうのスクロールバーが表示されなくなったのだけど何が原因と考えられるでしょうか？

・右キー押して自分でカーソルを右端まで動かせば一応画面のスクロールはさせられる
・以前はちゃんとスクロールバーが表示されてたはずなんだけどいつの間にか表示されなくなった？

2019/11/22(金) 09:14:29.30

>>782
クラス名が500文字とかあるならわかるけど100文字以内なら気にすることでもないと思う
気になるならそもそもクラスの命名が間違っているのでは？

2019/11/22(金) 10:12:54.94

xamlの質問になってしまいますが、全コントールアイテムのBorderBrushやForegroundの色を統一することって出来ないのでしょうか？
<Style TargetType="Button">
<Setter Property="BorderBrush" Value="Black"/>...
と一つ一つのコントロールを定義して回るしか方法はないのでしょうか？

2019/11/22(金) 10:34:58.33

>>785
この辺が参考になるかも
ttps://www.atmarkit.co.jp/ait/articles/1009/07/news096.html

2019/11/22(金) 11:05:21.71

>>776
ファイルスコープの別名なら普通に可能。
グローバルに別名が欲しいと考えてるならそもそも何か考え方が根本的に間違ってる気がする

2019/11/22(金) 11:21:07.27

>>784
そういう話ではない
それだと「変数をvarで定義するのは設計が間違っているからだ」と言ってるようなもん

2019/11/22(金) 11:34:48.44

>>788
いや誰が考えてもそういう（>>784）話ですw
それ以外にありえない

2019/11/22(金) 12:09:19.86

returnの型から推論できるんだからメソッドの戻り型にもvarを使わせろって話？
んじゃあ始め書き込みで予約語の例示が意味不明
というか長い名前という言葉から文章を開始しといて何が違うんだ？

変数でvarを使うのは名称が長いからではないぞ？
長いものも3文字で表現できるという副次的メリットはあれどそのために導入されたものではない

2019/11/22(金) 12:18:11.80

メンバの型に型推論が使えないのは単純に技術的な問題だよ
コンパイラは先にメンバのシグネチャだけを見てリストアップしてから各メソッドの本体を処理することで依存関係を解決している
メソッドの中身を見ないとメンバの型が確定しないとなると、一度メソッドを処理しただけでは依存関係を解決しきれないから
メソッドを何度も繰り返し処理する必要がでてきてコンパイルが遅くなる

2019/11/22(金) 12:18:49.41

>>785
できるよ～
１つのxamlにスタイルを定義して、全てのxamlから参照したりとか

**776** (ﾜｯﾁｮｲ 93bd-AvZR) · 2019/11/22(金) 12:21:55.56

なんか結論としては>99の質問と同じような感じになっちゃったけど
最初の質問が微妙に異なるので見落ちとしてた、すまん

>>787
単純に自身と同型のオブジェクトを返すときに、なんかスマートな方法あるのかな？と思っただけ
言語によってはそのへんの仕組みがあったりする

ファイルスコープでのエイリアスが可能なら>>778の言うように
分かりやすいところに ThisClass みたいな名前のエイリアスを用意しておいて
クラス内部では基本的にそっちを使うのもアリかなと思っている
予約語ではないのでエディタとの相性はそこまで良くないけのが欠点か

2019/11/22(金) 12:26:27.67

戻りの型名を普通に書くのがスマート
くだらないアイデアでコードを汚さないで

**776** (ﾜｯﾁｮｲ 93bd-AvZR) · 2019/11/22(金) 12:29:12.04

>>791
なるほど、確かにそうだな
動的な言語だとまた違うんだろうけど比較できるようなもんでもないしな

**776** (ﾜｯﾁｮｲ 93bd-AvZR) · 2019/11/22(金) 12:35:32.03

>>794
んだね

アリかナシかで言えばアリだと思ったけど
言語仕様として存在しないなら自分個人ではなるべく避けたいな

2019/11/22(金) 13:01:16.69

>>791
今どきのコンパイラでワンパスなんてないだろw

2019/11/22(金) 13:09:44.77

な？名称が長いかどうかなんて関係ない質問なのに余計な単語から質問を始めるから周りが混乱する。
コメントで超長いクラス名とかまで書いてんじゃん
そんで指摘したらそーじゃねぇよ！ってあほかとｗどんだけ説明下手くそなのｗ

2019/11/22(金) 13:09:46.78

>>793
なるほど失礼w

長い名前云々書いたのははミスリードだったねw
戻り値を型推論で省略できないか？とシンプルに書いて欲しかった

**776** (ﾜｯﾁｮｲ 93bd-AvZR) · 2019/11/22(金) 13:22:21.21

型推論ともちょっと違うからなあ

2019/11/22(金) 13:24:19.67

>>797
誰がワンパスだなんて言ったんだ？
現在何パス使っているにせよメンバの型推論を許せば間違いなくパスは増えるし、
791で書いた内容は俺の想像じゃなくてMS公式のコメントだぞ

2019/11/22(金) 13:48:44.67

>>801
多少パスが増えることぐらいでガタガタ騒ぐなよ
って話な
あとMSの見解がどうかしたのか？w

2019/11/22(金) 14:08:44.11

>>800
そうなの？w

// VLLCNじゃ何だかわからないので必要な場面で説明的な名前を与えるためだけのクラス
// 空っぽの継承のまま維持せよ。メンバ追加禁止！！！
class VeryLongLongClassName : VLLCN { private VeryLongLongClassName(){} }

// VeryLongLongClassNameの実体はこっち。
class VLLCN
{
　　....
}

まさかこんなのがお好みなのかなw

2019/11/22(金) 14:16:21.50

自身のクラス返すときだけ利用したいんでしょ
tweenerみたいな設定が多いものをチェインメソッドで必要な設定を好きな順番で書くとか
他にはfactoryみたいなのをわかりやすくするとか
気持ちはわからんでもないけど局所的すぎると思う

2019/11/22(金) 14:17:29.50

.Net CoreからBitFlyerの認証が必要なWebAPIを使いたいんだけどさあ
業者は暗号化キーをソースコードやファイル等に保存しないよう求めてるんだけど、.Net Coreでキーを守る手段ってどういうのがあるの？
WindowsやmacOS付属の機能も使えなさそうだし、最終的に動かしたいLinuxなんかそもそもそんな機能がないし・・・・
ランタイムにもそんな機能なさそうだし、どうすればいいんだろ

2019/11/22(金) 14:51:55.96

ソースはともかくファイルに保存は普通にやるよ
リポジトリに機密情報をコミットしない、と勘違いしてないか？

2019/11/22(金) 15:31:23.92

>>804
> tweenerみたいな設定が多いものをチェインメソッドで必要な設定を好きな順番で書くとか
チェインメソッドってよく見かけるようになったけど見易いのかなぁ…
X.A( ).B( ).C( );
より
X.A( );
X.B( );
X.C( );
の方が見易いと思う俺は老害なんだろうか

2019/11/22(金) 16:18:12.63

>>807
linqでつなげるのに慣れてれば違和感なくならない？
linqとは意味合いが違うけども
まぁ可読性なんて人それぞれだとは思うよ

2019/11/22(金) 16:37:13.07

>>808
linqはパイプみたいに順次処理して行くからまだ理解できるんだけど>>804が言う
> 設定が多いものをチェインメソッドで必要な設定を好きな順番で書く
とかは普通に分けて書けばいいのにって思うんだよね
まあ人それぞれと言うのには同意するけど

2019/11/22(金) 19:30:22.12

Groovy などでやる、フォームビルダーみたいに、

各コントロールのサイズ・色など、設定項目が多いものは、メソッドチェーンでは見にくい

2019/11/23(土) 02:25:29.33

>>807
自分もそう思う
>>808
LINQでつなげる場合はLINQメソッドの戻り値を意識しながらつなげるわけだから、話が違うじゃん
list.Reversed().Select((v)=>v+1)みたいな例はデータをどんどん変換しているから良いと思うけど、
form.ForeColor(Color.Red).BackColor(Color.Black)みたいなやつは1行で書けるメリットがあるのはわかるけど、
やってることは関数じゃないのに関数っぽくっ振る舞ってるのがすごくモニョモニョする。
これが、
form.CopyWithForeColor(Color.Red).CopyWithBackColor(Color.Black)で別のformが2つ作られるとか、
form.ForeColorChanger(Color.Red)でForeColorChanger<Form>が生成されて、ApplyFormで元のFormに反映されるとか
ToFormで新しくフォームが作れるとかならわかるんだけど、
副作用のあるメソッドで、戻り値がvoidのやつはもったいないから、戻り値をthisにするってのがなんか受け付けないんだよな―。

2019/11/23(土) 02:58:58.06

DSLとしてどの程度価値があるのか次第だと思う
https://martinfowler.com/bliki/FluentInterface.html

LINQのように関数型ライクな関数合成をOOで表現する場合と
FluentなBuilderパターンは見た目は似てても中身と目的は違うよね

2019/11/23(土) 03:16:21.47

だから意味合いは違うって書いてんでしょうが
this返して繋げる前提ライブラリなんてよくあるし好き嫌いの範疇
君が嫌いならしなきゃ良いだけじゃん
俺だってC#のライブラリ作るとき設定するだけのメソッドでthisなんて返さないよ
それは俺が作るものが小さいものだからできるだけ標準に近いものが良いだろうってだけ
大きめのものでそれが全体を通して同じようにthis返す設計で、それを使うならなるべくその思想には従うかもしれん程度

2019/11/23(土) 04:29:53.39

this返すお作法は昔のjava方面の文化じゃない？

C#は1.xの時代にMSか何かのガイドラインで「やるな」って書いてあったのを読んだ記憶がある。
個人的にそもそもそんなキモいことやらないよと思ったので禁止の理由までは覚えてないが。

2019/11/23(土) 08:12:23.68

>>813
> だから意味合いは違うって書いてんでしょうが
何にキレてるのか知らんけど、意味合いの違うものを引き合いに出すこと自体がおかしいって指摘されてることぐらいは理解しようよ

2019/11/23(土) 08:50:13.03

とは言え
X.A()?.B()?.C();
ならどうだろう？

2019/11/23(土) 11:11:29.56

意味合い違うものを出すのがおかしいなら807のレスがおかしいんだよ？
見やすいとか関係なくて776がこんな機能ないの？→無いよ→なんで欲しいの？→こういうのしたいんでしょ→見にくくね？気持ち悪くね？
って知るかよｗ
機能の話してんのになんで見易さの話にシフトすんだよ
見易さの話に変えられたので同じ表記の例示だしただけだし、そもそもlinqではないが採用してるライブラリも例示してんのになんでそこにこだわんの？ｗ

2019/11/23(土) 11:15:35.39

おおもとの>>776や>>793の疑問についてはusingでエイリアスをつけて
『using [別名] = [VeryLongLongClassNameとか別名をつけたいクラス名];』と宣言して、
『[別名] Foo() { return this; }』みたいなメソッドの書き方することはできるし、
その別名に「This」を使ってるようなソースもたまに見かける

なんだけど・・・そもそも戻り値が特にないからとりあえず安易にthisを返すみたいな考え方は間違ってる
戻り値がないならvoidにして無駄な戻り値を返さない
そのクラスがBuilder的な使い方をするクラスである場合に限って、
そういうクラスであることをクラス名ほかで明示したうえで首尾一貫して全voidメソッドでthisを返す
>>782みたいな考え方で戻り値がthisなのか新しいインスタンスなのかブレるかもしれないのは論外
戻り値が後者なメソッドが混ざってると>>807の２種類の書き方で結果が同一にならなくなる

2019/11/23(土) 11:33:01.08

Fluent apiってthisを返すことが目的じゃないからな
メソッドチェインで宣言的っぽくプログラミングするためのアイデアであってthisを返すメソッドはそのサブセットでしかない
世に出てるライブラリを見ればわかるがthis以外もバンバン返してる
だから作法としてとりあえずthisを返すなんてのは何もわかってない全く馬鹿げたことだ
先にFluent apiの設計をしなければならない
その設計に必要ならthisを返すメソッドを加えるだけだ

2019/11/23(土) 11:54:08.57

>>817
話題を変えること
と
違うものを引き合いに出して同じでしょ
って言うことの違いも理解できてないのかよ…

2019/11/23(土) 12:07:14.69

>>820
話題を変えたから見た目の話してんのに機能面に難癖つけてるの分かってる？
見た目はこれと一緒、機能はちがうけどね
ってレスしたらそれは機能が違う！って戻してんじゃんｗ

見た目も機能も同じtweenerという例示
見た目の話に切り替えたので見た目は同じだが機能は異なるlinqという例示
念の為機能は異なることも明記した上での提示に対して機能面についてあーだこーだ言われてもねぇ

2019/11/23(土) 12:14:24.40

喧嘩すんなよ。

いろいろな観点から指摘が入って、設計やスタイルに関する考察が深まるのはいいことだ。

揚げ足取りとか噛み付きとか不毛だからやめような。

2019/11/23(土) 12:25:25.02

コードレビューするなら
本質的な機能では無いのに戻り値返すのは利用者の理解を妨げる上に、バグの元にもなるので、余計な事すんなと言うな

あとから戻り値欲しくなった途端に困るやろ

2019/11/23(土) 12:58:03.05

今までレスしてる中でthis返す設計に肯定的な姿勢なのは元の質問者である782だけ
C#標準にそういう設計は無いからその利用者の多くは否定的になる、俺も含めて

世の中いろんな設計指針があるし他言語の流儀を真似することもある
同じチームで開発することになるならその辺りはできるだけ同じ方向を向きたいけれど、そういうのじゃなければ最終的にはお好きなようにとなるよね

2019/11/23(土) 13:19:13.45

>>821
バカなの？
> linqはパイプみたいに順次処理して行くからまだ理解できるんだけど
って書いてあるだろ
そういう必然性のない
> 設定が多いものをチェインメソッドで必要な設定を好きな順番で書く
を同一視してるのがおかしいの
わかった？

2019/11/23(土) 13:30:54.32

>>825
それは機能の話ね
で、機能は初めから違うよ、って言ってるよね？
誰も同一視してないのになんで同一視してんじゃねーよ！って絡んでくるの？

2019/11/23(土) 13:39:42.87

揚げ足取りだけど＆Javaからの輸入だけど
>C#標準
つStringBuilder

もっとも自分でコード書くなら（変数名が短い前提で）メソッドチェーンにはしないけど
「文字列組み立ての順序を明示する」意図でメソッドチェーンで書くのはまあ理解できる

2019/11/23(土) 13:44:55.41

linqもtweenerみたなのもメソッドをドットでつなげて表記する
データを加工して流すものとthisを返すものという機能面では全く異なるもの
機能と見た目を完全に切り離せるわけではないので、その見た目から機能面を理解しづらい＝可読性に影響があるという議題は残るものの、どちらも利用する上での表記は同じ

ただこれだけで当初から機能は異なることを明記してるのになんで機能違うじゃねーか！みたいなすでに注釈してる内容に噛み付いてくるんだ

2019/11/23(土) 13:48:34.67

>>827
おぉ、確かに
標準にもあったね、ありがとう

2019/11/23(土) 14:30:45.15

>>826
もしかして「必然性」っていう言葉を理解できないの？
機能が違うからダメと言うより必要もないのにチェインメソッド使わなくても良くね？
って話な

2019/11/23(土) 14:39:10.21

>>827
fact を提示するのは揚げ足取りではないと思うよ。

return this は言われるほど悪いものではないと個人的には思う。が、メソッドチェーンにする価値は LINQ に比べるとさしてないという意見にも同意。

2019/11/23(土) 14:40:26.89

>>830
うん、使わなくてよくね？
使うべきとも使ったほうが良いとも書いてない
そういうライブラリがこの世に多少は存在することを例示しただけ
そもそも俺自身がthis返す設計に否定的だって何度も書いてるんだけど読んでる？

2019/11/23(土) 15:10:38.43

他言語だけどスクレイピングでよく使う

browser
.GotoHome()
.Login()
.DoSomething()
.DoAnother()
.SkipSomething()
.PrintResult()

コンテキストのつながりが自分にとって自然で
各メソッドを部品としてチェリーピックして使うような場合は
読みやすくなると思ってる

結局 return thisの是非じゃなく
メソッドチェーンでつないでいくのが適してる用途なのか
そうじゃないのかの話だよねこれ

2019/11/23(土) 15:17:05.69

>>832
お前の意見はどうでもいいよ…
必然性の有無にも気づけずにLinqガーとかいうアホがいたって話だしw

2019/11/23(土) 16:24:36.28

なんか絡まれたから対応したら君の意見はどうでもいいって…
じゃあなんで絡んだんだよｗ

2019/11/23(土) 16:33:18.34

VBのWithみたいなことやりたいって理由でthis返すんなら最低だな

2019/11/23(土) 17:56:40.63

>>835
> じゃあなんで絡んだんだよｗ
ちゃんと書いてあるだろ…

> 必然性の有無にも気づけずにLinqガーとかいうアホがいたって話だしw

見た目の話だけなら個人の好みだから人それぞれでいいけどLinqとかの必然性があるものを持って来られても困る

2019/11/23(土) 18:13:01.41

>>837
いや、だからなんで俺の意見はどうでも良いはずなのに未だに絡むの？
何を説明しようがどうでもいいで片付けるんだから話にならないじゃんｗ

もう一回説明しようか？
linqと見た目が一緒、機能は異なる
ただそれだけなんだけど伝わらない？これも意見だからどうでも良いんだと思うけど
ずーっとこう主張してるのになんでlinqは必然性があるから良いんだ！みたいな頓珍漢な絡みするの？

2019/11/23(土) 18:19:16.92

>>838
まじで日本語の理解力がなさすぎ
(引っ込みつかなくなってるだけかも知れんがw）

> うん、使わなくてよくね？
という君の意見はどうでもいい
Linqは>>811が書いてる通り
> LINQでつなげる場合はLINQメソッドの戻り値を意識しながらつなげるわけだから、話が違うじゃん
ってことな

2019/11/23(土) 18:31:57.35

>>839
いや、だからそんなことわかりきってるよｗ
807で君が言った内容に対して表記が同じとしか言ってない
ちゃんと機能が異なることを追記した上で同じ表記だね、って言っただけでしょ？

それに対して延々と同じ内容で煽り続けてるんだよ？
linqは意味が違うよっていう808からの始まった内容に対してlinqは意味が違う！馬鹿なの？って
もっかい始めの方からレス内容確認したほうが良いよ
言葉尻捕まえて煽るだけで引っ込みつかなくなってるのはたぶん君の方だよ

2019/11/23(土) 18:40:43.12

判った。LINQ宗教だ

2019/11/23(土) 18:41:15.69

もう堂々巡りにして引き分けに持ち込もうと必死だな
Linqならメソッドチェーンにする意味があるから
> tweenerみたいな設定が多いもの
と一緒にされても困るって何度書いても同じこと書いてくるんだろうなw

2019/11/23(土) 18:46:16.32

機能の話から表記の話なってまた機能の話に戻す
表記の話のときに表記が同じ例を提示すると機能が違うんだから同じにすんな！
ってそりゃそうですよね、機能は違うってみんな言ってますもん
機能が同じだなんてレスどこにありました？

2019/11/23(土) 19:45:54.89

804：機能の話
807：機能から発展した表記の話
808：表記の類似例の提示
811：機能ちげーじゃんというツッコミ
813：そうだよ機能は違うよという返し
ここから延々、表記の類似例に対して機能が違うじゃんというツッコミ
811は807とは違う人だけどね

807でも機能の話をしてたと言うなら俺の読解力が悪かった
表記の話であることを明確にするために808に意味合いが異なると注記したつもりではあった
今見返しても表記に関しての話題転換にしか見えないけど

2019/11/23(土) 19:53:56.23

linqなんてゴミだろ

2019/11/23(土) 19:58:41.98

LINQ友の会スレ消えちゃった？（核爆）

2019/11/23(土) 19:59:21.32

ゴミのような時間の使い方をしている人らとはどっこいどっこいって感じよ

2019/11/23(土) 19:59:52.48

まだ言ってるのかよw

> 機能が違うからダメと言うより必要もないのにチェインメソッド使わなくても良くね？
> って話な
って書いてあるのに「機能が違う」を連呼するしかない脳無し乙

2019/11/23(土) 20:07:04.96

>>1
>なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
>C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください

ID真っ赤にしている人はコレ100回読んでね

2019/11/23(土) 20:20:39.76

お互い口汚く罵るのはやめよう。どちらも有益な情報を持ち込み、スレに貢献してると思うよ。

>>844
機能と表記の 2 観点からの考察ありがとう。君の主張は首尾一貫していて妥当だと思うよ。
私は return this 完全否定はしないけどね。

>>842
tweener なるものが何か知らないのだが、設定の手数の観点で C# と比較できるものではないということはわかった。ありがとう。

私が return this を時折使う理由も設定の手数あたりにあるかもしれないと思った。

変数宣言&インスタンス初期化を “本処理とは分けて” ワンライナーで書きたいのだが、初期化の手数が多いときに return this 使うよ。

var a = new ClassA().Init1().Init2().Init3();
var b = new ClassB().Init(a);

// a, b, その他の変数を用いた本処理

という感じで。

初期化と本処理をごちゃ混ぜに書くと本処理の本質が見えづらくなるため好きではないし、if, for などで新しいブロックが出てくるわけでもないのにコンテクストの途中で新規変数宣言するのも好きではない。純粋に表記スタイルの (好みの) 話。

2019/11/23(土) 20:21:25.84

まあLINQはさておき
前者と後者じゃ後者のほうがスッキリして見える場合もあるんじゃないかなとは思う

hoge.foo();
hoge.bar();
hoge.baz();
hoge.quz();

hoge
　　.foo()
　　.bar()
　　.baz()
　　.quz();

セミコロン必須の言語やif文とは相性そんなに良くないけどさ

2019/11/23(土) 20:27:14.79

>>850
tweenerはたぶんゲーム分野とかで使うことが多いと思うけど表示物のアニメーション制御に使うようなライブラリを指して言った
最近はweb系もアニメーションには富んでるからそっちにも似たようなものはある

表示物のx座標をaからbにc秒かけて移動させる、そのときd秒遅れてアニメーションを開始して終了後にe関数を呼ぶ
みたいな設定をするのに使う

2019/11/23(土) 20:32:13.74

>>851
疑似with構文ってとこかな？

2019/11/23(土) 21:28:03.06

c#の先祖に当たるdelphiではwithがあったがC#で亡くなった

2019/11/23(土) 21:33:29.44

まあ罵倒は見てて見苦しいねw

thisを返す手法に違和感を感じる人（自分もその一人）が多いのは、

(1) シグジェチャだけではメソッドが返す値がthisなのか別のインスタンスなのか分からない
(2) チェーンさせる目的でthisを返すのは意味論（メソッド名はそのメソッドの機能を表現する）を破壊する

こんなところか。

本来は必用なら言語レベルで実現すべき機能なんだろうね。
でもC#erってVBのWithブロックには否定的な人が多かったよな

2019/11/23(土) 22:00:39.91

相談させてください。
以下のようなクラスを作りたいと考えています。

class MyStaticClass1
{
　　static double HighCostMethod() { ... }

　　public static double X = Math.Sign(HighCostMethod());
　　public static double Y = Math.Abs(HighCostMethod());
}

しかし高コストな HighCostMethod を２回も呼びだすのは無駄なので
以下のように改良しました。

class MyStaticClass2
{
　　static double HighCostMethod() { ... }

　　public static double X, Y;
　　static MyStaticClass2()
　　{
　　　　var v = HighCostMethod();
　　　　X = Math.Sign(v);
　　　　Y = Math.Abs(v);
　　}
}

ところがこのコードは規則 CA1810 に違反すると警告が表示されました。
静的コンストラクターにはパフォーマンス上の欠点があるようなのです。
【CA1810 参照型の静的フィールドをインラインで初期化します - Visual Studio Microsoft Docs】
https://docs.microsoft.com/ja-jp/visualstudio/code-quality/ca1810?view=vs-2019
（続く）

2019/11/23(土) 22:01:03.42

（続き）
そこでさらに次のように改良したところ、無事警告は表示されなくなりました。

class MyStaticClass3
{
　　static double HighCostMethod() { ... }

　　public static double X = Initialiser.Instance.X;
　　public static double Y = Initialiser.Instance.Y;

　　class Initialiser
　　{
　　　　public static Initialiser Instance = new Initialiser();

　　　　public double X, Y;
　　　　Initialiser()
　　　　{
　　　　　　var v = HighCostMethod();
　　　　　　X = Math.Sign(v);
　　　　　　Y = Math.Abs(v);
　　　　}
　　}
}

ただ、クラス初期化時のパフォーマンス上の問題を解消するために
さらに別のクラスを定義するのは本末転倒な気もします。

私のアプローチは正しいのでしょうか。
それとも素直に CA1810 の警告表示を抑制すべきでしょうか。
もしくは、別のもっとスマートな解決策があるのでしょうか。
アドバイス等をいただけると嬉しく思います。よろしくお願いいたします。

2019/11/23(土) 22:01:38.76

俺自身もthis返す設計に否定的で813で明確に表明してるんだけどねｗ
850の初期化の例みたいなのもC#ではメソッドに引数名を指定して呼び出すことができる機能があるからそれで事足りる
引数の数が多くなったりオプション引数使えば更に長くなったり呼び出し側も見た目はスマートとは言えないような書き方になったりするんで多用は避けたいところだけど局所的な利用なら無しでは無い気もする
まぁ設定用の構造体作って渡すとかjson等をシリアライズしたものを渡すとかのほうがいいんじゃない？とは思う