Julia: API整合性レビュー

これについて言及するのに適切な場所ではない場合はお詫びしますが、今後は関数名のアンダースコアとの一貫性を高めるとよいでしょう。

いいえ、これはそのための良い場所です。 はい、アンダースコアが必要なすべての名前を削除するように努める必要があります:)

• 「この[これらの]ディメンション全体で計算する」入力引数の一貫した処理、許可されるタイプなど、キーワード引数としてこれらを実行することが望ましいかどうかを検討します
• do-blockの関数引数、出力する関数のIO引数、インプレース関数の出力などの観点から、何が最初になるかをリストして優先順位を付けます（編集：これにはすでに1つ開いている可能性があると考えました）

@tkelmanの2番目のポイントについては、 https：//github.com/JuliaLang/julia/issues/19150を参照して

findのAPIと関連関数に関する最近のJulepもありました： https ：

push!とshift!があるので、チャネルでput!とtake!を非推奨にする必要がありますか（そして将来も同じようにする必要があります）？ APIで2つの冗長な単語を削除することを提案するだけです。

shift!がユーザーフレンドリーであることに疑いを持っています。 候補はfetch!です。 take!の非変異バージョンであるfetchがすでにあります。

ref＃13538＃12469

@amitmurthy @malmaud

編集：チャネルでsendとrecvを再利用することも理にかなっています。 （現時点では、これらがUDPSocketにのみ使用されていることに驚いています）

put! / take!をpush! / fetch!に置き換えるための+1

私は名前を変更する追加します@inferredに@test_inferred 。

特殊化がより一般的な関数と一致していること、つまり＃20233のようなものではないことを再確認してください。

エクスポートされたすべての関数を確認して、print_with_colorなどの複数のディスパッチに置き換えることで削除できるかどうかを確認します。

キューのようなデータ構造を操作する場合の一般的なペアリングは、 push!とshift!です。

この種のデータ構造に一般的な名前のペアリングを使用しない場合、操作にこれらの名前で適切に伝達されない通信オーバーヘッドが伴うことが懸念されるため、 push!とは思いません。 sendとrecv本当に良いかもしれません。

関数がタプルを最後の引数として取るか、varargを取るかについて、一般的な一貫性があることを再確認してください。

この問題には大きすぎるかもしれませんが、関数がエラーをスローするタイミングと、 NullableまたはUnionを返すタイミング（例： parseについて一貫したルールを設定するとよいでしょう。 tryparse 、 matchなど）

大きすぎる問題はありません、 @ simonbyrne –これは洗濯物のリストです。

ところで：これは実際には特定の変更（たとえば、特定の機能の名前変更）のためではありません-それは私たちがレビューできるものの種類に関するものです。 特定の提案された変更については、その変更を提案する問題を開くだけです。

code_xxxのような基礎となる関数とペアになっている@code_xxxのようなツールがたくさんあります

これがあなたが話していることであるかどうかはわかりませんが、

• 「出力タイプ」APIを要素タイプまたは全体的なコンテナータイプのどちらにする必要があるか（参照番号11557および＃16740）

• エクスポートされたすべての関数（doctestを含む）を文書化します

エクスポートされたすべての関数（doctestを含む）を文書化します

これがこの一部である場合は、おそらく次のようにもなります。テストに問題/プラントル数のラベルを付けることを忘れないでください。 そのテストがなぜそこにあるのかを理解するのがはるかに簡単になります。 git blameがどのように機能するかは知っていますが、テストセットを追加するとき（例を示すため）、テスト対象が少し謎になることがあります。問題/プラントル数が常に存在する場合は素晴らしいでしょう。

@dpsanders ：そしてエクスポートされたマクロ！ たとえば、 @fastmathにはdocstringがありません。

これは非常にマイナーですが、 string Symbol関数とsymbol方が理にかなっていると思います。

@amellnik違いは、 Symbolが型コンストラクターであり、 stringが通常の関数であるということです。 以前はsymbolを使用していたIIRC string代わりにStringコンストラクターを使用する必要があると思います。

どちらかといえば、文字列の代わりにStringコンストラクターを使用する必要があると思います。

いいえ、それらは異なる機能であり、マージすべきではありません

julia> String(UInt8[])
""

julia> string(UInt8[])
"UInt8[]"

いいえ、それらは異なる機能であり、マージすべきではありません

これは、 string(args...)を廃止して、 sprint(print, args...)を優先する必要がある状況のように見えます。その場合、 string(args...) stringとString両方があると混乱します。 sprint(::typeof(print), args...)に特化して、失われたパフォーマンスを回復することができます。 これらの方針に沿って、 repr(x)をsprint(showall, args...)非推奨にすることも理にかなっています。

stringを呼び出して何かを文字列に変換するのはかなり標準的なようですが、それは問題ないように聞こえます。

文字列を呼び出して何かを文字列に変換するのはかなり標準的なようです

はい、しかしそこでStringとstring間の断絶が起こります。

sprint(print, ...)は冗長だと感じています。 stringを削除すると、 sprint名前をstringできるため、 string(print, foo)とstring(showall, foo)が得られます。 。

これは、一貫性が過大評価されている場合である可能性があります。 「xの文字列表現を教えてください」にstring(x)を指定しても問題ないと思います。 それよりも複雑になる場合、たとえば、使用する印刷機能を指定する必要がある場合は、 sprintなどの別の名前を使用するのが理にかなっています。

String(UInt8[])名前を別の名前に変更し、 String代わりにstring Stringを使用しても問題ありません。 stringは、将来、返す文字列のタイプを変更するための柔軟性を少し高めますが、そうなる可能性は低いようです。

reinterpret(String, ::Vector{UInt8}はまったく意味がありますか、それともreinterpret駄洒落ですか？

それは理にかなっているようです。

問題は、この関数が時々コピーしているため、名前が多少誤解を招く可能性があることです。

本当ですが、文字列は不変であると想定されているので、おそらくそれを回避することができます。

そこにもあるString(::IOBuffer)方法は、それはそれは非推奨にすることができようになりますreadstring 。

提案されたAPIの変更についても考えましたが、 string(a, b...)のインターフェースは、引数を文字列化して連結することであり、これにより、呼び出し可能な最初の引数に対して厄介な例外が発生します。 stringから連結を削除すると、機能するようになります。

はい、同意しました。 一貫性と落とし穴の回避が最も重要です。

「次元の引数」カテゴリの問題＃18326および＃3893に注意してください。

別の項目に取り組むことができれば、可変のコンテナの動作が文書化され、一貫していることを確認してください。

@ JaredCrean2 ：それが何を意味するのか詳しく説明していただけますか？

確かに、「防御的なコピー」をたくさん作成する必要がないことを願っています。

たとえば、可変型の配列があり、その上でsortを呼び出す場合、返された配列は入力配列と同じオブジェクトを指しますか、またはオブジェクトをコピーして返された配列がを指すようにしますかそれら？

同じオブジェクト。 コレクションの並べ替え、getindex、フィルタリング、検索などのすべてのメソッドがこのルールに従っていると確信しています。

その点で明確さや一貫性の欠如があるとは思いません-それは常に同じオブジェクトです。

実際、そうでない標準関数はdeepcopyだけだと思います。ここで重要なのは、すべての新しいオブジェクトを取得することです。

それはどこかに文書化されていますか？

いいえ–できますが、どこに文書化するのが最適かわかりません。 関数が不必要にコピーを作成するのはなぜですか？ 彼らの印象はどこで得たのですか？

こんにちは。 私は、データのシリアル化についての発言を信じているのを見たことがありません。

遅かれ早かれ、ジュリアプログラムが作成され、公に実行され、データは何年にもわたって階層化され始めることがあります。 データのシリアル化（例： チェーン：タイプ（おそらくjsonまたは...）によって駆動されるバイトへのオブジェクトは、時間の回復力があるように構築する必要があります。 セマンティックバージョニングとWebAPIについて考えることも重要かもしれません。

ユーザーデータのシリアル化がhttps://github.com/JuliaLang/julia/blob/v0.5.1/base/serialize.jlの近くにとどまると期待でき

関数が不必要にコピーを作成するのはなぜですか？ 彼らの印象はどこで得たのですか？

彼らがそうするかどうかはわかりません。 私の知る限り、動作は未定義です。 @JeffBezansonのコメントから、防御的なコピーを作成することを提唱する人々がいますが、彼は反対しています。 したがって、ドキュメントはどこかで防御コピーの問題に対処する必要があります。

ある種の最小作用の原理を暗示しているように見えますが、アルゴリズムの詳細によっては、「最小作用」とは何かがあいまいになります。 API全体で一貫性を保つには、より具体的なガイダンスが必要だと思います。

@ o314 ：これはAPI整合性レビューの問題であり、シリアル化がどのように関連しているかわかりません。

@ JaredCrean2 ：トップレベルのオブジェクトがコピーされるかどうかは、確かに文書化する必要があります。 私が言っているのは、（明らかに）ディープコピーを除いて、より深いオブジェクトは決してコピーされないということです。

私が言っているのは、（明らかに）ディープコピーを除いて、より深いオブジェクトは決してコピーされないということです。

いくつかの配列ラッパー、たとえばSubArrayとSparseMatrixCSCだけでなく、 Symmetric 、 LowerTriangularについても、 copyのコンテキストでこれについて最近議論がありました。 LowerTriangular 。 上記のポリシーの下では、 copyはそのようなラッパータイプのヌープになると私には思えます。 ここで言及しているポリシーは、適切なレベルの抽象化ですか？ たとえば、 ArrayがJuliaに実装されている（バッファをラップしている）場合、 Arrayのcopyの動作はnoopに変わるはずだと思います。

より深いオブジェクトは決してコピーされないという慣習がある場合、残っているのはそれを文書化することだけです。 ドキュメントはAPIの非常に重要な部分です。 この振る舞いは（おそらくコードの一部を書いたために）あなたには明白に見えるかもしれませんが、外部の観点からはそれほど明白ではありません。

編集：アンドレアスの投稿が表示されませんでした。 これは興味深い考慮事項です。

@StefanKarpinski私はあなたの
そして、ここで呼び出されるすべての主要なトピックは非常に優れていて賢いです。

しかし、Juliaのプロセスとデータのバランスについて少し恐れることがあります：

確かに、FortranまたはCを簡単に呼び出すことができます。
しかし、コードは、たとえば、最新のデータセンターに簡単にデプロイされます。 サービスパターンとしての機能を持つawslambda。 コードはインターネット、オープンAPIを介して簡単に呼び出すことができますか？

場合によっては、機能負荷を下げてスケーリングし（ジェネリックなし、関数シグネチャのvaargsなし、パブリックapiの高次なし）、より体系的にデータをバインドする必要があります（json schema / openapi）。

私はいくつかの非常に優れたPythonライブラリがこれらの方法で沈んでいくのを見てきましたが、それは残念です。

言語1.0にとって、データと機能のバランスを保ち、モジュール化してWebに簡単にデプロイできるようにすることが重要だと思います。 そして、この機能のために、インターフェースは、必要に応じて、ペットを減らし、牛をより重視する必要があります。

それはこのトピックのポイントではないかもしれません。

@StefanKarpinskiあなたの投稿を誤解した可能性があります。 あなたが言ったとき

トップレベルのオブジェクトがコピーされているかどうかは、確かに文書化する必要があります

「トップレベルオブジェクト」とはどういう意味ですか？ x::Vector{MyMutableType}がある場合、最上位のオブジェクトはx xですか、それとも

トップレベルオブジェクトは、 xの要素ではなく、 xます。

@andreasnoackトップレベルオブジェクトの概念は、実装の詳細ではなく、実装された抽象構造を参照する必要があります。

型と値の両方に作用するfloatや他の同様の関数を追加するかもしれませんか？

0.6のリリースノートを見ると、 iszero(A::Array{T})が導入されているのは奇妙に思えますが、配列に対する他の多くの関数（ sumabs 、 isinteger 、 isnumber ）はall(f,A)を優先して非推奨になりました。

配列はゼロであり、それらはベクトル空間の要素がゼロです。 iszero一般的に、何かが加法逆数であるかどうか、つまりゼロ配列であるかどうかをテストします。

再。 関数名のアンダースコアの一貫性。これがcount_onesとcount_zerosブレッドクラムです。

Julia APIの一貫性を維持したい場合は、（a）APIルール/規則を指定し、（b）Juliaコードの静的分析を実行して検出できるソフトウェアが必要になるようです。それらの規則/慣習からの逸脱、および（c）提案を提供します。 このようなツールは、JuliaBaseとすべてのJuliaパッケージの両方にメリットがあります。 新しいJuliaパッケージでうまくいくかもしれません。 （舌の頬：このパッケージが最初にすべきことは、APICheck.jl、ApiCheck.jl、API_Check.jl、APIChecker.jl、JuliaAPIChecker.jlなどの独自の名前を提案することです。）私はJuliaにかなり慣れていません。だから、そのようなことを主導したくない。 しかし、私は貢献してもかまいません。 これを実現する方法について何か提案はありますか？

Lint.jlでそれを持っていたいです！

num2hexおよびhex2num （＃22031および＃22088）

私も、Lint.jlがJuliaAPIの整合性チェックに適したパッケージであると信じています。 しかし、その道を進むと、ステファンの元のリストをもっと正確にする必要があります。 たとえば、彼が「DataStructuresのすべてのコレクションに一貫したAPIがあることを確認する必要があります」と書いたときに、頭に浮かぶ質問は次のとおりです。

• データ構造をコレクションにするものは何ですか？ （ベースのコレクションのリスト）
• コレクションがサポートしなければならない機能は何ですか？ （コレクションごとの関数のスプレッドシート）
• これらの各関数の署名はどうあるべきですか？
• Baseがコレクション用に提供するAPIは、実際にはすでに一貫していますか？

このようなインベントリと分析を管理するには、Juliaリポジトリ（プロジェクト＃8）、JuliaPraxisリポジトリ（TotalVerbによってオフラインで提案）、またはLintリポジトリにプロジェクトを追加することをお勧めします。 その場合、誰がそのようなプロジェクトを所有するのか、誰が最初から関与するのか、そして誰がジュリアのコンベンションが実際に何であるかについて最終決定を下す必要がある（リンティングの目的で）必要があります。

しかし、これらの方針に沿ってさらに進む前に、 たいと思います

これを具体的に特定することは良い考えであることに同意します。 そのリストがどうあるべきかを理解することは、ここでの作業の一部です–もしあなたがそれをクラックしたいのなら、それは素晴らしいことです。

Base.datatype_moduleとBase.function_moduleが本当に必要ですか？

データ型と関数にディスパッチする統合関数「モジュール」（おそらくgetmodule）は、私にはより一貫しているようです。

@code_typedとその友達のアンダースコアはどうですか？

これはリファクタリングの良い機会です（アンダースコア禁止の理由を述べています）。 @codeマクロを作成し、最初の引数を必要な種類のコードにすることができます。

（ @bramtayl 、マクロの周りにバッククォートを付けることを忘れないでください。そうでない場合は、githubユーザーの「コード」にpingを送信します; @code ）

FWIW、タブ補完は関数名でのみ機能します。 @code_<TAB>ができるのはいいですね。

リファクタリングが検討されているが拒否された場合、アンダースコアの禁止の唯一のポイントはリファクタリングを奨励することであるため、アンダースコアがあるかどうかは重要ではありません。 実際、その場合、言語を明確にするためにアンダースコアを推奨する必要があるようです。

アンダースコア監査。

反対提案：これらの名前は引き続き監査しますが、代わりに、コードを読みやすくするためにアンダースコアを

私はこれについて絶対主義者ではありません。 @KristofferCが指摘しているように、 code_typedは問題なく、便利なタブ補完であると思います。必要な出力を選択するための引数として渡すことは、実際には明らかではありません。

基本的にBaseの半分を廃止する必要があるため、私には、船がアンダースコアを追加して航海したように見えます。 一例として、74個の述語で始まる関数があるisで始まり、わずか6 is_ 。 6または74を非推奨にして、どちらがより理にかなっていますか？

わかりました、ここにはいくつかの矛盾する目標があります：

1）名前を読みやすくする
2）コードチャーンの削減
3）リファクタリングの奨励

単語を衝突させてアンダースコアを削除すると、3つの面すべてで失敗します。

ストリームを受け入れるshowメソッドが!終了していないということは、通常の規則と矛盾しているように見えますか？ 参照。 https://github.com/JuliaLang/julia/pull/22604/commits/db9d70a279763ded5088016d9c3d4439a49e3fca#r125115063。 ベスト！ （編集：これは、ストリームを受け入れるwriteメソッドと一致すると思います。）

トレイトAPIには矛盾があります。 一部の特性は、次のような特性を呼び出すことによって計算されます
TypeArithmetic(Float64)
他の人はこの関数を小文字で綴る必要があります：
iteratorsize(Vector{Float64})

size -> shape名前を変更することを検討してください（外部参照＃22665）

Array{T,1}()もおそらく非推奨になるはずです：

julia> Array{Int,1}()                                                                                                                  
0-element Array{Int64,1}                                                                                                               

julia> Array{Int,2}()                                                                                                                  
WARNING: Matrix{T}() is deprecated, use Matrix{T}(0, 0) instead.                                                                       

コレクションについて考えてきました。 基本的に3種類あります。

• いくつかの値を含む単純なセットのような（またはバッグのような）コレクション。
• データの横にインデックスを追加する配列のようなコレクション。
• データの一部としてインデックスを持つディクトのようなコレクション、つまりk=>vペア。

私は口述のような振る舞いに懐疑的になりました。 炭鉱のカナリアはmapです。通常、キーのセットを変更したくないため、キーと値のペアを操作するのは自然ではありません。 配列とdictが同じインターフェースを実装することも可能です。

• keysはeachindex対応します
• mapindexedとfilterindexedは、dictと配列の両方に役立ちます。 これらは、問題のアイテムのインデックスを関数に渡すことを除いて、マップとフィルターに似ています。
• 配列とdict（および名前付きタプルなど）は、基本的にzip(keys(c), values(c))ショートカットであるpairsイテレーターを使用できます。

ind2subとsub2ind名前を変更することを検討してください。これらは明らかにMATLAB主義であり、MATLAB以外のユーザーには非ジュリアンで奇妙な名前が付いています。 可能な名前は、それぞれindiceとlinearindiceです。 人々がどう思うかわからないので、あえてPRをしませんでしたが、サポートがあればやります。

rad2degとdeg2rad同じです。

参照。 ＃22791（ select -> partialsort ）。 ベスト！

私がここで見たことがないことの1つ：オプションの位置引数は最初に行くのか最後に行くのか？ sum(f, itr)やrand([rng,] ..)ように、オプションの位置引数が最初に来る場合があります。 しかし、他の場所では、たとえばmedian(v[, region])やsplit(s::AbstractString[, chars])などで最後になります。 最初または最後に移動できる場合もありますが、両方に移動することはできません。 （たとえば、 meanは最初に関数を、最後に次元をとることができますが、両方をとることはできません。）

現在の言語セマンティクスでは、オプションの引数を最後に強制します。 f(a, b=1)は記述できますが、 f(b=1, a)は記述できません。 しかし、すべてのオプションの引数が最後になると、便利なdoブロックはどうなりますか？

他に何もないとしても、言語がrand.jl ： shuffle!(a::AbstractVector) = shuffle!(GLOBAL_RNG, a)からそのようなメソッドを定義しなければならないことはマイナーな警告です。 オプションの定位置引数構文は、まさにこのユースケースを処理する必要があります。

別の問題に取り組む必要があるかもしれませんが、オプションの引数を好きな場所に移動することは可能のようです。 したがって、たとえば、 f(a = 1, b, c = 2)はf(x) = f(1, x, 2)とf(x, y) = f(x, y, 2)を定義します

任意の位置でデフォルトの引数を有効にする（人気のない）試みについては、外部参照＃22460。

たぶんwarn名前をwarning （matlabもこれを使用します）、大したことではありませんが、私が言及したいと思いましたか？

throwような動詞なので、 warn好きです。

私はこれによって非常に混乱しました：

julia> f(;a=1,b=1) = a+b                                                                                                                              
f (generic function with 1 method)                                                                                                                    

julia> f(a=4,5)            # I intended to write f(a=4,b=5)                                                                                                                           
ERROR: MethodError: no method matching f(::Int64; a=4)                                                                                                
Closest candidates are:
  f(; a, b) at REPL[13]:1

キーワード関数を定義するときと同様に、関数を呼び出すときはキーワードを最後に許可することをお勧めします。

キーワード関数を定義するときと同様に、関数を呼び出すときはキーワードを最後に許可することをお勧めします。

他の位置にキーワードを渡すことが有用で人間工学的であるAPIはたくさんあります。

好奇心から、位置引数とキーワード引数の評価順序は定義されていますか？ 私はいくつかの古い問題を見ました、そしてhttps://docs.julialang.org/en/latest/manual/functions/#Evaluation -Scope-of-Default-Values-1はスコープについて話します、しかし私が見つけたものは何も述べていません。引数は左から右に評価されるか、すべての位置引数がすべてのキーワード引数の前に評価されるか、または定義された評価順序（または他の何か）がない場合。

@yurivish 、キーワードについては、ドキュメント（https://github.com/JuliaLang/julia/issues/23926も参照）を参照してください。 オプションのものについては、話はもう少し複雑です、多分ここを読んで

それ自体の問題の価値はないようですが、 bits(1)がString返すことは私にはいつも奇妙に思えます、それはBitVectorまたはVector{Bool}でなければならないようです

FunctionまたはCallableディスパッチするメソッドテーブルのレビューを提案したいと思います。 これらのAPIが希望どおりであること、そして任意のオブジェクトをダックコールできるようにテーブルを再構築できる機会を逃していないことを確認してみましょう。

allとany 、 all(f(x) for x in xs)に廃止するのは簡単なようですが、これはすでにall(Generator(f, xs))イータ削減されているため、オーバーヘッドはありません。

わからない、それはあなたが何を意味するかだが、私は念のために述べて、それの価値を考え出した場合：私は、発電のために任意の機能スタイルのAPIを廃止反対筋金入りです。 any(f, x)とall(f, x)あり、広く使用されています。 それら（または実際にはそのようなメソッド）を削除するための-10000000。

Imプロジェネレーター。 遅延プログラミングの基本的な構成要素のようであり、エクスポートする必要があります。 all(Generator(f, xs)) 、定義された関数にとってall(f(x) for x in xs)よりも便利な場合があります。 また、バランスを回復するために+10000000

可能であれば、ここでは構文を少なくすることをお勧めします。 「xsを取り、すべてにfを適用し、それらすべてがtrueの場合はtrueを返す」という考えを表現するのが簡単で読みやすく、パフォーマンスが高い場合、なぜそれを1つの動詞に入れる必要があるのでしょうか。

懸念がf(x) for x in xsの不要な名詞xである場合、 @ bramtaylのGeneratorのエクスポートの提案（おそらくMapようなより良い名前を使用しますか？）理にかなっています。

以下のようなものall(isnull, x)よりかなり単純であるall(isnull(v) for v in x) 。 all(isnull, x)を優先して、NullableArraysからallnull関数を非推奨にしました。 その構文がなくなった場合は、おそらくそれを再導入する必要があります。

どのように名前の変更についてstrwidthにstringwidth （私はこれがSTRに文字列を省略しているだけで、エクスポート、文字列操作関数だと思います）

実際には、名前がtextwidth （https://github.com/JuliaLang/julia/pull/23667）に変更されています。

IMO、この問題は広すぎて1.0マイルストーンを設定できません。まもなく機能がフリーズするようにしたいからです。 これを行う場合は、複数の所有者が必要になり、レビューのために一連の機能を割り当てる必要があります。

また、これはFemtoCleanerが1.0以降の多くのものを自動更新できるもう1つの場所ですが、問題がなければ問題ありません。

textwidthに関するコメント：

INFO: Testing Cairo
Test Summary:   | Pass  Total
Image Surface   |    7      7
Test Summary:   | Pass  Total
Conversions     |    4      4
Test Summary:   | Pass  Total
TexLexer        |    1      1
WARNING: both Compat and Cairo export "textwidth"; uses of it in module Main must be qualified
Samples        : Error During Test
  Got an exception of type LoadError outside of a <strong i="6">@test</strong>
  LoadError: UndefVarError: textwidth not defined
  Stacktrace:
   [1] include_from_node1(::String) at .\loading.jl:576
   [2] include(::String) at .\sysimg.jl:14
   [3] macro expansion at C:\Users\appveyor\.julia\v0.6\Cairo\test\runtests.jl:86 [inlined]
   [4] macro expansion at .\test.jl:860 [inlined]
   [5] anonymous at .\<missing>:?
   [6] include_from_node1(::String) at .\loading.jl:576
   [7] include(::String) at .\sysimg.jl:14
   [8] process_options(::Base.JLOptions) at .\client.jl:305
   [9] _start() at .\client.jl:371
  while loading C:\Users\appveyor\.julia\v0.6\Cairo\samples\sample_pango_text.jl, in expression starting on line 28

エラーメッセージは、問題が何であるかについてかなり明確に見えますか？ Cairoは基本メソッドを拡張する必要があります。

help?>  Base.textwidth
  No documentation found.

  Binding Base.textwidth does not exist.

julia> versioninfo()
Julia Version 0.6.0

julia> Compat.textwidth
textwidth (generic function with 2 methods)

メッセージ（travis経由で取得）に問題がないことは間違いありませんが、Compatが0.6でない場合、なぜテキスト幅をエクスポートするのですか？

それがCompatのポイントだからですか？ しかし、この議論は非常に範囲外になっているので、談話やたるみについて続けることができると思います。

copyをshallowcopy 、 deepcopyをcopy変更することをお勧めします。最近、コピーが「浅い」コピーであり、私が書いた関数は配列の配列を変更することでした。 copyが「深い」コピーを実行し、 shallowcopyようなものが浅いコピーに使用されると、はるかに直感的になると思いますか？ deepcopyいつ使用するかですが、他の多くのユーザーも同じ問題に遭遇すると思います。

「私が嫌いな特定のもの」の袋ではなく、APIの一貫性のためにこの問題を維持するようにしてください。

Associative名前は、Juliaの他のすべてのタイプ名とかなり矛盾しているようです。

まず、タイプは通常形容詞ではありません。 名詞はAssociation 、少なくとも私が見つけたいくつかのMathematicaドキュメントで使われています。

AbstractDictは、 AbstractArray 、 AbstractRange 、 AbstractSet 、 AbstractStringなどの他のタイプとはるかに一貫性があると思います。プロトタイプの具象型Dict 、 Array 、 Range 、 Set 、 String 。

私たちの例外タイプはいたるところにあります。 FooErrorという名前のものもあれば、 BarExceptionという名前のものもあります。 いくつかはエクスポートされますが、ほとんどはエクスポートされません。 これは、一貫性のためにパススルーを使用できます。

では、 FooErrorまたはBarExceptionどちらが優先されますか？ エクスポートされたかどうか？

私にとって、 BarExceptionはどこかでレイズ/キャッチパターンを含みます。

私は多くのことを好みますが、機能の世界では、制御フローがより直接的で予測可能なSome / Noneパターン（*）を使用します。

したがって、 FooError +1

（*） Some / Void ex Optional in julia＃23642。

機能がフリーズした場合、これらのものはまだテーブルにありますか？ 特にオプション引数とキーワード引数に取り組みたいのですが、複数のオプション引数を持つ関数のリスト（代わりにキーワード引数を使用する最も明確なケース）はかなり長いです。

ぜひご覧ください！ 私はこれらの問題を体系的に経験する機会を得ていません。

ところで、私はしまし指摘形質の命名に矛盾を：我々はiteratorsize 、 iteratoreltypeが、 IndexStyle 、 TypeRangeStep 、 TypeArithmeticおよびTypeOrder 。 CamelCaseの亜種はより多く、より最近のもののように見えるので、おそらくどこでもその規則を採用する必要がありますか？

それらは間違いなく一貫している必要があります。 PRをしたいですか？

これはhttps://github.com/JuliaLang/julia/pull/25356の一部として修正する必要があると思い

編集： https ： ください

これは主に行われるか、1.xリリースで行うことができます。 チェックボックスを更新することはできますが、トリアージコールでチェックボックスを確認したところ、＃25395とアンダースコア監査以外はすべて完了しました。

アンダースコア監査

以下は、アンダースコアを含み、非推奨ではなく、文字列マクロではない、Baseからエクスポートされたすべてのシンボルの分析です。 ここで注意すべき主な点は、これらはエクスポートされた名前のみであるということです。 これには、修飾されたと呼ぶように人々に指示するエクスポートされていない名前は含まれません。

私は物事をカテゴリー別に分けました。 うまくいけば、それは煩わしいよりも便利です。

反射

対応する関数を持つ次のマクロがあります。

• [] @code_llvm 、 code_llvm
• [] @code_lowered 、 code_lowered
• [] @code_native 、 code_native
• [] @code_typed 、 code_typed
• [] @code_warntype 、 code_warntype

マクロに適用される変更がある場合は、それを関数にも同様に適用する必要があります。

• [x] module_name -> nameof （＃25622）
• [x] module_parent -> parentmodule （＃25629、以前の名前変更の試みについては＃25436を参照）
• [x] method_exists -> hasmethod （＃25615）
• [x] object_id -> objectid （＃25615）
• [] pointer_from_objref

pointer_from_objrefは、おそらくaddressような、よりわかりやすい名前で行うことができますか？

C相互運用のエイリアス

アンダースコアを含むタイプエイリアスは、 C_NULL 、 Cintmax_t 、 Cptrdiff_t 、 Csize_t 、 Cssize_t 、 Cuintmax_t 、およびCwchar_t 。 _tで終わるものは、対応するCタイプと一致するように名前が付けられているため、そのままにしておく必要があります。

C_NULLはここで奇妙なものであり、Cでミラーリングされていないアンダースコアを含む唯一のCエイリアスです（CではこれはNULL ）。 これをCNULLと呼ぶことを検討できます。

• [] C_NULL

ビットカウント

• [] count_ones
• [] count_zeros
• [] trailing_ones
• [] trailing_zeros
• [] leading_ones
• [] leading_zeros

これらの名前の変更については、＃23531を参照してください。 私は、これらのアンダースコアと、そのPRで提案されている代替案のいくつかを削除することを非常に好みます。 再考すべきだと思います。

安全でない操作

• [] unsafe_copyto!
• [] unsafe_load
• [] unsafe_pointer_to_objref
• [] unsafe_read
• [] unsafe_store!
• [] unsafe_string
• [] unsafe_trunc
• [] unsafe_wrap
• [] unsafe_write

これらをそのままにしておいても大丈夫でしょう。 アンダースコアの醜さは、彼らの安全性をさらに強調しています。

インデックス作成

• [] broadcast_getindex
• [] broadcast_setindex!
• [] to_indices

どうやらbroadcast_getindexとbroadcast_setindex!が存在します。 彼らが何をしているのか分かりません。 おそらく、彼らはもっとわかりやすい名前を使うことができるでしょうか？

興味深いことに、 to_indices 、 Base.to_indexの単一インデックスバージョンはエクスポートされません。

トレース

• [] catch_backtrace
• [x] catch_stacktrace -> stacktrace(catch_backtrace()) （＃25615）

おそらく、これらはそれぞれbacktraceとstacktraceに相当するcatchブロックです。

タスク、プロセス、およびシグナル

• [] current_task
• [] task_local_storage
• [] disable_sigint
• [] reenable_sigint
• [] process_exited
• [] process_running

ストリーム

• [] redirect_stderr
• [] redirect_stdin
• [] redirect_stdout
• [x] nb_available -> bytesavailable （＃25634）

より一般的なIO -> IOリダイレクト関数を使用すると、これらすべてを組み合わせることができます（例： redirect(STDOUT, io) ）。これにより、アンダースコアとエクスポートの両方が削除されます。

プロモーション

• [] promote_rule
• [] promote_shape
• [] promote_type

promote_ruleに関する関連する議論については、＃23999を参照してください。

印刷

• [x] print_with_color -> printstyled （＃25522を参照）
• [] print_shortest （＃25745を参照）
• [] escape_string （＃25620を参照）
• [] unescape_string

escape_stringとunescape_stringは、ストリームに出力したり、文字列を返したりできるという点で少し奇妙です。 これらを移動/名前変更する提案については、＃25620を参照してください。

コードの読み込み

• [] include_dependency
• [] include_string

include_dependency 。 これはBaseの外でも使用されていますか？ 典型的なシナリオでは、 include代わりにこれが必要になる状況は考えられません。

include_string 。 これは、公式に認可されたeval(parse())バージョンではありませんか？

わざわざ分類しなかったもの

• [x] gc_enable -> GC.enable （＃25616）
• [] get_zero_subnormals
• [] set_zero_subnormals
• [] time_ns

get_zero_subnormalsとset_zero_subnormalsは、よりわかりやすい名前で行うことができます。 それらをエクスポートする必要がありますか？

method_exists => methodexistsおよびobject_id => objectid +1。 catch_stacktraceが存在するのもちょっとばかげています。 その定義stacktrace(catch_backtrace())非推奨になる可能性があります。

C_NULLアンダースコアを下げることについてどう思いますか？ 私はそれにかなり慣れてきましたが、他のC*名前にはアンダースコアがないという議論も購入します。

他のC名は型ですが、 C_NULLは定数です。 ネーミングのガイドラインに従っているのは良いことだと思います。

命名ガイドラインに従います。

どうして？

多くの場合、定数はすべてアンダースコア付きの大文字です– C_NULL続きます。 @ iamed2が言ったように、これは型ではなく値であるため、 Cfoo命名規則は必ずしも適用されません。

https://github.com/JuliaLang/julia/blob/master/doc/src/manual/variables.md#stylistic -conventionsが定数を参照していると誤解しましたが、そうではありません。 おそらくそうすべきです。

ベクトルがジュリア配列ではない一般的なヒルベルト空間に対して、一貫性のある数学的に健全なインターフェースを提案します。 vecdot 、 vecnormなどの関数名は、 https：// githubで説明されているように、 innerとnormの一般的な概念に置き換えることができます。 com / JuliaLang / julia / issues / 25565。

何度か言ったように、これは変更したいことの包括的な問題ではありません。

この傘の下に1.0で残っているのは、＃25501と＃25717だけだと思います。

(get|set)_zero_subnormals何かしたいのですが、おそらく最良の短期的な解決策は、それらをエクスポート解除することです。

おそらく確認する必要があるのは、 mapやcollectなどの収集操作のコンテキストで数値がどのように扱われるかです。 前者はスカラーを返しますが、後者は0D配列を返すことが指摘されました。