Julia: 필요, 가져오기 및 가져오기를 제거하고 병합하여 사용

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에서 원하는 모든 식별자를 나열하는 것을 원하지 않습니다. 충돌하는 단일 식별자를 가져오는 것을 방지합니다.

그러나 가져오려는 식별자를 명시적으로 나열했다면 소프트 바인딩을 제공할 이유가 없습니다. 하드 바인딩과 소프트 바인딩이 동일한 동작을 하는 경우 식별자의 새 메서드를 정의하지 않거나 새 메서드를 정의하려고 합니다. 이 경우 소프트 바인딩은 바인딩 없음과 동일하며 원하는 경우 목록에서 식별자를 제거하기만 하면 됩니다.

간단히 말해서 @StefanKarpinski 의 제안이 마음에 듭니다. 개념적으로 하드 바인딩과 소프트 바인딩이 모두 필요하지만 단일 키워드로 모든 유용한 동작을 얻을 수 있습니다.

너의 의도를 알 겠어. 이 경우 using Foo: (콜론은 있지만 항목 없음)이 개념적으로 일관되는 ​​것처럼 보인다는 귀하의 제안이 마음에 듭니다. 콜론은 가져올 기호를 제한하지만 아무 것도 나열하지 않음을 나타냅니다.

: 뒤에 오는 빈칸이 좀 웃기긴 한데 익숙해지실 거라 생각합니다.

빈 후행 콜론의 문제는 현재 다음 줄에서 이름을 찾고 있다는 것입니다. 즉, using Foo: 는 불완전한 것으로 간주됩니다.

관련: #4600

현재 Julia 관행은 모든 것을
현재 모듈의 네임스페이스이지만 여전히
모듈 이름만 가져올 수 있는 간단하고 자연스러운 방법입니다.

나는 또한 Foo를 사용하고 Foo.Bar를 사용하는 현재 오버로딩이
문제가 있는; Foo 내부는 보이지만 Foo.Bar 내부는 아닙니다(Foo.Bar가
모듈?)

나는 Stefan의 제안에서 이것이 다음과 같이 다루어진다고 생각합니다.

Foo 사용: Foo

2014년 8월 14일 목요일에 toivoh [email protected] 은 다음과 같이 썼습니다.

현재 Julia 관행은 모든 것을
현재 모듈의 네임스페이스이지만 여전히
모듈 이름만 가져올 수 있는 간단하고 자연스러운 방법입니다.

나는 또한 Foo를 사용하고 Foo.Bar를 사용하는 현재 오버로딩이
문제가 있는; Foo 내부는 보이지만 Foo.Bar 내부는 아닙니다(Foo.Bar가
모듈?)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/8000#issuecomment -52202142.

@kmsquire 하지만 Foo 모듈 내부에 Foo 모듈이 있으면 어떻게 됩니까? 불행히도 모호합니다.

그것은 설계 오류(그리고 경고 발생)이므로 문제가 되지 않습니다.

저는 @ssfrr 이 제안한 버전이 가장 좋습니다.

패키지에 하나의 모듈 진입점만 있다는 기본 규칙이 있습니까? -- To 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 를 사용하는 것보다 개선된 것입니다.

예, 패키지, 패키지 진입점 및 모듈은 일대일이어야 합니다. 필요한 경우 이 규칙을 어길 수 있지만 모듈은 이름 지정을 위한 것일 뿐 기능 단위가 아니기 때문에 그렇게 할 필요가 많지 않습니다. 상대 가져오기 구문이 import .bar 인 반면 import bar 는 절대 가져오기라는 점을 제외하고는 #4600이라는 아이디어가 있습니다.

@StefanKarpinski import .bar 는 실제로 로컬 디렉토리에서 "bar.jl"을 찾습니까? import .Bar 이 이미 현재 상위 모듈의 하위 모듈만 참조한다는 인상을 받았습니다.

업데이트: 아, 그게 당신이 #4600에서 제안한 것입니다. 죄송합니다.

:+1:. 우리가 이것을 하려고 한다면, 0.4가 그것을 하기에 좋은 시기가 될 것입니다.

:+1: 계속해서 이 중 일부를 정리하십시오(0.4용으로!)

확장 여부를 구분하기 위해 두 가지 가져오기 메커니즘을 사용하는 대신 기능 정의에서 키워드 또는 주석을 통해 확장 사이트 자체에서 확장 신호를 보내지 않는 이유는 무엇입니까? 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 재정의 단어는 단지 제안일 뿐입니다. 확장되거나 의미 있는 다른 것이 될 수 있습니다. 또한 julia에서는 매크로를 의미하므로 @ 가 없어야 합니다( @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 는 편의상 사용할 수 있습니다. 이것은 또한 전환하기 특히 쉽습니다.

BTW, using 내가 여기 에 게시한 것처럼 일관성이 없어 보입니다. using 를 유지하는 경우 가능한 경우 use 로 이름을 바꿔야 합니다.
import-the-extend 패턴보다 의미가 훨씬 명확하기 때문에 함수를 확장할 때 모듈 수량화가 필요하다고 생각합니다.

내가 선호하는 접근 방식:

• 확장에 대한 명시적 모듈 접두사 필요
• 기호가 아닌 모듈 이름만 원하면 using A: A 를 사용하십시오.
• import 및 생성된 바인딩 종류를 제거합니다.

https://github.com/JuliaLang/julia/issues/8000#issuecomment -327512355를 구현하기 위해 필요한 일:

• using A 의 동작을 하드 가져오기 A 변경
• using A: x 에 대한 지원 제거
• x 가 하위 모듈이 아닌 using A.x 에 대한 지원 제거
• x 가 하위 모듈이 아닌 import A.x 에 대한 지원 제거
• ... 구문에 대한 지원을 import 에 추가

using A: x 는 자주 사용되며 매우 유용합니다. 네임스페이스에 x 를 원하지만 확장하고 싶지는 않습니다. import A: x 에서 x 를 확장할 수 있기를 원한다고 말하고 있습니다. 사용할 수 있는 기능을 갖는 것과 확장할 수 있는 것 사이에는 의미 있는 차이가 있습니다.

생각해 보니 여기서 가장 큰 문제는 using A.B 가 두 가지 일을 한다는 것입니다. B 가 모듈이면 모든 내보내기를 소프트 가져오고 그렇지 않으면 소프트 가져오기만 합니다. B . 나는 그것을 수정하고 using A.B 를 모듈에만 허용하고 한 번에 하나씩 특정 바인딩을 소프트 임포트하기 위해 using A: a, b 를 가져야 한다고 생각합니다.

import A: x 을 쓰는 대신 import A.x 와 동일한 방법이 있다면 선호합니다.

우리도 할 수 있기 때문에 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 는 모듈임) import A.X: ...
• using A: X ( X 는 모듈이 아님)은 import A: X 가 됩니다.
• import A: X 는 변경되지 않지만 X 를 자동으로 확장할 수 없습니다(첫 번째 항목 참조).
• using 키워드 삭제

사용 사례가 누락되었습니까? 아마도 이것은 이미 제안되었을 것입니다 ...

확장할 때 모듈에 대해 명시적으로 말하는 것에 대해 내가 좋아하는 것은 확장이 훨씬 더 지역적이라는 것입니다. 지금은 메서드가 확장될 때 가져오기를 모듈의 맨 위에 매우 가깝게 배치하는 것이 일반적입니다(완전히 다른 파일에 있을 수 있습니다!). 확장 메서드가 삭제되면 일반적으로 import 문을 잊어버립니다.

나는 그것이 본질적으로 상당한 양의 지원을 받은 위의 제안 과 동일하다고 생각합니다. @JeffBezanson 은 using A 를 최소한 사용하기 쉽게 유지하고 $#$ using A: x $#$를 유지하기를 원합니다. 분명히 (저는 이에 대해 판매하지 않음) 바인딩을 가져올 수 있는 중요한 사용 사례이기 때문입니다. 연장할 수 없는 방식입니다. 다른 방향으로 가서 import 를 using 로 대체하자는 몇 가지 제안이 있지만 그 중 어느 것도 실제로 많은 관심을 끌지 못했습니다( import 가 더 근본적인 것 같습니다).

차이점은 다음과 같습니다.

• import A: x, y # x 및 y 에 대한 하드 바인딩 from 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: ... 제 생각에는 좀 과한 것 같습니다.

나는 그것을 반대 방향으로 본다. 사람들이 using A (이것은 멋지고 짧고 우리 모두 익숙함)에서 import A: ... 로 전환하도록 하는 것은 단지 하나의 키워드만 있다는 인위적인 요구 사항을 충족시키기 위해 과도하다는 것입니다.

쓰레드를 읽어보니 2개의 키워드를 갖는 것의 주된 가치는 확장 가능한 바인딩(하드 바인딩)을 구분하는 것 같습니다. 이를 염두에 두고 두 가지 실행 가능한 솔루션이 있다고 생각합니다.

• 1개의 키워드 + 확장을 위한 접두사 필요
• 두 개의 키워드, 하나는 일반(비확장) 사용을 위한 것이고 다른 하나는 확장 사용을 위한 것이며 이 경우 using 및 extending 를 제안합니다. import 는 괜찮지만 extending 는 두 번째 키워드의 존재 이유를 명확하게 합니다.

두 경우 모두 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, 제 생각에는 "... make 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 의 확장을 허용합니다. 따라서 이 가정을 취하고 문서를 읽으면 이에 대해 두 가지가 잘못되었음을 알 수 있습니다.

1. using module 를 사용하면 module.x 를 확장할 수 있습니다. 따라서 학습자 예측 using module 에는 import module 처럼 작동하는 부작용 이 있습니다. 즉, module.x 확장 가능하게 만듭니다. 그리고 확장 가능하게 만드는 것은 using 가 아니라 import $#$입니다.
2. import 와 달리 using 는 module 뿐만 아니라 그 안에 있는 모든 것을 사용할 수 있게 합니다.

이것이 제가 제 테이블로 표현하려고 한 것입니다. 두 개의 다른 단어가 사용되면(가져오기/사용) 두 가지 다른 작업을 수행해야 하며 이는 명확해야 합니다. using 가 확장을 허용하는 경우가 있고 그렇지 않은 경우에는 예측할 수 없는 동작입니다.

좋은 대안은 @martinholters 가 제안한 대로 가져오기를 완전히 제거하는 것입니다. 특정 일에 무작위로 사용되는 두 단어를 가질 수는 없습니다. import 가 특정 함수를 가져올 때 확장 가능하게 만드는 것을 의미하지만 using module: foo 에서는 이를 허용하지 않는 경우 네임스페이스에 module 만 포함할 때 동일한 동작이 발생해야 합니다.

모듈이 네임스페이스에 있는 경우 지금 바로 전체 이름으로 모든 것을 확장할 수 있다고 해서 이것이 명백하거나 직접적인 의미는 아닙니다.

네임스페이스에 있는 것만으로도 충분하며 using module:x 로 네임스페이스에 포함하거나 네임스페이스에 있는 것만으로는 충분 하지 않은 경우 x 도 확장할 수 있어야 합니다. using 명령을 사용할 때 module.x 를 확장할 수 없습니다.
또는 세 번째 옵션: import 가 없고 항상 전체 이름으로 함수를 확장해야 합니다.

모듈이 네임스페이스에 있는 경우 전체 이름으로 모든 함수를 확장할 수 있다는 것은 절대적으로 분명하지 않습니다.

동의합니다. 그래서 문서를 다시 작성해야 한다고 주장합니다. 그러나 이는 현재 문제와 관련이 있습니다. (1) 현재 API에 대한 문서 개선을 위한 제안과 (2) 두 가지가 다소 관련이 있더라도 개별적으로 유지하는 것이 가장 좋습니다. 곧 (1)에 대한 PR을 할 계획입니다.

@tpapp 본질적으로 말이 되지 않는 것을 문서화할 수 없습니다. 다음 문서 중 어느 것도 올바르지 않습니다.

1. "네임스페이스에 있는 모든 것을 확장할 수 있습니다"( using module:x 는 x 확장을 허용하지 않기 때문에)
2. "네임스페이스에 있는 것만으로는 확장에 충분하지 않습니다. 이것이 using 및 import 라는 별도의 단어가 존재하는 이유입니다."(전체 이름의 경우 실제로 네임스페이스에 있는 것으로 충분하기 때문에 거짓입니다. 충분하다는 것이 내 제안이었습니다)
3. "이름 공간에 있는 모든 것을 전체 이름으로 확장할 수 있습니다."(완전한 사실이 되기 위해 존재를 중지하려면 import module:x 가 필요합니다. - @martinholters 제안)

이들 중 어느 것이든 허용될 것입니다. 그러나 이들 중 어느 것도 실제로 현실이 아닙니다. 현실은 현재 "물건 가져오기"에 사용되는 두 가지 다른 단어가 있지만 실제로는 뚜렷한 사용 사례가 없습니다. for 루프는 부울을 반복할 때 while 루프처럼 작동합니다. 문서가 아무리 많아도 혼란스럽지 않습니다.

본질적으로 의미가 없는 것을 문서화할 수 없습니다.

현재 모듈 API는 잘 정의되어 있으므로 문서화할 수 있습니다.

다음 문서 중 어느 것도 올바르지 않습니다.

내(또는 다른 사람)의 PR과 거기에 있을 실제 텍스트에 대한 의견을 기다릴 만큼 친절하십시오. 가상의 문서를 게시하고 그것이 틀렸다고 주장하는 것은 이 논의에 잡음을 더하는 것입니다.

@tpapp 아마도 내가 말했어야 했는데,

본질적으로 이해되지 않는 혼란스럽지 않은 방식으로 무언가를 문서화할 수 없습니다.

어떤 의미에서 코드는 필요한 모든 문서입니다. 그게 무슨 문제야? 소화하는 데 걸리는 시간입니다. 그리고 나는 현재 그것이 어떻게 작동하는지 설명할 간단한 방법이 없습니다. 왜냐하면 예외로 가득 차 있기 때문입니다. 애초에 있어서는 안되는 예외.

제가 전달하려는 내용이 정말 이해가 안 가시나요?

현재 상황이 불필요하게 복잡하고 문서화가 부적절하다는 데 일반적으로 동의한다고 생각합니다. 그리고 의심할 여지 없이 기계를 단순화하면 문서화가 더 쉬워질 것입니다. 그러나 그러한 단순화는 깨질 것이므로 2.0 이전에는 할 수 없습니다. 그렇다면 그 이전의 문서 개선이 말이 되지 않는다는 것이 당신의 요점입니까? 그럼 저는 동의하지 않습니다. 두 가지 개별 문제가 있습니다. 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는 using 또는 import 중 하나의 단일 키워드로 통합할 수 있으며 한 줄을 잃게 됩니다.

using LinearAlgebra, Random, StaticArrays

브레이킹 체인지를 고려하지 않아도 그만한 가치가 있는지 확신할 수 없습니다.

이것은 원래 디자인이 놓친 깨끗한 솔루션을 제공하는 문제 중 하나가 아닙니다. 절충안이 있습니다. 현재(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 |