Julia: requireを削除し、インポートし、場合によってはimportallを削除して、使用にマージします

import Foo機能もどういうわけか必要です。ここでは、 Fooだけを取得し、他には何もありません。

using Foo: ？

using Foo: Foo ？

FooをFooモジュールにバインドするには（他には何もありません）：
import Foo
FooをモジュールFooにバインドするには、 xをFoo.xにバインドし、 yをFoo.yにバインドします
import Foo: x, y
FooをモジュールFooにバインドし、Fooのエクスポートされたすべての名前を修飾せずにバインドするには：
import Foo: *

代わりにusingになる可能性がありますが、これはimportの精神に基づいているように感じます。

これにより、スコープ内に何かを持ち込むことと、メソッド拡張に使用できるようにすることの違いもなくなります。 個人的にはそれは良いことだと思いますし、モジュールシステムをより理解しやすくしますが、私はそれを確実に立ち上げたかったのです。

モジュールのエクスポートされたすべてのバインディングを使用可能にするコンストラクトは、ハード（ importall ）バインディングではなく、ソフト（ using ）バインディングにする必要があるという強いケースがあります。 モジュールAがモジュールBを使用し、 foo(::Any)を定義するとします。 モジュールBの今後のリリースでも、 foo(::Any)が定義およびエクスポートされる場合は、それらが相互に競合することは望ましくありません。 また、モジュールBがfoo(::Int)を定義し、モジュールAが定義したメソッドの代わりにそのメソッドを呼び出す場合があります。これは、モジュールBがより具体的であるため、またはモジュールBから必要なすべての識別子をリストする必要があるためです。単一の競合する識別子のインポートを回避するため。

ただし、インポートする識別子を明示的にリストしている場合は、ソフトバインディングを指定する理由はありません。 識別子の新しいメソッドを定義しない場合（ハードバインディングとソフトバインディングの動作は同じ）、または新しいメソッドを定義する場合（ソフトバインディングはバインディングなしと同等であり、必要に応じて）その動作では、リストから識別子を削除する必要があります。

つまり、 @StefanKarpinskiの提案が好きです。 概念的には、ハードバインディングとソフトバインディングの両方が必要ですが、1つのキーワードですべての有用な動作を取得できます。

あなたの言ってる事がわかります。 その場合、 using Foo: （コロンはあるがアイテムはない）は概念的に一貫しているように見えるというあなたの提案が好きです。 コロンは、プルするシンボルを制限することを示していますが、リストしていません。

空の末尾の:は少しおかしいように見えますが、人々はそれに慣れると思います

空の末尾のコロンの問題は、現在、次の行で名前を検索していることです。つまり、 using Foo:は不完全であると見なされます。

関連：＃4600

現在のジュリアの慣習は、すべてをにインポートすることであることを私は知っています
現在のモジュールの名前空間ですが、まだあるはずだと本当に思います
モジュールの名前だけをインポートする簡単で自然な方法です。

また、FooとFoo.Barを使用した場合の現在のオーバーロードは
問題がある; Fooの内部に見えますが、Foo.Barの内部には見えません（Foo.Barが
モジュール？）

ステファンの提案では、これは次のように対処されていると思います

Fooの使用：Foo

2014年8月14日木曜日、 toivohnotifications @github.comは次のように書いています。

現在のジュリアの慣習は、すべてをにインポートすることであることを私は知っています
現在のモジュールの名前空間ですが、まだあるはずだと本当に思います
モジュールの名前だけをインポートする簡単で自然な方法です。

また、FooとFoo.Barを使用した場合の現在のオーバーロードは
問題がある; Fooの内部に見えますが、Foo.Barの内部には見えません（Foo.Barが
モジュール？）

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

@kmsquireですが、Fooモジュール内にFooモジュールがある場合はどうなりますか？ 残念ながら、それはあいまいです。

これは設計エラーです（そして警告が発生します）ので、問題ではありません

@ssfrrが提案したバージョンが一番好きです。

パッケージにはモジュールエントリポイントが1つしかないという基本的な規則はありますか？ -- import Fooは、パッケージFooのモジュールFooをインポートすることを意味します。 その他のモジュールは、 Fooのサブモジュールである必要があります。 これは、パッケージFoo、パッケージ内のFoo.jlとパッケージ内のmodule Fooの間に暗黙の対応があることを意味します。

importをローカル/相対インポートにも使用できるかどうか疑問に思っています。 プロジェクトにsrc/foo.jlとsrc/bar.jlがあり、 foo.jlあるとします。

import bar

src/bar.jlからインポートします。 これは、モジュールシステム内で動作するため、 includeを使用するよりも改善されています。

はい、パッケージ、パッケージエントリポイント、およびモジュールは1対1であることが期待されています。 必要に応じてこの規則を破ることができますが、モジュールは名前を付けるためだけのものであり、機能ユニットではないため、それほど必要はありません。 import barが絶対インポートであるのに対し、相対インポートの構文がimport .barであることを除いて、あなたが提起しているアイデアは＃4600です。

@StefanKarpinski import .barは実際にローカルディレクトリで「bar.jl」を検索しますか？ import .Barは、すでに現在の親モジュールのサブモジュールのみを参照しているという印象を受けました。

更新：ええと、それはあなたが＃4600で提案するものです。 ごめん。

：+1:。 これを行う場合は、0.4が適切なタイミングです。

：+1：先に進んで、これのいくつかをクリーンアップしてください（0.4の場合！）

拡張するかどうかを区別する2つのインポートメカニズムを使用する代わりに、関数定義のキーワードまたはアノテーションを介して拡張サイト自体で拡張を通知しませんか？たとえば、関数の前にキーワードをオーバーライドしますか？ Javaの@Overrideアノテーションに似ています。

これには、関数が別の関数をオーバーライドしていることがはっきりとわかるという利点があります（したがって、メソッドです）。

@ssagaert、それはすでに可能です。 これを行うには、関数定義にモジュール名を明示的に記述します（たとえば、 Base.print(…) = … ）。これは、多くの人が集まるスタイルのようです。 唯一のこだわりは、構文がすべての可能な名前（ .+など）に対して機能するとは限らないことです。

（余談ですが、他のGitHubユーザーを困らせるのを防ぐために、マクロをバッククォートで囲むように注意してください）。

：+1： @overrideを使用するという@ssagaertの提案に対して、最初にメソッドをインポートせずにメソッドを拡張しようとしたときの元のエラーメッセージは次のようになります。

ERROR: error in method definition: function Foo.x must be explicitly imported to be extended

では、おそらく@extendの方が適しているのでしょうか。 私は英語を母国語とはしていませんが、_override_とは、キャンセル、無効化、無効化、無効化、無効化、無効化、中止などを意味することを理解しています。

これはもっと明確だと思います：

<strong i="13">@extend</strong> Base.show(...) = ...

よりも：

import Base: show

# ... several lines here

Base.show(...) = ...

@ Ismael-VC Base.show(...) = ... 、何もインポートせずにすでに機能しています。 importは、 show(...) = ...でBase.show $を拡張する場合にのみ必要です。

@Ismael-VCオーバーライドワードは単なる提案でした。 拡張またはその他の意味のあるものにすることができます。 また、ジュリアではマクロを意味するため、 @は存在しないはずです（ @Overrideは、注釈であるJavaを指します）。

@simonsterありがとう私はそれを知りませんでした！

@ssagaertだからあなたはキーワードを意味しますか？ 私はこのようなことを試みましたが、それでもmacro-fooを吸います：

module Extend

export <strong i="9">@extend</strong>


macro extend(x)
    mod = x.args[1].args[1].args[1]
    met = x.args[1].args[1].args[2]
    imp = :(Expr(:import, $mod, $met))
    :(Expr(:toplevel, $imp, $(esc(x))))
end


end

これは一般的ではないことはわかっていますが、それでも解析が行うことを返す式を作成することはできません。

julia> using Extend

julia> type Foo end

julia> <strong i="13">@extend</strong> Base.show(x::Foo) = Foo
:($(Expr(:toplevel, :($(Expr(:import, Base, :show))), show)))

julia> parse("import Base.show; Base.show(x::Foo) = Foo")
:($(Expr(:toplevel, :($(Expr(:import, :Base, :show))), :(Base.show(x::Foo) = begin  # none, line 1:
            Foo
        end))))

一般的で機能する@extendマクロは、インポートメカニズムのセマンティクスを変更しないと思います。

@ Ismael-VC私はやりましたが、@ mbaumanの「トリック」も好きです。

「これ」を意味するためにそれ自体で.を使用できるのは良いことだと思います。 したがって、次のような式を書くことができます。
import Base: . （インポートBase.Baseを意味します）
また
using ..

ただし、 https： //github.com/JuliaLang/julia/pull/11891#issuecomment-116098481が必要になると確信しています。 あいまいなケースを解決するには、 .の前にスペースを入れるだけで十分かもしれませんが、後はスペースを入れないでください。

requireはすでに非推奨になっていると思います。 モジュールのインポートに1.0でより柔軟なドット表記を追加するのは良いことかもしれませんが、ここで0.6機能のフリーズによって何かを変更することはないと思います。

昨日のたくさんの議論の後、私はhttps://github.com/JuliaLang/julia/issues/8000#issuecomment-52142845とhttps://github.com/JuliaLang/julia/の提案のようなものに傾いています

using A: x, y    # hard imports x and y from A

using A: A       # hard imports just the identifier `A`

using A: ...     # soft imports all of A's exports

using A     # equivalent to `using A: A, ...`

using A.B   # A.B must be a module. equivalent to `using A.B: B, ...`

using A: ..., thing1, thing2    # import all exports plus some non-exported things

別の方法は、 using importを保持することです。

import A             # hard binding for the module `A`
import A: ...        # soft bindings for all names exported by `A`
import A: x, y       # hard bindings for `x` and `y` from `A`
import A: x, y, ...  # equivalent to doing both of the previous two

バインディングがハードかソフトかについての一般的なルールは単純です。明示的に要求された名前はハードバインディングであり、暗黙的に指定されたバインディングはソフトです。

編集：このスキームにimport A; import A: ...の省略形を追加したいという要望があります。これは、現在using Aが行っていることとほぼ同じです（唯一の違いは、 using Aが現在Aソフトインポートしていることです。 using Aあるか、 import A...が提案されています。

はい、それも良い提案だと思います。 基本的には、 usingとimportのどちらを好むかによって決まります。

補遺、 using Aをimport A; import A: ...の省略形として保持することができます–各モジュールがそれ自体のエクスポートされたバインディングを持っているという現在の動作を取り除くことと相まって、 using Aが原因ですAへのソフトバインディングが利用可能になります。

それでも複数のキーワードがあったら、かなりがっかりします。

importとexportの対称性が好きです。 （誰かがどこかで指摘したように。）

メソッド拡張の観点から、常に「ハードバインディング」を実行することは、最も安全なデフォルトのようには思えません。 「ハードバインディング」の必要性を取り除くことができるメソッド拡張のためのモジュール修飾を要求するという、関連しているがいくぶん別個の提案がありました。

この目的には、ハードバインディングも必要です。

import Package: x
x = 1   # gives an error

そして決定的に、この提案は常にハードバインディングを行うとは限りません---明示的にリストしたものに対してのみ。 using importと言うことを要求しても、安全性はあまり向上しません。

安全性は、ソフトバインディングでうまく逃げることができるメソッド拡張を行っていない場所の大部分から来ています。 パッケージのすべてのエクスポートをインポートする（またはエクスポートされない特定のソフトバインディングを取得する）ことなく、特定のソフトバインディングを要求する方法がまだあるはずだと思います。

インポートされたバインディングを上書きするための警告はまだありますか？

モジュールの資格を要求するのは良い考えだと思います。 今のところ、関数が導入されているのか、メソッドが拡張されているのかを知るには、パッケージ全体の内容を調べてimport A: funcステートメントを探す必要があります。

インポートされたバインディングを上書きするための警告はまだありますか？

実は今は間違いだと思います。

両方のキーワードを保持しながら、物事を少し単純化する別の提案が浮かんでいます。

1. 構文import A: ...を追加します
2. using A:廃止する
3. using A.Bでは、モジュールとしてA.Bが必要であり、 import A.B; import A.B: ...の省略形であることを文書化します。

このように、すべてをimportで実行できますが、便利なようにusing Xを使用できます。 これは、特に簡単に移行できます。

ところで、私がここに投稿したように、 usingは一貫性がないように見えます。 usingを保持する場合は、可能であればuseに名前を変更する必要があります。
関数を拡張するときは、モジュールの定量化が必要だと思います。その意味は、インポートしてから拡張するパターンよりもはるかに明確だからです。

私の好きなアプローチ：

• 拡張には明示的なモジュールプレフィックスが必要です
• モジュール名のみが必要で、そのシンボルは必要ない場合は、 using A: Aを使用します
• importとそれが作成するバインディングの種類を削除します

https://github.com/JuliaLang/julia/issues/8000#issuecomment -327512355を実装するために発生する必要があること：

• using Aの動作をハードインポートAに変更します
• using A: xのサポートを削除します
• xがサブモジュールではないusing A.xのサポートを削除します
• import A.xのサポートを削除します。 xはサブモジュールではありません
• ...構文のサポートをimportに追加します

using A: xは頻繁に使用され、非常に便利です。 名前空間にxが必要だと言っていますが、それを拡張したくありません。 import A: xでは、 xを拡張できるようにしたいと言っています。 関数を使用できるようにすることと、それを拡張できることには、意味のある違いがあります。

考えてみると、ここでの最大の問題は、 using A.Bが2つのことを行うことです。 Bがモジュールの場合、すべてのエクスポートをソフトインポートするか、それ以外の場合はソフトインポートだけです。 B 。 これを修正し、 using A.Bをモジュールにのみ許可し、特定のバインディングを一度に1つずつソフトインポートするためのusing A: a, bを設定する必要があると思います。

import A.xと同等である代わりに、 import A: xを書く方法が1つあればいいのですが。

私もできるのでimport A: xに投票します。 import A: x, y, @zですが、 import A.x, A.y, a.@zは見苦しく見えます。

これが1.0から削除されるということは、1.0でusingとimportの両方が残ることを意味しますか？ それは私の意見では少し残念です。

どうですか：

• 拡張のためにモジュールプレフィックスを強制します。 これにより、他のファイルへのインポートによる偶発的な拡張子ではなく、拡張子が意図されていることがコードで明確になります。
• using Aはimport A: ...になります
• using A.X （ Xはモジュールです）はインポートA.X: ...になります
• using A: X （ Xはモジュールではありません）はimport A: Xになります
• import A: Xは変更されませんが、 Xを自動的に拡張することはできません（最初のポイントを参照）
• usingキーワードを削除します

いくつかのユースケースがありませんか？ 多分これはすでに提案されました...

拡張時にモジュールについて明示するのが好きなのは、拡張がはるかにローカルになることです。 現在、メソッドが拡張されると、インポートをモジュールの先頭に非常に近づけるのが一般的です（これは完全に異なるファイルにある可能性があります！）。 拡張メソッドが削除されると、通常、インポートステートメントは忘れられます。

それは、かなりの支持を得た上記の私の提案と本質的に同じだと思います。 @JeffBezansonは、少なくとも使いやすさのためにusing A: x using Aを維持したいと考えています。明らかに（私はこれで販売されていません）、バインディングをインポートできるようにすることは重要なユースケースです。あなたがそれを拡張することができないような方法。 反対方向に進んでimportをusingに置き換える提案がいくつかありますが、どれも実際にはあまり注目されていません（ importはより基本的なようです）。

違いは次のとおりです。

• インポートA：x、y＃ xおよびyのハードバインディングを$ Aから

「ハードバインディング」の意味がモジュールプレフィックスなしで拡張できるようなものであると仮定すると、私のバージョンではハードバインディングはありません。 拡張する場合は、拡張する場所にモジュールプレフィックスを付けます。 何かが拡張子であるかどうかの意味を変える他のファイルの不気味なimportステートメントはありません。

どうやら（私はこれで売られていません）、それを拡張できないような方法でバインディングをインポートできることは重要なユースケースであるため、 using A: xです。

モジュールプレフィックスを強制的に処理していませんか？ または、次のような非モジュールについて話しているのですか？

module M
    x = 1
end

import M: x; x = 2とusing M: x; x = 2の両方で同じ警告メッセージが表示されるため、問題が何であるかわかりません...

$ import A: ... ＃$を簡単にするためにusing Aを維持することは、私の意見では少し過剰に思えます。

モジュールプレフィックスを強制的に処理していませんか？

はい; 関数を拡張するために関数を修飾する必要がある場合、この点は関係ありません。

過剰インポートを容易にするためにAを使い続けるA：...私の意見では少し過剰に思えます。

私はそれを反対の見方で見ています。 キーワードが1つしかないという人為的な要件を満たすためだけに、人々をusing A （これは素晴らしくて短く、私たちは皆慣れています）からimport A: ...に切り替えさせます。

スレッドを読むと、2つのキーワードを持つことの主な価値は、拡張できるバインディングと拡張できないバインディング（ハードバインディング）を区別することであるように思われます。 それを念頭に置いて、私は2つの実行可能な解決策があると思います。

• 1つのキーワード+拡張にはプレフィックスが必要
• 2つのキーワード。1つは通常の（非拡張）使用用で、もう1つは拡張使用用です。この場合はusingとextendingをお勧めします。 importは問題ありませんが、 extendingは、2番目のキーワードが存在する理由を明らかにします

いずれの場合も、モジュールFooのみをバインドするために、次のいずれかを追加して、 usingをそのままにすることをお勧めします。

• using Foo: nothing （現在機能しています）
• using Foo: Foo （現在機能しています）
• using Foo: （後で追加できます）

その場合、 extendingはusingと同じように動作するはずですが、唯一の違いは、 extendingで持ち込まれたバインディングを拡張でき、場合によってはextending Fooを禁止して明示的にする。

現在の動作

| | 利用可能にする（使用）| 拡張可能にする（インポート）|
| ------------------- | -------------------------- | ---------------------- |
| モジュールのみ| using module: moduleまたはusing module: nothing | import module |
| エクスポートされたすべて| using module （副作用： import moduleのように機能します）| ？ |
| 特定のもの| using module: x,y | import module: x,y |

提案

| | 利用可能にする（使用）| 拡張可能にする（インポート）|
| ----------------- | ------------------------ | -------------------------- |
| モジュールのみ| using module | import module |
| エクスポートされたすべて| using module: * | import module: * |
| 特定のもの| using module: x,y | import module: x,y |

これの良いところは、より多くをインポートすることはより多くを書くことに対応するということです。 つまり、 using moduleから始めて、変数を名前空間に直接インポートする場合は、 nothingまたはmoduleを削除する代わりに、 : xを追加します。 また、入力する最短のものに含まれるものが最も少ないことも意味します。

using: *,xを実行して、エクスポートされたすべてのものを使用可能にし、エクスポートされなかったxを使用可能にすることもできます。

下位互換性のための妥協：

| | 利用可能にする（使用）| 拡張可能にする（インポート）|
| ----------------- | ------------------------ | -------------------------- |
| モジュールのみ| using module: | import module: |
| エクスポートされたすべて| using module: * | import module: * |
| 特定のもの| using module: x,y | import module: x,y |

下位互換性のために現在の動作でusing moduleとimport moduleを維持しますが、非推奨にします。

@FelixBenning ： import Module現在、（それ自体で） using Moduleを超えて拡張可能にすることはなく、コードをロードしてModule （および他には何も）を名前空間に取り込みません。 。

たるみについて私が言ったことを反映し、たるみの穴で消えないようにするためだけに：

using X: *をすべてのエクスポートされたものを利用可能にするためのデフォルトにするのに対して、 using Xだけにすることで、人々は必然的にインポートするものに対してより慎重になるとは思いません。 私は知っています、他の人がそれをどのように行うかを指摘すると、それは悪い形と見なされますが、Pythonは基本的にimport Xとimport X: *でそれらのセマンティクスを持っています、それでも彼らのエコシステムはそれらのスターインポートで散らかっています🤷‍♂️（そして彼らはそれを嫌っていることで有名です）入力しなければならないわずかに長いテキストが、人々が最も便利だと思うことをするのを妨げるとは思いません。すべてをインポート/使用して、コンパイラにそれを理解させるだけです。 だから私は人々にその星を明示的に書かせるという魔法の弾丸に警戒しているのです。

さらに、 import module: *とusing module: *は、提案された意味では使用できません。 *は有効なJulia識別子であり、 +や単語mulと同じようにインポート/使用できるため、すでに意味があります。

@tpappは、ドキュメントをもう一度誤解したか、 import ModuleによってModule.xが拡張可能になります。 using Module: xはModule.x拡張可能にしませんが。 したがってimport Moduleは何かを拡張できるようにし、 using Moduleもそうします。そのため、使用するとその副作用があることに気づきました。

（https://docs.julialang.org/en/v1/manual/modules/から）

私たちのどちらが正しいかは実際には問題ではありません-どちらの場合でも、すべてが何をしているのかさえ理解できない場合、現在の状況は明らかに混乱しています。

@mbauman良い点-私はそれを忘れました。 *は、 usingが、インポートと使用の違いでimportが行うことをミラーリングする構造だけで、拡張可能になるかどうかは関係ありません。 したがって、より適切な記号がある場合- all 、 __all__ 、 everything 、 exported 、...？ 私はそれですべてです。 もっとインポートすることは、おそらくもっと入力することによって反映されるべきだと思います。

しかし、それをまったく望まないのであれば、もちろん、

| | 利用可能にする（使用）| 拡張可能にする（インポート）|
| ----------------- | ------------------------ | -------------------------- |
| モジュールのみ| using module: module | import module: module |
| エクスポートされたすべて| using module | import module |
| 特定のもの| using module: x,y | import module: x,y |

また

| | 利用可能にする（使用）| 拡張可能にする（インポート）|
| ----------------- | ------------------------ | -------------------------- |
| モジュールのみ| using module | import module |
| エクスポートされたすべて| using module: module | import module: module |
| 特定のもの| using module: x,y | import module: x,y |

しかし、最終結果がどうであれ、それは一貫している必要があります。 そして現時点ではそうではありません。

using Aは、 A.f拡張可能にしますが、それ自体fではありません。 どのモジュールから拡張するかを宣言せずに_just_ fを拡張するには、明示的にimport A: fする必要があります。 それ以外の場合は、それを修飾する必要があります。

usingのセマンティクスについては、以下を確認してください

julia> module A
        export f
        f() = "no args in A"
       end
Main.A

julia> f()
ERROR: UndefVarError: f not defined
Stacktrace:
 [1] top-level scope at REPL[2]:1

julia> using .A

julia> f()
"no args in A"

julia> f(1)
ERROR: MethodError: no method matching f(::Int64)
Closest candidates are:
  f() at REPL[1]:3
Stacktrace:
 [1] top-level scope at REPL[5]:1

julia> f(x) = "one arg where?"
ERROR: error in method definition: function A.f must be explicitly imported to be extended
Stacktrace:
 [1] top-level scope at none:0
 [2] top-level scope at REPL[6]:1

julia> A.f(x) = "one arg where?"

julia> f(1)
"one arg where?"

そしてこれはimportのセマンティクスです：

julia> module A
        export f
        f() = "no args in A"
       end
Main.A

julia> f()
ERROR: UndefVarError: f not defined
Stacktrace:
 [1] top-level scope at REPL[2]:1

julia> import .A

julia> f()
ERROR: UndefVarError: f not defined
Stacktrace:
 [1] top-level scope at REPL[4]:1

julia> A.f()
"no args in A"

julia> f(1)
ERROR: UndefVarError: f not defined
Stacktrace:
 [1] top-level scope at REPL[6]:1

julia> A.f(1)
ERROR: MethodError: no method matching f(::Int64)
Closest candidates are:
  f() at REPL[1]:3
Stacktrace:
 [1] top-level scope at REPL[7]:1

julia> f(x) = "one arg where?"
f (generic function with 1 method)

julia> f(1)
"one arg where?"

julia> A.f(1)
ERROR: MethodError: no method matching f(::Int64)
Closest candidates are:
  f() at REPL[1]:3
Stacktrace:
 [1] top-level scope at REPL[10]:1

julia> A.f(x) = "one arg where in A"

julia> A.f(1)
"one arg where in A"

@FelixBenning ：はい、あなたは誤解していると思います。 FWIW、「... Foo.x拡張可能にする」は、区別にアプローチするための紛らわしい方法だと思います---完全修飾関数名にメソッドをいつでも定義できます。 using Foo: xで何が起こるかというと、 Foo自体は名前空間に取り込まれません。

ちなみに、このトピックを読み直すと、＃25306が一種の局所最適点に到達したかどうか疑問に思います。残っている唯一の決定は、名前空間（現在using Foo: f ）への拡張不可能なインポートが必要かどうかです。 しかし、それは壊れているので、マニュアルの章はおそらくその間に書き直しの恩恵を受けるでしょう、多くのユーザーは全体を混乱させると感じます。

これは私がドキュメントの現状に近づく方法です：

1. using Mはモジュールをロードし、 Mとそのエクスポートされたシンボルを名前空間に取り込みます。 これは、輸出が重要な唯一のケースです。
2. Mを取得したら、 M.yなどの修飾名を使用して、（a）エクスポートされていないシンボルにアクセスし、（b）エクスポートされているかどうかに関係なく、関数にメソッドを追加できます。
3. Juliaは、 M.fなどの修飾名を使用しない限り、関数にメソッドを追加できないようにします。
4. ... import M: fの場合、メソッドを定義するときにfを使用できます。
5. import Mとusing M: xは、それぞれMまたはx （ Mではない）をそれぞれ名前空間に取り込むためのものです。 一部の人々は、パッケージコードでこれらのフォームを使用して、名前空間がクリーンに保たれていることを確認することを好みます（関連するスタイルガイドをここにリンクしてください）。

順序は、多かれ少なかれ、より高度な使用法で遭遇したユースケースを反映しています。 上記のすべてがサブモジュールに適用され、 M M.Aが使用されます。

これはどうですか：

• using MはMをスコープにもたらします
• using M: xはM.xをスコープに取り込みます（ xとして）
• using M: ...は、エクスポートされたMのすべてのシンボルをスコープに取り込みます
• using M: x, ...は、エクスポートされたM x （エクスポートされていない可能性があります）をスコープに取り込みます。
• importはありません。 関数を拡張するには、修飾名を使用する必要があります。 （または、 using M; const foo = M.fooは、すでに実行できるようになります。）
• 上記のすべてにおいて、 Mもサブモジュールである可能性があります。たとえば、 Foo.Barおよびxも現在の意味でx as yである可能性があります。

または、 using importを使用すると、 https： //github.com/JuliaLang/julia/issues/8000#issuecomment-355960915と等しくなります。

非常に一般的な使用法（特に「スクリプト」での使用ですが、特定のスタイルのパッケージも使用されます）

using Foo, Bar, Baz

エクスポートされたシンボルに依存するだけです。 これを最も単純に、おそらく現在と同じくらい単純に保つことには、いくらかの利点があります。

@tpapp

あなたは誤解していると思います。 FWIW、私は「... Foo.xを拡張可能にする」というのは、区別に近づくための紛らわしい方法だと思います---完全修飾関数名にメソッドをいつでも定義できます。

さて、 using Foo: x $の後に$ Foo.xを拡張できますか？ はいの場合、ドキュメントは完全ではありません（私のスクリーンショットを参照）。 いいえの場合、私はこれらのステートメントがどのように機能するかを完全に理解しており、明らかにimport FooはFoo.x拡張可能にするために何かをしました。 したがって、文字通りFoo.xを拡張に使用できるようになります。 これらの言葉のあらゆる意味で。 確かに、 xを拡張に使用できるようにするわけではありませんが、それがimport Foo: xの目的です。

さて、 using Foo: x $の後に$ Foo.xを拡張できますか？

なんらかの方法Fooを名前空間に入れない限り（たとえばusing Foo ）、そうではありません。

私はこれらのステートメントがどのように機能するかを完全に理解しました

これについてはよくわかりませんが、モジュールと名前空間について質問がある場合は、Discourseフォーラムをご利用ください。

明らかにimport FooはFoo.x拡張可能にするために何かをしました

メソッドを追加する前に、修飾された名前を使用して関数を参照できる必要があるという意味でのみです。

その後、ドキュメントは完全ではありません

ちょっと変わった方法だと思います。 その特定の例では、あなたがするのがusing MyModule: x, pだけの場合; その場合、拡張に使用できるメソッドがないため、テーブルは正しいです。

私は、上で述べたように、それがより良く書かれる可能性があることに同意します。 名前空間に慣れていない多くの人は、それが混乱していると感じています。 そして、TBH、 using / importサーカス全体がやや混乱しているため、この問題が発生します。

@tpapp

モジュールが名前空間にある場合、すべての関数をフルネームで拡張できることは絶対に明らかではありません。 これが現在の振る舞いであることは知っていますが、それを知らない人がすでにそれを想定しているとは思いません。 特に、名前空間にあるからといって、それが拡張可能であるとは限らないからです。 using module:xを実行すると、 xを拡張できません。 xを拡張することはできますが、 import module:xを使用すると。 したがって、 usingとimportの違いは、インポートされた関数を拡張できるかどうかであるというのは合理的な仮定です。

この仮定を使用すると、 using moduleがmodule.xの使用のみを許可し、 module.xの拡張を許可しない場合は意味があります。 import moduleは、 module.xの拡張を許可します。 したがって、この仮定を採用してドキュメントを読むと、それに関する2つのことが間違っていることがわかります。

1. using moduleを使用すると、 module.xを拡張できます。 したがって、学習者の見通しからすると、 using moduleには副作用があり、 import moduleのように機能します。つまり、 module.x拡張可能にします。 そして、物事を拡張可能にすることは、 using import ＃$のことです。
2. importとは対照的に、 usingは、 moduleだけでなく、その中のすべてのものを利用可能にします。

これが私が自分のテーブルで表現しようとしたものです。 2つの異なる単語が使用されている場合（インポート/使用）、それらは2つの異なることを行う必要があり、それは明確である必要があります。 usingが拡張を許可する場合と許可しない場合は、予測できない動作になります。

@martinholtersが示唆しているように、インポートを完全に削除することをお勧めします。 特定のことにランダムに使用される2つの単語を使用することはできません。 importが特定の関数をインポートするときに拡張可能にすることを意味し、 using module: fooがそれを許可しない場合、名前空間にmoduleのみを含めると同じ動作が発生するはずです。

モジュールが名前空間にある場合、今すぐフルネームですべてを拡張できるからといって、これが明白または単純なことであるとは限りません。

名前空間に含まれているだけで十分である場合、 using module:xを使用して名前空間に含めた場合、または名前空間に含まれているだけでは不十分な場合は、 xも拡張できるはずです。 usingコマンドを使用すると、$ module.xを拡張できません。
または3番目のオプション： importはなく、常にフルネームで関数を拡張する必要があります。

モジュールが名前空間にある場合、すべての関数をフルネームで拡張できることは絶対に明らかではありません。

私は同意します。それが私がドキュメントの書き直しを主張する理由です。 しかし、それは現在の問題に正接しています。 （1）現在のAPIに関するドキュメントを改善するための提案と、（2）2つがいくらか関連している場合でも、それを別々に再設計するための提案を保持するのが最善です。 近いうちに（1）のPRをする予定です。

@tpapp本質的に意味をなさないものを文書化することはできません。 これらのドキュメントはどちらも正しくありません。

1. 「名前空間にあるものは何でも拡張できます」（ using module:xではxを拡張できないため）
2. 「名前空間に存在するだけでは拡張には不十分です。これが、別々の単語usingとimportが存在する理由です」（フルネームの場合、実際には名前空間に存在するだけで十分であるため、false-それを停止します十分であることが私の提案でした）
3. 「名前空間内のすべてのものをそのフルネームで拡張できます」（完全な真実であるために存在を停止するにはimport module:xが必要になります- @martinholtersの提案）

これらのいずれも許容されます。 しかし、これらのどれも実際には現実ではありません。 現在、「ものをインポートする」には2つの異なる単語が使用されていますが、実際には明確なユースケースはありません。 これは、ブール値を反復処理すると、 forループがwhileループのように動作する場合があるようなものです。 ドキュメントの量がそれを混乱させないようにすることはありません

本質的に意味をなさないものを文書化することはできません。

現在のモジュールAPIは明確に定義されているため、文書化できます（すでに文書化されているので、もっと良いはずだと思います）。

これらのドキュメントはどちらも正しくありません。

私（または他の誰か）のPRを待って、そこにある実際のテキストについてコメントしてください。 架空のドキュメントを作成し、それが正しくないと主張することは、この議論にノイズを追加するだけです。

@tpapp多分私は言うべきだった、

本質的に意味をなさない、紛らわしい方法で何かを文書化することはできません

つまり、ある意味で、コードは必要なすべてのドキュメントです。 それのどこが悪いんだい？ それを消化するのにかかる時間。 そして、それが例外に満ちているので、私は現在それがどのように機能するかを説明する簡単な方法を見ていません。 そもそも存在してはならない例外。

私が伝えようとしていることを本当に見ていませんか？

現在の状況は不必要に複雑であり、文書化が不十分であるという一般的な合意があると思います。 そして間違いなく、機械を単純化することで文書化が容易になります。 しかし、そのような単純化は破綻するので、2.0より前に行うことはできません。 それで、それ以前のドキュメントの改善は意味がないというあなたのポイントはありますか？ それから私は同意しません。 私は2つの別々の問題を見ています：2.0（この問題についてです）で行われる簡素化には、（うまくいけば）必要なドキュメントの更新と、このスレッドを読むことによってひどく必要と思われるが別の問題である現在の動作のドキュメントの改善が含まれます。

＃38271を行った後、未解決の質問は

他のモジュールの関数へのメソッドの追加を処理する方法

1. 常に完全修飾名（ Foo.bar() = ... ）が必要です。
2. また、シンボルがスコープ内にある場合にのみ許可します（ using Foo: bar; bar() = ... ）
3. （2）ただし、特別な方法でスコープに取り込みます（現状、 import Foo: bar; bar() = ... ）

エクスポートリストとモジュール名のみを処理する構文

1. using Fooは、 Foo内のすべてのエクスポートされたシンボルをスコープに移動します。 import Fooはモジュールのみです（現状）
2. using Foo: ...または他の同様の構文、次にusing Fooモジュールのみ。

（1 | 2）＆2を使用すると、1行を失う代わりに、 usingまたはimportのいずれかの単一のキーワードに統合できます。

using LinearAlgebra, Random, StaticArrays

大きな変化を考慮しなくても、それが価値があるかどうかはわかりません。

これは、元の設計が見逃したクリーンなソリューションを提供する問題の1つではありません。 トレードオフがあります。 私は待って、現在の（1.0）セットアップを維持しながら、より良いドキュメントがユーザーエクスペリエンスを改善できるかどうかを確認します。

2.0の場合、構文をクリーンアップするだけで、より一貫性があり、実際に何が起こっているのかを説明できると便利だと思います。 何かのようなもの：

| 前| 後|
|-|-|
| using Foo | useall from Foo |
| import Foo | use Foo |
| using Foo: a | use a from Foo |
| import Foo: aおよびimport Foo.a | extend a from Foo |