Julia: ab 필드 액세스 구문의 오버로딩 허용

mutator / accessor 메서드의 구문 설탕으로 점을 사용하는 기능은 많은 일에 좋을 것입니다. API를 손상시키지 않고 구조 필드를 더 복잡한 추상화로 전환 할 수 있도록이를 제공하는 언어로 항상 감사했습니다.

+1

나는 이것을 구현하는 절대적으로 멋진 방법이 있습니다.

그것에 대해 이야기하고 싶습니까? 나는이 기능을 사용하는 지혜에 점점 더 회의적이지만, Tom Short가 DataFrames에 이것을 갖는 것에 정말로 관심이 있다는 것을 알고 있습니다.

현재 내가 할 수 밖에있어 때문에 이것은 (PyCall를 통해) 파이썬 코드 상당히 좋네요를 호출 할 것 a[:b] 대신 a.b .

@JeffBezanson , 0.3을 위해 이것을 가질 기회가 있습니까? PyCall과 JavaCall (cc @aviks) 모두 언어 간 상호 운용성에 적합합니다.

@JeffBezanson if _not_, 이것이 어떻게 구현되기를 원하는지에 대한 방향을 제시 할 수있는 기회가 있습니까? ( I have an absolutely awesome way to implement this. )

내 경험상 Jeff가 좋아하지 않는 버전을 구현하는 것보다 Jeff가 무언가를 구현하도록하는 더 빠르고 확실한 방법은 없습니다 ;-)

기본 아이디어는

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

필드 당 오버로드 할 수 있습니다. 이를 통해 "실제"필드에 액세스하여 투명하게 작업 할 수 있습니다. 적절한 대체로 getfield(::MyType, ::Symbol) 도 작동합니다.

가장 큰 문제는 모듈이 . 과 관련하여 특별한 동작을한다는 것입니다. 이론적으로 이것은 getfield 의 또 다른 방법 일 뿐이지 만 문제는 기본적으로 전역 변수처럼 동작하기 때문에 모듈 참조 _earlier_를 해결해야한다는 것입니다. . 의 동작에서 이것을 특별한 경우로 유지해야한다고 생각합니다. (# 유형) * (# 필드) 추가 함수 정의를 분석하기 때문에 약간의 컴파일러 효율성 문제가 있습니다. 그러나 그것을 위해 우리는 무슨 일이 일어나는지 볼 것입니다.

@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 오버로드 유형의 다른 내부 코드)입니다 좋은을 . 모든 기호 (dataframes, 아마 사전)에 대한에 있습니다 Core.getfield s로 붐 빕니다.

나는 순수성 측면에 대해 걱정하지 않습니다.
필드 액세스를 전혀 사용해야하는 것은
주어진 유형의 구현. 필드 액세스가 API의 일부인 경우
모든 API와 마찬가지로 문서화해야합니다. 나는 그것이 편리 할 것이라는 데 동의합니다.
core.getfield에 대한 몇 가지 단축키 구문을 작성할 때
구현.

이미 # 4935에서 지적되었지만 여기로 당겨 보겠습니다. 점 오버로딩은 제대로 사용되지 않으면 기존 Julian 다중 디스패치와 약간 겹칠 수 있습니다.

getfield (x :: MyType, :: Field {: size}) = .........
for i = 1 : y.size .....

대신에

size (x :: MyType) = ..........
for i = 1 : size (y) ....

점은 컬렉션 (Dataframes, Dicts, PyObjects)의 항목에 액세스하는 데 유용하지만 필드가 아닌 개체 속성에 액세스하는 방식을 변경할 수 있습니다.

한 가지 고려할 사항은 접근하는 필드에 과부하를 걸 수 있다면 필드에 _setting_ 과부하를 걸 수 있어야한다는 것입니다. 그렇지 않으면 일관성이없고 실망 스러울 것입니다. 그렇게 멀리 가도됩니까?

@nalimilan , getfield 외에 setfield! 가 절대적으로 필요합니다. (유사 setindex! 대 getindex 대한 [] ). 나는 이것이 논쟁의 여지가 없다고 생각합니다.

@stevengj 동의 : DataFrames는 확실히 열에 대해 setfield! 를 구현할 것입니다.

나는 이것을지지한다.

다른 언어 (예 : C # 및 Python)에 대한 경험은 도트 구문이 많은 실용적인 가치를 가지고 있음을 보여줍니다. 특수한 방법을 통해 구현되는 방식은 주로 성능 회귀 문제를 해결합니다.

그러나 메서드의 _inlineability_가이 변경으로 인해 심각하게 영향을받지 않도록하는 것이 중요합니다. 예를 들어 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 아마도 이것에 대해 뭔가 말할 수 있습니까?

필드 액세스는 매우 낮은 수준이므로 성능이 유지되는지 확인하지 않고이 작업을 수행하지 않습니다.

결국 필드를 오버로딩하는 것이 좋은 생각이라고 확신하지 않습니다. 이 제안에는 항상 x.property = value 및 property!(x, value) 두 가지 속성 설정 방법이 있습니다. 필드 오버로딩이 구현되면 저자가 주어진 유형에 대해 어떤 솔루션을 선택했는지 미리 알 수없는 완전한 혼란으로 끝나지 않도록 매우 강력한 스타일 가이드가 필요합니다.

그리고 필드가 공개인지 비공개인지에 대한 질문이 있습니다. 필드 오버로딩을 허용하지 않으면 유형 시스템이 더 명확 해집니다. 필드는 항상 비공개입니다. 메소드는 공개되며 유형은 인터페이스 / 프로토콜 / 특성을 구현한다고 선언 할 수 있습니다. 즉, 주어진 메소드 세트를 제공합니다. 이는 @stevengj 의 https://github.com/JuliaLang/julia/issues/1974#issuecomment -12083268에 위배됩니다. .

필드 오버로딩을 후회할 유일한 장소는 DataFrames . df[:a] 는 df.a 만큼 좋지 않기 때문입니다. 그러나 그것은 그렇게 큰 변화를 필요로하는 것처럼 들리지 않는다. 다른 사용 사례는 PyCall 인 것 같습니다. 이는 필드 오버로딩이 허용되어야 함을 나타낼 수 있지만 매우 구체적인 비 줄리안 사용 사례에만 해당됩니다. 그러나 사람들이 기능을 사용할 수있게되면 오용하는 것을 방지하는 방법은 무엇입니까? 특수 모듈에서 숨기시겠습니까?

@nalimilan , 가능한 한 x.property 구문을 사용하는 것이 선호되어야한다고 말하고 싶습니다. 문제는 사람들이 _ 정말 _이 구문을 좋아한다는 것입니다 – 그것은 매우 즐겁습니다. 이러한 멋진 구문을 사용하고 객체에 대한 내부 액세스에만 사용해야한다고 구체적으로 말하는 것은 완전히 비뚤어진 것처럼 보입니다. "하,이 멋진 구문이 존재합니다. 사용하지 마세요!" API가 추악한 구문을 사용하도록하는 대신 사적인 것에 액세스하는 구문을 덜 편리하고 예쁘게 만드는 것이 훨씬 더 합리적입니다. 아마도 이것은 .. 연산자 인 private _real_ 필드 액세스 연산자에 대한 좋은 사용 사례 일 것입니다.

저는 사실이 변화가 상황을 덜 명확하고 일관성있게 만들 수 있다고 생각합니다. 범위를 고려하세요. 현재 step(r) 대 r.step 스타일의 끔찍한 조합이 있습니다. 특히 제가 FloatRange 도입했기 때문에 이것은 step(r) 를 사용하는 코드 만 정확하기 때문에 위험합니다. 혼합의 이유는 범위의 일부 속성이 저장되고 일부가 계산되기 때문입니다. 그러나 시간이 지남에 따라 변경되어 실제로 범위 유형에 따라 다릅니다. step(r) 자체의 정의를 제외하고 모든 액세스가 step(r) 스타일이면 더 나은 스타일이 될 것입니다. 그러나 그것에 대한 가파른 심리적 장벽이 있습니다. 우리가 r.step 를 기본적으로 r..step 하는 메서드 호출로 만들면 사람들은 자연스럽게하고 싶은 일을 할 수 있습니다.

악마의 옹호자 (나와 함께) 역할을하려면 r.length 또는 length(r) 써야합니까? 제네릭 함수와 메서드 사이의 불일치는 Python을 괴롭히는 문제이며 Ruby는 r.length 스타일에 전적으로 헌신했습니다.

.. +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와 유사한 코드를 작성하기 때문에 아마도 아닐까요?)

이 기능으로 가능합니다. 저를 멈출 수있는 것 중 하나입니다. 나는 그런 oo 스타일 코드에 문제가 없습니다 – 제가 말했듯이 꽤 즐겁고 사람들이 정말 좋아합니다 –하지만 그것은 우리가해야 할 일에 대한 강력한 정책이 _ 정말로 필요하다는 것을 작성하는 방법으로 충분한 선택을 소개합니다. 할 수있는 일에 매우 자유로울 것이기 때문입니다.

줄리아를 배우기 시작했을 때 점없는 구문은 OO 프로그래밍 스타일을 정신적으로 놓아주는 데 많은 도움이되었습니다. 그래서 그 이유만으로 제 제안이 나쁘다고 생각합니다.

또한 간단한 오버로딩 (즉, a.b sans (args...) )의 경우 위의 @nalimilan 의 의견에 동의합니다. 이슈 # 4935에서 합의는 필드가 API의 일부가 아니라 메서드 만 있어야한다는 것입니다. 결과적으로 그 문제는 종결 될 것으로 보입니다. . -overloading 구문을 사용하면 일반 필드가 API의 일부가 아니어야한다는 것을 훨씬 덜 명확하게 할 수 있으며 필드를 API의 일부로 만들 수 있습니다.

하지만 예, . 구문이 편리합니다 ...

어떻습니까 : 단일 . 은 _only_ getfield(x::MyType, ::Field{:name}) = ... 대한 구문 적 설탕이어야하며 필드 액세스는 _only_에서 .. (즉, . 가 지금 무엇인지).

이것은 명확한 구별을 허용합니다.

• . 는 유형 인스턴스의 값과 유사한 것에 액세스하기위한 공용 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) 는 추가 인수가 필요하지 않기 때문입니다.
• . 기본값을 .. . Julia는 상용구 언어로 알려져 있지 않습니다. 그렇게 유지하자

. 기본값을 .. . Julia는 상용구 언어로 알려져 있지 않습니다. 그렇게 유지하자

나는 이것에 동의하는 경향이 있습니다. 심지어 합성 속성을 설정하는 구문은 것 a.property = b 하지 a.property() = b .

물론, 구문으로서 a.property() 가 IMHO가 좋지 않은 이유를 명확히하고 싶었습니다.

또는 더 명확하게 : 점 구문에 대한 중요한 점은 함수를 유형 / 클래스와 연결할 수 있다는 것이 아니라 getter / setter를 좋은 방식으로 작성할 수 있다는 것입니다. 그리고 getter / setter는 데이터 캡슐화에 중요합니다 (인터페이스를 안정적으로 유지하지만 구현을 변경)

이 변경 사항은 API 디자이너의 관점에서 볼 때 훌륭 할 것이지만 미래의 불일치를 제한하기 위해 일종의 스타일 가이드와 함께 제공되어야한다는 데 동의합니다.

이것은 dsl과 같은 Ruby를 가능하게 할 것입니다 ...

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

그러나 광기처럼 자바에 대비하십시오.

object.propert1.property2.property3 ....

몇 가지 생각 :

• 나는 기호를 키로 사용하는 Dicts에 대해 . 구문을 가장 원합니다. d.key 다음 d[:key] 을 사용하는 것이 더 좋습니다. 그러나 결국 그것은 중요하지 않습니다.
• a->property 가 a..property 보다 더 잘 읽는다고 생각합니다. 그러나 다시 그것은 그렇게 큰 문제가 아니며 julia 구문으로 작동하는지 모르겠습니다.

@BobPortmann 동의하지 않습니다. 사전은 컨테이너 객체이고 컨테이너 객체의 API는 obj [index] 또는 obj [key]입니다. 지금은 Julia에 속성이 없기 때문에 컨테이너 API가 오버로드되어 PyCall과 같은 라이브러리 및 OpenCL에서이 기능을 제공합니다. 이 변경은 추가 기능을 제공하기 위해 오버로드되지 않으므로 컨테이너 API의 구별을 강화하는 데 도움이됩니다.

비공개 필드에 a->property 를 사용하면 C 해커가 Julia로부터 멀리 떨어져있는 좋은 방법이 될 것입니다 ;-)

저는 .. 구문을 좋아합니다.

a->property 구문은 이미 사용되었습니다. 이것은 익명 함수입니다. 그러나 a..b 연산자는 잠시 동안 사용되었습니다. 딕셔너리와 비슷하지만 선택 필드가 많은 것을 원하는 경우가 있습니다. getter / setter 구문을 사용하면 dict 인덱싱 구문보다 더 좋을 것입니다.

"a-> property 구문은 이미 사용되었습니다. 이것은 익명의 함수입니다."

예, 물론입니다. -> 주위에 공백이없는 것처럼 보이지 않았습니다.

스타일 가이드 라인으로 property (x)를 읽기 전용 속성에 사용하고 x.property를 읽기 / 쓰기 속성에 사용하도록 권장하는 것은 어떻습니까?

쓰기 가능한 속성의 경우 x.foo = bar가 set_foo! (x, bar)보다 훨씬 좋습니다.

읽기에 foo(x) , 쓰기에 x.foo 을 사용하는 것은 매우 혼란 스럽습니다. 실제로 이것은 속성이 그렇게 매력적으로 만드는 것입니다. 읽기 및 쓰기 액세스에 대해 동일한 구문을 사용합니다. 즉, 얻을 수있는 가장 간단한 구문 (게터 및 세터 용)

스타일과 관련하여이 기능이 구현되면 x.length 및 length(x) 둘 다 갖고 싶은지 또는 이후 양식을 더 이상 사용하지 않고 제거해야하는지 여부에 대한 큰 질문이 있습니다.

제 생각에는 우리는 한 가지 방법 만 가져야하고 앞으로 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) 를 사용하는 것을 제안하지 않았습니다. 내 제안은 _if_ 속성이 읽기와 쓰기가 모두 가능하다면 아마도 x.foo 읽고 쓰기를 _both_하고 싶을 것입니다.

@StefanKarpinski :하지만 length 의 경우가 아닙니다. 크기는 일반적으로 저장되는 것이고 length 는 크기의 제품입니다.

Jeffs는 이러한 변경으로 인해 이러한 기능이 더 이상 일류가 아니라고 지적합니다.

@stevengj :

@tknopp – 길이는 크기에서 파생되지만 크기와 동일하지는 않습니다. 크기를 알고 있다면 길이를 계산할 수 있지만 그 반대는 아닙니다. 물론 이것은 약간 흐릿한 선입니다. 이것이 lufact 허용되는 주된 이유는 우리가 그보다 더 나은 API를 찾지 못했기 때문입니다. 또 다른 접근법은 일반 행렬의 상부 삼각 부분과 하부 삼각 부분을 제공하는 upper 및 lower 일반 함수를 정의하는 것입니다. 그러나이 접근 방식은 예를 들어 QR 분해로 일반화되지 않습니다.

_really_가이 구문을 요구하는 것처럼 보이는 경우는 pycall, factorizations, 그리고 아마도 데이터 프레임 일 수 있습니다.
f(x) 대 x.f 의 무작위 뒤죽박죽으로 끝 날까 걱정됩니다. 시스템을 배우기가 훨씬 더 어려워 질 것입니다.

@StefanKarpinski 목록의 1 번 지점이 유형의 필드가 자동으로 공용 API에 속함을 의미하지 않습니까?

현재 모듈의 공용 API가 무엇인지 알 수 있습니다. 모든 내 보낸 함수와 유형 (필드는 아님). 이 변경 후에는 어떤 필드가 공용 API에 속해야하는지 여부를 알 수 없습니다. 파이썬 에서처럼 개인 필드의 이름을 a._foo 정도로 시작할 수 있지만 그렇게 좋지는 않습니다.

개인적으로 DataFrames 사례는 약간 불필요하다고 생각합니다. 이렇게하면 DataFrames에 기능을 추가 할 것이지만 몇 개의 문자를 저장하는 것보다 일관성 손실이 훨씬 더 문제가됩니다.

나는 또한 DataFrames, PyCall에 의존하는 결정을 내리지 않을 것입니다 (그리고 Gtk도 그것을 원합니다). 필드가 공용 인터페이스의 일부가되어야한다고 생각하거나 ( "멋져 보이기 때문에") 원하지 않기 때문입니다.

... 파이 콜 ...

및 JavaCall

이것의 주요 사용 사례는 비 줄리아 시스템과의 상호 작용 인 것처럼 보이므로 . 오버로드 대신 제안 된 .. 연산자를 사용하는 것은 어떻습니까?

여기서 더 간단한 해결책이 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이 "in"클래스에서 메소드 정의를 수행하도록 허용하는 동시에 사람들이 OO 유형 코드를 갖고 자하는 경우 일반 스타일을 허용하지만 매우 투명하지만 A.b() 는 재 작성일뿐입니다. OO에서 오는 사람들에게는 이것이 매우 자연스러운 일이라고 생각합니다.
또한 getfield 와 함께 A..b 가있는 새로운 getfield A..b 를 사용하여 여기에서 오버로딩을 허용하지만 여기에서 오버로딩하는 것은 강력히 권장하지 않으며 필드 유사 / 속성에만 사용됩니다 (매우 널리 사용되지는 않을 것 같습니다. getfield(A, ::Field{:field}) 오버로드가 약간 무섭기 때문입니다.

@ mauro3 :

@StefanKarpinski 목록의 1 번 지점이 유형의 필드가 자동으로 공용 API에 속함을 의미하지 않습니까?

그것은 필요할 때가 아니라 foo.bar 표기법을 사용해도되는 때의 목록이었습니다. 당신은 비활성화 할 수 있습니다 foo.bar 만 통해 액세스 할 것 "개인"필드에 대한 표기 foo..bar .

@karbarcca : 나는 당신이 여기서 제안하는 것에 대해 명확하지 않습니다.

fwiw, 저는 동의하는 성인용 방식을 사용하고 . 완전히 오버로드 할 수있게 만드는 팬입니다. 나는 이중 점 제안이 덜 혼란 스럽기보다는 더 많은 혼란으로 이어질 것이라고 생각한다.

@ihnorton – a..b 를 필드 액세스를위한 (언 오버로드 가능한) 코어 구문으로 사용하거나 a..b 를 오버로드 할 수있는 구문으로 사용하는 것에 반대합니까?

Julia의 가장 큰 특징 중 하나는 단순성입니다. 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 은 그다지 설득력이 없습니다. 두 캐릭터가 필요하다는 느낌이 아주 ... 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) 하고 작동하도록 할 수 있지만 대부분의 OO 언어와는 혼란스럽게 다른 의미를 갖는 것은 틀림없이 나쁜 일입니다.

물론 그 동전의 다른면은 끔찍한 스타일 조각화이며, a.f 는 a.f() 와 공통점이 없기 때문에 환상이 빠르게 무너집니다.

Julia의 가장 큰 특징 중 하나는 단순성입니다. x.y 오버로딩

여기도 같은 느낌. 이것이 실제로 필요한 것이 제한된 수의 interop 유형에 대한 것이라면 유형 선언에서 명시 적으로 요청한 경우에만 유효하게 만드는 것은 어떨까요? 예를 들면 외에 추가 키워드 type 및 immutable 될 수 ootype 또는 뭔가.

그리고 af가 af ()와 공통점이 없다는 사실은 환상을 빠르게 무너 뜨립니다.

이것이 @JeffBezanson의 의미를 명확히 할 수 있습니까?

a.f() 작동한다면 a.f 는 일종의 메서드 객체라고 생각합니다.

아, 알았어. 예, 분명히 map(t.method,collection) 같은 것을 할 수 없습니다.

obj.method(...) 를 허용하면 새로운 사용자가 줄리아를 파이썬, 루비 등과 경쟁하려는 또 다른 객체 지향 언어로 간주하고 완전히 감사하지 않을 위험이 있다는 @ mauro3 에 동의합니다 다중 디스패치 인 굉장함. 다른 위험은 표준 oo 스타일이 지금까지 개발 된 더 많은 줄리안 스타일과는 반대로 사용자가 더 익숙한 방식으로 우세하게된다는 것입니다.

DataFrames 이외의 사용 사례는 oo 언어와의 상호 운용으로 제한되어 있기 때문에이 모든 것이 매크로로 처리 될 수 있습니까? 즉, <strong i="8">@oo</strong> obj.method(a) 가 method(obj,a) 됩니까?

@karbarcca 이것은 자동으로 모든 것이 두 가지 방법으로 작성 될 수 있음을 의미합니다.

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

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

t.method (args ...)
#은 단지 재 작성일뿐입니다.
메소드 (t, args ...)

오버로드 가능한 점은 pyobj.func pyobj[:func] 를 호출하는 데 사용될 수 있으므로 PyCall에는 필요하지 않습니다. 그러면 pyobj.func() 는 실제로 (pyobj.func)() 입니다.

a.foo(x) 를 foo(a, x) a.foo(x) 로 다시 작성하면 PyCall의 문제가 해결되지 않습니다. foo 는 Julia 메서드가 아니고 Julia 메서드가 될 수 없기 때문에 런타임에 동적으로 조회해야합니다. . a.foo(x) 를 getfield(a, Field{:foo})(x) 또는 이와 유사한 [또는 getfield(a, Field{:foo}, x) ]로 다시 작성하여 getfield{S}(::PyObject, ::Type{Field{S}}) 가 올바른 일을 할 수 있도록해야합니다.

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

여기서 다른 운영자가 필요하다는 것을 알기 시작했지만 a..b는 그다지 설득력이 없습니다. 두 캐릭터가 필요하다는 느낌이 아주 ... 2 등석

반면에 .. 는 $ , @ 또는 | 보다 훨씬 빠르게 입력됩니다. Shift 키를 누를 필요가 없기 때문입니다. , 두 문자 인 동안 손가락은 동일한 키에 유지됩니다.

@stevengj 아,

JavaCall의 경우 실제로 본질적으로 unknownProperty 핸들러 만 필요합니다. 실제로 기존 속성 읽기 또는 쓰기를 다시 쓰거나 가로 챌 필요가 없습니다. 그렇다면 "x가 기존 속성이 아닌 경우에만 ax가 getfield (a, : x)에 다시 쓰여진다"라는 규칙이 문제를 정상화하는 데 도움이 될까요?

@simonbyrne , 매크로를 요구하면 깨끗하고 투명한 언어 간 호출에 대한 욕구가 type Foo; p::PyObject; end , 그리고 개체에 대한 f::Foo 당신이 원하는 foo.p.bar 경우 bar 파이썬 속성을 조회합니다. foo.p.bar 에서 두 점의 의미를 확실하게 구분할 수있는 매크로를 상상하기는 어렵습니다.

솔직히, 스타일에 대한 큰 문제는 보이지 않습니다. 고품질 패키지는 가능한 경우 Base 및 기타 패키지의 스타일을 모방하고 어떤 사람들은 우리가 무엇을하든 이상한 코드를 작성합니다. 매뉴얼의 뒷부분에 도트 오버로딩을 추가하고 신중하게 선택한 몇 가지 경우에만 사용하도록 권장하는 경우 (예 : 언어 간 상호 운용성, 읽기 / 쓰기 속성, 아마도 factor.U 같은 항목에 대한 네임 스페이스 오염을 방지하기 위해) , 그리고 일반적으로 foo[:bar] )에 대한 더 깨끗한 대안으로서, 나는 우리가 모든 것에 점을 사용하는 패키지로 넘치지 않을 것이라고 생각합니다. 가장 중요한 것은 _we_가 이것을 무엇에 사용하고 권장할지 결정하는 것입니다. 그리고 아마도 우리는 권장 사용 목록을 매우 짧게 유지하고 실제 요구가 발생할 때만 확장해야합니다.

type Foo; bar(...) = ....; end 에 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> 에는 "개인 필드"가 나열됩니다. 모듈의 경우 Mod.foo 의 기본 구현을 Mod..foo 하고 사람들에게 Module 에 getfield 메서드를 추가하지 말라고 알려주는 것이 괜찮습니까? 내 말은, 당신은 이미 정수 덧셈을 언어에서 재정의 할 수 있습니다 – 모든 지옥이 풀리고 당신은 segfault를 얻지 만 우리는 그것을 막으려 고하지 않습니다. 이보다 더 나쁠 수는 없죠?

프로그래밍 언어는 실제로 이름 지정에만 관심이 있기 때문에 사실 그보다 약간 더 나쁩니다. 이름을 확인하는 것이 정수를 추가하는 것보다 훨씬 더 중요합니다.

선택의 여지가 많지 않지만 Mod.foo 기본값을 Mod..foo 로 설정하지만 일부 위치에서는 부트 스트랩에 Mod..foo 를 사용해야 할 것입니다. .. 연산자가 없으면 대체를 정의하기 위해 Core.getfield 를 호출 할 수도 없기 때문에 여기서 매우 유용합니다. 그것으로, 우리는 아마 제거 할 것 Core.getfield 만이 .. .

그것은 공정한 요점입니다 – 명명은 프로그래밍에서 일종의 큰 문제입니다 :-). 좋은 방법 인 것 같습니다. .. 있고 Core.getfield .

이 두 가지 아이디어,

[...] 매뉴얼의 뒷부분에 도트 오버로딩을 넣고 신중하게 선택한 몇 가지 경우에만 사용하도록 권장합니다 @stevengj https://github.com/JuliaLang/julia/issues/1974#issuecomment -38847340

과

[...] 기본 설정은 가능한 한 많이 x.property 구문을 사용하는 것이 어야 합니다. https://github.com/JuliaLang/julia/issues/1974#issuecomment -38694885

분명히 반대합니다.

첫 번째 아이디어를 선택하려면 "신중하게 선택한 사례"에 대해 새 .. 연산자를 만드는 것이 더 합리적이라고 생각합니다.
장점 사용으로 ..name 현재 경우에 [:name] 사용 (DataFrames는, DICT는 {기호, ...}) 것보다 입력 / 구문 명확 필드 액세스에서 해당 뭔가 다른 진술 친화적 동안 일어나고 있었다. 또한 ..name 의 이중 점은 회전 된 콜론, :name 기호 구문에 대한 힌트로 볼 수 있으며 탭 완성에도 문제가 없습니다.
단점으로 PyCall et al. 원래 구문에 너무 가깝지 않을 것입니다 (그리고 . 실제로 사용해야하는 경우에는 혼동 될 수도 있습니다). 하지만 솔직히 말해서 Julia는 Python 구문과 완전히 호환되지 않으며 Python에서 간단한 명령을 수행하기 위해 PyCall을 사용하여 Julia에 많이 입력해야하는 경우가 항상있을 것입니다. .. 를 에뮬레이트하는 . 는 여기에서 좋은 균형을 제공 할 수 있습니다. (오해하지 마세요. 저는 PyCall을 정말 좋아하고 특별한주의가 필요한 중요한 기능이라고 생각합니다)

내가 현재 선호하는 두 번째 아이디어는 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.

이 흥미로운 글을 읽는 동안 머릿속에 떠오른 생각이 하나뿐입니다. 내보내기는 공용 필드를 선언하는 데 사용할 수 있으며 모든 필드는 정의 모듈 내에서 볼 수 있습니다. 예 :

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는 하나를 추가하는 함수를 통해 읽기 전용입니다. 모든 Person 내보내기는 export Person. * 또는 이와 유사한 것으로 수행 될 수 있습니다.

[pao : 인용구]

@emeseles 줄리아 코드와 같은 것을 인용 할 때 백틱을 사용하도록주의하십시오. 이렇게하면 서식이 유지되고 Julia의 매크로가 비슷한 이름의 사용자에 대한 GitHub 알림을 생성하지 못합니다.

. 및 .. 은 (는) 혼란 스럽습니다. 명확하고 기억하기 쉬운 신택스는 좋은 것입니다.

나는 이것을 할 수 있기를 정말로 고대하고있다. 이것은 0.4 프로젝트로 플래그를 지정하기 위해 (또는 # 5848의 WIP) 충분히 큰 변경입니까?

네, 확실히 프로젝트입니다.

나는 우리 대부분이 적어도 처음부터 권장되는 사용을 제한해야한다는 데 동의한다고 생각합니다. 내 느낌은 처음에는 상호 운용성 (PyCall에서와 같이 다른 언어와의 사용, 점 표기법이 자연스러운 외부 라이브러리)과 아마도 변경 가능한 상태 ( get_foo(x) 이후)의 두 가지 용도로만 권장되어야한다는 것입니다. set_foo!(x, val) 은 추합니다).

외화 상호 운용성을 위해서만 권장하더라도 그 목적만으로도이 기능을 정당화하기에 충분합니다. Julia와 같은 새로운 언어의 경우 나머지 소프트웨어 세계와 원활하게 대화하는 것이 매우 중요합니다.

Steven, 저는 getter / setter에 대해 100 % 확신하지 못합니다. 곧 불일치로 이어질 까봐 두렵지 만 다른 사용 사례에는 동의합니다. 그 위에 Gtk.jl 동적 속성에는 구문의 이점도 있습니다. 개인적으로 가장 좋아하는 것은 Stefan이 # 5842에서 설명한 열거 형 구현입니다.

충돌. 이 문제의 진행을 방해하는 것은 무엇입니까? 결정이 필요합니까, 아니면이 문제가 아직 완료되지 않은 다른 내부 변경에 의존합니까, 아니면 단지 코딩입니까?

이 문제의 진행을 방해하는 것은 무엇입니까?

일을하는 사람과 그것이 옳은 일인지에 대한 약간의 망설임.

@ihnorton은 이미 # 5848에서 초기 초안 구현을 수행했습니다. 나는 이것이 원하는 기능인지 여부에 대한 Julia 핵심 팀의 명확한 진술이 필요하기 때문에 주로 작업이 중단되었다고 생각합니다.

나는 이것으로 승선하고있다. @JeffBezanson 이 울타리에있는 것 같습니다.

저에게는이 기능이 있으면 대규모 Python 코드베이스에서 Julia로 쉽게 전환 할 수 있습니다. 학생들을 설명하기 위해 파이썬 코드를 사용한다면 익숙한 것과는 다른 구문이 필요합니다.

우리는이 스레드에서 위의 논의를했지만 여전히 완전한 합의를 볼 수 없습니다. 현재 몇몇 사람들은 공용 API가 함수 / 메소드로 구성되고 개인 API는 복합 유형의 필드라고 생각합니다. 이 계획에서 매우 드문 예외를 볼 수 있습니다. (LU 분해에서 .U ?)

파이썬 액세스와 열거 형이 유용한 경우이기 때문에 이것이 내가 반대한다는 의미는 아닙니다. 여전히 여기가 얼마나 긴급한지, 그리고 개발주기가 끝날 때 이것을 밀어 붙이는 것이 현명한 지 의문을 가질 수 있습니다.

@ ufechner7 , 주요 동기가 언어 간 상호 @tknopp , 우리는 이와 같은 것에 대해 만장일치로 합의하지 않을 것입니다. 궁극적으로 @JeffBezanson 과 @StefanKarpinski가 결정하는

많은 망설임이 Jeff의 최악의 악몽이라고 생각하는 것에서 비롯된 것 같습니다.

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

저도 이것을 매우 싫어할 것입니다. 이렇게 오용하기로 결정한 패키지는 저를 포함하여 시스템의 _all_ 유형에 오용을 가할 것입니다. 이 기능은 매우 강력하며 Julia가 작성되는 방식을 바꿀 것입니다. 더 좋게, (아마도 좋지만) 나쁘게.

예, 스티븐, 제 말이 적절하지 않을 수도 있습니다. 제가 말하고 싶었던 요점은이 변화가 언어가 어떻게 발전 할 것인지에 큰 영향을 미칠 수 있다는 것입니다. 그리고 우리가 다른 이슈에서 가지고있는 "공식적인 인터페이스"아이디어는 . 오버로드 가능하게 만드는 영향도받습니다. 예, @JeffBezanson 과 @StefanKarpinski가 결정할 수 있습니다. 여전히 문제는 결정이 지금 시행되어야하는지 여부입니다 ...

그만한 가치가 있기 때문에 나는 거의 모든 구문을 오버로드 가능하게 만들고 문화에 의존하여 너무 야생에 빠지지 않도록하는 것을 선호했습니다.

+1 . 여기에 call 오버로딩에 대한 강력한 철학적 (그리고 아마도 실용적인 ...) 아날로그가 있다고 생각합니다. 설명서에는 Don't do stupid stuff: we won't optimize that 섹션이 필요합니다. (물론, call 오버로딩은 성능상의 이유로 부분적으로 _for_했지만 남용의 가능성이 만연합니다.)

• : 100 : 그것에. 저는 문화가 이것을 남용하지 않도록 충분한 동기가되어야한다고 생각합니다

전반적으로 나는 찬성합니다. 학대 가능성이 가장 큰 걱정은 아닙니다. 나에게 큰 문제는

• "실제"필드 액세스에 허용되는 구문입니다. 나는 a..b 그다지 좋아하지 않습니다.
• 모듈. 정규화 된 이름은 매우 중요합니다. 메소드 디스패치로 표현하는 것은 가능하지만 실질적인 어려움이 있습니다. 즉, 정규화 된 이름이 있다는 것을 알기 위해 많은 컴파일러 단계 (아마도 인라인을 통해)를 거쳐야합니다. 이것은 AST를 사용하는 도구를 작성하는 모든 사람의 삶을 더 어렵게 만듭니다. 또한 이러한 도구에서이 경우를 잘못 처리하기가 매우 쉽습니다.

이러한 문제는 두 가지 모두에 대해 동일한 구문을 사용하여 한 번에 해결할 수 있지만이 시점에서 모듈에 대해 . 이외의 다른 것을 사용하는 것을 상상하는 것은 거의 불가능합니다. _ 내부적으로 _ 모듈 참조를위한 추상 구문이있을 것입니다. 그것을 드러 낼 좋은 방법이 없다면 그것은 실망 스러울 것입니다.

이 질문에 대한 나의 두 센트 : 왜 자격있는 이름에 : 를 사용하지 않습니까? 이미 비슷한 용도로 사용 중입니다.

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 가 모듈이면 먼저 모듈 조회를 수행"을 의미하도록 만들 가능성을 언급하려고했습니다. 도움이 될 수 있으며 모듈 조회의 의미를 재정의하고 싶지는 않습니다. 그러나 getfield(a,:b) 호출로 a.b 를 나타낼 수 없기 때문에 약간의 복잡성 비용이 발생합니다. 암시 적 분기가있는 특수 AST 노드 여야합니다. 물론 우리는 _explicit_ 브랜치를 사용할 수 있지만, 나는 그것으로부터 AST 팽창에 대해 걱정할 것입니다.

프런트 엔드와 백 엔드의 요구 사항 사이에 이러한 큰 갈등을 쉽게 해결할 수있는 방법은없는 것 같습니다.

다른 사람들이 a..b 좋아한다면 그것으로 사는 법을 배울 수있을 것 같아요. 그것은 완전히 다른 것을 의미하는 것처럼 보입니다. 아마도 간격.

나는 a..b 도 싫어하지만 왜 그것이 필요한지 궁금합니다. 이 스레드를 읽을 때 오버로딩은 실제 필드 액세스가 필요하지 않은 언어 래퍼 및 동적 사용 사례에서만 사용된다는 인상을받습니다.

어떤 시점에서 객체를 사용하려면 객체의 표현에 액세스해야하기 때문입니다. 이것은 상대적으로 드물고 get_actual_field(a,:x) 처럼 추악 할 수 있다고 주장 할 수 있지만 이것은 구문을 갖지 않기에는 너무 중요한 연산처럼 보입니다.

나는 알지만 이것은 우리가 아무도 사용하지 않기를 바라는 구문을 찾는 것처럼 들리나요?

.. 제공하지 않는 것은 동적 사용 사례에 대해 예라고 말하는 방법이지만 점 지향 프로그래밍에서는 아니오라고 말할 수 있습니다.

나는 그것이 어떻게 도트 지향 프로그래밍을 막을 수 있을지 모르겠다. 위의 @mbauman 예제를 계속 수행 할 수 있습니다.

a..b 구문은 일종의 간격처럼 보이지만 (이렇게 사용했습니다) 간격 산술에는 자체 입력 구문이 필요하다고 생각하지 않습니다. Interval(a,b) 것은 괜찮아요. 지금까지 줄리아에서 연산자로 사용되어 왔고 누구도 그 구문을 사용하고 싶어하는 사람이 많지 않습니다. 또한 필드 액세스처럼 보입니다.

이것에 대한 한 가지 은색 안감은 우리가 끔찍한 module_name 을 m..name 대체 할 수 있다는 것입니다. Module 객체의 필드에 액세스 할 수 없다는 것은 사마귀였습니다.

예, 저는 a.b 가 " a 가 모듈이면 먼저 모듈 조회를 수행"을 의미하도록 만들 가능성을 언급하려고했습니다. 도움이 될 수 있으며 모듈 조회의 의미를 재정의하고 싶지는 않습니다. 그러나 getfield(a,:b) 호출로 a.b 를 나타낼 수 없기 때문에 약간의 복잡성 비용이 발생합니다. 암시 적 분기가있는 특수 AST 노드 여야합니다. 물론 우리는 _explicit_ 브랜치를 사용할 수 있지만, 나는 그것으로부터 AST 팽창에 대해 걱정할 것입니다.

우리가함으로써이 문제를 해결할 수 a.b 무조건 평균 getfield(a,:b) 그것은 오류가에 방법을 추가하고 다음과 getfield 그 교차 getfield(::Module, ::Field) 방법은? 그 행동을 강요하는 일종의 이상한 방법이지만 궁극적으로 동일한 효과를 가질 것입니다. 그렇다면 낮추는 것은 당신이 속임수를 쓰거나 자격을 갖춘 이름 조회로 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 필드에 액세스하려면 별도의 메커니즘이 필요합니다.

Ahhh, 그래서 전부 아니면 아무것도? 어떻게 든 가질 수있는 인상을 받았습니다

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! 재정의를 허용 할 것입니다. 행이 유형이되는 데이터베이스에 가변 뷰를 노출하는 것이 정말 마음에 듭니다.

네, 제 인상이었습니다.

좋아, IMHO는 실제 필드 액세스에 .. 를 사용할지 아니면 Core.getfield 를 사용할지 그다지 큰 문제가 아닙니다. 일반 기능을 실험적으로 도입하여 변경 될 수 있습니다.

문제는 이것이 0.4의 시간 프레임에 맞는지 여부입니다. 그렇다면 최종 구현과 모듈 문제를 해결할 수있는 # 5848?

@johnmyleswhite : 나는 또한 이것을 대칭으로 만들고 setfield! 허용하도록 투표 할 것입니다. Gtk.jl에서는 둘 다 사용합니다.

이 기능을 사용할 때와 사용하지 않을 때 규칙이 무엇인지 명확하지 않은 것 같습니다. 메서드 / 필드를 동적으로 조회해야하므로 Julia 메서드 / 복합 유형이 될 수없는 PyCall의 요점을 확인했습니다 (결과 구문은 Python에 더 가깝습니다). 그런데 왜 Gtk.jl에 사용합니까? 이 일을 시작하면 foo.bar = x 대신 setbar!(foo, x) , 다음 표준 줄리아 코드가 invitably도이 패턴을 사용하여 시작됩니다 : 이것은 우리가 원하는 무엇인가? 아마도 그럴 수도 있지만 그것에 대해 분명히합시다.

이 기능을 사용하여 추상 (그리고 구체적도) 유형에 대해 정의 된 속성 getter 및 setter를 구현하는 것이 허용 / 권장됩니까?
다른 유형의 다른 모듈에서 속성을 가져 오는 데 사용되는 메서드의 이름 충돌을 피할 수 있다고 생각합니다.

참고 : https://github.com/JuliaLang/julia/issues/4345 , https://groups.google.com/forum/#!msg/julia -users / p5-lVNlDC8U / 6PYcvvsg29UJ

@nalimilan : Gtk는 getter / setter가 아닌 동적 속성 시스템을 가지고 있습니다.

@tknopp 아,

이 시점에서 (그리고 올바른 규칙을 파악하기 위해 약간의 실험이 필요하다고 생각합니다) f 가 "와 같은 일반적인 독립 실행 형 개념으로 이해 될 때 f(x) 가 더 좋습니다. f 가 x 와 실제로 독립적이지 않은 경우 x.f 사용해야합니다. 내 이전 예제를 여기에 맞추기 위해, 대부분의 벡터와 컬렉션에는 단계 개념이 없기 때문에 일반적인 step 함수를 사용하는 것은 실제로 유용하지 않습니다. 범위가있을 때 _only_ 의미가 있습니다. 어떤 종류의. 따라서 x.step 범위를 x 범위의 단계로 가져 오는 방법이되는 것은 괜찮습니다. 그것은 약간의 판단 호출이지만 인생은 그것들로 가득 차 있다고 생각합니다.

.. 은 나에게 직접 접근 할 수 없기 때문에 마음에 들지 않습니다. foo.bar. 는 어떻습니까? 끝에있는 추가 점은 직접 액세스 할 수 있도록 고정합니다.

유니 코드 기호를 선택할 수도 있습니다. 여전히 많은 기호가 남아 있습니다.

@GlenHertz , 필드 액세스를 연결해야하는 경우 실제로 작동하지 않습니다.

@simonbyrne , 저는 일반적으로 유니 코드 사용을 필요로하는 핵심 언어 또는 표준 라이브러리에있는 것을 반대합니다. 그것을 허용하는 것과 사람들이 그것을 사용하도록 강요하는 것은 완전히 다른 것입니다.

이 시점에서 제 생각에 (그리고 올바른 규칙을 알아 내기 위해 약간의 실험이 필요하다고 생각합니다) f (x)는 f가 "길이"와 같은 일반적인 독립형 개념으로 합리적 일 때 더 낫지 만 xf를 사용해야합니다. f가 x와 실제로 독립적이지 않을 때.

이 기능을 사용하는 제 개인적인 규칙은 다음과 같습니다. 언어 상호 운용성 또는 "거의 필드"또는 "증강 필드"인 항목에만 이것을 사용하십시오. 예를 들어, 유형의 모든 필드 값에 의존하는 캐시를 업데이트하기 위해 이것을 사용할 수 있습니다.

이 기능에 대한 한 가지 큰 질문은 유형 추론과 어떻게 상호 작용합니까? 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 : 예, 오버로드 된 필드는 동적 속성에만 사용됩니다. 이것이 제임슨이이 문제를 해결하고자하는 방식이고 저는 이것이 좋다고 생각합니다. 모든 실제 getter 및 setter는 자동 생성되지만 모든 get / set 이름 지정 없이도 여전히 작동합니다. GAccessor 모듈의 라이브 (짧은 G_ )

구문에서 실제 필드 액세스에 <- 를 사용하지 않는 이유는 무엇입니까?
람다에 사용되는 C ++의 -> 와 유사하지만 <- 는 현재 사용되지 않습니다.
유형에서 읽을 수 있으며 값을 직접 가져올 수 있습니다.

.. 인터벌에서 사용하고 싶은 사람들에게는 미사용 상태로 남겨두고 지금까지 생각할 수있는 다른 용도가없는 미사용 페어를 사용하게 될 것입니다.

필드 액세스에 R의 할당 표기법을 사용하지 마십시오.

->를 사용하여 C / C ++를 직접 미러링하고 새로운 구문을 얻을 수 있습니다.
익명 기능. 나는 익명의 기능을별로 신경을 쓰지 않았습니다.
구문이 약간 간결하거나 읽을 수 없기 때문입니다. 대신 할 수 있을지도 몰라
뭔가

func (x) x ^ 2 끝

또는 더 길고 일관된

함수 (x) x ^ 2 끝

아마도 필요하지 않은 좋은 구문을 생각 해낼 수있는 방법이있을 것입니다.
끝을 사용하여.

토론을 너무 많이 변경하지는 않지만 확실히 이해가 될 것입니다.
실제 필드 액세스를 위해->를 사용합니다.

2015 년 1 월 28 일 수요일 오전 8:49, John Myles White [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이 제안한 유니 코드 문자는 옵션으로 괜찮습니다). 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)) 

저는 Julia를 처음 접했지만 다중 파견 접근 방식에 대해 빠르게 감사를 받았습니다. 특히 과학적 프로그래밍을위한 객체 지향 프로그래밍은 많은 작업을 더 복잡하게 만듭니다. OO 패러다임 / 구문이 Julia의 스타일 개발에 부정적인 영향을 미칠까 걱정됩니다.

또는 문자열 인턴 및 / 또는 인용에 대해 잊어 버렸기 때문에 :

someobj <: field_name |> length

@elcritch , <: 는 현재 Julia의 "is subtype of"연산자로 사용되고 있으며, :> 가 도입되면 유형 관련 항목에 사용하고 싶을 것입니다. 세습 재산.

instance..member 이 문제인 경우 몇 가지 가능성이 있습니다. 눈을 가리세요! 이들 모두가 더 나쁠 가능성이 있습니다.

• instance^.member (당근 도트)
• instance~.member (물결표)
• instance:.member (콜론 점)
• instance*.member (별표)
• instance-.member (대시 점)
• [email protected] (at-sign 점)
• instance&.member (앰퍼 도트)
• instance$.member (달러 도트)
• instance<.>member (우주선 점)

나는 솔직히 (a) .. 충분히 좋아 보인다고 생각하고 (b) 이것이 언어의 모호한 구석이 될 것이기 때문에 그것이 멋져 보이는지 여부는 실제로 중요하지 않다고 생각합니다. 대부분의 사람들은 instance.member 사용합니다. 필드 또는 getfield 메서드 만 있고 둘 다 가질 수는 없기 때문입니다.

(이 문제에 대해 멤버와 메서드를 모두 사용하려는 대부분의 사람들은 .. 에 대해 배우는 데 신경 쓰지 않을 것입니다. foo.member 대한 메서드를 정의하고 "real "field foo._member . 어쨌든 이것은 더 나은 스타일입니다. 즉, type 정의를 읽을 때 _member 가 무언가가 아니어야한다는 것이 즉시 분명해집니다. 직접 액세스 할 수 있거나 액세스해야합니다. 이는 귀중한 구두점 부동산을 차지하지 않고 :. 와 같이보기 흉하고 모호한 것으로 .. 를) 만들어야한다고 주장합니다.)

.. 를 중위 간격 연산자로 사용하는 기능을 놓칠 수 있지만 오버로드 가능한 필드 액세스는 가치있는 절충안입니다. 콜론에 더 이상 의미를 추가 하는 것을 약간 두려워 :. 은 그렇게 나쁘지 않은 것 같습니다.

:. 는 현재 symbol(".") 대해 실제로 유효한 구문이므로 사용하는 것이 좋지 않을 수 있습니다. .. 가 잠재적으로 유용하다는 점은 잘 받아 들여졌습니다. 우리는 아무도 거의 사용하지 않을 구문에 낭비해서는 안됩니다. @. 와 같은 더 추악한 것을 사용하는 것이 완벽하게 기쁩니다 ( . 는 유효한 매크로 이름이 아니고 식별자를 시작할 수 없기 때문에 어떤 것과도 충돌하지 않는 것 같습니다 ). 다시 말하지만, 이것은 Julia의 모호한 코너가 될 것이므로 그것을 예쁘게 만들 가치가 없습니다.

.. 사용하여이 작업을 수행하고 잠재적 추악함을 무시하는 데 +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 의 제안과는 달리 "실제"필드 액세스를 오버로드 가능하게 만들기 만 제안했습니다. 개인적으로 저는 실제 필드를 오버로드하는 것을 불가능하게 만드는 것에 만족할 것입니다. 단, 언어의 동적 특성으로 인해 구현이 훨씬 더 복잡해질 것입니다. 당신이있는 경우 "모든-overloadable"접근 방식 예를 들어, x::Vector{Any} , 다음 일을 x[i].y 해석 될 수 getfield(x[i], Field{:y}) 및 파견 시스템에 관계없이 여부의 옳은 일을 할 것입니다 y 은 실제 필드이지만 "가상"필드에 대해 getfield 만 호출하려는 경우 코드 생성기는 x[i] 의 런타임 검사를 위해 디스패치 시스템의 미니어처 하위 집합을 구현해야합니다.

또 다른 질문은 Module.foo 이 오버로드 가능해야하는지 여부 getfield 를 사용하는 것은 일정한 일관성이 있으며, 위에서 언급 한 Vector{Any} 예제에는 Module 배열 멤버가있을 수 있으므로이 경우를 처리해야합니다. 어쨌든. 반면에 @JeffBezanson 은 이것이 컴파일을 더 어렵게 만들고 function Base.sum(...) 와 같은 선언의 동작을 그루 킹 하기 어렵게 만들 수 있다고 지적했습니다. 내가 선호하는 것은 적어도 지금은 컴파일러가 Module (즉, Vector{Any} 아님)과 함께 작동한다는 것을 알고있는 경우에 Module.foo 오버로드를 방지하는 것입니다. ; 변경되는 사항에 대해 보수적이기 위해서는 약간의 불일치가 그만한 가치가있는 것 같습니다.

Module.foo 오버로드를 허용하지 않으려면 +1합니다.

여기에서 OO 프로그래밍과 구문이 실제로 FP보다 우수한 과학 컴퓨팅 영역 중 하나는 에이전트 기반 모델링입니다. 에이전트 계층 구조를 설정하기위한 구체적이고 다중 상속이 그리워졌지만 Julia의 가볍고 빠른 추상화와 빠른 프로토 타이핑은 놀랍습니다. 이미 몇 개의 ABM 프레임 워크가 나타났습니다.

ABM에서는 에이전트 상호 작용을 표현하는 데 점 표기법이 선호됩니다 : Agent1.dosomething (Agent2) 대 dosomething (Agent1, Agent2).

이 명백한 것이 가장 큰 사용 사례는 아니지만 ABM에 대해 생각하고 코딩 할 때이 구문 설탕을 유지하는 것이 좋습니다.

또한 Julia에서이 구문을 사용하고 싶습니다. 같이
디자인에서 기능 지향적 접근 방식에 감사하는만큼
관점, 메서드 호출 구문은 매우 유용하고 여러
도메인. Ab (C)가 b (A, C)와 같으면 좋을 것입니다.
2015 년 4 월 22 일 오전 8시 50 분에 "datnamer" [email protected]이 작성했습니다.

여기에 OO 프로그래밍이있는 과학 컴퓨팅의 한 영역은
구문은 실제로 FP보다 우수합니다. 에이전트 기반 모델링입니다. 비록 내가
에이전트 계층을 설정하기 위해 구체적이고 다중 상속을 놓치면
Julia의 가볍고 빠른 추상화와 빠른 프로토 타이핑은
놀라운-이미 두 개의 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) 이 b(a,c) 와 동등하다고 제안하지 않습니다. 그것은 일어나지 않을 것입니다.

오버로드 가능한 점은 다른 언어와의 자연스러운 상호 운용을 위해 중요합니다. 그게 충분한 이유입니다.

Subject.Verb (DirectObject)

여러 상황에서 상당히 자연 스럽습니다. 많은 OO 프로그래머가
함수 (A, B)의 단순한 재정렬이지만, 그 재정렬은
가독성을 위해 많은 일을합니다, IMO.
2015 년 4 월 22 일 오전 10:32에 "Andy Hayden" [email protected]이 작성했습니다.

ABM에서는 에이전트 상호 작용을 표현하는 데 점 표기법이 선호됩니다.
Agent1.dosomething (Agent2) 대 dosomething (Agent1, Agent2).

그게 더 나은 이유는 무엇입니까?

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

나는 그것을 제안했다. (죄송합니다. 전쟁을 시작할 생각도 없었습니다.
그 제안은 인기가 없을 것입니다.) 나는 이것이 전에 나온 것을 본 적이 있다고 생각했습니다.
포럼에서 이미 해고되었다는 사실을 깨닫지 못했습니다.
나쁜 생각. 이유를 물어봐도 될까요? (스레드를 가리킬 수 있습니까?)

감사.
2015 년 4 월 22 일 오전 11:09, "Steven G. Johnson" [email protected]
썼다 :

철자법에 대한 종교적 전쟁에 빠져들지 말아주세요. 뿡뿡
https://github.com/dbeach24 , 아무도 ab (c)가
줄리아에서 b (a, c)와 동등 함; 그것은 일어나지 않을 것입니다.

오버로드 가능한 도트는 다른 언어와의 원활한 상호 운용을 위해 중요합니다.
그게 충분한 이유입니다.

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

이렇게하지 않는 한 가지 이유는 a.b 은 b 의 범위에서 a 찾는 반면 b 는 b 에서 검색하기 때문입니다. 둘러싸는 범위. 점선 액세스가 때때로 왼쪽 개체에서 조회되지 않으면 매우 혼란 스러울 것입니다.

Btw, Julia의 기능이 객체 내부가 아니라 현재 범위에서 조회되는 기능으로 간주됩니다. 사람들이 사물 내부를 조회하는 기능을 사용하기 시작할 것이라는 두려움이 점 과부하를 막아 온 이유 중 하나라고 생각합니다.

@toivoh , 도트 오버로딩의 모든 구현은 기존 메서드 디스패치를 ​​사용하므로 범위 지정 동작을 변경하지 않습니다. @ dbeach24 , a.b(c) 무차별 사용을 권장하지 않는 기본 이유는 동일한 작업을 수행하기위한 구문이 너무 많으면 언어와 라이브러리가 엉망이되기 때문입니다. 하나의 철자를 고르는 것이 더 낫습니다. Julia의 여러 디스패치는 b(a,c) 선호합니다. b 가 a "소유"되어 있지 않다는 것이 더 분명하기 때문입니다 — 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)처럼 취급하십시오.
나는 _might_하지만 익명 함수를 저장하는 멤버가있는 구조체 (유형)를 사용하는 데 사용할 수 있습니다. 여기서 Julia로 작성된 함수를 데이터베이스에서로드 한 다음 구문 분석을 수행하고 함수를 객체에 저장합니다.
그런 일을하기에 더 나은“줄리안”스타일은 무엇일까요?

감사!

@ScottPJones 나는 이것들이 동등하지 않아야한다는 합의가 있다고 생각합니다 *.

"스타일"규칙에는 예외가있을 수 있지만, 점 오버로딩과 마찬가지로 필드에 함수를 넣으려면 강력한 사례가 있어야합니다. 나는 사람들이 그것을 위해 / 그들이 할 수 있기 때문에 이런 어리석은 짓을하지 말아야한다고 생각한다.

그것은 예일 수도 있지만 더 좋은 방법이있을 수도 있습니다 (확실히 유일한 방법은 아닙니다) ...

99 % 이상의 경우 typeof (a)에서 디스패치하는 것이 좋습니다. 기능 필드, 도트 오버로딩 없음.

* _ 그런데이 땅에 바로 그런 일을하는 패키지가있을 거라는 건 다들 아실 것 같아요 ..._

D에서는 a.b(arg) 대해 "uniform function call syntax"라는 이름도 가지고 있으며 꽤 인기가 있지만, Julia가 작동하는 다중 디스패치 방식 인 일반 함수와는 상당히 일치한다고 생각합니다. 문제의 함수가 익명이거나 완전히 덕 형식이면 모든 것이 작동 할 것이라고 생각하지만 상당히 제한적인 IMO입니다. 클래스 기반의 전통적인 OO 언어의 습관을 제외하고는 복합 유형 안에 함수 필드를 저장할 이유가별로 없다고 생각합니다. 어딘가에서로드하는 경우 일반 함수를 저장하는 더 좋은 위치는 모듈입니다.

그러나 우리는 지금 "실질적인 질문"과는 거리가 멀다. 또한 getfield 오버로딩을 허용하고, 모듈에서 getfield 오버로딩을 허용하지 않으며, "true getfield"에 대한 특수 구문에 대해 너무 걱정하지 않는 방식에 대해 보수적 인 태도를 선호합니다.

@stevengj : 예, 제가 a.b(c) 가 b(a, c) 와 같게되는 일이 결코 일어나지 않을 근본적인 이유 중 하나입니다. .

이것에 대한 메일 링리스트에 대한 토론이있었습니다. 내 관점에서이 스레드에 대한 가장 관련성이 높은 게시물 (@nalimilan)은 다음과 같습니다. https://groups.google.com/d/msg/julia-users/yC-sw9ykZwM/-607E_FPtl0J

이 기능을 언제 사용 해야하는지 에 대한 개인 정책에 대한 의견 에 추가하면 일부 HTTP 아이디어가 여기에서 유용 할 수 있으며 getfield() 에는 부작용 및 setfield!() 가 없어야합니다. 멱등이어야합니다 (즉, 동일한 값으로 여러 번 호출하면 한 번 호출하는 것과 동일한 효과가 있어야합니다). 반드시 컴파일러에 의해 강제되는 엄격하고 빠른 규칙은 아니지만 너무 미치게 만드는 것을 방지하기위한 사용 지침입니다.

포인터 매개 변수가있는 매개 변수 유형을 사용하는 해결 방법을 게시하고 필드를 설정할 때 사용자 지정 setter를 호출하도록 변환합니다.
게시물 : https://groups.google.com/forum/#!topic/julia -users / _I0VosEGa8o
코드 : https://github.com/barche/CppWrapper/blob/master/test/property.jl

setfield까지이 방법을 패키지에서 해결 방법으로 사용해야하는지 궁금합니다! 과부하가 가능합니까, 아니면 파라 메트릭 유형 시스템에 너무 많은 스트레스가 있습니까?

getfield / setfield! 오버로딩의 추가 이점 하나를 언급하고 싶습니다. 이것이 적절한 장소가되기를 바랍니다. 그렇지 않으면 죄송합니다. (https://groups.google.com/forum/#!topic/julia-users/ThQyCUgWb_Q에 관련 주제가 올라옴)

getfield / setfield가있는 Julia! 오버로딩은 _external package_에서 autoreload 기능의 놀랍도록 우아한 구현을 허용합니다. (이 기능을 얻기 위해 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
표현식 a.b -> getMember(a, :b) 의 AST를 변환하는 매크로

0.6에서 제거하면 이것이 좋은 아이디어라는 합의가없고 도트 구문으로 수행 할 작업에 대해 상충되는 제안이 있기 때문입니다.

@Keno : 상충되는 제안에 대한 링크가 있습니까?

@StefanKarpinski 가 아직 작성했다고 생각하지 않지만 곧 Julep이 나올 것으로 예상합니다.

fieldname(object) 또는 get_fieldname(object) 와 같은 getter 함수보다 object.fieldname 더 좋은 것을 발견했습니다. object.fieldname (또는 object$fieldname )가 getpublicfield (더 나은 이름 일 수 있음)에 대한 호출이고 object..fieldname 가 실제 getfield (비공개)는 좋은 옵션이 될 수 있습니다. 이런 식으로 유형은 getter 대신 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?)을 붙이는 것이 좋습니다. 감사!

Jeff와 저는 다중 인수 사건에 대해 논의하지 않았습니다. 내 느낌은 우리가 그것을 지원할 수도 있다는 것입니다. 인수가없는 경우에서 함수를 반환하여 어쨌든 시뮬레이션 할 수 있기 때문입니다 (하지만 같은 이유로 즉시 수행하는 것은 중요하지 않습니다).

변환기를 사용하여 값을 캐스팅하고 데이터의 유효성을 검사합니다.
이렇게 :

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 실제로 프로젝션 함수를 호출한다 Field{:b}() 대신 getfield 이 같은 기능을 얻을 그래서, x->x.a 무료 이미 있습니다. 또한 getfield 는 항상 낮은 수준의 필드 액세스를 의미합니다.

위의 구현은 완전히 작동하지만 컴파일러에서는 상당히 어렵습니다 (sysimg + 5 %, 정말 즐거운 놀라움입니다). 따라서 이것은 몇 가지 전문화 휴리스틱이 필요하고 초기 최적화가 업데이트되어야하지만 그렇게되면 실행 가능할 것입니다.

그 구현으로 테스트를 통과 할 수 있다는 것에 놀랐습니다. 이 의미 체계가 codegen이 모듈 참조를 최적화하는 것을 불가능하게하지 않습니까? 또한 전역 변수를 훨씬 더 비싸게 만들 것 같습니다 (속도와 메모리). 이것이 sysimg에 나타날 가능성은 그리 크지 않은 것 같습니다. 추론 저하가 여기에서 sysimg를 더 작게 만들었어야하는 것처럼 보이지만 5 % 더 나빠지는 것은 좋은 시작처럼 들리지 않습니다.)

예, jl_resolve_globals 에이를 업데이트해야하는 GlobalRefs로 변환하는 코드가 있습니다. 그 외에는 코드 생성이 처리 할 수 ​​있도록 인라인 처리되어야합니다. 추론에서 우리는 getindex 튜플과 비슷한 특별한 경우가 필요할 것입니다.

튜플 getindex와 비슷한 특별한 경우가 필요할 것입니다.

이 특별한 경우는 내장 된 getindex 메소드 서명과 교차하는 메소드가 정의되지 않기를 희망하고 가정합니다. 나는 그 사건이 여기서 어떻게 특히 적용되는지 보지 못합니다.

::Module 에 대한 메서드를 추가하고 섀도 잉 할 수 없다고 말하겠습니다.

@JeffBezanson 그 세 줄로 된 지점이 있습니까? 로컬 빌드에 직접 추가하려고했지만 줄리아가 지금 쯤 이동 한 것 같아서 작동하지 못했습니다.

줄리아 1.0의 기능에 대한 소원이 하나만 있다면 이것이 될 것이라고 말해야합니다. Mimi 와 Query 에서 내가 가지고있는 두 가지 오랜 문제를 해결할 것입니다.

쿼리의 경우는 꽤 일반적이라고 생각합니다. 매크로에서 새로운 유형을 생성 할 필요가없는 NamedTuples 버전을 그러면 다음 과 같은 필드 세트로 NamedTuple 를 반환하는 생성 된 함수를 작성할 수 있습니다. 생성 된 함수에서 계산됩니다. 나는 이것이 지금까지 Query.jl에서 가장 큰 걸림돌 인 blackrock / NamedTuples.jl # 4의 type-stable 버전을 작성할 수있게 해줄 것이라고 생각합니다.

간단히 말해서 이것은 줄리아의 전체 데이터 처리 스토리에 대해 매우 유용 할 것입니다.

아래 구문을 사용할 수 있습니까?

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

왜 세상에서 그 구문을 원하십니까?

쓰고 싶은 obj.plus(n) 대신 obj + n 심각한 OO 스톡홀름 증후군이다.

좋아, 주어진 예는 사소한 것 (그리고 나쁜 것)이었습니다.
getfield 오버로드 대신이 구문을 사용하고 인수를 사용할 수 있다는 아이디어였습니다.

나는 주로 기능에 관심이 있습니다. getfield 오버로딩에 대한 축약 된 구문을 사용하는 것은 훨씬 덜 중요해 보이며 논쟁 할 가치가 없습니다. 또한 getfield 및 setfield! getindex 및 setindex! 직접 미러링하므로 Julia에서는 다소 자연 스럽습니다. 마지막으로, OO 스타일을 광범위하게 사용하는 것은 Julia의 관용구에 적합하지 않으며, OO와 같은 메서드 정의 구문으로 권장하지 않는다고 생각합니다 (하지만 인수에 대한 위의 의견 참조 ).

나에게 일어난 한 가지는 $ 연산자가 더 이상 사용되지 않는다는 것입니다. 자, 이것은 분명히 $(x, sym::Symbol) = ... 와 같은 것을 이미 사용할 수있게 만들지 만, 다음과 같이 더 멋진 구문 재 작성을 즐길 수도 있습니다.

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

본격적인 getfield 오버로딩을하지 않고 이미이 문제에서 언급 된 대부분의 경우를 다루고 있다고 생각합니다. 솔직히 . 연산자는 Julia에서 의미 상 포화 상태이므로 이와 같은 것은 이해하기 쉽고 여전히 유용 할만큼 편리합니다.

@quinnj , 이미 #

그러나 필드 액세스를 위해 이미 . 이 (가) 있으므로 필드 액세스와 유사한 두 개의 연산자 (하나는 오버로드 가능하고 다른 하나는 그렇지 않은 연산자)가있는 것은 좋지 않은 것 같습니다. 그리고 거의 보편적으로 . 사용하는 Python 및 기타 OO 언어에 대한 언어 간 호출에는 약간 부자연 스러울 것입니다.

나는 이와 같은 것을 도입하기위한 유효한 주장으로 다른 언어와의 상호 운용성을 보지 않는다. 마치 "Python 코드는 이렇게 생겼기 때문에 파이썬 인 척 할 수 있으려면 우리도이 작업을해야합니다."라고 말하는 것과 같습니다. 나는 Julia 자체를 더 좋게 만들거나 더 일관되게 만들 논쟁을 아직 보지 못했습니다. Julia가 OOP 스타일의 x.f() 구문을 제공하지 않는다는 것은 이미 잘 알려져 있습니다. 그런 것을 허용하는 것은 불일치를 요구합니다.

@stevengj , 내가 오는 곳의 일부는 x.f _isn't_ 필드 액세스라는 사실입니다. 실제 필드 멤버 f 이 (가) 없습니다. 이 모든 문제는 getfield 오버로딩에 관한 것이며, x.f 실제로 필드를 참조하는지 아니면 내부에서 다른 작업을 수행하는지에 대한 잠재적 인 혼란이 주요 관심사라고 생각합니다.

내가 제안한 구문 재 작성의 장점은 getfield와의 추가 혼동없이 언어 상호 운용성 스토리를 충족한다는 것입니다. 이것이 제가 . 가 과포화 될 것이라고 언급했을 때 언급 한 것입니다. x$f 이 (가) 정말 훨씬 더 번거로울까요? 왜이 _has_ 점 연산자를 사용하는지 모르겠습니다.

이 모든 문제는 getfield 오버로딩에 관한 것이며 x.f 실제로 필드를 참조하는지 아니면 내부에서 다른 작업을 수행하는지에 대한 잠재적 인 혼란이 주요 관심사라고 생각합니다.

@JeffBezanson 의 세 줄 제안에 혼동의 여지가 없다고 생각합니다. a.b 는 항상 프로젝션 함수 호출로 낮아지고 getfield 호출이 아닙니다. 그런 다음 getfield 를 호출하는 프로젝션 함수에 대한 기본 / 대체 메서드가 있습니다. 사용자는 원하는 경우 해당 프로젝션 함수에 자신의 유형에 대한 메서드를 추가 할 수 있습니다. getfield 항상 해당 제안에서 낮은 수준의 필드 액세스를 의미하며 사용자는 getfield 에 메서드를 추가하지 않습니다 ( "getfield 오버로드"라는 의미라고 가정합니다). 그것은 나에게 매우 깨끗한 것 같습니다. 그래도 그 제안이 아직 테이블에 있는지 여부는 명확하지 않지만 이해하지 못하는 컴파일러 문제가있는 것 같습니다. :)

저는이 기능을 정말 갖고 싶습니다 (Scala에서 항상 좋아했습니다). 필드에 직접 액세스하는 IMHO는 Julia에서 매우 자연 스럽습니다 (예 : 모든 것에 대해 getter 및 setter를 방어 적으로 정의하는 Java 방식과 비교). 그러나 "가상"필드를 추가하는 기능이 없으면 많은 코드를 깨지 않고 구조를 발전 / 리팩터링하는 것이 매우 어려워집니다.

나는 이것이 v2.0으로 태그되었다는 것을 알고 있지만, v1.0에 대해 이것을 재고하기 위해 이것을 다시 불러오고 싶습니다. 이 기능은 패키지 / 라이브러리 개발자에게 매우 유용합니다.

사용자를위한 패키지를 빌드 할 때 속성 접근자를 오버로드하면 패키지 관리자가 훨씬 더 깨끗한 사용자 인터페이스를 제공 할 수 있습니다. 나는 주장 할 것입니다.

complex_data_structure.attribute

입력하기 쉽습니다.

get(complex_data_structure, :attribute)

여기서 get 는 :attribute 설명되는 데이터를 가져 오는 데 필요한 함수입니다.

이는 잠재적으로 REPL에서 검색 가능성을 향상시킬 수 있으며 언어 코드 및 데이터 탐색에 도움이됩니다.

또한, setter 속성 인터셉터도 매우 유용합니다. 다음 예제를 고려하십시오 (현재 내 많은 스크립트에서 이미 발견되었습니다 :)).

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

속성 getter 및 setter가 Julia의 일부로 포함 된 경우 위의 내용은 다음과 같습니다.

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)

생성자는 도메인 입력을 변경 불가능한 구조로 제한 할 수 있지만 사용자는 여전히 유효하지 않은 값을 입력 할 수 있습니다. 속성 getter 및 setter는 여기에서 데이터 유효성에 대한 피드백을 더 즉각적으로 만들고 언어 사용자로서 훨씬 더 깨끗한 인터페이스를 만들 수 있기 때문에 여기에서 도움이 될 것입니다.

이것은 또한 PyCall.jl 및 DataFrames.jl과 같은 다른 패키지에 큰 이점을 제공하여 사용자를위한 더 나은 직관적 인 인터페이스를 구축 할 수 있습니다. 이 패키지의 작성자는 또한이 기능에 관심을 표명했습니다.

생각? 스레드를 읽어 보면 이미 최종 단계에 가까워졌습니다. 저자의 생각이 궁금합니다.

https://github.com/bramtayl/DotOverloading.jl 에서 유형 안정적인 선택적 매크로로 구현되었습니다

@bramtayl , 나는 a.b 표현식 앞에 @overload_dots 를 넣어야한다고 생각합니다.

나는 매크로를베이스에 추가 할 것을 제안하지 않았습니다. 나는 매크로가 사용하는 전략을 파서에 구울 것을 제안했습니다. 그러나 전체 파일에서 실행되거나 IDE로 해킹 될 수있는 매크로입니다.

즉 수반 a.b 으로 해석되고 Expr(:., :a, :(Val{:b}()) 와로 저하 get_field_overloadable(a, Val{:b}())

@bramtayl , 위 의 Jeff의

getfield 오버로딩의 한 가지 문제점은 일부 라이브러리가 데이터 구조의 내부에 대한 적절한 인터페이스가 없다는 것입니다. 내가 원하는 것은 내 코드를 실행하고 내일 보고서를 작성할 수 있도록 구조의 데이터 포인트를 수정하는 것뿐 일 때, 특히 내 의존성에 3 단계 깊이있는 라이브러리에서 코드를 편집 할 수있는 것을 기대하지 않습니다. 합리적이고 빠른 방식으로 데이터 포인트에 직접 액세스합니다. 사용중인 데이터 구조를 제어 할 수있는 것처럼 느끼고 싶습니다.

두 번째 요점은 getfield 및 setfield를 사용할 때 거대한 함수 메커니즘 대신 데이터 구조에 직접 액세스한다는 합리적인 기대를 원한다는 것입니다. 게다가 struct 키워드는 유형을 정의하는 데 사용되어 C를 상기시켜 주며 getfield 액세스가 직접적이어야한다는 기대감을 제공합니다.

따라서 $ 연산자를 대신 사용하는 것은 getfield 에서처럼 직접 액세스 할 것이라는 기대가 없기 때문에 합리적인 타협이라고 생각합니다. 이미 다른 컨텍스트에서는 특수 문자이므로 그리 놀랍지 않습니다. 이런 식으로 사용하면 사용하는 사람이 적고 더 이상 함수가되지 않기 때문에 폐기하기 쉬우 며 R에서도 비슷하게 사용됩니다.

getfield 오버로딩의 한 가지 문제점은 일부 라이브러리가 데이터 구조의 내부에 대한 적절한 인터페이스가 없다는 것입니다.

위의 @JeffBezanson 구현은 getfield (또는 setfield )를 오버로드하지 않습니다.

나는 또한 이것을 1.0으로 만들 것을 간청하고 싶습니다. 나는 종종 내 코드를 다소 유연하게 유지하기 위해 getter / settings를 작성하는 것 (그리고 이름을 지정하는 방법에 대해 궁금해 함)과 내 코드 사용자가 직접 필드 액세스를 사용하도록 "허용 / 장려"하는 것 사이에서 갈등을 느낀다.

많은 게터와 세터를 방어 적으로 작성하는 것은 나에게 줄리안처럼 보이지 않습니다. 결국 Julia는 개인 / 보호 필드가 없으므로 사용자가 필드에 직접 액세스하도록 권장합니다. 그런 다음 다른 패키지와 많은 충돌을 일으키지 않고 많은 getter / setter 함수의 이름을 지정하는 방법에 대한 질문이 있습니다. 그리고 getfield 및 setfield! (또는 이와 유사한)에 대한 메서드를 추가하는 대안으로 Val{:fieldname} 정도에 발송되는 것도 사용자 친화적 인 것처럼 보이지 않습니다.

반면에 직접 필드 액세스가 기본적으로 모든 구조체를 영구적으로 잠그는 경우 특히 장수 코드의 경우 권장되지 않아야합니다. @JeffBezanson 의 구현은이 딜레마에서 아주 깔끔한 방법 인 것 같습니다.

맞아, @davidanthoff. getfield 오버로딩과 . 필드 액세스 구문의 오버로딩을 합쳐야합니다. 필드 액세스 구문의 과부하를 의미했습니다.

이 기능을 추가하는 이전 버전과 호환되는 방법이 있으므로 1.x 릴리스에 추가 할 수 있지만 1.0에서는 발생하지 않습니다. 완성 된 디자인이나 구현할 시간이 없습니다.

(C-) 구조체에 대한 포인터에 도트 구문을 사용하는 것이 매우 편리합니다.

내가 선호하는 구문은 포인터를 이동 및 변환하는 데만 점을 사용하고 deref를 위해 []를 사용하는 것입니다.

따라서 somepair a :: Int b :: Int end, p :: Ptr {somepair}를 구성하면 pa는 a 필드에 대한 포인터이고 pa [] = 3으로 쓰거나 x =로 읽습니다. 아빠[].

다음으로 우리는 타입의 포워드 선언과 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의 런타임 lib의 유형을 내보낼 수 있으며 pointer_from_objref는 실제로 더 편리한 인트로 스펙 션을 위해 멋진 유형의 포인터를 제공 할 수 있습니다.

동일한 오프셋을 가진 두 개의 필드를 갖는 것만으로도 조합이 자동으로 작동해야한다는 느낌이 듭니다.

@chethega 나는 당신이 C의 메모리 모델 채택을 둘러싼 문제없이 대략 동일한 기능을 제공하는 https://github.com/JuliaLang/julia/pull/21912를 찾고 있다고 생각합니다 (유형 실행 위반, -그 언어에서 가능한 성능 최적화를 제한하는 경계 액세스, 내부 포인터의 앨리어싱 등).

지속적인 전파가 이것을 더 가능하게 만들까요?

이정표를 1.0으로 변경하십시오! :)

@ Liso77 무슨 말이야? 닫을 때 상태에 표시된대로 이미 git master에 구현되어 있습니다.

@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 기능이 동결되기 전에 어쨌든 병합되었습니다. 명확성을 위해 이정표를 제거했지만이 시점에서 master에 병합 된 모든 항목은 1.0이됩니다.

설명해 주셔서 감사합니다! 신난다! NEWS 파일도 특히 깨달았습니다.

제거해 주셔서 감사합니다! 1.0에 나올 것이 너무 기쁩니다! :)

예를 들어 fieldnames ? 오버로드를 허용하여 자동 완성에서 이러한 새로운 "동적으로 정의 된 필드"를 지원하는 방법이 있는지 궁금합니다. 이것은 많은 열 및 / 또는 긴 열 이름이있는 DataFrame s (앞으로 df.column_name 를 지원할 것이라고 가정)를 다룰 때와 같이 대화식 사용을 위해 매우 강력 할 수 있습니다.

나는 현재 REPL (탭 확장), 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 맞습니다-하지만 현재 그렇게하는 것이 "안전"합니까? fieldnames 에 의존하는 것이 무엇인지 잘 모르겠습니다.

안전하지 않은 경우 complete_fieldnames(x) = fieldnames(x) 를 정의하고 REPL 완성에 complete_fieldnames 를 사용하고 사용자 지정 완성에 대해 오버로드 할 수 있습니다.

예, 이것이 제가 이것을 제기 한 이유입니다. Base에서 무언가를 변경 / 추가해야 할 경우 REPL과 친구들이 나중에 활용할 수 있습니다. 0.7 기능 동결 관점에서 ...

이것이 제가 getproperty 함수를 호출하게되어 기쁩니다. fieldnames 와 같은 것을 참조하지 않는다는 것을 명확히하는 데 도움이됩니다. fieldnames 방해하면 확실히 심각한 문제가 발생할 수 있습니다.

유효한 속성 값을 제공하기 위해 해당 propertynames 가 필요할 수 있습니다. 물론, 그것은 잘 정의 된 개념이 아닐 수 있으므로 우리는 완성을 위해 더 구체적인 것을 원할 것입니다.

전문가의 의견과 심층 분석이 필요할 수 있다는 느낌이 들었습니다 (감사합니다!).이 문제에 대해 새로운 문제를 열어야합니까?