Data.table: magrittrとの統合

DT[, a := some.function(a)]

完全に正常に動作します

しかし、私見

Complicated_data_table_variable_name[, a_very_very_very_very_long_variable_name := some.function(a_very_very_very_very_long_variable_name)]

完全に元気ではありません。 この便利な関数を追加するというアイデアが好きです。

しかし、おそらく%:>%は%<>%よりも優れているでしょうか？

データセットにそのような奇妙な名前を含めるべきではありません。 それは不便であり、ほとんど保守できません。 それ以外に、列名を変数に格納してから、次の操作を行うことができます。

shortname <- "a_very_very_very_very_long_variable_name"
DT[, (shortname) := some.function(get(shortname))]

その通りですが、中間の長さの変数を使用しても、magrittr構文の方が読み取りと書き込みにはるかに便利です。 とにかく、これは私の個人的な意見です。

変数に何が保存されているかを明確にするために、複雑なデータセットに長い変数名を含める方がよい場合があります。 それは個人的な好みの問題です。 コンビニエンス関数は、定義ごとにタスクを実行する必要はありません。コーディングが高速になり、多くの場合、理解しやすくなります。 この機能が多くのユーザーに役立つことは間違いありません。 しかし、data.table開発者が（多すぎる）便利な関数を実装/維持したくない場合は、どこかに線を引く必要があることも理解しています;）

このスレッドを購読している方は、最後のコメント（現在は削除されています）を無視してください。 ばかげていた。

@ and3kのコメントから構築すると、

DT[, a %:=>% some.function]

読みやすくなると思います（つまり、 :=と%>%一緒に）。 それは「幸せなパイプ」ですか？ ここに書かれているように、私は変数名の繰り返しを減らす努力のファンです： http ：

:=>演算子の=>部分には、追加の意味があります。おそらく:=: ？

DT[, a %:=:% some.function]

または:=.は、 :=後に.がfunに渡されるように直接マップされます

=>はどのような特別な意味がありますか？ >は、RHSへの引数としてLHSを渡すことを伝えるので便利です。 これが、ハドリーが元の%.%から%>%変更された理由です。

私の理解では、 %>%に移動する動機の大部分は、 %.%よりも入力がはるかに簡単であるということ%.%を入力しようとすることが多いと思います） %>% ）。

私は_より大きいか等しい_演算子を意味します。
そして、 %:>%どうですか？ これは、 %:=>%または%:=:%よりも入力が簡単です。
and3kはすでに上記の1つに言及しています。

私の投票は%:>%または:>です。

%は、Rが実際には中置演算子を許可していないためにのみ存在しますよね？ DT[]内の演算子を節約することもできます。

タイピングの側面を考慮していませんでした。つまり、演算子のすべての文字のShiftキーを押したままにする方が簡単だと思います。 理にかなっています。
:>は残念ながら解析されません。 [...]の内部は、有効なR構文である必要があります（すべての引数は、関数に未評価で渡される前に常に解析されます）。したがって、 [...]内部で新しい演算子を作成することはできず、ラップする必要があります。 % 。
では、 %:>%は私にも似合います。 それが大きな優先事項であるとは限りませんが、実装するのは難しくなく、議論するのは良いことではありません。

ありがとう、 %:>%は私には良さそうです。

不思議なことに、 :=が[....]内で解析しているのに、なぜ:>が解析されないのですか？ :=も有効なR構文ではありませんか？

@ my-R-それが有効な構文であるのを助けてください、これを見てくださいなぜ：=が中置演算子として許可されているのですか？

+ 1OP機能の要求とmagrittr構文の使用に同意します。 これは、いくつかの理由から、最良かつ最も明白な選択です。

• 人々はすでにitmagrittrでDTを多用しています
• magrittrの構文は、この時点ではどこにでもあります...独自のrstudioホットキーを取得する可能性もあります...そして他の構文上の選択は混乱を招く可能性があります。

任意のmagrittrの選択と同じように選択する新しい演算子を導入することにより、このFRを考えすぎないように強くお勧めします。

任意のmagrittrの選択と同じように選択する新しい演算子を導入することにより、このFRを考えすぎないように強くお勧めします。

@ctbrown提案は、 %>%とは異なる何かを行うパイプ演算子、他のいくつかのパイプ演算子も含むパッケージを対象としています。 それらのいずれとも競合しない限り、何が問題なのでしょうか。

OPのFRリクエストは十分に明確だったと思います。
%<>%を転送パイプと割り当ての組み合わせとして具体的に使用する
オペレーター。 おそらくこれは、magrittrがすでに%<>%を定義しているためです
まさにこの目的。 magrittrが支配的なパイプのように見えるので
実装と多くの人々が％<>％を使用しているようです、私の学生と
それらの間の同僚。 別のものを紹介するのは意味がありません
まったく同じ目的の演算子。 を選択する方がはるかに理にかなっています
コミュニティがさらされている、またはすでに持っているものに一致する構文
採用。 ユビキタスについての私のポイントを参照してください。

別のオペレーターを紹介することで何が得られると思いますか？
別のコンテキストでまったく同じ機能を実行しますか？ 見えない
どんな利益でも。 選択する演算子は、magrittrと同じくらい任意です。
したがって、単にシステム全体を恣意的にすることは意味がありません。
さらに別の恣意的なものにするのではなく、ここでmagrittrのリードに従う
構文上の決定？

11時41 AMに木、2016年10月27日には、franknarf1 [email protected]
書きました：

新しいものを導入して、このFRを考えすぎないように強くお勧めします
選択が任意のmagrittrの選択と同じである演算子。

@ctbrownhttps ：//github.com/ctbrown提案はパイプオペレーター向けです
それはmagrittrのバニラ％>％とは違うことをします
他のいくつかのパイプ演算子も含むパッケージ。 そうでない限り
それらのいずれかと競合します、問題は何ですか？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Rdatatable/data.table/issues/1208#issuecomment -256732710、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AC5xaxIp36dTUCz9d5a5mU7CJUV6PaxCks5q4PBDgaJpZM4FSJR5
。

%<>%は参照によって割り当てられますか？ そうでない場合、彼らは実際にはまったく同じことをしていません。

技術的にはあなたは正しいです、magrittrの％<>％は参照によって割り当てません、
しかし、これは要点を超えています。 ユーザーの期待の範囲内で、
違い。 参照による割り当てか値による割り当てか
実装の問題はインターフェースの問題ではありません。 OPは採用を提案しました
magrittrインターフェースであり、必ずしも実装を示唆しているわけではありません。
OP提案にメリットがありました。 上記の理由を参照してください。 私はしません
'％：>％ or anything as arbitrary. The merit of this has not been articulated. The ％<>％ `のようなものを採用する理由を参照してください
オペレーターはすでに存在し、magrittrによって積極的に推進されています（12番目に多い
METACRANによると人気のあるパッケージです。）これは何よりも
標準になります（Rコミュニティ内）。 フォローすることの良いところ
確立された慣行は、ユーザーの混乱と
包括的なドキュメント。 「ああ、これはmagrittrと同じです、私は
このフォワードパイプを知っていて、「これは何ですか」ではなく「割り当てを行います」
奇妙な％：>％？ それは新しいピエロの絵文字ですか？」

14:18の木、2016年10月27日には、マイケル・キリコ[email protected]
書きました：

％<>％は参照によって割り当てますか？ そうでない場合、彼らは実際には_していない_
まったく同じこと。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Rdatatable/data.table/issues/1208#issuecomment -256772769、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AC5xa3ssE14PcamL2U9HlvCdfA8-7Iz8ks5q4RUagaJpZM4FSJR5
。

ユーザーの期待の範囲内で、違いはありません。

まず、それが真実であり、あなたがすべてのユーザーのために話しているとは思いません。 たとえば、私はユーザーです。 次に、それが当てはまる場合、これらのユーザーはdata.tableの使用法を学ぶときに違いについて学ぶ必要があります。

あなたの「上記の理由」は私と一緒に水を保持していません。 重複しないパイプ演算子を実装して、明確であるが関連することを行うことは、どういうわけかmagrittrに反することではありません。 私にとって-そしてこれは私の印象であり、あなたが言っていることはすべてあなたのものであるのと同じように-これはmagrittrの「確立された慣行」（私がdata.tableを使用するのとほぼ同じくらい頻繁に使用する）と完全に一致しているようです）。

このコンテキストで使用すると、一度に複数のオブジェクト（列）に割り当てられる可能性があります。これは、 %<>% ..？とはまったく異なることに同意するはずです。 つまり

DT[, (cols) %:>% lapply(as.character) ]

また、参照によって変更し、一度に複数のものを変更する可能性があることに加えて、 %<>%とはまったく異なるもの（data.table）の一部を変更しているという事実があります。

とにかく、開発者はすぐにこのタスクを実行する兆候を示していないので（このFRに優先度またはマイルストーンをマークすることによって）、実際に前進した場合は、これを再検討してみませんか？

@ctbrown _by-reference_は実装が異なるだけでなく、ユーザーインターフェイスの_by-value_関数と区別する必要があります。 これが、data.tableのset*関数と:=演算子の要点であり、関数の入力を実際に変更しているものをユーザーに明確に伝えます。 このような短い期間の後、Rコミュニティ内の標準を判断するのは困難ですが、Rアプリケーションは数十年にわたって作成されており、「新しい標準」を判断するのは時期尚早です。 、間違っている場合は訂正してください。 何度も言ったように、magrittrパイプは、コードのチャンクを提示したいときにインタラクティブに使用するのに非常に便利ですが、機能が主な焦点であるRパッケージを作成する場合は実際には必要ありません。 IMOで何かをインプレースで変更できる場合は、インプレースで変更しない演算子とは異なる演算子を使用する必要があります。

@ franknarf1 、

まず、すべてのRユーザーについて話すことについての主張はありませんでした。 それはばかげた主張です。 「ユーザーの期待」への言及は、おそらく私自身、おそらくOPと、すでにdt[ , var %<>% ... ]を試し、なぜそれが機能しないのかを尋ねた私の学生の何人かに対するものでした。 さらに、DTが期待どおりに機能する場合、ユーザーに「data.tableの使用法を学ぶときに違いについて学ぶ」ことは危険です。 これは悪いソフトウェア設計につながります。

第二に、あなたが指摘するように、magriitr構文に従うというOPの提案に従うことに賛成して議論を受け入れるか拒否するかは個人の責任です。 なぜこれが有益であるかについていくつかの議論が提供されてきましたが、代替案が優れている、あるいは有益でさえある理由を提供する説得力のある議論はほとんどありません。 実装が異なるため、マイナーな議論があるようですが、それはかなり弱い議論です。

さらに、

• %<>%は、複数の引数を処理するように実装することもでき、OPや他の人の期待を守りながら、コンテキスト内で完全に意味をなします。 OPの提案は、彼が複数の引数を変更したいかどうかを実際には指定していませんでした。
• 一部を変更するか全体を変更するかは重要ではありません。常に、環境などの一部を変更します。
• 開発者の行動または不作為は別の赤いニシンであり、OPの提案/要求のメリットとは関係ありません。 これは、どちらの方法でも実際には意見を提供していない、かなり貧弱な権威への訴えの議論です。

OPの提案に賛成/反対の議論があれば、私はそれらを聞いてみたいです。 しかし、私が聞いた唯一のことは、「それが違うから」ということです。 たぶん、これは有効であると考える人もいるかもしれませんが、OPの当初の提案と比較すると、代替案は良くないようです。

data.tableを使用したことのある人は、いつか別の方法で:=使用について学ぶ必要があります（おそらく開始後すぐに）。 いや、不気味！ <-または=はないのはなぜですか？

これに対する答えは、誰もがdata.table使用について最初に学ぶことの1つです。 これは、 2番目のイントロビネットのトピックです。

%<>%と%<:>% （または最終的には何であれ）はまったく同じ区別です。 したがって、答えはここでマットによってカバーされています：

http://stackoverflow.com/questions/7033106/why-has-data-table-defined-rather-than-overloading

@jangorecki

まず、ほとんどのユーザーは、参照によるものと値によるものの違いを知る必要はありません。 これを知っていることは、DTを使用するための前提条件ではありません。 おそらく、これがDT構文がDFに非常に近い理由です。 @mattdowleは、純粋関数型インターフェースを備えたDTを明確に設計できたはずです。 彼はしませんでした。 おそらく、理由の1つは、DTが代替品のドロップとして機能する可能性があることでした。

set*関数に関しては、これらは参照によって示される場合がありますが、より明確なset*ByRefという名前ではないことに注意してください。 これらの機能は、主に効率的な操作を実行し、DFをDTに変換し、キーを設定するために存在しているようです。 それらが参照による操作を示すために取られることができるということは二次的なようです。

:= 、私は彼が使用した理由@mattdowleビーイングは、ユーザーUCLAで尋ね思い出すと思います:=の代わりに= 。 IIRC、彼は=を使用できず、 :=が利用可能であると述べました。 IIRC、彼は=を使用することを好んだでしょう。

Rコミュニティの標準であるWRT（標準がないことで有名）magrittrは、広く使用され、議論されています。 OPは、それとの相互運用性が優れた機能になることを示唆しています。 同意します。 これについて疑問がある場合は、CRANページをご覧ください。 開発者は、独自のパッケージでmagrittrを使用しています。 さらに、パッケージの作成はRユーザーの大多数ではありません。 しかし、これは本当にトピックからの逸脱です。

あなたが提供する議論は、「割り当ては参照によるものであり、構文が異なるため、DTはmagrittrとは異なります」に該当します。 応答はまだです：実装は異なります、本当です。 ただし、ほとんどのユーザーにとって実質的に同じ操作であり、ユーザーの期待に準拠し、コンテキストから実際の操作を推測できるため、インターフェースは同じである必要があります。

@mattdowleは、純粋関数型インターフェースを備えたDTを明確に設計できたはずです。 彼はしませんでした。

彼がしなかったのはうれしい。 「純粋に機能する」にロックすることは、ユーザーがより速く、よりメモリ効率の高いコードを書くために使用できるようになったいくつかの重要な機能を削除することを意味します。 「純粋関数」フレームワークで使用するのは基本的に実用的ではないプロジェクト（つまり、アンカーモデリング）があります。

@jangorecki
全くもって同じ意見です。 しかし、私たちは当初の提案からDTのメリットへと逸脱し始めています。

@MichaelChirico

議論に悟りの感覚をもたらしてくれてありがとう。 参照は元の提案から少し外れていますが、賛成のポイントまたはOP提案を説明するのに役立ちます。

• 演算子の選択は任意です。 Matt Dowleは、 :=前にいくつか試しました。 ：彼は最初の標準最初に、より整合していた明白なものを試してみました<- 、 <<- 、 := 、それが利用可能だったのでちょうどつまずいたと醜い構文のために作られた選択肢。 彼が新しい演算子を定義するよりも既存の演算子を好むことは明らかでした。
• ユーザーは、割り当てが参照による割り当てによって行われることをコンテキストから理解できますが、それがどのように行われるかは問題ではありません。
• 等。

まず、すべてのRユーザーについて話すことについての主張はありませんでした。 それはばかげた主張です。 「ユーザーの期待」への言及は、私自身、おそらくOPと私の学生の何人かに対するものでした。

あなたが本当に自分自身を意味するときに「ユーザー」を指すことは、逆効果で気を散らす修辞的な装置です。 OPが「 %:>%は私には似合う」と言っていることにも気づいたかもしれません。

開発者の行動または不作為は別の赤いニシンであり、OPの提案/要求のメリットとは関係ありません。 これは、どちらの方法でも実際には意見を提供していない、かなり貧弱な権威への訴えの議論です。

私はそこで論点を主張していないので、それは権威への訴えではありません。 落ち着くのはあなたへのアピールとして。 これは決して実装されないかもしれないので、大騒ぎを延期することはできませんか？ 実装後に関数の名前を切り替えるのは簡単なことだと思います（もしそうなら）。その時点でどのような正確な機能を見ているのかがよくわかります。

実質的な議論に関する限り、次のようになります。

• 私はそれが非常に低いmagrittrが今まで使用しようとしていることを考える%<>%同じように、そのLHS上の複数のオブジェクトを変更するためにlist(x, y) %<>% logに類似し、 DT[, c("x", "y") := lappy(.SD, log), .SDcols = c("x","y")] 。
• 同様に、あなたは%<>%がx[ 2:4 ] %<>% logようなオブジェクトの一部を変更するために使用される可能性があることを私が見た最初のヒントです。これはDT[ 2:4, x := log(x) ]類似しています。

https://github.com/tidyverse/magrittr/issuesでこれらの機能のFRを見るのを楽しみにしています。確かにその機能を使用するので、FRが通過することを願っています。

@ franknarf1 、

取られたポイント; OPが「％：>％は私には似合う」と言っているのを見逃していました。

それにもかかわらず、それは私だけではありません。 OPは、最初にmagrittr構文を提案しました。 おそらく、彼は後で代替案を認めたにもかかわらず、それは良い考えだと思った。 私もそれが良い考えだと思っていました。それが私をここに連れてきた理由であり、これはそれを試した何人かの学生によって促されました。 おそらく、他にもあります。 とにかく、これを唯一の視点として却下することは、ちょっとしたポイントの脇にあります。

第二に、議論は実際、権威への訴えでした。 完全に落ち着いていますが、「落ち着くのも魅力」かもしれません。 いずれにせよ、その点は話題から外れているように思われ、OP提案のメリットに対処していません。 また、これが実施される可能性が非常に低いという事実は、提案のメリットとは関係がないようです。

それはあなたが正しいことをさらに認めなければなりません。 実装した関数の名前を変更するのは簡単です。 ただし、このような変更により、この機能を使用して開発されたコードが破損する可能性があります。 後で互換性のない変更でユーザーに負担をかけるのではなく、実装する前にインターフェースについて話し合うことに時間を費やすことは完全に理にかなっています。 議論をシャットダウンすることが有用な目的に役立つのかは不明です。

実質的な議論に関しては、彼らは、提案された%<>%構文に対処するよりも、magrittrの機能の向上を支持しているようです。 （個人的には、magrittrの人々があなたの提案、特に最初の提案を実行する必要があることに同意します。2番目の提案をそれほど使用するかどうかはわかりません。）magrittrの人々への提案に関係なく、何もありません。 DTが拡張機能を採用し、magrittr %<>%演算子を使用することと矛盾しています。 そして、私はまだ実際に読んでおらず、 %:=% （または代替）が%<>%よりも優れているという説得力のある議論をしています。

話題に戻るために、関連する議論を要約することが役立つかもしれないと思いました。

%:>%を支持する議論：

• DTパイプフォワード割り当ては、参照による割り当てを実装します。 これは、割り当てがどのように実装されているかをユーザーに明確にするため、演算子で区別する必要があります。 これにより、不必要な混乱を避けることができます。
• DTがmagrittrで（まだ？）サポートされていない追加機能を追加する場合があります（たとえば、複数の割り当て、部分的な割り当て）。 したがって、操作を区別するのが最善です。
• %<>%は他の選択肢と同じように恣意的であり、 %:>%はよりDTに似ています。

%<>%を支持する議論：

• magrittrはすでにパイプフォワード代入演算子を実装しており、広く使用されており、何でも標準のようです。 標準に従うことは、暗黙的ではありますが、新しいオペレーターを説明するために必要なドキュメントと説明の量がDT開発者の負担を軽減することを意味します。
• ユーザーはすでに:=のRHSでDTでmagrittrを使用しています。 さらに、いくつかの証拠は、ユーザーがmagrittr %<>%構文を期待/試したことを示唆しています。 それを採用することは、これらのユーザーの期待に一致するでしょう。
• コードをdplyr / magrittr <-> DTに移動すると、構文が似ている場合があるため、より簡単で簡単になります。
• 演算子の数が増えると、さらに複雑になります。 この場合、オペレーターはアクションを指定する必要があり、必然的に実装を指定する必要があるため、複雑さは不要です。これがジェネリックメソッドの動作方法です。
• %:>%は%<>%と同じくらい恣意的です。

コードをdplyr / magrittr <-> DTに移動すると、構文が似ている場合があるため、より簡単で簡単になります。

参照による変更がこの種の移植されたコードをひどく壊す方法を完全に見逃しています。
元のオブジェクトが変更されないことがわかっていた場所は、割り当て方法が変更されたために突然変更されます。そのため、演算子を区別する（そして、同じ行に値（コピー）で割り当てる可能性を維持することが重要です）。コードも）。

data.tableをコピーする場合とdata.frameをコピーする場合（dt2 <-dt）と同じ問題で、2番目の作業のみを行ったときに、元のdtが更新された理由について突然頭を悩ませます。

この正確な予防策は、オペレーターが何をするかについての正確な文書を必要とするため、最初のポイントも無効にします。別の文書を使用すると、正しい文書を簡単に見つけることができます。

@tensibai、

了解した。 したがって、アサーションの「可能性がある」部分です。

1:32の水、2016年11月2日には、Tensibaiの[email protected]は書きました：

コードを-dplyr / magrittr <-> DTに移動すると、より簡単になります。
場合によっては構文が似ている可能性があるためです。

参照による変更がどのようにひどく行われるかを完全に見逃しています
この種の移植されたコードを破ります。 あなたがあなたのオリジナルを知っていた場所
オブジェクトは変更されません割り当てメソッドが突然変更されます
変更、これが本当に演算子を区別することが重要である理由です
（そして、同じ行に値（コピー）で割り当てる可能性を維持するため
コードの）。

これは、data.tableをコピーする場合とdata.frameをコピーする場合と同じ問題です。
（dt2 <-dt）、突然、元のdtがなぜ
あなたが2番目だけで仕事をしたときに更新されました。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Rdatatable/data.table/issues/1208#issuecomment -257801913、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AC5xaxyWXkh4C7i5-GtjMFiQ0AY2L5BLks5q6EqIgaJpZM4FSJR5
。

コメントとフィードバックをありがとうございます。

ちょっとしたこと（何かが足りないかもしれません）：この特定のケースでは、参照による割り当てか値による割り当てかに違いはありませんか？ 私たちがやりたいのは、data.table内の1つ（または複数の列）を更新することです。 ユーザーは、古い列がどちらの方法でも上書きされることを知っています。 誤解の余地はありませんね。 対照的に、これはDTa=DTbとDTa=copy(DTb) （この機能リクエストでは説明していません）とは大きく異なります。ここでは、data.table自体を処理します。参照で割り当てるか値で割り当てるかに違いはありません。

@ my-R-help、

あなたの直感は正しいです。

この操作がどのように_実装_されるかはユーザーに違いはありません。 ユーザーの観点からは、結果は同じです。列の値が再割り当てされます。 いくつかの差別化が必要であると述べているいくつかの議論がありましたが、_理由_についての説得力のある説明はありませんでした。

%<>%構文を採用するというあなたの提案は正しいものです。 実装が_interface_とは異なることを正しく想定しており、操作を実行するための一般的で現存する慣行があるため、それを採用する必要があります。 実際、これは優れたソフトウェア設計手法に従います。

（ちなみに、「ありがとう（SIC）、％：>％は私には似合います」と言ったとき、私は少しがっかりしました。最初の直感と提案をもっと強く主張しませんでした。とにかく、提案に感謝します。DTで実装されているかどうかは素晴らしいです。）

クリストファー、お返事ありがとうございます。

明確にするために、私は個人的に%<>%を好みます。これは、magrittrとの整合性が高く、多くの人がそれを使用しているように見えるためです。 ただし、data.table開発者が別の演算子（ %:>% ）を好む場合は、それを使用することもできます（個人的にはmagrittrの方法を好みますが）。

多分私はそれをそのように表現すべきだった。 混乱を招いた場合は申し訳ありません。

ユーザーは、古い列がどちらの方法でも上書きされることを知っています。 誤解の余地はありませんね。

この操作の実装方法に違いはありません。 ユーザーの観点からは、結果は同じです。列の値が再割り当てされます。

ジョイン付きのフットガンの余地はまだあると思います。

同じ名前の副作用で2人の演算子の動作が少し異なると、エラーが発生しやすくなり、混乱を招きます。 それ以上の議論はできませんが、パッケージが基本関数をマスクするとき、またはパッケージをロードするときに別のパッケージ関数をオーバーロードするときにRが警告するのには理由があります。

私の意見では、副作用が異なる場合、少なくとも一部のユーザーが特定のオペレーターを持つことは違いを生みます。

_ボーナス_演算子を検索すると、ヘルプに2つの選択肢があるのではなく、間違いなくDTページで警告/制限を説明することになります。

ここでは、ユーザーインターフェイスではなく言語について話していますが、最終的なソフトウェアユーザーはXボタンの背後にある実装を気にしないことに同意しますが、プログラマーは関数の背後にある実装を気にしないことに同意します。

主な反対意見は次のとおりです。 %<>%がDTの外部と同じように動作すると考えている人は、意図しないときにDT列を傷つけると、頭がおかしくなります。

TL; DR：プログラミングはUXではありません。必要なものを具体的に指定する必要があるため、よく知られている名前を再利用することはできません。

@テンシバイ、

副作用がどういうわけか異なるという主張は疑わしいです。 いずれの場合も、変数の再割り当てが実行されています。 それらは両方とも副作用です。 両方のシステムの比較最終状態が類似した方法で変更されたため、実装（参照または値による）はこれらを真に区別しません。

副作用が異なっていても。 区別はかなり重要ではありません。 この点は、上記の議論で繰り返し提起されてきました。 区別が重要である場合、それがユーザーに違いをもたらす例を提供することが可能であるはずです。 決定的ではないが事実に反する例がないことは、区別がないことを強く示しています。

に関して：

必要なものを具体的に指定する必要があるため、よく知られている名前を再利用することはできません。

これは間違っています。 一般的でよく知られている名前の再利用は、発生するだけでなく、非常に一般的であり、優れたプログラミング手法と見なされています。 これはポリモーフィズムと呼ばれます。 異なる方法で実装された同じ名前のメソッドを使用することは完全に許容されます。

person.speak（）
"こんにちは世界"
dog.speak（）
"横糸"

いずれの場合もspeakが使用されました。 これは悪い習慣ですか？ いいえ。実際、ポリモーフィズムが採用されない場合、それは惨事になります。 すべての関数とメソッドには独自の名前があります。 これはオブジェクト指向言語に基づくかなり一般的な例ですが、Rも例外ではありません。 Rには、同様の方法で機能するS3メソッドとジェネリック関数があります。

その提案：

私は、プログラマーが関数の背後にある実装について気にするべきではないことに非常に同意しません。

同様に欠陥があり、ほとんどのユーザーエクスペリエンスに反しています。 ほとんどのプログラマーは、おそらく何百もの関数/メソッドを使用します。 彼らは彼らの実装の詳細を知らなくてもそうします。 ユーザーは、関数が役立つために入力と出力/副作用を知る必要がありますが、それがどのようにそこに到達するかはほとんどの場合無関係です。 確かに、ユーザーは関数を微調整またはデバッグするために詳細を知る必要がある場合がありますが、これは非常に少数のケースであると主張することができます。 ユーザーがすべての機能がすべてのレベルでどのように機能するかを知る必要があった世界を考えてみてください。 認知的負荷は計り知れません。 複雑なものをプログラミングすることは不可能な作業です。 に関して：

オペレーターを検索すると、ヘルプに2つの選択肢があるのではなく、間違いなく警告/制限を説明するDTページが表示されます。

これは_ボーナス_ではありませんが、a）混乱を招き（これは非常に人気のあるmagrittrパッケージ、exacltyとどのように異なりますか？）、b）そもそも追加の不要なドキュメントの必要性を生み出すことによる責任です。 magrittr構文の場合、DT開発者は次のように言うことができます。「そこに行ってドキュメントとビネットを読んでください。DTはそこで行っていることをサポートしています。」 この協力とクロスパッケージ借入は、DT、magrittr、およびRエコシステムの価値を高めます。 ）。

最後に、「ユーザーインターフェイス」、「Xボタン」、「UX」に関するコメントから、特定のUIが暗示されていることが推測される場合があります。 それは単にそうではありません。 そして、私たちが言語について話していることは十分に明らかですが、その言語にはインターフェースが欠けていると言うのは誤りです。 インターフェイスはその構文であり、重要です。

要約すると、問題は最終的に解決できます。

必要なのは、次の翻訳を処理することだけです。

DT[, a %<:>% fun] ## or "%:>%"

DT[, a := fun(a)]

そうですか？

aがシンボルではなく文字変数である場合、どのように動作する必要がありますか？

DT[, "a" %<:>% fun]

DT[, "a" := fun(a)]   ## this?
DT[, "a" := fun("a")] ## or this?

その長さが1でない場合はどうなりますか？

DT[, c("a","b") %<:>% fun]

DT[, c("a","b") %<:>% fun(a, b)]
DT[, c("a","b") %<:>% fun("a","b")]
DT[, c("a","b") %<:>% lapply(list(a, b), fun)]
DT[, c("a","b") %<:>% lapply(c("a", "b"), fun)]

個人的に言えば、かなり複雑になり、新しい問題を解決できないため、修正されないので閉じます。
私はそれについて合意しているので、本当に必要な場合はいつでも再開することができます。