Julia: abフィールドアクセス構文のオーバーロードを許可する

ミューテーター/アクセサーメソッドのシンタックスシュガーとしてドットを使用する機能は、多くの場合に役立ちます。 APIを壊すことなく構造フィールドをより複雑な抽象化に変換できるように、これを提供する言語でこれを常に評価してきました。

+1

私はこれを実装するための絶対に素晴らしい方法を持っています。

それについて話すことに興味がありますか？ この機能を使用することの知恵にますます懐疑的になっていますが、TomShortがDataFramesにこれを使用することに本当に興味を持っていることを知っています。

これは、現在私がやることを余儀なくだから、かなり立派（PyCall経由）Pythonコードを呼び出すことになるだろうa[:b]の代わりにa.b 。

@ JeffBezanson 、0.3でこれを持っている可能性はありますか？ PyCallとJavaCall（cc @aviks）の両方で、言語間の相互運用に最適です。

@JeffBezansonが_not_の場合、これをどのように実装するかについて何らかの方向性を示す可能性はありますか？ （ I have an absolutely awesome way to implement this. ）

私の経験では、ジェフに気に入らないバージョンを実装するよりも、ジェフに何かを実装させるためのより速く確実な方法はありません;-)

基本的な考え方は、実装することです

getfield(x::MyType, ::Field{:name}) = ...

フィールドごとにオーバーロードできるようにします。 これにより、「実際の」フィールドにアクセスして、透過的に作業を続けることができます。 適切なフォールバックを使用すると、 getfield(::MyType, ::Symbol)も機能します。

最大の問題は、モジュールが.に関して特別な動作をすることです。 理論的には、これはgetfield別の方法にすぎませんが、問題は、モジュール参照が基本的にグローバル変数のように動作するため、モジュール参照を_以前に_解決する必要があることです。 .動作では、これを特別なケースに保つ必要があると思います。 （＃タイプ）*（＃フィールド）の余分な関数定義を分析するため、コンパイラーの効率に関する懸念も少しあります。 しかし、そのためには、何が起こるかを見ていきます。

@JeffBezansonモジュール内のconst動作も参照していますか？ モジュールをエミュレートするユーザータイプがあり、動的フィールドルックアップの結果が実際に一定である場合にコンパイラーに通知できると便利です。 （別のアプローチは、実際のモジュールから始めて、失敗したjl_get_globalを「トラップ」し、オンデマンドで新しいバインディングを挿入できるようにすることです）

＃5395と組み合わせると非常に便利だと思います。 次に、未定義の関数またはメソッドMyMod.newfunction(new signature)への呼び出しをインターセプトし、オンデマンドで（おそらく大きな）APIへのバインディングを生成できます。 これは、私が推測する通常のconstバインディングとしてキャッシュされます。

単純なJuliaの初心者である私に、少し懸念を示しましょう。ドット演算子をオーバーロードする可能性は、フィールドアクセスの「純度」が何らかの理由で失われることを意味する可能性があると思います。

abを実行することが参照/値への単なるアクセスである場合、または背後で呼び出される巨大な関数機構が存在する可能性がある場合、ユーザーは一般に知識を失います。 それがどのように悪いのかはわかりませんが、それはただの気持ちです...

一方で、これは多くの場合（PyCall、Dataframes ...）のシンタックスシュガーに対する大きな願いであり、完全に理解できます。
多分それは..＃2614の時間ですか？

私はこれをサポートします。

しかし、純度は、一つは使用することができたとしても、それのために言いたいことがあるんnames(Foo)の実数成分かを把握するためにFoo 。

純度の議論は、私が持っている主な実際的な懸念と密接に関連しています。それは、タイプのフィールドが使用したい名前と干渉する場合に、名前の競合を処理する方法です。 DataFramesでは、列名としてのcolumnsとcolindexの使用を禁止することでこれを解決できると思いますが、これに対する人々の計画を知りたいと思いました。

MyTypeにフィールドfooがある場合、 getfield(x::MyType, ::Field{:foo}) = ...を禁止する必要があると思います。そうしないと、実際のフィールドへのアクセスが失われます（またはフィールドへのアクセスを強制する方法）。利用可能である必要があります）。
しかし、抽象型はフィールドについて何も知らないため、 getfieldは具象型に対してのみ定義できます。

（その間、私はC ++についてこれに出くわしました。）

それは大きな問題ではありません。 Core.getfield(x, :f)ようなものを提供して、実際のフィールドへのアクセスを強制することができます。

わかりました、多分私は売られています。 ただし、 Core.getfield(x, :f)へのショートカット（例： x..f ）を定義すると便利です。そうでない場合. 、すべてのシンボル（データフレーム、おそらく辞書）のCore.getfieldで混雑します。

私は純度の側面について心配していません-これができるまで、唯一のコード
フィールドアクセスを使用する必要があるのは、に属するコードです。
特定のタイプの実装。 フィールドアクセスがAPIの一部である場合、
他のAPIと同様に、それを文書化する必要があります。 私はそれが便利かもしれないことに同意します
ただし、core.getfieldのショートカット構文は、それらを作成するときに使用します。
実装。

＃4935ですでに指摘されていましたが、ここに引っ張ってみましょう。適切に使用しないと、ドットのオーバーロードが従来のJulian多重ディスパッチと少し重なる可能性があります。

getfield（x :: MyType、:: Field {：size}）=........。
i = 1：y.sizeの場合....。

の代わりに

size（x :: MyType）=.........。
for i = 1：size（y）...。

ドットはコレクション（データフレーム、ディクト、PyObjects）のアイテムにアクセスするのに最適ですが、オブジェクトのプロパティ（フィールドではない）へのアクセス方法を何らかの形で変更できます。

考慮すべきことの1つは、アクセスフィールドをオーバーロードできる場合は、フィールドの_setting_もオーバーロードできるはずだということです。 そうでなければ、これは一貫性がなく、イライラするでしょう。 そこまで行っても大丈夫ですか？

@nalimilan 、 setfield!に加えてgetfield setfield!が絶対に必要です。 （と同様にsetindex!対getindexについて[] ）。 これは物議を醸すとは思わない。

@stevengjに同意しsetfield!を実装します。

私はこれを支持します。

他の言語（C＃やPythonなど）での経験から、ドット構文には多くの実用的な価値があることがわかります。 特殊な方法で実装する方法は、主にパフォーマンスの低下の懸念に対処します。

ただし、メソッドの_インライン化可能性_がこの変更によって深刻な影響を受けないようにすることが重要です。 たとえば、 f(x) = g(x.a) + h(x.b)ようなものは、この着陸後に突然インライン化できなくなることはありません。

これを実現することにした場合は、プロパティの定義を簡単にするマクロも提供すると便利です。これは次のようになります。

# let A be a type, and foo a property name
<strong i="10">@property</strong> (a::A).foo = begin
    # compute the return the property value
end

# for simpler cases, this can be simplified to
<strong i="11">@property</strong> (a::A).foo2 = (2 * a.foo)

# set property 
<strong i="12">@setproperty</strong> (a::A).foo v::V begin
    # codes for setting value v to a property a.foo
end

舞台裏では、これらすべてをメソッド定義に変換できます。

<strong i="5">@property</strong> (a::A).foo =がgetproperty(a::A, ::Field{foo}) =よりもはるかに簡単だとは思いません...

いずれにせよ、より良いシンタックスシュガーは、基本的な機能が着陸した後に追加できるものです。

インライン化に関しては、周囲の関数をインライン化するかどうかを決定する前にフィールドアクセスがインライン化されている限り、なぜ影響を受けるのかわかりません。 しかし、おそらくこれは現在インライン化が行われている順序ではありませんか？

getproperty(a::A, ::Field{:foo}) =はコロンが多すぎるので私を襲います:-)これは些細なことであり、おそらく今は心配する必要はないでしょう。

私の懸念は、これがパフォーマンスの低下を引き起こすかどうかです。 内部コード生成メカニズムについてはよくわかりません。 @JeffBezansonはおそらくこれについて何か言うかもしれませんか？

フィールドアクセスは非常に低レベルなので、パフォーマンスが維持されていることを確認せずにこれを行うことはありません。

結局のところ、フィールドのオーバーロードが良い考えだとは確信していません。 この提案では、プロパティを設定する方法は常に2つあります。 x.property = valueとproperty!(x, value)です。 フィールドのオーバーロードが実装されている場合、作成者が特定のタイプに対してどのソリューションを選択したかが事前にわからないような完全な混乱に終わらないように、非常に強力なスタイルガイドが必要になります。

そして、フィールドがパブリックかプライベートかという問題があります。 フィールドのオーバーロードを許可しないと、型システムが明確になります。フィールドは常にプライベートになります。 メソッドはパブリックであり、型は、インターフェイス/プロトコル/トレイトを実装することを宣言できます。つまり、特定のメソッドのセットを提供します。 これは、S」@stevengj反するhttps://github.com/JuliaLang/julia/issues/1974#issuecomment APIを壊し回避するための方法でフィールドをオーバーロードについて-12083268：唯一のAPIの一部として、メソッド、および決してフィールドを提供します。

df[:a]はdf.aほど良くないので、フィールドのオーバーロードを後悔する唯一の場所はDataFramesです。 しかし、それだけでそのような大きな変更が必要になるとは思えません。 他のユースケースはPyCallのようです。これは、フィールドのオーバーロードを許可する必要があることを示している可能性がありますが、これは非常に具体的な非ジュリアンのユースケースに限られます。 しかし、機能が利用可能になったら、人々がその機能を誤用しないようにするにはどうすればよいでしょうか。 特別なモジュールで非表示にしますか？

@nalimilan 、可能な限りx.property構文を使用することをお勧めします。 重要なのは、人々はこの構文が_本当に_好きだということです–それはとても楽しいです。 このような優れた構文を採用し、オブジェクトへの内部アクセスにのみ使用する必要があると具体的に言うと、まったくひねくれたように見えます。「ああ、この優れた構文は存在します。使用しないでください！」 APIに醜い構文を使用させるのではなく、私的なものにアクセスするための構文を不便できれいにする方がはるかに合理的だと思われます。 おそらく、これは..演算子の良いユースケースです：プライベート_real_フィールドアクセス演算子。

私は実際、この変更により、物事がより明確になり、一貫性が失われるのではなく、より明確になると思います。 範囲を検討してください–現在、 step(r)とr.stepスタイルの恐ろしい組み合わせがあります。 特にFloatRangeを導入して以来、 step(r)を使用するコードのみが正しいため、これは危険です。 混合の理由は、範囲の一部のプロパティが保存され、一部が計算されるためです。ただし、これらは時間の経過とともに変化し、実際には範囲のタイプごとに異なります。 step(r)自体の定義を除いて、すべてのアクセスがstep(r)スタイルであると、より良いスタイルになります。 しかし、それに対していくつかの急な心理的障壁があります。 r.stepをデフォルトでr..stepに設定するメソッド呼び出しを行うと、人々は自然にやりたいことを実行できます。

悪魔の代弁者を（私と一緒に）演じるには、 r.lengthまたはlength(r)と書くべきですか？ Rubyがr.lengthスタイルに完全にコミットしているのに対し、ジェネリック関数とメソッドの間の不一致はPythonを苦しめている問題です。

以下のための1 ..のようにCore.getfield ！

@StefanKarpinski理にかなっていますが、プライベートフィールドの構文を追加する必要があり、インターフェイスはメソッドとパブリックフィールドの両方を指定する必要があります。 そして確かに、一貫性を確保するためのスタイルガイドが必要です。 lengthは難しいものですが、たとえばsizeもあります。これは非常に似ていますが、ディメンションインデックスが必要です。 この決定はワームの缶を開きます...

その場合、実際のフィールドにアクセスするための..と、メソッドまたは実際の値であるフィールドにアクセスするための.もサポートします。

悪魔の代弁者を（私と一緒に）演じるには、 r.lengthまたはlength(r)と書くべきですか？ ジェネリック関数とメソッドの間の不一致はPythonを苦しめている問題ですが、Rubyはr.lengthスタイルに完全にコミットしています。

この問題を明確にする可能性のある重要な要素は、何かを高階関数として使用できるようにするかどうかです。 つまりは、 fでf(x)何かであることができますmapコレクション以上、一方fでx.fない（短い書き込みのですx -> x.f ）–これはシングルディスパッチ言語のすべてのメソッドで同じ状況です。

なぜフィールドアクセスで停止するのですか？ x.foo(args...)をgetfield(x::MyType, ::Field{:foo}, args...) = ...と同等にするのx.size(1)を設定できます。 （私が私の提案を気に入っているかどうかはわかりませんが、考慮すべきことがあるかもしれません。あるいは、人々はOOに似たコードを書くだけなので、おそらくそうではありませんか？）

これは、この機能で可能になります。 それは私に一時停止を与えるものの1つです。 私はそのようなooスタイルのコードに問題はありません-私が言ったように、それはかなり快適で、人々はそれを本当に好きです-しかしそれは私たちがあなたがすべきことについての強力なポリシーを_本当に_必要とするものを書く方法に十分な選択肢をもたらしますあなたはあなたができることで非常に自由になるからです。

Juliaを学び始めたとき、ドットなしの構文は、オブジェクト指向プログラミングスタイルを精神的に手放すのに大いに役立ちました。 それだけで、私の提案は悪いと思います。

また、単純なオーバーロード（つまり、 a.b sans (args...) ）の場合、上記の@nalimilanのコメントに同意します。 問題＃4935では、フィールドはAPIの一部ではなく、メソッドのみである必要があるというコンセンサスがあるようです。 その結果、その問題は解決されるようです。 . -overloading構文を使用すると、通常のフィールドをAPIの一部にすべきではないことが明確になり、フィールドをAPIの一部にすることが推奨されます。

しかし、はい、 .構文は便利です...

どうですか：単一の.はgetfield(x::MyType, ::Field{:name}) = ...シンタックスシュガーである必要があり、フィールドアクセスは..まで_のみ_です（つまり、 .は現在何ですか）。

これにより、明確な区別が可能になります。

• .は、パブリックAPIが型インスタンスの値のようなものにアクセスするためのものです
• ..はフィールドアクセス用であり、通常はパブリックAPIで使用しないでください

もちろん、これは重大な変更になります。

これは基本的に私が提案していたことですが、 .デフォルトで..ため、壊れることはありません。

すみません、読み直してください！

しかし、デフォルトで..ない.は、パブリックAPIとは何か、そうでないものについて開発者に決定を強いるので、実際には良いかもしれません（壊れていることは別として）。 また、ユーザーが..使用する場合、コードが破損する可能性があると予想できますが、 .は破損しないはずです。

それは良い点です。 a.bデフォルトでa..bし、非推奨の警告を表示することで、このルートに進むことができます。

スタイルの観点から、私はずっと見たいと思います

a = [1:10]
a.length()
a.size()

より

a.length
a.size

何らかの形で型に格納されているプロパティだけが取得されるのではなく、関数が呼び出されているという考えを維持するのに役立つと思います（上記の「純度」の懸念に戻ります）。 他の言語のように物事が乱雑にならないように、この種のスタイルを確保するのに役立つ方法があるのだろうか。

私は本当に好きではありません

a.length()

それ以来、元のタイプに関数フィールドがあったかどうかはわかりません。 .がフィールドにアクセスしない場合、それは明らかに問題ではありません。 そうでなければ、それは私には混乱しているようです。

先験的に、私たちはa.length()またはa.lengthどちらもすべきではないと感じています。 しかし、問題はなぜですか？ r.stepとr.length違いは何ですか？ 違いますか？ それらに違いがない場合、 step(r)とlength(r)またはr.stepとr.lengthますか？

Stefanによって提案されたセマンティクスと私による追加により、 .常に関数呼び出しであるのに対し（ +も同様）、 ..は常にフィールドであることが明らかです。アクセス。

a.lengthなどが良い考えであるかどうかの問題について： .アクセスは、多かれ少なかれ、dictのエントリを使用するのと同じように、タイプの実際のデータにアクセスするためにのみ使用する必要があります。 。 size 、 length 、 stepなどの非データプロパティの関数を使用しますが、それらの一部には追加のパラメーターが必要になるため、 a.size(1)タイプの構文が正しくありません。

これがこのトピックに関する私の見解です：

• ドット構文は、タイプ/クラスの属性にのみ使用する必要があります。 これはゲッターだけでなくセッターについてもあり、 a.property() = ...ようなものは完全に間違っていると感じることを覚えておいてください。
• 関数がパブリックAPIを定義し、フィールドがプライベートであるという現在の状況が好きですが、ドット構文はあまりにも素晴らしく、パブリックAPIでは禁止できないというStefansの意見を共有しています。 ただし、これを単純な属性に制限してください。 a.lengthは良い例ですが、 a.size(1)は、追加の引数が必要なためではありません。
• .デフォルトで..ます。 ジュリアは定型的な言語として知られていません。 そのように保ちましょう

.デフォルトで..ます。 ジュリアは定型的な言語として知られていません。 そのように保ちましょう

私はこれに同意する傾向があります。 でも合成プロパティを設定するための構文は、ちょうどだろうa.property = b 、ないa.property() = b 。

確かに、構文としてのa.property()が私見ではない理由を明確にしたかっただけです

もっと明確に言うと、ドット構文で重要なのは、関数を型/クラスに関連付けることができるということではなく、ゲッター/セッターを適切に記述できることです。 また、ゲッター/セッターはデータのカプセル化にとって重要です（インターフェイスを安定させますが、実装を変更します）

この変更はAPI設計者の観点からは素晴らしいことですが、将来の不整合を制限するために、何らかのスタイルガイドが付属している必要があることに同意します。

これにより、dslのようなRubyが有効になります...

amt = 1.dollar + 2.dollars + 3.dollars.20.cents 

しかし、狂気のようなJavaに備えてください。

object.propert1.property2.property3 ....

ほんの少しの考え：

• 記号をキーとするディクトの.構文が最も必要です。 d.keyを使用してからd[:key]を使用する方が良いでしょう。 しかし、結局それは重要ではありません。
• a->propertyはa..propertyよりも読みやすいと思います。 しかし、これもそれほど大きな問題ではなく、julia構文で機能するかどうかはわかりません。

@BobPortmann私は同意し

プライベートフィールドにa->propertyを使用することは、Cハッカーをジュリアから遠ざけるための良い方法です;-)

私は..構文が好きです。

a->property構文はすでに話されています–これは無名関数です。 ただし、 a..b演算子は、しばらくの間使用されています。 dictのようなもので、オプションのフィールドがたくさんあるものが必要な場合があります。 そのためにgetter / setter構文を使用すると、dictインデックス構文よりも優れています。

「a-> property構文はすでに話されています-それは無名関数です。」

はい、もちろん。 ->周りにスペースがないと、そのようには見えません

スタイルガイドラインとして、property（x）を読み取り専用プロパティに使用し、x.propertyを読み取り/書き込みプロパティに使用することを推奨するのはどうですか？

書き込み可能なプロパティの場合、x.foo = barはset_foo！（x、bar）よりもはるかに優れています。

読み取り用にfoo(x)を使用し、書き込み用にx.fooを使用すると、非常に混乱します。 実際、これがプロパティの魅力です。 読み取りアクセスと書き込みアクセスに同じ構文を使用する、つまり、取得できる最も単純な構文（ゲッターとセッターの場合）

スタイルに関しては、この機能が実装された場合にx.lengthとlength(x)両方が必要かどうか、または後のフォームを非推奨にして削除する必要があるかどうかという大きな問題があります。

私の意見では、それを行う方法は1つだけで、将来はx.lengthのみを使用する必要があります。 そして、スタイルに関しては、とてもシンプルだと思います。 型の単純なプロパティであるものはすべて、フィールド構文を使用して実装する必要があります。 機能を持つ他のすべて。 私はC＃でプロパティを頻繁に使用しましたが、何かがプロパティである必要があるかどうかわからない場合はめったに見つかりませんでした。

ランダムに選択された1引数関数のセットをx.f構文に変更することに反対です。 @ mauro3は、これを行うと言語の性質があいまいになるという良い点を示したと思います。

a.bは、少なくとも視覚的には、一種のスコープ構造です。 bは、グローバルに表示される識別子である必要はありません。 これは決定的な違いです。 たとえば、上部の行列因数分解には.Uプロパティがありますが、これは実際には一般的なものではありません---グローバル関数Uは必要ありません。 もちろん、これは少し主観的です。特に、 U(x) = x.U簡単に定義できるためです。 しかし、 lengthは別の種類のものです。 ファーストクラスである方が便利です（例： map(length, lst) ）。

これが私が提案するガイドラインです。 foo.bar表記は、次の場合に適切です。

1. fooには、実際にはbarという名前のフィールドがあります。 例： (1:10).start 。
2. fooは、関連するタイプのグループのインスタンスであり、その一部には実際には.barという名前のフィールドがあります。 fooに実際にbarフィールドがない場合でも、そのフィールドの値はそのタイプによって示されます。 例： (1:10).step 、 (0.1:0.1:0.3).step 。
3. fooはbar明示的に格納しませんが、同等の情報をよりコンパクトまたは効率的な形式で格納するため、使い勝手が悪くなります。 例： lufact(rand(5,5)).U 。
4. PythonやJavaなどの別のAPIをエミュレートしています。

barプロパティをケース1と3で割り当て可能にするのは理にかなっていますが、2ではない場合があります。ケース2では、値のタイプを変更できないため、 barプロパティを変更することはできません。それはそのタイプによって暗示されます。 このような場合、他の関連するタイプのbarプロパティの変更を、それらを不変にするか、 foo.bar = baz明示的にエラーにすることによって禁止する必要があります。

@tknopp 、私は書き込みにx.fooを使用し、読み取りにfoo(x)を使用することを提案していませんでした。 私の提案は、プロパティが読み取りと書き込みの両方である場合、おそらくx.foo読み取りと書き込みの両方を行うことをお勧めします。

@StefanKarpinski ：しかし、 lengthは3の場合ではありません。ここで、サイズは通常保存されるものであり、 lengthはサイズの積です。

この変更により、これらの関数はもはやファーストクラスではなくなるとジェフスは指摘しています。

@stevengj ：なるほど。 混乱してすみません。

@tknopp –長さはサイズから導き出されますが、それらと同等ではありません。 サイズがわかっている場合は、長さを計算できますが、その逆はできません。 もちろん、これは少しぼやけた線です。 これがlufact受け入れられる主な理由は、それよりも優れたAPIを見つけられなかったためです。 別のアプローチは、一般的な行列の上三角部分と下三角部分を与えるupperとlowerジェネリック関数を定義することです。 ただし、このアプローチは、たとえばQR分解に一般化されていません。

pycall、因数分解、そしておそらくデータフレームなど、この構文を_本当に_要求しているように見えるケースはごくわずかであることがわかります。
f(x)対x.fランダムなごちゃ混ぜになってしまうのではないかとかなり心配しています。 それはシステムを学ぶのをはるかに難しくするでしょう。

@StefanKarpinskiのリストのポイント1は、タイプのフィールドが自動的にパブリックAPIに属することを意味しませんか？

現時点では、モジュールのパブリックAPIとは何か、エクスポートされたすべての関数とタイプ（フィールドは除く）がわかります。 この変更後、どのフィールドがパブリックAPIに属しているのか、どのフィールドに属していないのかを判断できなくなります。 Pythonのように、プライベートフィールドにa._foo程度の名前を付けることもできますが、それはあまり良くないようです。

個人的には、DataFramesのケースは少し不必要だと思います。 これを行う場合、DataFramesに機能を追加しますが、一貫性の喪失は、数文字を保存するよりもはるかに厄介です。

また、DataFrames、PyCallに依存して決定を下すことはしません（そしてGtkもそれを望んでいます）。 フィールドはパブリックインターフェイスの一部である必要があると考えているため（「見栄えが良い」ため）、または必要ありません。

... pycall..。

およびJavaCall

これの主な使用例は非Juliaシステムとの相互作用であるように思われるので、 .をオーバーロードする代わりに、提案された..演算子を使用するのはどうでしょうか。

ここでのより単純な解決策は、OOに対するより一般的なヒントであるかどうか疑問に思います。

#we already do
A[b] => getindex(A,b)
#we could have
A.b(args...) => b(A, args...)
# while
A..b => getfield(A,::Field{:b})
# with default
getfield(A, ::Field{:b}) = getfield(A, :b)

これにより、JavaCall / PyCallがクラス内でメソッド定義を実行できるようになりますが、非常に透過的なA.b()は単なる書き直しですが、OOタイプのコードが必要な場合は一般的なスタイルも許可されます。 これは、オブジェクト指向から来る人々にとって非常に自然なことだと思います。
また、新しいgetfieldとA..bを使用して、そこでのオーバーロードを許可しますが、ここでのオーバーロードは強くお勧めできません。 getfield(A, ::Field{:field})のオーバーロードのわずかな怖さのため。

@ mauro3 ：

@StefanKarpinskiのリストのポイント1は、タイプのフィールドが自動的にパブリックAPIに属することを意味しませんか？

これは、必要なときではなく、 foo.bar表記を使用しても問題がない場合のリストでした。 「プライベート」フィールドのfoo.bar表記を無効にすると、 foo..bar介してのみアクセスできるようになります。

@karbarcca ：あなたがここで何を提案しているのかはっきりしていません。

fwiw、私は慣習による大人の同意アプローチを採用し、 .完全に過負荷にできるようにするのが好きです。 二重点の提案は、混乱を減らすのではなく、増やすことにつながると思います。

@ihnorton –フィールドアクセスの（オーバーロード不可能な）コア構文としてa..bを使用することに反対するのか、オーバーロード可能な構文にa..bを使用するのに反対するのか。

ジュリアの最高の機能の1つは、そのシンプルさです。 x.yオーバーロード

@StefanKarpinskiしかし、これは、デフォルトのプライベートフィールドからデフォルトのパブリックフィールドへのパラダイムのかなりのシフトを意味します。

私がちょうど持っていた認識、おそらくこれはずっと他の人に明らかでした。 完全なOOスタイルのプログラミングは、基本的な.オーバーロードで実行できます（醜いですが）。 定義

getfield(x::MyType, ::Field{:foo}) = args -> foofun(x, args...) # a method, i.e. returns a function
getfield(x::MyType, ::Field{:bar}) = x..bar+2                  # field access, i.e. returns a value

その後、 x.foo(a,b)とx.bar機能します。 したがって、 x.size(1)を実装する必要があるのか​​、それともx.sizeのみを実装するのかについての議論は議論の余地があります。

@StefanKarpinskiは、一般的に過負荷のa..b 、 a..b -> Core.getfield(a,b)について

ここで別のオペレーターの必要性がわかり始めましたが、 a..bはあまり説得力がありません。 2人のキャラクターが必要なのはとても... 2番目のクラスです。 たぶんa@b 、 a$b 、またはa|b （ビット演算子はそれほど頻繁には使用されません）。 外部の可能性もa b`であり、パーサーはおそらくコマンドと区別できます。

プリミティブフィールドへのアクセスに「醜い」演算子を使用しても大丈夫です。 経験上、具体的な操作であるため、ほとんど使用されておらず、使用するのはやや危険であることがわかっていると思います。

コンベンション/書き換えによってOOシングルディスパッチのシミュレーションを許可することを提案しています：

type Type end
# I can define methods with my Type as 1st argument
method(T, args...) = # method body
t = Type()
# then I can call that method, exactly like Java/Python methods, via:
t.method(args...)
# so
t.method(args...) 
# is just a rewrite to
method(t, args...)

ここでの正当化は、getindex / setindex！に対して同様の構文の書き換えをすでに行っているため、これを使用して完全なOO構文を許可しましょう。 そうすれば、PyCallとJavaCallはする必要がありません

my_dna[:find]("ACT")
# they can do
my_dna.find("ACT")
# by defining the appropriate find( ::PyObject, args...) method when importing modules from Python/Java

getindex / setindexと同じようにかなり明確な変換であるため、これが好きですが、特にOO言語パッケージの場合は、必要に応じて単一のディスパッチOOシステムをシミュレートできます。

次に、フィールドアクセスに..演算子を使用し、オーバーロードするオプションを使用することを提案しました。 ここでの使用は、PyCall / JavaCallが..への呼び出しをオーバーロードすることによってフィールドアクセスをシミュレートできるようにし、DataFramesが列アクセスのために..をオーバーロードできるようにすることです。これは、の新しいデフォルトのフィールドアクセスでもあります。あらゆるタイプの一般。

純粋な構文の書き直しにはソフトスポットがあります。 今すぐa.f(x)記述して機能させることができるのは間違いなく悪いことですが、ほとんどのオブジェクト指向言語とは紛らわしいほど異なる意味を持っています。

もちろん、そのコインの反対側は恐ろしいスタイルの断片化であり、 a.fがa.f()と何の共通点もないという事実は、幻想をすぐに崩壊させます。

ジュリアの最高の機能の1つは、そのシンプルさです。 x.yオーバーロード

ここでも同じ気持ち。 これが実際に必要なのが限られた数の相互運用型である場合、型宣言で明示的に要求された場合にのみ有効にするのはどうでしょうか。 たとえば、 typeとimmutable以外の追加のキーワードは、 ootypeなどになります。

そして、afがaf（）と何の共通点もないという事実は、幻想をすぐに崩壊させます。

これが@JeffBezansonの意味を明確にできますか？

a.f()機能する場合、 a.fはある種のメソッドオブジェクトであると思います。

ああ、わかった。 ええ、あなたは間違いなくmap(t.method,collection)ようなことをすることができないでしょう。

@ mauro3に同意します。 obj.method(...)許可すると、新しいユーザーがjuliaをPythonやRubyなどと競合しようとしている別のオブジェクト指向言語と見なし、十分に評価できないリスクがあります。複数のディスパッチである素晴らしさ。 もう1つのリスクは、これまでに開発されたよりジュリアンなスタイルとは対照的に、これがユーザーがより精通しているものであるため、標準のooスタイルが優勢になることです。

DataFrames以外のユースケースはオブジェクト指向言語との相互運用に制限されているので、これはすべてマクロで処理できますか？ つまり、 <strong i="8">@oo</strong> obj.method(a)はmethod(obj,a)ますか？

@karbarccaこれは、すべてが自動的に2つの方法で記述できることを意味します。

x = 3
x.sin()
sin(x)
x + 2
x.+(2) # ?!

@karbarcca https://github.com/JuliaLang/julia/issues/1974#issuecomment -38830330

t.method（args ...）
＃は単なる書き直しです
method（t、args ...）

オーバーロード可能なドットを使用してpyobj.func pyobj[:func]を呼び出すことができるため、PyCallではこれは必要ありません。 その場合、 pyobj.func()は実際には(pyobj.func)()ます。

a.foo(x)をfoo(a, x)として書き換えても、PyCallの問題は解決されません。これは、 fooがJuliaメソッドではなく、Juliaメソッドになることもできないため、実行時に動的に検索する必要があるためです。 。 getfield{S}(::PyObject, ::Type{Field{S}})が正しいことを実行できるように、 a.foo(x)をgetfield(a, Field{:foo})(x)または同様のもの[またはおそらくgetfield(a, Field{:foo}, x) ]に書き換える必要があります。

@JeffBezanson https://github.com/JuliaLang/julia/issues/1974#issuecomment -38837755

ここで別のオペレーターの必要性がわかり始めましたが、a..bはあまり説得力がありません。 2人のキャラクターが必要だととても感じます...セカンドクラス

一方、 ..は、Shiftキーを押す必要がないため、 $ 、 @または|よりもはるかに速く入力されます。 、そして2人のキャラクターである間、指は同じキーに留まります：smile：

@stevengjああ、なるほど。 しかし、私の主張は、書き換えはマクロで実行できるということです。

JavaCallの場合、実際に必要なのは基本的にunknownPropertyハンドラーだけです。 私は実際に既存のプロパティの読み取りまたは書き込みを書き換えたり傍受したりする必要はありません。 では、「xが既存のプロパティでない場合にのみaxがgetfield（a、：x）に書き直される」というルールは、物事を正気に保つのに役立ちますか？

@simonbyrne 、マクロを必要とすることは、クリーンで透過的な言語間呼び出しの欲求を打ち負かすでしょう。 また、確実に動作させるのは難しいでしょう。 たとえば、 type Foo; p::PyObject; endがあり、オブジェクトf::Fooに対してfoo.p.barを実行するとします。ここで、 barはPythonプロパティルックアップです。 foo.p.barの2つのドットの意味を確実に区別できるマクロを想像するのは難しいです。

正直なところ、私はスタイルに大したことは見ていません。 高品質のパッケージは、可能な場合はBaseやその他のパッケージのスタイルを模倣し、何をしても奇妙なコードを書く人もいます。 マニュアルの後のセクションでドットのオーバーロードを配置し、慎重に選択されたいくつかのケースでのみ使用することをお勧めします（たとえば、言語間の相互運用性、読み取り/書き込みプロパティ、おそらくfactor.Uなどの名前空間の汚染を回避するため） 、そして一般的にfoo[:bar]よりクリーンな代替手段として）、すべてにドットを使用するパッケージでオーバーランすることはないと思います。 主なことは、_we_が何を使用するかを決定し、これを推奨することです。おそらく、推奨される使用法のリストを非常に短くし、実際のニーズが発生した場合にのみ拡張する必要があります。

foo.bar(...)にtype Foo; bar(...) = ....; endような非常に簡単なOOのような構文を追加していないので、初心者の誘惑も制限されます。

私は基本的にここで@stevengjに完全に同意してa..b好きです。

1. a.b似ています
2. あるべきであるため、あまり便利ではありません
3. あまり便利ではありません
4. 既存の意味はなく、1年以上にわたって説得力のある使用法は見つかりませんでした
5. a b`のように恐ろしく奇妙ではありません

この変更により、おそらく（https://github.com/JuliaLang/julia/issues/2403）Juliaの構文のほぼすべてがオーバーロード可能になりますか？ （私が考えることができる唯一の例外は三項演算子です）ほとんどすべての構文がオーバーロード可能なメソッドディスパッチに下げられていることは、私にとって非常に統一された機能のようです。

私はそれが実際には一種の単純化であることに同意します。 三項演算子と&&と||は実際には制御フローなので、それはちょっと違います。 もちろん、そのようなものは、 a..b実際のフィールドアクセスにすることに反対します。それ以来、_that_が唯一のオーバーロード不可能な構文になるでしょう。 しかし、それでもそれは良い考えだと思います。 一貫性は良好ですが、それ自体のために最優先事項ではありません。

ああ、オーバーロードできない関数呼び出しもあります。 とても基本的な私はそれを忘れました。

それが問題＃2403が対処するものです。

うん。 しかし、これはそれよりもはるかに起こりそうです。

ここでの私にとっての唯一の問題は、モジュールに実際のフィールドアクセス演算子を使用するのが本当に良いことですが、誰もPackage..fooを書きたくないので、おそらくそれは起こりません。

ドットの後にタブを完成させるのは少し醜いです。 技術的には、 x.が呼び出す可能性のあるメソッドをチェックして、オブジェクトフィールド名またはモジュール名を一覧表示することが適切かどうかを確認する必要があります。 そして、誰もgetfield(::Module, ...)を定義しようとしないことを願っています。

タブの補完は次のように実行できると思います。 foo.<tab>は「パブリックフィールド」をリストし、 foo..<tab>は「プライベートフィールド」をリストします。 モジュールの場合、それだけのデフォルト実装できるようにOKだろうMod.foo可能Mod..fooとばかりにGETFIELDメソッドを追加していない人々に伝えるModule ？ つまり、言語で整数の加算を再定義することはできます。すべての地獄が解き放たれ、セグメンテーション違反が発生しますが、それを防止しようとはしていません。 これはそれより悪くなることはありませんね。

プログラミング言語は実際には名前付けだけを気にするので、実際にはそれよりもわずかに悪いです。 名前の解決は、整数を追加するよりもはるかに重要です。

Mod.fooデフォルトでMod..fooにする以外に選択肢はありませんが、場所によってはブートストラップにMod..fooを使用する必要があります。 ..演算子は、フォールバックを定義するためにCore.getfieldを呼び出すことさえできないため、ここでは非常に役立ちます。 これを使用すると、おそらくCore.getfieldを削除するだけで、 ..しかありません。

それは公正な点です–命名はプログラミングにおいて一種の大きな問題です:-)。 行くには良い方法のように思える-のみ..なしCore.getfield 。

この2つのアイデア、

[...]ドットのオーバーロードをマニュアルの後のセクションに置き、慎重に選択されたいくつかのケースでのみ使用することをお勧めします@stevengj https://github.com/JuliaLang/julia/issues/1974#issuecomment -38847340

そして

[...]可能な限りx.property構文を使用することをお勧めします： //github.com/JuliaLang/julia/issues/1974#issuecomment -38694885

明らかに反対している。

最初のアイデアを選択する場合は、「慎重に選択したケース」に対して新しい..演算子を作成する方が理にかなっていると思います。
利点として、現在[:name]が使用されている場合（DataFrames、Dict {Symbol、...}）に..nameを使用すると、フィールドアクセスとは異なることを明確に示しながら、入力/構文がよりわかりやすくなります。起こっていました。 さらに、 ..nameの二重ドットは、回転したコロン、シンボル構文:nameヒントと見なすことができ、タブの補完にも問題はありません。
不利な点として、PyCallらでの使用。 元の構文にそれほど近くはありません（ .実際に使用する必要がある場合は混乱する可能性もあります）。 しかし、正直に言うと、JuliaはPython構文と完全に互換性があるわけではなく、Pythonで簡単な命令を実行するために、PyCallを使用してJuliaで多くの入力を行う必要がある場合が常にあります。 ..をエミュレートするための.は、ここでバランスをとることができます。 （誤解しないでください。私はPyCallが本当に好きで、特別な注意が必要な重要な機能だと思います）

私が現在好んでいる2番目のアイデアは、 property(x)またはx.propertyいつ使用する必要があるかについて大きな決定を下します。そのようなものが存在する場合は、エレガントでありながら明確な定義が必要です。 。
オーバーロード可能な.が必要な場合は、そもそもx.property APIスタイルを好むからだと思われます。
とにかく、私は.オーバーロード可能なフィールドアクセス演算子としてではなく、デフォルトでオーバーロード不可能なフィールド演算子..設定されるオーバーロード可能な「プロパティ」アクセス演算子（ getprop(a, Field{:foo})かもしれませんか？）として見たいと思います。 .. 。
他の決定も行う必要があります。たとえば、フィールドアクセスの具体的な実装コードで使用される..または. ？ たとえば、範囲ステップの例の場合、慣用的になりますか？ step(r::Range1) = one(r..start)またはstep(r::Range1) = one(r.start) ？ （ stepがメソッドであるかプロパティである必要があるかという質問は言うまでもありません）。

そのため、私はその角度から離れて、次の基準を提案しました： https ：//github.com/JuliaLang/julia/issues/1974#issuecomment-38812139。

この興味深いスレッドを読んでいるときに頭に浮かんだのは、たった1つの考えでした。 エクスポートを使用してパブリックフィールドを宣言できますが、すべてのフィールドは定義モジュール内に表示されます。例：

module Foo
   type Person
     name
     age
   end
   export Person, Person.name
   <strong i="6">@property</strong> Person :age(person) = person..age + 1
end

この状況では、エクスポートされたPersonは「name」および「age」のように見えますが、この場合、ageは1を追加する関数を介して読み取り専用になります。 すべてのPersonのエクスポートは、exportPerson。*などとして実行される場合があります。

[pao：引用符]

@emeseles Juliaコードのようなものを引用する場合は、バッククォートを使用するように注意してください。これにより、フォーマットが維持され、Juliaのマクロが同じ名前のユーザーに対してGitHub通知を作成できなくなります。

.と..は紛らわしいです：明確で覚えやすい悪行税は良いものです

これができるのを本当に楽しみにしています。 これは、0.4プロジェクトとしてフラグを立てるのに十分な大きさの変更（または＃5848のWIP）ですか？

はい、それは間違いなくプロジェクトです。

私たちのほとんどは、少なくともそもそも、推奨される使用法を制限する必要があることに同意していると思います。 私の考えでは、最初は相互運用性（PyCallのように他の言語との相互運用性、より一般的にはドット表記が自然な外部ライブラリ）と、おそらく可変状態のオブジェクト（ get_foo(x)以降）の2つの使用法にのみ推奨する必要がありますset_foo!(x, val)は醜いです）。

外国との相互運用性のためだけにそれを推奨したとしても、私の意見では、その目的だけでこの機能を正当化するのに十分です。 ジュリアのような新しい言語にとって、ソフトウェアの世界の他の部分とスムーズに話すことは非常に重要です。

スティーブン、私はゲッター/セッターについて100％確信が持てません。それはすぐに矛盾につながるのではないかと心配しているからですが、他のユースケースには同意します。 その上、Gtk.jlには、構文の恩恵を受ける動的プロパティがあります。 私の個人的なお気に入りは、Stefanが＃5842で概説した列挙型の実装です。

バンプ。 この問題の進行を妨げているのは何ですか？ 決定が必要ですか、それともこの問題はまだ行われていない他の内部変更に依存していますか、それともコーディングだけですか？

この問題の進行を妨げているのは何ですか？

仕事をしている人と、それが正しいことかどうかについて躊躇している人。

@ihnortonはすでに＃5848で初期ドラフト実装を行っていることに注意してください。 これが望ましい機能であるかどうかについて、Juliaコアチームからの明確な声明が必要なため、作業が停滞していると思います。

私はこれに乗っています。 @JeffBezansonはフェンスにいるようです。

私にとって、この機能があれば、大規模なPythonコードベースからJuliaへの移行が簡単になります。 学生に説明すると、Pythonコードを使用する場合、以前とはまったく異なる構文が必要になるため、これが困難になる可能性があります。

このスレッドで上記の議論がありましたが、まだ完全な合意は見られません。 現在、パブリックAPIは関数/メソッドで構成されており、プライベートAPIは複合型のフィールドであると考える人もいます。 このスキームからは非常にまれな例外が見られます。 （LU分解で.U ？）

Pythonのアクセスと列挙型はこれが役立つ場合であるため、これは私がこれに反対しているという意味ではありません。 それでも、ここでの必要性がどれほど緊急であるか、そして開発サイクルの終わりにこれをプッシュすることが賢明であるかどうかを疑問視することができます。

@ ufechner7 、私は主な動機が言語間の相互運用であることに同意します。 @tknopp 、私たちはこのようなことについて全会一致で合意することは決してありません。 最終的には、 @ JeffBezansonと@StefanKarpinskiが決定することになります。

ためらいの多くは、ジェフの最悪の悪夢かもしれないと私が想像することに起因していると思います。

module DotOrientedProgramming
  Base.getfield(x, ::Field{:size}) = size(x)
  Base.getfield(x, ::Field{:length}) = length(x)
  ⋮
end

私もこれを非常に嫌います-このようにそれを誤用することを決定したパッケージは、私自身を含むシステムの_すべての_タ​​イプに誤用を課します。 この機能は非常に強力で、Juliaの記述方法を変更します。 より良くそして（おそらく、しかしうまくいけばそうではない）より悪い。

はい、確かにスティーブン、それは私から適切に表現されていないかもしれません。 私が言いたかったのは、この変更が言語の進化に大きな影響を与える可能性があるということです。 また、別の問題で取り上げている「正式なインターフェイス」のアイデアは、 .オーバーロード可能にすることによる影響も受けています。 そうです、 @ JeffBezansonと@StefanKarpinskiに決めさせてください。 それでも問題は、決定を今すぐ実施する必要があるかどうかです...

その価値については、ほとんどすべての構文をオーバーロード可能にし、文化に依存して、あまりにも大げさになりすぎないようにすることを好むようになりました。

+1 。 ここには、 callオーバーロードに類似した強力な哲学的（そしておそらく実用的な...）があると思います。 マニュアルには、 Don't do stupid stuff: we won't optimize thatというタイトルのセクションが必要です。 （もちろん、 callオーバーロードは、パフォーマンス上の理由の一部でしたが、悪用される可能性があります）

• ：100：それに。 文化はこれを乱用しないための十分な動機になるはずだと思います

全体的に、私は賛成です。 虐待の可能性は私の最大の心配ではありません。 私にとって大きな問題は

• 「実際の」フィールドアクセスに使用できる構文。 a..bはあまり好きではありません。
• モジュール。 修飾名は非常に重要です。 メソッドディスパッチでそれらを表現することは可能ですが、実際的な困難があります。 つまり、修飾名があることを知るためだけに、多くのコンパイラフェーズを（おそらくインライン化を介して）実行する必要があります。 これにより、ASTを使用するツールを作成する人の生活が困難になります。 また、このようなツールでこのケースを誤って処理することも非常に簡単になります。

これらの問題は、両方に同じ構文を使用することで一気に解決できますが、現時点でモジュールに.以外のものを使用することを想像することはほぼ不可能です。 _内部的に_モジュール参照の抽象構文は間違いなくあります。 それを明らかにする良い方法がなかったら、それはイライラするでしょう。

この質問に対する私の2セント：修飾名に:を使用してみませんか？ これは、同様の目的ですでに使用されています。

import Base: call, show, size

これは次のようなものを与えるでしょう

module Foo
    module Bar
        f(x) = 3*x
    end
    const a = 42
end

<strong i="10">@assert</strong> Foo:a == 42

Foo:Bar:f(789)

それとも、すでに:記号を使いすぎているのでしょうか。 ::記号（C ++スタイル）は、私には冗長すぎるようです。

:は、すでにJuliaで最も過負荷になっているシンボルなので、役に立たないのではないかと思います。

module.nameをオーバーロードできないようにすることで、修飾された命名の問題を単純化できますか？ モジュールバインディングは一定であるため、同じセマンティクスを維持できますが、 a.bのLHSがモジュールであることがわかるとすぐに、修飾名ルックアップの通常のロジックをすべて短絡します。 モジュールで名前を検索することの意味を人々が上書きできないようにすることはかなり合理的だと思います。

私は実際のフィールドアクセス用のa..b構文が好きです。 それに対するあなたの異議は何ですか？

余談ですが、いくつかの機能言語のようなインポートリストに( )を使用したかったのですが。 すなわち：

import Base (call, show, size)

私の理由は、コンマをオプションにして、末尾のコンマを許可できるからです。 インポートされた名前のすべてに末尾のコンマが必要なのは本当にうっとうしいです。

はい、 a.bを「 aがモジュールの場合は、最初にモジュール検索を実行する」という意味にする可能性について言及しようとしていました。 それは役立つかもしれません、そして私たちは確かにモジュールルックアップの意味を上書きしたくありません。 ただし、 a.bを呼び出しgetfield(a,:b)として表すことができないため、複雑なコストがかかります。 暗黙の分岐を持つ特別なASTノードである必要があります。 もちろん、_explicit_ブランチを使用することもできますが、それによるASTの肥大化が心配です。

フロントエンドとバックエンドのニーズの間のこのような大きな対立から抜け出す簡単な方法はないようです。

他のみんながa..b好きなら、私はそれと一緒に暮らすことを学ぶことができると思います。 それはまったく異なる何か、おそらく間隔を意味するように私には見えます。

a..bも嫌いですが、なぜそれが必要になるのか疑問に思います。 このスレッドを読むと、オーバーロードは言語ラッパーと実際のフィールドアクセスが不要な動的ユースケースでのみ使用されるという印象を受けます。

ある時点で、オブジェクトを操作するためにオブジェクトの表現にアクセスする必要があるためです。 これは比較的まれであり、 get_actual_field(a,:x)ように醜い可能性があると主張する人もいるかもしれませんが、これは構文を持たない操作としては重要すぎるようです。

わかりましたが、これは、誰にも使用してほしくない構文を探しているように聞こえますか？

..を提供しないこと

それがドット指向プログラミングをどのように妨げるのかわかりません。 上記の@mbaumanの例を引き続き実行できます。

a..b構文は区間のように見えますが（私はそれをそのように使用しました）、区間演算に独自の入力構文が必要だとは思いません。 Interval(a,b)書くだけです。それは何年もの間ジュリアの演算子であり、誰もそれをほとんど何にも使用していないので、他に誰もその構文を使用したいと思うことはほとんどありません。 また、フィールドアクセスのように見えます。

これに対する1つの銀の裏打ちは、恐ろしいmodule_nameをm..name置き換えることができるということです。 モジュールオブジェクトのフィールドにアクセスできないことは、いぼでした。

はい、 a.bを「 aがモジュールの場合は、最初にモジュール検索を実行する」という意味にする可能性について言及しようとしていました。 それは役立つかもしれません、そして私たちは確かにモジュールルックアップの意味を上書きしたくありません。 ただし、 a.bを呼び出しgetfield(a,:b)として表すことができないため、複雑なコストがかかります。 暗黙の分岐を持つ特別なASTノードである必要があります。 もちろん、_explicit_ブランチを使用することもできますが、それによるASTの肥大化が心配です。

a.b無条件にgetfield(a,:b)を意味し、 getfield(::Module, ::Field)メソッドと交差するメソッドをgetfieldに追加することをエラーにすることで、これを処理できますか？ これは、その動作を強制するための奇妙な方法のようなものですが、最終的には同じ効果があります。 次に、下げることは、チートするためにそれを行うことができないことがわかっているという事実を使用して、修飾名の検索にmodule.nameを下げることができます。

逆に言えば、このスレッドの誰かが..を使用しますか？はいの場合、典型的なユースケースは何でしょうか？ （つまり、内部フィールドアクセスを完全にシャドウイングしても問題ない可能性があります）

@StefanKarpinskiはい、

@tknopp module..nameとmodule..parentへのアクセス:)また、明確にするために、低レベルのフィールドアクセス用にget(obj,:field)ような関数呼び出し構文を提唱していますか？

いいえ、特定の構文を推奨していません。 この機能が必要な理由とユースケースを確認するのは良いことだと思います。 動的なユースケースの場合、それは問題ありません

• a.bは、 Base.getfield(a, ::Field{:b})が定義されていない場合のフィールドアクセスです。
• a.b Base.getfield(a, ::Field{:b})が定義されている場合、 a.bは動的バージョンです。 この場合、実際のフィールドアクセスはシャドウされる可能性があります

私の質問は、シャドウイングがうまくいかないユースケースがあるかどうかでした。

はい; pyobject.xを定義して、すべてのxについて、 xが常にpyobjectのディクショナリで検索されるようにすることができます。 次に、pyobjectのjuliaフィールドにアクセスするために別のメカニズムが必要です。

ああ、それでそのすべてか無か？ どういうわけか、

type A
  c
end

Base.getfield(a::A, ::Field{:b}) = 3

a = A(1)

a.c # This still calls the field access
a.b # This calls the function

はい、それは_できます_が、すべてのオブジェクトがそうするわけではありません。 すべてのフィールドをインターセプトするためにgetfield(a::A, ::Field)を定義したい人もいます。

わかりました、今はわかりました。 すべての動的ユースケースではgetfield(a::A, ::Field)が必要になるため、内部フィールドを呼び出す方法が必要になります。

次に、私の考えでは、誰かがこれが煩わしい実用的なユースケースを見つけない限り、 Core.getfieldで十分です。

これはおそらく当然のことですが、 setfield!オーバーライドも許可しますよね？ 行が型になるデータベースに可変ビューを公開するために、それが本当に必要です。

はい、それが私の印象でした。

[OK]を、私見を使用するかどうか..実際のフィールドアクセスのためまたはCore.getfield 、このような大したことではありません。 一般的な機能を実験的なものとして紹介し、これを変更する可能性があります。

問題は、これが0.4の時間枠に収まるかどうかです。 それで、それは最終的な実装に近い＃5848であり、モジュールは解決可能ですか？

@johnmyleswhite ：これを対称にし、 setfield!許可することにも投票します。 Gtk.jlでは両方を使用します。

この機能を使用する場合と使用しない場合のルールは明確ではないようです。 メソッド/フィールドを動的に検索する必要があるため、Juliaメソッド/コンポジットタイプにすることはできない（結果の構文はPythonに近い）PyCallのポイントがわかります。 しかし、なぜそれをGtk.jlに使用するのでしょうか？ それはやって起動した場合はfoo.bar = xの代わりにsetbar!(foo, x) 、そして標準ジュリア・コードはinvitablyあまりにもこのパターンを使用して起動します：これは私たちが何をしたいのですか？ たぶんそうかもしれませんが、それについて明確にしましょう。

この機能を使用して、抽象（および具象も）タイプ用に定義されたプロパティゲッターおよびセッターを実装することは許容/推奨されますか？
これにより、さまざまなタイプのさまざまなモジュールからプロパティを取得するために使用されるメソッドの名前の衝突を回避できると思います。

参照： https ： ： //groups.google.com/forum/#！msg / julia -users / p5-lVNlDC8U / 6PYcvvsg29UJ

@nalimilan ：Gtkには、ゲッター/セッターではなく、動的なプロパティシステムがあります。

@tknoppああ、

この時点での私の見解では（そして正しいルールを理解するためにこれを少し実験する必要があると思います）、 fが「」のような一般的なスタンドアロンの概念として意味がある場合、 f(x)方が優れています。 fが実際にはx独立していない場合は、 x.fを使用する必要があります。 前の例をそれに当てはめるために、一般的なstep関数を使用することは、ほとんどのベクトルとコレクションにステップの概念がないため、あまり役に立ちません。範囲がある場合にのみ意味があります。ある種の。 したがって、 x.step範囲xのステップを取得する方法として使用しても問題ありません。 ちょっとした判断の呼びかけですが、人生はそれらでいっぱいだと思います。

..は私に直接アクセスできないため、好きではありません。 foo.bar.どうですか？最後の余分なドットは、直接アクセスできるように固定します。

ユニコード記号を選択することもできます：まだたくさん残っています...

@GlenHertz 、フィールドアクセスをチェーンする必要がある場合は実際には機能しません。

@simonbyrne 、私は一般的に、Unicodeの使用を必要とするコア言語または標準ライブラリに何かを

この時点での私の見解では（そして正しいルールを理解するためにこれを少し実験する必要があると思います）、fが「長さ」のような一般的なスタンドアロンの概念として意味がある場合はf（x）が優れていますが、xfを使用する必要がありますfがxから実際に独立していない場合。

この機能を使用するための私の個人的なルールは次のようになります。これは、言語の相互運用、または「ほぼフィールド」または「拡張フィールド」のいずれかであるものにのみ使用してください。 たとえば、これを使用して、タイプ内のすべてのフィールドの値に依存するキャッシュを更新できます。

この機能について私が持っている1つの大きな質問：これは型推論とどのように相互作用しますか？ sさまざまな値に対してさまざまな型の出力を生成する関数getfield(x::T, s::Symbol)を定義しようとしているようです。 getfieldが魔法であるためにのみ機能しますか？ プログラムの任意の時点で、固定xおよびsのgetfield(x, s)の出力を再定義できますか？ もしそうなら、それはどのようにタイプを再定義することができないことと噛み合っていますか？

sさまざまな値に対してさまざまな型の出力を生成する関数getfield(x::T, s::Symbol)を定義しようとしているようです。

そのため、これをgetfield{s}(x::T, f::Field{s})として表現する計画があります。ここで、 sはシンボルです。

私はそれを逃していました。 私をまっすぐにしてくれてありがとう。

@nalimilan ：はい、オーバーロードされたフィールドは動的プロパティにのみ使用されます。 これがジェムソンがこれに取り組みたい方法であり、これは良いことだと思います。 すべての実際のゲッターとセッターは自動生成されますが、すべてのget / setの名前がなくても機能します。 GAccessorモジュールでのライブ（短いG_ ）

構文では、実際のフィールドアクセスに<-を使用してみませんか？
これは、lamdaに使用されているc ++の->に似ていますが、 <-は現在使用されていません。
タイプから読み取ることができ、値を直接取得します。

それはまだ間隔を置いてそれを使いたい人のために未使用のままになり、私が今のところ考えることができる他の用途がない未使用のペアを使い果たしてしまうでしょう。

フィールドアクセスにRの割り当て表記を使用しないでください。

->を使用してC / C ++を直接ミラーリングし、次の新しい構文を取得することができます。
匿名関数。 私は匿名関数をあまり気にしませんでした
少し簡潔で読めないので構文。 多分代わりにできる
何かのようなもの

func（x）x ^ 2 end

またはより長く、より一貫性のある

関数（x）x ^ 2終了

おそらく、必要のない優れた構文を考え出す方法があるでしょう。
終わりを使用します。

議論をあまり変えないでください、しかしそれは間違いなく理にかなっています
->実際のフィールドアクセスに使用します。

2015年1月28日水曜日午前8時49分、ジョンマイルズホワイト[email protected]
書きました：

フィールドアクセスにRの割り当て表記を使用しないでください。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/1974#issuecomment-71857083 。

@quinnj ： func (x) x^2 endすでに機能しています。 しかし、無名関数の構文が非常に簡潔であると便利です。 map(x->x^2, 1:10)

フィールドアクセスに特別な構文は必要ないと思います（ @simonbyrneが提案したUnicode文字はオプションと同様に問題ありません）。 x -> x^2を失いたくありません。

この問題はまだ開いている/保留中の議論のようですか？ ドット演算子に関するさまざまなコメントをすべて読んで興味深くなりました。

他の新しい演算子トークンを追加する提案はありますか？ :>ようなものを使用することは良い選択肢かもしれません。 |>と類似しており、よりネイティブなJulia_feel_を持っている可能性があります。

c = foo.a + foo.b
pyobj:>obj:>process(c)

それでも書くのははるかに簡単ですが：

pyobj[:obj][:procees](c)

または比較：

someobj :> array |> length 
# vs
length(get_array(someobj)) 

私はジュリアに不慣れですが、多重ディスパッチのアプローチにすぐに強い評価を得ました。 オブジェクト指向プログラミング（特に科学プログラミングの場合）は、多くのタスクをより面倒にします。 オブジェクト指向パラダイム/構文がジュリアのスタイルの開発に悪影響を与えるのではないかと心配しています。

または、文字列のインターンや引用を忘れたので、次のようにします。

someobj <: field_name |> length

@elcritch 、 <:は現在、Juliaの「 issubtype of」演算子として使用されており、 :>が導入された場合、そのためにタイプ関連の何かに使用したいと思う可能性があります。遺産。

instance..memberが問題になる場合は、いくつかの可能性があります。 目を保護してください！ これらのすべてがより悪い可能性があります：

• instance^.member （にんじんドット）
• instance~.member （チルダドット）
• instance:.member （コロンドット）
• instance*.member （スタードット）
• instance-.member （ダッシュドット）
• [email protected] （アットマークドット）
• instance&.member （アンペアドット）
• instance$.member （ドルドット）
• instance<.>member （宇宙船ドット）

私は正直に言って、（a） ..は十分に良さそうだし、（b）これは常に言語のあいまいなコーナーになるので、見栄えが良いかどうかは問題ではないと思います。 ほとんどの人はinstance.memberを使用します。これは、フィールドまたはgetfieldメソッドのいずれかのみがあり、両方はないためです。

（さらに言えば、メンバーとメソッドの両方を使用したいほとんどの人は、おそらく..について学ぶことすら気にしないでしょう。彼らはfoo.memberメソッドを定義し、「本物」という名前を付けるだけです。 "フィールドfoo._member 。間違いなく、これはとにかくより良いスタイルです。つまり、 type定義を読むと、 _memberが何かではないことがすぐにわかります。直接アクセスできる、またはアクセスする必要があります。これは、貴重な句読点の不動産を使用するのではなく、 .. :.ように醜く曖昧なものにすることを主張します。）

..を中置区間演算子として使用する機能がないのですが、過負荷のフィールドアクセスは価値のあるトレードオフです。 コロンにこれ以上意味を追加することを少し恐れていますが、 :.はそれほど悪くはないようです。

:.は、現在symbol(".")に対して実際に有効な構文であるため、これを使用するのは適切ではない可能性があることに注意してください。 ..が潜在的に有用であるという点はよく理解されています。 だれもほとんど使用しない構文でそれを無駄にすべきではありません。 @.ようなもっと醜いもので行くのは完全にうれしいです（ .は有効なマクロ名ではなく、識別子を開始することもできないため、これは何かと競合するようには見えません）。 繰り返しになりますが、これはジュリアの非常にあいまいなコーナーになるため、きれいにしようとする価値はありません。

..を使用してこれを実行し、潜在的な醜さを無視することへの+1

ええ、とにかく..行きましょう。もし..使用できるなら、それは_range_コンストラクターだと思いますが、コロンを使ってすでにそこにあります。 start:stop 。

最後のパント： .:どうですか？ ab、a。（b）、a。（：b）_and_ a.:bを持つのは微妙すぎますか？

@hayd 、それは微妙すぎて偶然に使いやすいようです。

@ ihnorton 、＃5848のバージョンを復活させる可能性はありますか？ 構文の質問をパントして、 Core.getfield(x, Field{y})を使用して「実際の」フィールドにアクセスすることができます。

Core.getfield構文についてのバイクシェッドはさておき、実質的な質問が残っていますか？

＃5848で、 @ tknoppは、すべてをオーバーロード可能にする必要があるという@JeffBezansonの提案とは対照的に、「実際の」フィールドアクセスのみをオーバーロード可能にすることを提案しました。 個人的には、言語の動的な性質により実装がはるかに複雑になることを除いて、実際のフィールドをオーバーロードできないようにしたいと思います。 たとえば、「everything-overloadable」アプローチでは、 x::Vector{Any}場合、 x[i].yを実行すると、 getfield(x[i], Field{:y})と解釈でき、ディスパッチシステムはyかどうかに関係なく正しいことを実行します。 getfieldのみを呼び出したい場合、codegenはx[i]ランタイムチェックのためにディスパッチシステムのミニチュアサブセットを実装する必要があります。

もう1つの質問は、 Module.fooをオーバーロード可能にするかどうかgetfieldを使用することには一定の一貫性があり、上記のVector{Any}例にはModule配列メンバーが含まれる可能性があるため、その場合を処理する必要があります。とにかく。 一方、 @ JeffBezansonは、これによりコンパイルが困難になり、 function Base.sum(...)ような宣言の動作が困難になる可能性があると指摘しました。 私の好みは、少なくとも今のところ、コンパイラがModule動作していることを知っている場合（つまり、 Vector{Any}はない）に、 Module.fooをオーバーロードできないようにすることです。 ; 何が変更されるかについて保守的にするために、わずかな不一致は価値があるように思われます。

Module.fooオーバーロードを許可しない場合は+1。

ここでチャイムを鳴らすために、オブジェクト指向プログラミングと構文が実際にFPより優れている科学計算の1つの領域は、エージェントベースのモデリングです。 エージェント階層を設定するための具体的で多重継承が恋しいですが、Juliaの軽量で高速な抽象化と迅速なプロトタイピングは驚くべきものです-すでにいくつかのABMフレームワークが登場しています。

ABMでは、エージェントの相互作用を表すにはドット表記が適しています：Agent1.dosomething（Agent2）とdosomething（Agent1、Agent2）。

これは明らかなユースケースではありませんが、ABMについて考え、コーディングするために、このシンタックスシュガーを保持しておくと便利です。

また、この構文をJuliaで利用できるようにしたいと思います。 なので
デザインからの機能指向のアプローチに感謝します
パースペクティブ、メソッド呼び出し構文は非常に便利で、いくつかの場所で読みやすくなっています
ドメイン。 Ab（C）がb（A、C）と同等であれば素晴らしいと思います。
2015年4月22日午前8時50分、「datnamer」 [email protected]は次のように書いています。

ここでチャイムを鳴らすには、オブジェクト指向プログラミングが行われる科学計算の1つの領域です。
構文は実際にはFPよりも優れています。エージェントベースのモデリングです。 私は
エージェント階層を設定するための具体的で多重継承を見逃している
ジュリアの軽量で高速な抽象化とラピッドプロトタイピングは
驚くべき-すでにいくつかのABMフレームワークが登場しています。

ABMでは、エージェントの相互作用を表現するにはドット表記が適しています。
Agent1.dosomething（Agent2）とdosomething（Agent1、Agent2）。

これは明らかなユースケースではありませんが、これを維持するとよいでしょう
ABMについて考えてコーディングするためのシンタックスシュガー。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/1974#issuecomment-95218555 。

ABMでは、エージェントの相互作用を表すにはドット表記が適しています：Agent1.dosomething（Agent2）とdosomething（Agent1、Agent2）。

なぜそれが良いのですか？ 編集：私はこのABMコンテキストで具体的に意味します。

スペルをめぐる宗教戦争に巻き込まれないようにしてください。 @ dbeach24 、 a.b(c)がJuliaでb(a,c)と同等であると提案している人は誰もいません。 それは起こりません。

オーバーロード可能なドットは、他の言語との自然な相互運用にとって非常に重要です。 それは十分な理由です。

Subject.Verb（DirectObject）

いくつかの状況でかなり自然です。 多くのOOプログラマーは
それ、そしてそれは関数（A、B）の単なる並べ替えですが、その並べ替えは
読みやすさのためにたくさんのことをします、IMO。
2015年4月22日午前10時32分、「AndyHayden」 [email protected]は次のように書いています。

ABMでは、エージェントの相互作用を表現するにはドット表記が適しています。
Agent1.dosomething（Agent2）とdosomething（Agent1、Agent2）。

なぜそれが良いのですか？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/1974#issuecomment-95256390 。

私はそれを提案していました。 （申し訳ありませんが、私は戦争を始めるつもりはありませんでしたし、知りませんでした
提案は人気がないでしょう。）私はこれが前に出てくるのを見たと思いました
フォーラムで、しかしそれがすでに却下されていることに気づいていませんでした
悪いアイデア。 理由を聞いてもよろしいですか？ （スレッドを教えてもらえますか？）

ありがとう。
2015年4月22日午前11:09、「スティーブンG.ジョンソン」 [email protected]
書きました：

スペルをめぐる宗教戦争に巻き込まれないようにしてください。 @ dbeach24
https://github.com/dbeach24、ab（c ）が
Juliaではb（a、c）;と同等です。 それは起こりません。

オーバーロード可能なドットは、他の言語とのスムーズな相互運用に不可欠です。
それは十分な理由です。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/1974#issuecomment-95266671 。

これを行うにはない1つの理由は、あるa.b見上げbの範囲でaながら、 bルックスまで一人でbで囲んでいるスコープ。 ドット付きアクセスが左側のオブジェクトで検索されない場合があると、非常に混乱します。

ところで、Juliaの関数はオブジェクト内ではなく、現在のスコープで検索される機能と見なされます。 オブジェクトの内部で調べた関数を人々が使い始めるのではないかという恐れが、ドットのオーバーロードを抑制していた理由の1つだと思います。

@toivoh 、ドットオーバーロードの実装は既存のメソッドディスパッチを使用するため、スコープの動作は変更されません。 @ dbeach24 、無差別なa.b(c)使用を奨励しない基本的な理由は、同じことを行うには構文が多すぎると、言語とライブラリが混乱するためです。 bがaによって「所有」されていないことが明らかであるため、1つのスペルを選択してそれを維持することをお勧めします。Juliaの多重ディスパッチはb(a,c)優先します— b(a,c)メソッドは、_both_ aとcによって等しく決定されます。

もちろん、最大の例外は、PythonやC ++などの言語で外部ライブラリを呼び出す場合です。この場合、呼び出すライブラリのドット構文をミラーリングできると便利です。 （たとえば、ドキュメントや例をあまり変更せずに直接Juliaに翻訳できるようにします。）

私はみんな濡れていますが、ab（arg）は、aのフィールドbに格納されている無名関数を取得し、指定された引数でそれを評価することを意味しませんか？

私のiPhoneから送信された

2015年4月22日午後5時6分、Steven G.Johnsonの[email protected]は次のように書いています。

外部

@ScottPJones現在は問題なく動作しますが、一般的には良いスタイルとは見なされません。

私はスタイルについては気にしませんでした。それはすでに意味を持っていたので、それはJuliaの動作方法（つまり、匿名関数をフィールドに格納できること）と一致していたので、それは良い議論ではないと思いました。 ab（arg）をb（a、arg）であるかのように扱ってみてください。
私は、匿名関数を格納するメンバーを持つ構造体（型）を持つために使用する可能性があります。ここでは、データベースからJuliaで記述された関数をロードし、それらを解析して、関数をオブジェクトに格納します。
そのようなことをするためのより良い「ジュリアン」スタイルは何でしょうか？

ありがとう！

@ScottPJonesこれらは同等であってはならないという合意があると思います*。

「スタイル」ルールには例外がある場合がありますが、ドットのオーバーロードの場合と同様に、フィールドにput関数を使用するには説得力のあるケースが必要です。 問題は、人々がこれらの意地悪なことをするべきではないということだと思います/それのために/彼らができるからです。

それは一例かもしれませんが、より良い方法もあるかもしれません（確かにそれが唯一の方法ではありません）...

99％以上の場合、typeof（a）でディスパッチすることをお勧めします。 関数フィールド、ドットのオーバーロードはありません。

* _しかし、私は誰もがこれが着陸する2番目にそれを行うパッケージがあることを知っていると思います..._

Dでは、 a.b(arg) 「統一関数呼び出し構文」という名前もあり、非常に人気がありますが、一般的な関数であるJuliaの多重ディスパッチ方法とはかなり相性が悪いと思います。 問題の関数が匿名または完全にダックタイピングされている場合、問題は機能すると思いますが、それはかなり制限的なIMOです。 クラスベースの従来のオブジェクト指向言語の習慣がない限り、関数フィールドを複合型内に格納する理由はあまりないと思います。 ジェネリック関数をどこかからロードする場合は、モジュール内に格納するのが適しています。

しかし、私たちは今、「実質的な質問」からかなり遠いところにいます。 また、getfieldのオーバーロードを許可する方法、モジュールでのgetfieldのオーバーロードを許可しない方法、および「truegetfield」の特別な構文についてあまり心配しない方法に保守的であることに賛成です。

@stevengj ：はい、そして私が言おうとしていたように、それは、ドットのオーバーロードで何をするかに関係なく、 a.b(c)がb(a, c)と等しくなることが決して起こらない基本的な理由の1つです。 。

これに触れているメーリングリストでいくつかの議論がありました。 私の見解では、このスレッドに（@nalimilanによる）最も関連性のある投稿は次のとおりです： https ：//groups.google.com/d/msg/julia-users/yC-sw9ykZwM/-607E_FPtl0J

この機能をいつ使用するかについての個人的なポリシーに関する@johnmyleswhiteのコメントに追加すると、ここでいくつかのHTTPのアイデアが役立つ可能性があり、 getfield()副作用やsetfield!()がないはずだと思います。べき等である必要があります（つまり、同じ値で複数回呼び出すと、1回呼び出すのと同じ効果があります）。 コンパイラによって強制される必ずしも厳格なルールではありませんが、物事が狂わないようにするための使用ガイドライン。

ポインターパラメーターを使用してパラメトリック型を使用し、フィールドを設定するときにカスタムセッターを呼び出すように変換する回避策を投稿しました。
投稿： https ：//groups.google.com/forum/#！topic / julia -users / _I0VosEGa8o
コード： https ：

setfieldまでの回避策として、パッケージでこのアプローチを使用する必要があるかどうか疑問に思っています。 過負荷が利用可能ですか、それともパラメトリック型システムに過度のストレスがかかっていますか？

getfield / setfield!オーバーロードのもう1つの利点について言及したいと思います。これが適切な場所であることを願っています。それ以外の場合は、申し訳ありません。 （関連トピックがhttps://groups.google.com/forum/#!topic/julia-users/ThQyCUgWb_Qに掲載されました）

getfield / setfieldのジュリア！ オーバーロードにより、_外部パッケージ_での自動リロード機能の驚くほど洗練された実装が可能になります。 （この機能を取得するには、IPython自動リロード拡張機能https://ipython.org/ipython-doc/3/config/extensions/autoreload.htmlに追加する必要のあるすべてのハードワークを参照してください。）自動リロードの考え方は、 REPLの操作中に、外部モジュールの関数とタイプを変更できます。

TLDR： getfield / setfield!オーバーロード、辞書、およびhttps://github.com/malmaud/Autoreload.jlに類似したパッケージでうまくいくはずです。

具体的には、Autoreload.jlに似た次のようなパッケージを想像してみてください。

最初にモジュールM.jlを作成します。

module M
type Foo
  field1::Int64
end
bar(x::Foo) = x.field1 + 1.0
end

REPLで、次のように入力します

julia> using Autoreload2
julia> arequire("M")
julia> foo = Foo(42)

次に、M.jlをに変更します

module M
type Foo
  field1::Int64
  field2::Float64
end
bar(x::Foo) = x.field1+x.field2

これは自動リロードされ、に変換されます

# type redefinition removed as already done by Autoreload.jl
const field2_dict = Dict{UInt64,Float64}()
setfield!(x::Foo, ::Field{:field2}, value) = field2_dict[object_id(x)] = value
getfield(x::Foo, ::Field{:field2}) = field2_dict[object_id(x)]
<strong i="25">@do_not_inline</strong> bar(x::Foo) = x.field1 + x.field2

そしてREPLであなたはすることができます

julia> foo.field2 = 3.14
julia> println(bar(foo)) # prints 45.14

パフォーマンスはPythonの場合よりも悪くなることはないため、IPython自動リロードからワークフローを移行する人はパフォーマンスの面で何も失うことはありません。 そして、REPLを再起動すると、完全なパフォーマンスに戻ります。

a[:field][:field2][:morestuff](b[:random_stuff])はあまり読めないので、書くのに飽きました。 だから私は0.4と0.5のユースケースで機能するこの小さなマクロを書きました
https://github.com/sneusse/DotOverload.jl

TL; DR
式のASTを変換するマクロa.b -> getMember(a, :b)

これが良い考えであるというコンセンサスがなく、ドット構文をどうするかについて矛盾する提案があるため、0.6から削除します。

@Keno ：矛盾する提案へのリンクはありますか？

@StefanKarpinskiがまだそれを書いているとは思わないが、すぐにジュレップがあると思う。

object.fieldname 、 fieldname(object)やget_fieldname(object)ようなゲッター関数よりも優れていることがわかりました。 object.fieldname （またはobject$fieldname ）がgetpublicfield （おそらくより良い名前）への呼び出しであり、 object..fieldnameが実際のgetfield （プライベート）は良いオプションかもしれません。 このように、型はゲッターの代わりにgetpublicfieldを定義する必要があり、 object.fieldnameを実行しようとすると、フィールドがプライベートであるというエラーIDが返されます（の定義がない場合はプライベートになりますgetpublicfield ）。

決定ラベルを追加しました。 この問題は詳細に議論されており、実行する必要があるかどうかのどちらかです。 ＃5848を読んだとき、 @ JeffBezanson @ StefanKarpinskiと@stevengjがこれを望んでいるようでした。 はいの場合、この問題は忘れられないようにマイルストーンを取得する必要があります。 それ以外の場合は閉じます。 いずれにせよ、これは1.0より前に行われるべき変更だと思います。

@JeffBezansonと私は昨日これについて話し合っていました。 暫定的な結論：（i）はい、これが必要です。 （ii） Moduleドットオーバーロードを許可しない（これは特別に処理されます）。 （iii） Core.getfield特別な構文を指定しないでください（オーバーロードされたgetfieldが「実際の」フィールドと同じ名前を持つ必要がないため、後者は次のように始めることができます。アンダースコア）。

@stevengj ：合理的な計画のようですね。 これが単一の引数に制限されるのか、それとも複数の引数のバージョンa.fieldname(b)もサポートされる必要があるのか​​を教えてください。 これにより、上記の議論に結論が出ます。 さらに、これに適切なマイルストーンラベルを付けるのは素晴らしいことです（1.0？）。 ありがとう！

ジェフと私はマルチ引数のケースについては話しませんでした。 引数なしの場合から関数を返すことでとにかくシミュレートできるので、サポートしたほうがよいと思います（ただし、同じ理由ですぐに実行することは重要ではありません）。

コンバーターを使用して値をキャストし、データを検証します。
このような：

abstract AbstractAge{T}
abstract AbstractPerson
type PersonAge <: AbstractAge{AbstractPerson} 
    value::Int64
end

Base.convert(t::Type{AbstractAge{AbstractPerson}}, value::Int64) =  begin
  if value < 140 && value > 0
    PersonAge(value) 
  else
     throw(ErrorException("ValueError"))
  end
end

type Person <: AbstractPerson
  age::AbstractAge{AbstractPerson}
end 

a = Person(32)
a.age = 67

これの楽しい3行の実装は次のとおりです。

diff --git a/base/boot.jl b/base/boot.jl
index cd3ae8b..a58bb7e 100644
--- a/base/boot.jl
+++ b/base/boot.jl
@@ -266,6 +266,9 @@ Void() = nothing

 (::Type{Tuple{}})() = ()

+struct Field{name} end
+(::Field{f})(x) where {f} = getfield(x, f)
+
 struct VecElement{T}
     value::T
     VecElement{T}(value::T) where {T} = new(value) # disable converting constructor in Core
diff --git a/src/julia-syntax.scm b/src/julia-syntax.scm
index b4cb4b5..59c9762 100644
--- a/src/julia-syntax.scm
+++ b/src/julia-syntax.scm
@@ -1685,7 +1685,7 @@
     (if (and (pair? e) (eq? (car e) '|.|))
         (let ((f (cadr e)) (x (caddr e)))
           (if (or (eq? (car x) 'quote) (eq? (car x) 'inert) (eq? (car x) '$))
-              `(call (core getfield) ,f ,x)
+              `(call (new (call (core apply_type) (core Field) ,x)) ,f)
               (make-fuse f (cdr x))))
         (if (and (pair? e) (eq? (car e) 'call) (dotop? (cadr e)))
             (make-fuse (undotop (cadr e)) (cddr e))

私の考えでは、 a.bは実際にはgetfieldではなく射影関数Field{:b}()呼び出す必要があるため、 x->x.aような関数getfieldは常に低レベルのフィールドアクセスを意味します。

上記の実装は完全に機能しますが、コンパイラーではかなり困難です（sysimg + 5％、これは本当に嬉しい驚きです）。 したがって、これにはいくつかの特殊化ヒューリスティックが必要であり、いくつかの初期の最適化を更新する必要がありますが、うまくいけば、これは実行可能です。

その実装でテストに合格できることに驚いています。 このセマンティクスにより、codegenがモジュール参照を最適化することが不可能になりませんか？ また、グローバル変数（速度とメモリ）がはるかに高価になるようです。 これがsysimgに表示される可能性はそれほど高くないようです。 推論の低下は、ここではsysimgを小さくする必要があるように思われますが、5％悪化すると、良いスタートとは思えません）

はい、 jl_resolve_globalsには、これらをGlobalRefsに変換するためのコードがあり、更新する必要があります。 それ以外は、codegenがそれらを処理できるように、これらをインライン化する必要があります。 推論では、タプルgetindex場合と同様の特殊なケースが必要になる可能性があります。

タプルgetindexの場合と同様の特殊なケースが必要になる可能性があります

この特殊なケースでは、組み込みのgetindexメソッドシグネチャと交差するメソッドが定義されないことを期待し、想定しています。 ここでは、そのケースが特にどのように当てはまるのかわかりません。

::Moduleメソッドを追加し、それをシャドウイングすることは許可されていないと言います---実際のエラーで強制される可能性があります。

@JeffBezansonこれらの3行のブランチはありますか？ 自分でローカルビルドに追加しようとしましたが、ジュリアはもう動き始めたようで、動作させることができませんでした。

julia 1.0の機能に対する希望が1つしかない場合は、これで十分です。 これは、 MimiとQueryの両方で私が抱えている2つの長年の問題を解決します。

クエリの場合はかなり一般的だと思います。 これを使用して、マクロで新しい型を生成する必要のないバージョンのNamedTuplesを記述できると思います。これにより、生成された関数を記述して、次のフィールドのセットでNamedTupleを返すことができます。生成された関数で計算されます。 これにより、type-stableバージョンのblackrock / NamedTuples.jl＃4を作成できるようになると思います。これは、現在Query.jlで最大の障害となっています。

簡単に言えば、これはジュリアのデータ処理ストーリー全体にとって非常に価値があります。

以下の構文は利用できますか？

function (obj::MyType).plus(n::Int)
       return obj.val + n
end

なぜ世界でその構文が必要なのですか？

書きたいobj.plus(n)の代わりにobj + nいくつかの深刻なOOストックホルム症候群です。

わかりました、与えられた例は些細なもの（そして悪いもの）でした。
getfieldをオーバーロードする代わりにこの構文を使用して、引数を使用できるようにするためのアイデアにすぎ

私は主に機能に関心があります。 getfieldをオーバーロードするための省略された構文を持つことは、それほど重要ではないように思われ、議論する価値がありません。 さらに、 getfieldとsetfield! getindexとsetindex!を直接ミラーリングしているため、Juliaではやや自然です。 最後に、オブジェクト指向スタイルを広範に使用することは、ジュリアのイディオムにはあまり適していません。オブジェクト指向のようなメソッド定義構文でそれを奨励したいとは思いません（ただし、引数については上記のコメントを参照してください）。

私が思いついたのは、 $演算子が非推奨になったということです。 さて、これは明らかに$(x, sym::Symbol) = ...ようなことをすでに利用可能にしますが、次のようなより凝った構文の書き直しを楽しむこともできます。

x$y          => $(x, ::Type{Val{:y}})
x$z(args...) => $(x, ::Type{Val{:z}}, args...)

これは、本格的なgetfieldのオーバーロードを行わずに、この問題ですでに言及されているほとんどのケースをカバーしていると思います。 率直に言って、 .演算子はJuliaでかなり意味的に飽和しているので、このようなものは消化しやすく、それでも役立つのに十分便利です。

@ quinnj 、＃

ただし、フィールドアクセス用にすでに.ため、フィールドアクセスのような演算子を2つ持つことは、1つはオーバーロード可能で、もう1つはそうではないように見えます。 また、ほとんどの場合.使用するPythonやその他のオブジェクト指向言語への言語間呼び出しは少し不自然です。

他の言語との相互運用性は、このようなものを導入するための有効な議論ではないと思います。 「Pythonコードはこのように見えるので、Pythonのふりをするためにも、これを行う必要があります」と言っているようなものです。 ジュリア自体をより良くおよび/またはより一貫性のあるものにするこれについての議論はまだ見ていません。 JuliaがOOPスタイルのx.f()構文を提供しないことはすでに十分に確立されています。 そのようなことを許可することは矛盾を求めています。

@stevengj 、私がどこから来たのかというと、 x.fフィールドアクセスではないという事実です。 実際のフィールドメンバーfはありません。 この全体の問題はgetfieldのオーバーロードに関するものであり、主な懸念はx.f実際にフィールドを参照しているのか、それとも内部で何か他のことをしているのかという潜在的な混乱だと思います。

私が提案した構文の書き直しの利点は、getfieldとの追加の混乱を招くことなく、言語の相互運用ストーリーを実現することです。 それは、 .が過飽和になると言ったときに私が言及していたことです。 x$f本当にもっと面倒なのだろうか？ なぜこれがドット演算子を使用する必要があるのか​​わかりません。

この全体の問題はgetfieldのオーバーロードに関するものであり、主な懸念はx.f実際にフィールドを参照しているか、内部で何か他のことをしているのかという潜在的な混乱だと思います。

@JeffBezansonの3行の提案に混乱がa.bは常に射影関数呼び出しに下げられ、 getfield呼び出しにはなりません。 そして、 getfieldを呼び出す射影関数のベースにデフォルト/フォールバックメソッドがあります。 ユーザーは、必要に応じて、独自のタイプのメソッドをその射影関数に追加できます。 getfield常にその提案の低レベルのフィールドアクセスを意味し、ユーザーはgetfieldメソッドを追加しません（これが「getfieldのオーバーロード」の意味だと思います）。 それは私にはとてもきれいに思えます。 そうは言っても、その提案がまだテーブルにあるかどうかは私にはわかりませんが、私が理解していないコンパイラの懸念があるようです:)

私はこの機能が本当に欲しいです（私はいつもScalaでそれを愛していました）。 Juliaでは、フィールドに直接アクセスするIMHOが非常に自然になります（たとえば、すべてのゲッターとセッターを防御的に定義するJavaの方法と比較して）。 しかし、「仮想」フィールドを追加する機能がないと、多くのコードを壊さずに構造を進化/リファクタリングすることは非常に困難になります。

これがv2.0のタグが付けられていることは知っていますが、v1.0でこれを再検討することを期待して、これをもう一度取り上げたいと思います。 この機能は、パッケージ/ライブラリ開発者にとって非常に価値があります。

ユーザー向けのパッケージを作成するときに、属性アクセサーをオーバーロードすると、パッケージメンテナーがはるかにクリーンなユーザーインターフェイスを表示できるようになります。 私はそれを主張します、

complex_data_structure.attribute

入力が簡単です

get(complex_data_structure, :attribute)

ここで、 getは、 :attribute記述されたデータを取得するために必要な関数です。

これにより、REPLでの発見可能性も向上する可能性があり、言語コードとデータ探索に役立ちます。

さらに、セッター属性インターセプターも非常に価値があります。 次の例を考えてみましょう（現在、私のスクリプトの多くですでに見つかりました:)）、

set(complex_data_structure, :attribute, modify_attribute(get(complex_data_structure, :attribute), additional_arguments))

属性ゲッターとセッターがジュリアの一部として含まれている場合、上記は次のようになります。

complex_data_structure.attribute = modify_attribute(complex_data_structure.attribute, additional_arguments)

私の謙虚な意見では、これははるかに読みやすいです。 （補足：パイプ構成を使用して読みやすくすることもできますが、 additional_argumentsを使用すると、再び複雑になります。ここでの議論は依然として有効です。）

さらに、ユーザーが提供する値を制約することは非常に一般的なユースケースであり、これはv1.0で非常に優れています。 複数のパッケージのユーザーインターフェイスが大幅に改善されます。 現在、私の知る限り、次のことを行う方法はないようです（私が間違っている場合、誰かが私を修正できますか？）

module point

mutable struct Point
    x::Int
    y::Int
    function Point(x, y)
        if x < 0 || y < 0
            throw(error("Only non-negative values allowed"))
        end
        this = new(x, y)
    end
end

end
# point

p1 = point.Point(-1, 0)
# Only non-negative values allowed

# Stacktrace:
# [1] point.Point(::Int64, ::Int64) at ./In[30]:8
# [2] include_string(::String, ::String) at ./loading.jl:515

p1 = point.Point(0, 0);
p1.x = -1;
p1
# point.Point(-1, 0)

コンストラクターはドメイン入力を不変の構造に制限できますが、ユーザーは無効な値を入力する可能性があります。 属性ゲッターとセッターは、ここでのデータの有効性に関するフィードバックをより迅速に行うため、ここで役立ちます。これにより、言語のユーザーとしてのインターフェイスがはるかにクリーンになります。

これは、PyCall.jlやDataFrames.jlなどの他のパッケージにも大きなメリットをもたらし、ユーザーにとって間違いなくより優れた、より直感的なインターフェイスを構築します。 これらのパッケージの作成者は、この機能を持つことに上記の関心を示しています。

考え？ スレッドを読むと、これはすでに最終段階にかなり近いようです。 著者の考えがこれについてどうなっているのか興味がありますか？

ここでタイプ安定オプションマクロに実装されています： https ：

@bramtaylは、私が入れてあると思います@overload_dots前に、 a.b表現すると、ここでのポイントを破ります。

マクロをベースに追加することを提案していませんでした。 マクロで使用される戦略をパーサーに組み込むことを提案していました。 ただし、これはファイル全体で実行したり、IDEにハッキングしたりできるマクロです。

それは必然的に伴うa.bに解析されるExpr(:., :a, :(Val{:b}())とまで下げget_field_overloadable(a, Val{:b}())

@bramtayl 、上記のJeffの

getfieldのオーバーロードに関する問題の1つは、一部のライブラリがデータ構造の内部への適切なインターフェイスを備えていないことです。 構造内のデータポイントを変更して、コードを実行し、明日のレポートを作成できるようにするだけの場合、依存関係の3レベル深いライブラリでコードを編集して、次のことができるようにすることは特に楽しみではありません。合理的かつ迅速な方法でデータポイントに直接アクセスする。 使用しているデータ構造を自分で制御できるようにしたいと思います。

2つ目のポイントは、getfieldとsetfieldを使用しているときに、巨大な関数メカニズムではなく、データ構造に直接アクセスしていることを合理的に期待したいということです。 さらに、キーワードstructはタイプを定義するために使用され、Cを思い出させます。これにより、getfieldアクセスが直接であることが期待できるようになります。

したがって、代わりに$演算子を使用することは、getfieldのように直接アクセスすることは期待できないため、妥当な妥協案だと思います。他のコンテキストではすでに特殊文字であるため、それほど驚くことではありません。このように使用すると、使用する人が少なく、関数ではなくなるため、非推奨になりやすく、Rでも同様に使用されます。

getfieldのオーバーロードに関する問題の1つは、一部のライブラリがデータ構造の内部への適切なインターフェイスを備えていないことです。

上記の@JeffBezansonの実装は、 getfield （またはsetfield ）をオーバーロードしません。

また、これを1.0にすることをお願いしたいと思います。 コードをある程度柔軟に保つためにゲッター/設定を書くこと（そしてそれらに名前を付ける方法を考えていること）と、コードのユーザーが直接フィールドアクセスを使用することを「許可/奨励」することの間で、私はしばしば引き裂かれます。

たくさんのゲッターとセッターを前もって防御的に書くことは、私にはあまりジュリアンのようには思えません-結局のところ、ジュリアにはプライベート/保護されたフィールドがないので、ユーザーがフィールドに直接アクセスすることをお勧めします。 次に、他のパッケージとの多くの競合のリスクを冒さずに、多くのゲッター/セッター関数に名前を付ける方法についての質問があります。 また、 getfieldとsetfield! （または同様のもの）のメソッドを追加してVal{:fieldname}程度でディスパッチするという方法も、あまりユーザーフレンドリーではないようです。

一方、直接フィールドアクセスが基本的にすべての構造体を永久にロックする場合、特に長期間有効なコードの場合は、明らかに推奨されるべきではありません。 @JeffBezansonの実装は、このジレンマから抜け出すための

そうです、@ davidanthoff。 getfieldオーバーロードと.フィールドアクセス構文のオーバーロードを混同しているに違いありません。 フィールドアクセス構文のオーバーロードを意味しました。

この機能を追加するには下位互換性のある方法があるため、1.xリリースで追加できますが、1.0では追加されません。 たとえそれがあったとしても、完成した設計やそれを実装する時間はありません。

（C-）構造体へのポインタにドット構文を使用すると非常に便利です。

私の好みの構文は、ポインターの移動と変換にのみドットを使用し、derefに[]を使用することです。

したがって、struct somepair a :: Int b :: Int end、およびp :: Ptr {somepair}の場合、paはフィールドへのポインターであり、pa [] = 3で書き込むか、x =で読み取ります。 pa []。

次に、型の前方宣言と、場合によってはCヘッダーをインポートする方法が必要です。そうすれば、Cを簡単にラップできます。

追伸、明確にするために、次のようなもの：

function getfield(p::Ptr{T}, fn::Symbol) # dispatch on values of T and fieldname
ftype = fieldtype(T, fn)
offset = fieldoffset(T,fn)
return convert(Ptr{ftype}, p+offset)
end

getindex(p::Ptr{T}) where T = unsafe_load(p)
setindex!(p::Ptr{T}, v) where T = unsafe_store!(p, convert(T,v))

ボーナスポイントについては、juliaのランタイムライブラリからの型をエクスポートでき、pointer_from_objrefは実際には、より便利なイントロスペクションのために適切に型指定されたポインターを提供できます。

同じオフセットを持つ2つのフィールドがあるだけで、ユニオンは自動的に機能するはずだと思いますか？

@chethega https://github.com/JuliaLang/julia/pull/21912を探していると思います。これは、Cのメモリモデルの採用を取り巻く問題（型のパンニング違反、アウトオブ）なしで、ほぼ同じ機能を提供します。 -アクセスの制限、内部ポインターのエイリアスなど、その言語で可能なパフォーマンスの最適化を制限します）。

定数伝播はこれをより実行可能にしますか？

plsはマイルストーンを1.0に変更します！ :)

@ Liso77どういう意味ですか？ クローズ時のステータスに記載されているように、これはすでにgitmasterに実装されています。

@nalimilan間違って理解したらごめんなさい！ しかし、1.xには延期されたラベルが付けられているため、 1.0今解決されて

オープンソースは分散型コミュニティです。 マイルストーンは、1.0までに完了する必要があるものを設定しますが、貢献者は彼らが望むものに取り組みます。 この場合、誰かが1.0でこれを望んでいたので、そこに到達するためのコードを提供しました。

@ Liso77私が理解しているように、これはv1.0にはありません。 Julia v1.0の機能凍結日は12月15日に設定されていましたが、この問題は12月17日にクローズされたため、1.xリリースで期待できると思います。 私の解釈が正しくない場合、コア開発者は私を修正することができます。

いいえ、マスターにマージされ、次のリリースに含まれる予定です。

：） 上手！ 1.0で出てくるものに1.0のラベルを付けるのは良いことだと思っただけです。 それが望まれないなら、邪魔してすみません！ :)

NEWSファイルは、1.0に何が入っているかを確認するためのより良い方法だと思います。

マイルストーンは「1.xリリースシリーズの互換性を損なうことなく実装できる」という意味で追加されましたが、コードの準備ができたため、1.0機能がフリーズする前にとにかくマージされました。 わかりやすくするためにマイルストーンを削除しましたが、この時点で、マスターにマージされるものはすべて1.0になります。

説明してくれてありがとう！ これはエキサイティングです！ NEWSファイルも特に啓発的でした。

削除していただきありがとうございます。 1.0で登場するのも嬉しいです！ :)

オートコンプリートでこれらの新しい「動的に定義されたフィールド」をサポートする方法があるのだろうか。たとえば、 fieldnamesをオーバーロードできるようにするなどです。 これは、インタラクティブに使用する場合など、非常に強力な場合があります。たとえば、多くの列や長い列名を持つDataFrameを処理する場合（将来的にdf.column_nameをサポートすると想定）。

現時点では、REPL（tab-expansion）、IJuliaなどがインスタンスではなく型定義を調べていると思いますか？ しかし、インタラクティブに使用するために、変更される可能性があります。 ただし、コーディング中にインスタンスを使用できないため、JunoのようなIDEでサポートすることはおそらく不可能です。

@oschulz 、あなたはすでにfieldnamesオーバーロードすることができます：

julia> struct Foo; foo; end

julia> fieldnames(Foo)
1-element Array{Symbol,1}:
 :foo

julia> Base.fieldnames(::Type{Foo}) = [:bar, :baz]

julia> fieldnames(Foo)
2-element Array{Symbol,1}:
 :bar
 :baz

そして、 fieldnamesはREPLが見ているもののように見えます：

julia> x = Foo(3)
Foo(3)

julia> x.ba<tab>
bar baz

@yurivish right-しかし、現在、そうすることは「安全」ですか？ 他に何がfieldnames依存しているのかわかりません。

安全でない場合は、 complete_fieldnames(x) = fieldnames(x)を定義し、REPL補完にcomplete_fieldnamesを使用し、カスタム補完にそれをオーバーロードすることが可能であるはずです。

はい、これが私がこれを提起した理由です-REPLや友人が後でそれを利用できるように、Baseで何かを変更/追加する必要がある場合に備えて。 0.7機能のフリーズを考慮して...

これが、関数getpropertyを呼び出してよかった理由です。 fieldnamesと同じものを参照していないことを明確にするのに役立ちます。 fieldnames干渉すると、間違いなく深刻な問題が発生する可能性があります。

有効なプロパティ値を指定するには、対応するpropertynamesが必要になる場合があります。 もちろん、それは明確に定義された概念ではないかもしれないので、おそらく私たちは完成にもっと具体的な何かが欲しいのです。

これには、もう少し深い分析と専門家からの入力が必要になるかもしれないと感じました（ありがとう！）-これについて新しい問題を開く必要がありますか？