アカウント名:
パスワード:
最近色んな言語間で機能がやり取りされてる感じはあるけれど、同じ機能でも名前が違ったりすることがあるように見える。(つまり、アロー関数じゃなくてラムダ式で良いじゃん。)同一機能ならできるだけAPI(関数名とか)も揃えて欲しい。(C#のLinqとJavaのStreamとか名前揃えて欲しい。)その辺規格とかできないもんかな？というか最初に実装したところが決めた名前でいいじゃん。
Stream APIのfilterやmapは関数型言語でよく使われてた名前から、LINQのselectやwhereはSQLからの類推と、出処がバラバラなんですよねえ
// LINQに慣れすぎてRubyの「select」でハマる
SQLからの類推に見えても・Whereの中で使っている列名が （ほんとうのSQLならその場限りのローカル扱い）・そのLINQを使っている場所で定義されている同名の 変数名とバッティングするなんてSQLと違うのは確かで、SQLっぽいのを止めるのは賛成！
LINQなぁ、なんであんな仕様作ったのかさっぱり理解できない。CollectionもRDB同じように扱えるっていうけど、同じように扱いたいか？というか同じように扱っちゃダメだろと。しかも直に扱うより思いっきりパフォーマンスも悪いし。パフォーマンス変わらないのならまだしも。
ORMと同じような発想を裏返したプログラミングインターフェイスなんじゃないかね。ORMはSQLの文法を知らなくても何となくメソッドチェインでそれなりに目的は達成される、でもパフォーマンスを理解するには生成されるSQLを知っていなければならない。
一方LINQはSQLフレンドリーな記述をRDB以外のリソースに適用できる。リソース毎に固有のインターフェースを知らなくても、何となく対象のリソース操作を行える。パフォーマンスの問題は同様。
まあ自分も正直、C#にクエリ式の文法は要らないんじゃないのと思う方だけど。LINQの目指す所も分からないでもなく、LINQがラムダ式と型推論の早期導入を後押しした気がするから、あまり嫌ってやらずにおいている感じ。
LINQ to Objects (C#) [microsoft.com]
本質的に、LINQ to Objects は、コレクションを扱うための新しい方法です。 従来の方法では、複雑な foreach ループを記述して、コレクションからデータを取得する方法を指定する必要がありました。 LINQ を使用する場合は、何を取得するかを表す宣言コードを記述します。
また、LINQ クエリには、従来の foreach ループと比べて、次の 3 つの重要な利点があります。
Collectionに対するシンタックスシュガーな拡張関数は便利でいいんだけどね。こいつらはsystem.linq.dllを参照しなくとも使えるし。性能は自分でごりごり書くのと結局同じだからな。書かずに済むので実にいい。
でもここで話しているLINQはSQLモドキのこと。RDBだとSQLServer以外まともにつかえないんじゃね。ODP.NETは対応してたと思うが使ってる奴なんて実際いるのかね？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
名前統一してほしい (スコア:0)
最近色んな言語間で機能がやり取りされてる感じはあるけれど、同じ機能でも名前が違ったりすることがあるように見える。
(つまり、アロー関数じゃなくてラムダ式で良いじゃん。)
同一機能ならできるだけAPI(関数名とか)も揃えて欲しい。
(C#のLinqとJavaのStreamとか名前揃えて欲しい。)
その辺規格とかできないもんかな？
というか最初に実装したところが決めた名前でいいじゃん。
Re: (スコア:0)
Stream APIのfilterやmapは関数型言語でよく使われてた名前から、LINQのselectやwhereはSQLからの類推と、出処がバラバラなんですよねえ
// LINQに慣れすぎてRubyの「select」でハマる
Re:名前統一してほしい (スコア:0)
SQLからの類推に見えても
・Whereの中で使っている列名が
（ほんとうのSQLならその場限りのローカル扱い）
・そのLINQを使っている場所で定義されている同名の
変数名とバッティングする
なんてSQLと違うのは確かで、
SQLっぽいのを止めるのは賛成！
Re: (スコア:0)
LINQなぁ、なんであんな仕様作ったのかさっぱり理解できない。
CollectionもRDB同じように扱えるっていうけど、同じように扱いたいか？
というか同じように扱っちゃダメだろと。
しかも直に扱うより思いっきりパフォーマンスも悪いし。パフォーマンス変わらないのならまだしも。
Re: (スコア:0)
ORMと同じような発想を裏返したプログラミングインターフェイスなんじゃないかね。
ORMはSQLの文法を知らなくても何となくメソッドチェインでそれなりに目的は達成される、
でもパフォーマンスを理解するには生成されるSQLを知っていなければならない。
一方LINQはSQLフレンドリーな記述をRDB以外のリソースに適用できる。
リソース毎に固有のインターフェースを知らなくても、何となく対象のリソース操作を行える。パフォーマンスの問題は同様。
まあ自分も正直、C#にクエリ式の文法は要らないんじゃないのと思う方だけど。
LINQの目指す所も分からないでもなく、LINQがラムダ式と型推論の早期導入を後押しした気がするから、
あまり嫌ってやらずにおいている感じ。
Re: (スコア:0)
LINQ to Objects (C#) [microsoft.com]
本質的に、LINQ to Objects は、コレクションを扱うための新しい方法です。 従来の方法では、複雑な foreach ループを記述して、コレクションからデータを取得する方法を指定する必要がありました。 LINQ を使用する場合は、何を取得するかを表す宣言コードを記述します。
また、LINQ クエリには、従来の foreach ループと比べて、次の 3 つの重要な利点があります。
Re: (スコア:0)
Collectionに対するシンタックスシュガーな拡張関数は便利でいいんだけどね。
こいつらはsystem.linq.dllを参照しなくとも使えるし。
性能は自分でごりごり書くのと結局同じだからな。書かずに済むので実にいい。
でもここで話しているLINQはSQLモドキのこと。
RDBだとSQLServer以外まともにつかえないんじゃね。
ODP.NETは対応してたと思うが使ってる奴なんて実際いるのかね？