Julia: सार प्रकारों के लिए इंटरफेस

आम तौर पर, मुझे लगता है कि यह बेहतर इंटरफ़ेस-उन्मुख प्रोग्रामिंग के लिए एक अच्छी दिशा है।

हालाँकि, यहाँ कुछ याद आ रहा है। एक इंटरफ़ेस के लिए विधियों के हस्ताक्षर (न केवल उनके नाम) भी महत्वपूर्ण हैं।

इसे लागू करना आसान नहीं है और इसमें बहुत सारी गड़बड़ियां होंगी। शायद यही एक कारण है कि _Concepts_ को C++ 11 द्वारा स्वीकार नहीं किया गया था, और तीन वर्षों के बाद, केवल एक बहुत ही सीमित _lite_ संस्करण C++ 14 में आता है।

मेरे उदाहरण में size विधि में हस्ताक्षर शामिल थे। इसके अलावा बेस.ग्राफिक्स से @mustimplement भी हस्ताक्षर को ध्यान में रखता है।

मुझे यह जोड़ना चाहिए कि हमारे पास पहले से ही Concept-light का एक हिस्सा है जो एक प्रकार को एक निश्चित सार प्रकार के उप प्रकार के रूप में प्रतिबंधित करने की क्षमता है। इंटरफेस दूसरा हिस्सा हैं।

वह मैक्रो बहुत अच्छा है। मैंने मैन्युअल रूप से त्रुटि-ट्रिगर फॉलबैक को परिभाषित किया है, और यह इंटरफेस को परिभाषित करने के लिए बहुत अच्छा काम करता है। उदाहरण के लिए जूलियाऑप्ट का मैथप्रोगबेस यह करता है, और यह अच्छी तरह से काम करता है। मैं एक नए सॉल्वर (https://github.com/IainNZ/RationalSimplex.jl) के साथ घूम रहा था और मुझे इंटरफ़ेस फ़ंक्शंस को तब तक लागू करना था जब तक कि इसे काम करने के लिए त्रुटियों को उठाना बंद न हो जाए।

आपका प्रस्ताव भी कुछ ऐसा ही करेगा, है ना? लेकिन क्या आप पूरे इंटरफ़ेस को लागू करने के लिए _have_ होंगे?

यह कॉन्वेंट/कॉन्ट्रावेरिएंट पैरामीटर से कैसे निपटता है?

उदाहरण के लिए,

abstract A has foo(::A, ::Array)

type B <: A 
    ...
end

type C <: A
    ...
end

# is it ok to let the arguments to have more general types?
foo(x::Union(B, C), y::AbstractArray) = ....

@IainNZ हां, प्रस्ताव वास्तव में @mustimplement को थोड़ा अधिक बहुमुखी बनाने के बारे में है जैसे कि हस्ताक्षर प्रदान किया जा सकता है लेकिन प्रदान करने की आवश्यकता नहीं है। और मेरी भावना यह है कि यह ऐसा "कोर" है कि इसका अपना सिंटैक्स प्राप्त करना उचित है। यह लागू करना बहुत अच्छा होगा कि सभी विधियों को वास्तव में लागू किया गया है लेकिन वर्तमान रनटाइम जांच जैसा कि @mustimplement है, पहले से ही एक अच्छी बात है और इसे कार्यान्वित करना आसान हो सकता है।

@ लिंडहुआ एक दिलचस्प उदाहरण है। इसके बारे में सोचना होगा।

@ लिंडाहुआ शायद आपका उदाहरण सिर्फ काम करना चाहेगा। @mustimplement काम नहीं करेगा क्योंकि यह अधिक विशिष्ट विधि हस्ताक्षरों को परिभाषित करता है।

तो इसे कंपाइलर में थोड़ा गहरा लागू करना पड़ सकता है। अमूर्त प्रकार की परिभाषा पर किसी को इंटरफ़ेस नाम/हस्ताक्षर का ट्रैक रखना होता है। और उस बिंदु पर जहां वर्तमान में "... परिभाषित नहीं" त्रुटि फेंकी जाती है, किसी को उचित त्रुटि संदेश उत्पन्न करना होता है।

MethodError प्रिंट के तरीके को बदलना बहुत आसान है, जब हमारे पास जानकारी को व्यक्त करने और एक्सेस करने के लिए एक सिंटैक्स और एपीआई है।

एक और चीज जो हमें मिल सकती है वह है base.Test में एक फ़ंक्शन यह सत्यापित करने के लिए कि एक प्रकार (सभी प्रकार?) मूल प्रकारों के इंटरफेस को पूरी तरह से लागू करता है। यह वास्तव में एक साफ-सुथरी इकाई परीक्षण होगा।

धन्यवाद @ivarne। तो कार्यान्वयन निम्नानुसार दिख सकता है:

1. एक के पास वैश्विक शब्दकोश है जिसमें अमूर्त प्रकार कुंजी और फ़ंक्शन (+ वैकल्पिक हस्ताक्षर) मान के रूप में हैं।
2. जब has घोषणा को पार्स किया जाता है तो पार्सर को निर्देश भरने के लिए अनुकूलित करने की आवश्यकता होती है।
3. MethodError को यह देखने की जरूरत है कि क्या वर्तमान फ़ंक्शन वैश्विक शब्दकोश का हिस्सा है।

अधिकांश तर्क तब MethodError ।

मैं इसके साथ थोड़ा प्रयोग कर रहा हूं और निम्नलिखित सार का उपयोग कर रहा हूं https://gist.github.com/tknopp/ed53dc22b61062a2b283 मैं यह कर सकता हूं:

julia> abstract A
julia> addInterface(A,length)
julia> type B <: A end
julia> checkInterface(B)
ERROR: Interface not implemented! B has to implement length in order to be subtype of A ! in error at error.jl:22

length को परिभाषित करते समय कोई त्रुटि नहीं डाली जाती है:

julia> import Base.length
julia> length(::B) = 10
length (generic function with 34 methods)
julia> checkInterface(B)
true

ऐसा नहीं है कि यह वर्तमान में हस्ताक्षर को ध्यान में नहीं रखता है।

मैंने कोड को थोड़ा सा अपडेट किया है ताकि फ़ंक्शन हस्ताक्षरों को ध्यान में रखा जा सके। यह अभी भी बहुत हैकी है लेकिन निम्नलिखित अब काम करता है:

julia> abstract A
julia> type B <: A end

julia> addInterface(A,:size,(A,Int64))
1-element Array{(DataType,DataType),1}:
 (A,Int64)
julia> checkInterface(B)
ERROR: Interface not implemented! B has to implement size in order to be subtype of A !
in error at error.jl:22

julia> import Base.size
julia> size(::B, ::Integer) = 333
size (generic function with 47 methods)
julia> checkInterface(B)
true

julia> addInterface(A,:size,(A,Float64))
2-element Array{(DataType,DataType),1}:
 (A,Int64)
 (A,Float64)
julia> checkInterface(B)
ERROR: Interface not implemented! B has to implement size in order to be subtype of A !
 in error at error.jl:22
 in string at string.jl:30

मुझे यह जोड़ना चाहिए था कि जिस्ट में इंटरफ़ेस कैश अब कार्यों के बजाय प्रतीकों पर काम करता है ताकि कोई इंटरफ़ेस जोड़ सके और बाद में फ़ंक्शन घोषित कर सके। मुझे हस्ताक्षर के साथ भी ऐसा ही करना पड़ सकता है।

बस देखा कि #2248 में पहले से ही इंटरफेस पर कुछ सामग्री है।

जब तक हम दरवाजे से बाहर नहीं हो जाते, तब तक मैं इंटरफेस जैसी अधिक सट्टा सुविधाओं पर विचारों को प्रकाशित करने से रोक रहा था, लेकिन जब से आपने चर्चा शुरू की है, यहां कुछ समय पहले मैंने लिखा था।

इंटरफ़ेस घोषणा और उस इंटरफ़ेस के कार्यान्वयन के लिए सिंटैक्स का मॉकअप यहां दिया गया है:

interface Iterable{T,S}
    start :: Iterable --> S
    done  :: (Iterable,S) --> Bool
    next  :: (Iterable,S) --> (T,S)
end

implement UnitRange{T} <: Iterable{T,T}
    start(r::UnitRange) = oftype(r.start + 1, r.start)
    next(r::UnitRange, state::T) = (oftype(T,state), state + 1)
    done(r::UnitRange, state::T) = i == oftype(i,r.stop) + 1
end

आइए इसे टुकड़ों में तोड़ दें। सबसे पहले, वहाँ समारोह प्रकार वाक्य रचना: A --> B एक समारोह में उस प्रकार की वस्तुओं के नक्शे के प्रकार है A टाइप करने के लिए B । इस संकेतन में टुपल्स स्पष्ट कार्य करते हैं। अलगाव में, मैं प्रस्ताव कर रहा हूं कि f :: A --> B घोषित करेगा कि f एक सामान्य कार्य है, मैपिंग प्रकार A टाइप करने के लिए B । यह थोड़ा खुला प्रश्न है कि इसका क्या अर्थ है। क्या इसका मतलब यह है कि जब A प्रकार के तर्क पर लागू किया जाता है, तो f B प्रकार का परिणाम देगा? क्या इसका मतलब यह है कि f केवल A प्रकार के तर्कों पर लागू किया जा सकता है? क्या स्वचालित रूपांतरण कहीं भी होना चाहिए - आउटपुट पर, इनपुट पर? अभी के लिए, हम मान सकते हैं कि यह सब करता है कि इसमें कोई तरीका जोड़े बिना एक नया जेनेरिक फ़ंक्शन बनाया गया है, और प्रकार केवल दस्तावेज़ीकरण के लिए हैं।

दूसरा, इंटरफ़ेस Iterable{T,S} की घोषणा है। यह Iterable एक मॉड्यूल की तरह और एक सार प्रकार की तरह थोड़ा सा बनाता है। यह एक मॉड्यूल की तरह है जिसमें इसमें Iterable.start , Iterable.done और Iterable.next नामक सामान्य कार्यों के लिए बाइंडिंग है। यह उस Iterable और Iterable{T} और Iterable{T,S} प्रकार की तरह है जहां अमूर्त प्रकार का उपयोग किया जा सकता है - विशेष रूप से, विधि प्रेषण में।

तीसरा, implement ब्लॉक परिभाषित करता है कि UnitRange Iterable इंटरफ़ेस को कैसे लागू करता है। implement ब्लॉक के अंदर, Iterable.start , Iterable.done और Iterable.next फ़ंक्शन उपलब्ध हैं, जैसे कि उपयोगकर्ता ने import Iterable: start, done, next , अनुमति देता है इन कार्यों के लिए विधियों का जोड़। यह ब्लॉक टेम्पलेट की तरह है जिस तरह से पैरामीट्रिक प्रकार की घोषणाएं हैं - ब्लॉक के अंदर, UnitRange अर्थ एक विशिष्ट UnitRange , न कि छाता प्रकार।

implement ब्लॉक का प्राथमिक लाभ यह है कि यह स्पष्ट रूप से import फ़ंक्शंस की आवश्यकता से बचता है जिसे आप विस्तारित करना चाहते हैं - वे आपके लिए निहित रूप से आयात किए जाते हैं, जो अच्छा है क्योंकि लोग आमतौर पर import बारे में भ्रमित होते हैं। Base में अधिकांश सामान्य कार्य जो उपयोगकर्ता विस्तारित करना चाहते हैं उन्हें कुछ इंटरफ़ेस से संबंधित होना चाहिए, इसलिए इसे import लिए उपयोगों के विशाल बहुमत को समाप्त करना चाहिए। चूंकि आप हमेशा किसी नाम को पूरी तरह से योग्य बना सकते हैं, हो सकता है कि हम इसे पूरी तरह से हटा दें।

एक और विचार जो मैंने इधर-उधर उछाला है, वह है इंटरफ़ेस फ़ंक्शंस के "आंतरिक" और "बाहरी" संस्करणों को अलग करना। इससे मेरा तात्पर्य यह है कि "आंतरिक" फ़ंक्शन वह है जिसे आप कुछ इंटरफ़ेस को लागू करने के लिए विधियों की आपूर्ति करते हैं, जबकि "बाहरी" फ़ंक्शन वह है जिसे आप कुछ इंटरफ़ेस के संदर्भ में सामान्य कार्यक्षमता को लागू करने के लिए कहते हैं। विचार करें कि जब आप sort! फ़ंक्शन के तरीकों को देखते हैं (बहिष्कृत विधियों को छोड़कर):

julia> methods(sort!)
sort!(r::UnitRange{T<:Real}) at range.jl:498
sort!(v::AbstractArray{T,1},lo::Int64,hi::Int64,::InsertionSortAlg,o::Ordering) at sort.jl:242
sort!(v::AbstractArray{T,1},lo::Int64,hi::Int64,a::QuickSortAlg,o::Ordering) at sort.jl:259
sort!(v::AbstractArray{T,1},lo::Int64,hi::Int64,a::MergeSortAlg,o::Ordering) at sort.jl:289
sort!(v::AbstractArray{T,1},lo::Int64,hi::Int64,a::MergeSortAlg,o::Ordering,t) at sort.jl:289
sort!{T<:Union(Float64,Float32)}(v::AbstractArray{T<:Union(Float64,Float32),1},a::Algorithm,o::Union(ReverseOrdering{ForwardOrdering},ForwardOrdering)) at sort.jl:441
sort!{O<:Union(ReverseOrdering{ForwardOrdering},ForwardOrdering),T<:Union(Float64,Float32)}(v::Array{Int64,1},a::Algorithm,o::Perm{O<:Union(ReverseOrdering{ForwardOrdering},ForwardOrdering),Array{T<:Union(Float64,Float32),1}}) at sort.jl:442
sort!(v::AbstractArray{T,1},alg::Algorithm,order::Ordering) at sort.jl:329
sort!(v::AbstractArray{T,1}) at sort.jl:330
sort!{Tv<:Union(Complex{Float32},Complex{Float64},Float64,Float32)}(A::CholmodSparse{Tv<:Union(Complex{Float32},Complex{Float64},Float64,Float32),Int32}) at linalg/cholmod.jl:809
sort!{Tv<:Union(Complex{Float32},Complex{Float64},Float64,Float32)}(A::CholmodSparse{Tv<:Union(Complex{Float32},Complex{Float64},Float64,Float32),Int64}) at linalg/cholmod.jl:809

इनमें से कुछ विधियां सार्वजनिक उपभोग के लिए अभिप्रेत हैं, लेकिन अन्य सार्वजनिक छँटाई विधियों के आंतरिक कार्यान्वयन का हिस्सा हैं। वास्तव में, यह एकमात्र सार्वजनिक तरीका होना चाहिए:

sort!(v::AbstractArray)

बाकी शोर हैं और "अंदर" पर हैं। विशेष रूप से,

sort!(v::AbstractArray{T,1},lo::Int64,hi::Int64,::InsertionSortAlg,o::Ordering)
sort!(v::AbstractArray{T,1},lo::Int64,hi::Int64,a::QuickSortAlg,o::Ordering)
sort!(v::AbstractArray{T,1},lo::Int64,hi::Int64,a::MergeSortAlg,o::Ordering)

सामान्य सॉर्टिंग मशीनरी में हुक करने के लिए सॉर्टिंग एल्गोरिदम लागू करने के तरीके हैं। वर्तमान में Sort.Algorithm एक अमूर्त प्रकार है, और InsertionSortAlg , QuickSortAlg और MergeSortAlg इसके ठोस उपप्रकार हैं। इंटरफेस के साथ, Sort.Algorithm इसके बजाय एक इंटरफ़ेस हो सकता है और विशिष्ट एल्गोरिदम इसे लागू करेंगे। कुछ इस तरह:

# module Sort
interface Algorithm
    sort! :: (AbstractVector, Int, Int, Algorithm, Ordering) --> AbstractVector
end
implement InsertionSortAlg <: Algorithm
    function sort!(v::AbstractVector, lo::Int, hi::Int, ::InsertionSortAlg, o::Ordering)
        <strong i="17">@inbounds</strong> for i = lo+1:hi
            j = i
            x = v[i]
            while j > lo
                if lt(o, x, v[j-1])
                    v[j] = v[j-1]
                    j -= 1
                    continue
                end
                break
            end
            v[j] = x
        end
        return v
    end
end

तब हम जो अलगाव चाहते हैं उसे परिभाषित करके पूरा किया जा सकता है:

# module Sort
sort!(v::AbstractVector, alg::Algorithm, order::Ordering) =
    Algorithm.sort!(v,1,length(v),alg,order)

यह, क्या हम वर्तमान में कर रहे हैं उससे _very_ करीब है को छोड़कर हम उस Algorithm.sort! के बजाय सिर्फ sort! - और जब विभिन्न छँटाई एल्गोरिदम को लागू करने, "आंतरिक" परिभाषा की एक विधि है Algorithm.sort! sort! फ़ंक्शन नहीं। इसका बाहरी इंटरफ़ेस से sort! के कार्यान्वयन को अलग करने का प्रभाव है।

@StefanKarpinski आपके लेखन के लिए बहुत बहुत धन्यवाद! यह निश्चित रूप से 0.3 सामान नहीं है। बहुत खेद है कि मैं इस समय इसे लाया। मुझे यकीन नहीं है कि 0.3 जल्द ही या आधे साल में होगा ;-)

पहली नज़र से मैं वास्तव में (!) को पसंद करता हूं कि कार्यान्वयन अनुभाग को अपना कोड ब्लॉक परिभाषित किया गया है। यह प्रकार परिभाषा पर इंटरफ़ेस को सीधे सत्यापित करने में सक्षम बनाता है।

कोई चिंता नहीं - जब हम किसी रिलीज़ को स्थिर करने का प्रयास कर रहे हैं, तो भविष्य की सुविधाओं के बारे में अनुमान लगाने में कोई बुराई नहीं है।

आपका दृष्टिकोण बहुत अधिक मौलिक है और कुछ इंटरफ़ेस स्वतंत्र मुद्दों को हल करने का भी प्रयास करता है। यह भाषा में एक नया निर्माण (यानी इंटरफ़ेस) भी लाता है जो भाषा को थोड़ा और जटिल बनाता है (जो कि एक बुरी चीज नहीं है)।

मैं "इंटरफ़ेस" को अमूर्त प्रकारों के एनोटेशन के रूप में अधिक देखता हूं। यदि कोई इसमें has डालता है तो कोई इंटरफ़ेस निर्दिष्ट कर सकता है लेकिन किसी को ऐसा नहीं करना पड़ता है।

जैसा कि मैंने कहा था कि मैं वास्तव में पसंद करूंगा यदि इंटरफ़ेस को सीधे इसकी घोषणा पर मान्य किया जा सकता है। एक प्रकार की घोषणा के अंदर विधियों को परिभाषित करने की अनुमति देने के लिए यहां कम से कम आक्रामक दृष्टिकोण हो सकता है। तो अपना उदाहरण लेना कुछ इस प्रकार है

type UnitRange{T} <: Iterable{T,T}
    start(r::UnitRange) = oftype(r.start + 1, r.start)
    next(r::UnitRange, state::T) = (oftype(T,state), state + 1)
    done(r::UnitRange, state::T) = i == oftype(i,r.stop) + 1
end

किसी को अभी भी प्रकार की घोषणा के बाहर फ़ंक्शन को परिभाषित करने की अनुमति होगी। अंतर केवल इतना होगा कि आंतरिक कार्य घोषणाएं इंटरफेस के खिलाफ मान्य हैं।

लेकिन फिर, शायद मेरा "कम से कम आक्रामक दृष्टिकोण" बहुत छोटा है। सच में नहीं पता।

उन परिभाषाओं को टाइप ब्लॉक के अंदर रखने के साथ एक मुद्दा यह है कि ऐसा करने के लिए, हमें वास्तव में कम से कम इंटरफेस के एकाधिक विरासत की आवश्यकता होगी, और यह अनुमान लगाया जा सकता है कि विभिन्न इंटरफेस के बीच नाम टकराव हो सकता है। आप इस तथ्य को भी जोड़ना चाहेंगे कि एक प्रकार किसी बिंदु पर इंटरफ़ेस का समर्थन करता है _after_ प्रकार को परिभाषित करता है, हालांकि मैं इसके बारे में निश्चित नहीं हूं।

@StefanKarpinski यह

ग्राफ़ पैकेज वह है जिसे इंटरफ़ेस सिस्टम की सबसे अधिक आवश्यकता है। यह देखना दिलचस्प होगा कि यह प्रणाली यहां उल्लिखित इंटरफेस को कैसे व्यक्त कर सकती है: http://graphsjl-docs.readthedocs.org/en/latest/interface.html।

@StefanKarpinski : मैं इस मुद्दे को एकाधिक विरासत और इन-ब्लॉक फ़ंक्शन घोषणाओं के साथ पूरी तरह से नहीं देखता हूं। टाइप ब्लॉक के भीतर सभी विरासत में मिले इंटरफेस की जांच करनी होगी।

लेकिन मैं समझता हूं कि कोई इंटरफ़ेस कार्यान्वयन को "खुला" देना चाहता है। और इन-टाइप फ़ंक्शन घोषणा भाषा को बहुत जटिल कर सकती है। हो सकता है कि मैंने #7025 में जो दृष्टिकोण लागू किया है, वह पर्याप्त हो। या तो एक डाल verify_interface समारोह घोषणाओं के बाद (या एक इकाई परीक्षण में) या करने के लिए यह आस्थगित करें MethodError ।

यह मुद्दा यह है कि विभिन्न इंटरफेस में एक ही नाम से सामान्य कार्य हो सकता है, जो एक नाम टकराव का कारण बनता है और एक स्पष्ट आयात करने या पूरी तरह से योग्य नाम से विधियों को जोड़ने की आवश्यकता होती है। यह यह भी कम स्पष्ट करता है कि कौन सी विधि परिभाषाएं किस इंटरफेस से संबंधित हैं - यही कारण है कि नाम टकराव पहली जगह में हो सकता है।

बीटीडब्ल्यू, मैं मानता हूं कि भाषा में एक और "चीज" के रूप में इंटरफेस जोड़ना थोड़ा गैर-ऑर्थोगोनल लगता है। आखिरकार, जैसा कि मैंने प्रस्ताव में उल्लेख किया है, वे मॉड्यूल की तरह थोड़े हैं और थोड़े प्रकार के हैं। ऐसा लगता है कि अवधारणाओं का कुछ एकीकरण संभव हो सकता है, लेकिन मैं इस बारे में स्पष्ट नहीं हूं कि कैसे।

मैं कुछ कारणों से इंटरफ़ेस-एज़-लाइब्रेरी मॉडल को इंटरफ़ेस-एज़-लैंग्वेज-फ़ीचर मॉडल के लिए पसंद करता हूं: यह भाषा को सरल रखता है (बेशक वरीयता और कोई ठोस आपत्ति नहीं) और इसका मतलब है कि यह सुविधा वैकल्पिक बनी हुई है और आसानी से हो सकती है वास्तविक भाषा के साथ छेड़छाड़ किए बिना सुधार या पूरी तरह से बदल दिया गया।

विशेष रूप से, मैं @tknopp से प्रस्ताव लगता है (या प्रस्ताव के कम से कम आकार) @StefanKarpinski से एक से बेहतर है - यह कुछ भी भाषा में नई परिभाषा की आवश्यकता के बिना समय की जाँच प्रदान करता है। मुझे जो मुख्य दोष दिखाई दे रहा है, वह है टाइप वेरिएबल्स से निपटने की क्षमता की कमी; मुझे लगता है कि इंटरफ़ेस परिभाषा को आवश्यक कार्यों के प्रकार के लिए _predicates_ प्रकार प्रदान करके इसे नियंत्रित किया जा सकता है।

मेरे प्रस्ताव के लिए प्रमुख प्रेरणाओं में से एक बड़ी मात्रा में भ्रम है जो _import_ सामान्य कार्यों के कारण होता है - लेकिन उन्हें निर्यात नहीं करता है - ताकि उनमें विधियों को जोड़ा जा सके। अधिकांश समय, ऐसा तब होता है जब कोई अनौपचारिक इंटरफ़ेस लागू करने का प्रयास कर रहा होता है, इसलिए ऐसा लगता है कि यह हो रहा है।

यह हल करने के लिए एक ऑर्थोगोनल समस्या की तरह लगता है, जब तक कि आप इंटरफेस से संबंधित विधियों को पूरी तरह प्रतिबंधित नहीं करना चाहते हैं।

नहीं, यह निश्चित रूप से एक अच्छा प्रतिबंध नहीं लगता।

@StefanKarpinski आप उल्लेख करते हैं कि आप एक इंटरफ़ेस पर प्रेषण करने में सक्षम होंगे। साथ ही implement सिंटैक्स में विचार यह है कि एक विशेष प्रकार इंटरफ़ेस को लागू करता है।

यह कई प्रेषण के साथ थोड़ा सा लगता है, क्योंकि सामान्य तरीके किसी विशेष प्रकार से संबंधित नहीं होते हैं, वे एक प्रकार के टपल से संबंधित होते हैं। तो यदि विधियां प्रकारों से संबंधित नहीं हैं, तो इंटरफेस (जो मूल रूप से विधियों के सेट हैं) एक प्रकार से कैसे संबंधित हो सकते हैं?

कहो कि मैं पुस्तकालय एम का उपयोग कर रहा हूँ:

module M

abstract A
abstract B

type A2 <: A end
type A3 <: A end
type B2 <: B end

function f(a::A2, b::B2)
    # do stuff
end

function f(a::A3, b::B2)
    # do stuff
end

export f, A, B, A2, A3, B2
end # module M

अब मैं एक सामान्य कार्य लिखना चाहता हूं जो ए और बी लेता है

using M

function userfunc(a::A, b::B, i::Int)
    res = f(a, b)
    res + i
end

इस उदाहरण में f फ़ंक्शन एक एड-हॉक इंटरफ़ेस बनाता है जो A और एक B लेता है, और मैं यह मानने में सक्षम होना चाहता हूं कि मैं f को कॉल कर सकता हूं उन पर

अन्य मॉड्यूल जो A और B ठोस उपप्रकार प्रदान करना चाहते हैं, उनसे f कार्यान्वयन की अपेक्षा की जानी चाहिए। आवश्यक विधियों के संयोजन विस्फोट से बचने के लिए मैं पुस्तकालय से अमूर्त प्रकारों के विरुद्ध f को परिभाषित करने की अपेक्षा करता हूं:

module N

using M

type SpecialA <: A end
type SpecialB <: B end

function M.f(a::SpecialA, b::SpecialB)
    # do stuff
end

function M.f(a::A, b::SpecialB)
    # do stuff
end

function M.f(a::SpecialA, b::B)
    # do stuff
end

export SpecialA, SpecialB

end # module N

माना जाता है कि यह उदाहरण बहुत ही काल्पनिक लगता है, लेकिन उम्मीद है कि यह दिखाता है कि (मेरे दिमाग में कम से कम) ऐसा लगता है कि कई प्रेषण और इंटरफ़ेस को लागू करने वाले एक विशेष प्रकार की अवधारणा के बीच एक मौलिक गलत मिलान है।

हालांकि मैं import भ्रम के बारे में आपकी बात देखता हूं। मुझे यह याद रखने के लिए इस उदाहरण में एक जोड़े ने कोशिश की कि जब मैंने using M डाला और फिर f विधियों को जोड़ने का प्रयास किया तो यह मेरी अपेक्षा से नहीं हुआ, और मुझे विधियों को जोड़ना पड़ा से M.f (या मैं import उपयोग कर सकता था)। मुझे नहीं लगता कि इंटरफेस उस समस्या का समाधान हैं हालांकि। क्या जोड़ने के तरीकों को और अधिक सहज बनाने के तरीकों पर विचार-मंथन करने के लिए कोई अलग मुद्दा है?

@ abe-egnor मुझे यह भी लगता है कि एक अधिक खुला दृष्टिकोण अधिक व्यवहार्य लगता है। मेरे प्रोटोटाइप #7025 में अनिवार्य रूप से दो चीजों का अभाव है:
ए) इंटरफेस को परिभाषित करने के लिए एक बेहतर वाक्यविन्यास
बी) पैरामीट्रिक प्रकार परिभाषाएं

जैसा कि मैं इतना अधिक पैरामीट्रिक प्रकार का गुरु नहीं हूं, मुझे पूरा यकीन है कि बी) गहरे अनुभव वाले किसी व्यक्ति द्वारा हल किया जा सकता है।
के संबंध में) कोई मैक्रो के साथ जा सकता है। व्यक्तिगत रूप से मुझे लगता है कि हम अमूर्त प्रकार की परिभाषा के हिस्से के रूप में इंटरफ़ेस को सीधे परिभाषित करने के लिए कुछ भाषा समर्थन खर्च कर सकते हैं। has दृष्टिकोण बहुत छोटा हो सकता है। एक कोड ब्लॉक इसे अच्छा बना सकता है। वास्तव में यह #4935 से अत्यधिक संबंधित है जहां एक "आंतरिक" इंटरफ़ेस परिभाषित किया गया है जबकि यह सार्वजनिक इंटरफ़ेस के बारे में है। इन्हें बंडल करने की आवश्यकता नहीं है क्योंकि मुझे लगता है कि यह मुद्दा #4935 से कहीं अधिक महत्वपूर्ण है। लेकिन फिर भी वाक्य रचना के अनुसार दोनों उपयोग के मामलों को ध्यान में रखना चाह सकते हैं।

https://gist.github.com/abe-egnor/503661eb4cc0d66b4489 मैंने जिस तरह के कार्यान्वयन के बारे में सोच रहा था, उस पर मेरा पहला छुरा है। संक्षेप में, एक इंटरफ़ेस एक प्रकार से एक फ़ंक्शन है जो उस इंटरफ़ेस के लिए आवश्यक कार्यों के नाम और पैरामीटर प्रकारों को परिभाषित करता है। @implement मैक्रो केवल दिए गए प्रकारों के लिए फ़ंक्शन को कॉल करता है और फिर दिए गए फ़ंक्शन परिभाषाओं में प्रकारों को विभाजित करता है, यह जांचता है कि सभी फ़ंक्शन परिभाषित किए गए हैं।

अच्छे अंक:

• इंटरफेस की परिभाषा और कार्यान्वयन के लिए सरल वाक्यविन्यास।
• ओर्थोगोनल, लेकिन अन्य भाषा सुविधाओं के साथ अच्छी तरह से खेलता है।
• इंटरफ़ेस प्रकार की गणना मनमाने ढंग से फैंसी हो सकती है (वे इंटरफ़ेस प्रकार पैरामीटर पर केवल कार्य कर रहे हैं)

बुरे संकेत:

• यदि आप पैरामीटर को इंटरफ़ेस प्रकार के रूप में उपयोग करना चाहते हैं तो पैरामीटरयुक्त प्रकारों के साथ अच्छा नहीं खेलता है। यह काफी महत्वपूर्ण नकारात्मक पहलू है, लेकिन मुझे इसे संबोधित करने का तत्काल तरीका नहीं दिख रहा है।

मुझे लगता है कि मेरे पास पैरामीटरकरण समस्या का समाधान है - संक्षेप में, इंटरफ़ेस परिभाषा एक मैक्रो ओवर टाइप एक्सप्रेशन होनी चाहिए, न कि प्रकार मानों पर फ़ंक्शन नहीं। @implement मैक्रो तब प्रकार पैरामीटर को फ़ंक्शन परिभाषाओं तक बढ़ा सकता है, जिससे कुछ ऐसा हो सकता है:

<strong i="7">@interface</strong> stack(Container, Data) begin
  stack_push!(Container, Data)
end

<strong i="8">@implement</strong> stack{T}(Vector{T}, T) begin
  stack_push!(vec, x) = push!(vec, x)
end

उस स्थिति में, प्रकार पैरामीटर इंटरफ़ेस में परिभाषित विधियों तक बढ़ाए जाते हैं, इसलिए यह stack_push!{T}(vec::Vector{T}, x::T) = push!(vec, x) फैलता है, जो मुझे लगता है कि बिल्कुल सही बात है।

जैसे ही मुझे समय मिलेगा मैं इसे करने के लिए अपने प्रारंभिक कार्यान्वयन पर फिर से काम करूंगा; शायद एक सप्ताह के आदेश पर।

https://github.com/JuliaLang/julia/pull/7695

मैंने यह देखने के लिए इंटरनेट को थोड़ा सा ब्राउज़ किया कि अन्य प्रोग्रामिंग भाषाएं इंटरफेस, विरासत और इस तरह के बारे में क्या करती हैं और कुछ विचारों के साथ आई हैं। (यदि किसी को यहां दिलचस्पी है तो मैंने https://gist.github.com/mauro3/e3e18833daf49cdf8f60 बहुत मोटे नोट लिए हैं)

इसकी कमी यह है कि शायद इंटरफेस को इसके द्वारा लागू किया जा सकता है:

• अमूर्त प्रकारों के लिए एकाधिक वंशानुक्रम की अनुमति देना, और
• अमूर्त प्रकार के क्षेत्रों के रूप में सामान्य कार्यों की अनुमति देना।

यह अमूर्त प्रकारों को इंटरफेस में बदल देगा और उस इंटरफ़ेस को लागू करने के लिए ठोस उपप्रकारों की आवश्यकता होगी।

लंबी कहानी:

मैंने जो पाया वह यह है कि कुछ "आधुनिक" भाषाएं उपप्रकार बहुरूपता से दूर होती हैं, यानी प्रकारों का कोई सीधा समूह नहीं होता है, और इसके बजाय वे इंटरफेस/विशेषता/प्रकार वर्गों से संबंधित उनके आधार पर समूह बनाते हैं। कुछ भाषाओं में, इंटरफेस / लक्षण / प्रकार की कक्षाओं में उनके बीच क्रम हो सकता है और एक दूसरे से विरासत में मिल सकता है। वे भी (ज्यादातर) उस पसंद से खुश लगते हैं। उदाहरण हैं: जाओ ,
जंग , हास्केल ।
गो तीनों में से सबसे कम सख्त है और इसके इंटरफेस को स्पष्ट रूप से निर्दिष्ट करने देता है, अर्थात यदि कोई प्रकार किसी इंटरफ़ेस के कार्यों के विशिष्ट सेट को लागू करता है तो वह उस इंटरफ़ेस से संबंधित होता है। जंग के लिए इंटरफ़ेस (लक्षण) को impl ब्लॉक में स्पष्ट रूप से लागू किया जाना चाहिए। न तो गो और न ही रस्ट के कई तरीके हैं। हास्केल में बहुविध हैं और वे वास्तव में सीधे इंटरफ़ेस (प्रकार वर्ग) से जुड़े हुए हैं।

कुछ अर्थों में यह जूलिया के समान है, अमूर्त प्रकार एक (अंतर्निहित) इंटरफ़ेस की तरह हैं, यानी वे व्यवहार के बारे में हैं न कि फ़ील्ड के बारे में। यह वही है जो @StefanKarpinski ने ऊपर की अपनी एक पोस्ट में भी देखा और कहा कि इसके अतिरिक्त इंटरफेस होने से "थोड़ा बहुत गैर-ऑर्थोगोनल लगता है।" तो, जूलिया में एक प्रकार का पदानुक्रम है (यानी उपप्रकार बहुरूपता) जबकि गो/रस्ट/हास्केल नहीं है।

सभी प्रकार के पदानुक्रम None<: ... <:Any में रखते हुए, जूलिया के अमूर्त प्रकारों को एक इंटरफ़ेस/विशेषता/प्रकार वर्ग में बदलने के बारे में कैसे? यह आवश्यक होगा:
1) (अमूर्त) प्रकारों के लिए एकाधिक वंशानुक्रम की अनुमति दें (समस्या # 5)
2) अमूर्त प्रकारों के साथ कार्यों को जोड़ने की अनुमति दें (यानी एक इंटरफ़ेस परिभाषित करें)
3) सार (यानी एक डिफ़ॉल्ट कार्यान्वयन) और ठोस प्रकार दोनों के लिए उस इंटरफ़ेस को निर्दिष्ट करने की अनुमति दें।

मुझे लगता है कि इससे हमारे पास अब की तुलना में अधिक महीन दाने वाले प्रकार का ग्राफ बन सकता है और इसे चरण दर चरण लागू किया जा सकता है। उदाहरण के लिए, एक सरणी-प्रकार को एक साथ जोड़ा जाएगा:

abstract Container  <: Iterable, Indexable, ...
end

abstract AbstractArray <: Container, Arithmetic, ...
    ...
end

abstract  Associative{K,V} <: Iterable, Indexable, Eq
    haskey :: (Associative, _) --> Bool
end

abstract Iterable{T,S}
    start :: Iterable --> S
    done  :: (Iterable,S) --> Bool
    next  :: (Iterable,S) --> (T,S)
end

abstract Indexable{A,I}
    getindex  :: (A,I) --> eltype(A)
    setindex! :: (A,I) --> A
    get! :: (A, I, eltype(A)) --> eltype(A)
    get :: (A, I, eltype(A)) --> eltype(A)
end

abstract Eq{A,B}
    == :: (A,B) --> Boolean
end
...

तो, मूल रूप से अमूर्त प्रकारों में फ़ील्ड के रूप में सामान्य कार्य हो सकते हैं (यानी एक इंटरफ़ेस बन जाते हैं) जबकि ठोस प्रकारों में केवल सामान्य फ़ील्ड होते हैं। उदाहरण के लिए यह AbstractArray से प्राप्त होने वाली बहुत सी चीजों की समस्या को हल कर सकता है, क्योंकि लोग केवल अपने कंटेनर के लिए उपयोगी टुकड़े चुन सकते हैं, जैसा कि AbstractArray से प्राप्त होने के विपरीत है।

यदि यह एक अच्छा विचार है, तो काम करने के लिए बहुत कुछ है (विशेष रूप से प्रकार और प्रकार पैरामीटर कैसे निर्दिष्ट करें), लेकिन शायद एक विचार के लायक है?

@ssfrr ने ऊपर टिप्पणी की कि इंटरफेस और एकाधिक प्रेषण असंगत हैं। ऐसा नहीं होना चाहिए, उदाहरण के लिए, हास्केल में बहुविध केवल प्रकार की कक्षाओं का उपयोग करके ही संभव है।

मैंने यह भी पाया है, जबकि पढ़ने @StefanKarpinski लेख कि सीधे का उपयोग कर abstract के बजाय interface मतलब सकता है। हालांकि इस मामले में, यह महत्वपूर्ण है कि abstract को interface एक महत्वपूर्ण संपत्ति विरासत में मिलती है: एक प्रकार की संभावना implement interface _after_ परिभाषित की जा रही है। फिर मैं अपने कोड में घोषित करके lib B से एक एल्गोरिदम algoB के साथ lib A से एक प्रकार typA का उपयोग कर सकता हूं कि typA algoB द्वारा आवश्यक इंटरफ़ेस लागू करता है (मुझे लगता है कि इसका तात्पर्य है कि ठोस प्रकारों में एक प्रकार की खुली एकाधिक विरासत होती है)।

@ मौरो 3 , मुझे वास्तव में आपका सुझाव पसंद है। मेरे लिए, यह बहुत "जूलियन" और स्वाभाविक लगता है। मुझे यह भी लगता है कि यह इंटरफेस, एकाधिक विरासत, और अमूर्त प्रकार "फ़ील्ड" का एक अद्वितीय और शक्तिशाली एकीकरण है (हालांकि, वास्तव में नहीं, क्योंकि फ़ील्ड केवल विधियां/कार्य होंगे, मान नहीं)। मुझे यह भी लगता है कि यह "आंतरिक" बनाम "बाहरी" इंटरफ़ेस विधियों को अलग करने के @StefanKarpinski के विचार के साथ अच्छी तरह से abstract Algorithm और Algorithm.sort! घोषणा करके abstract Algorithm sort! उदाहरण के लिए उनके प्रस्ताव को लागू कर सकते हैं। Algorithm.sort! ।

सभी को क्षमा करें

------------------ -------------------
: "जैकब क्विन" सूचनाएं @github.com
नंबर: 2014年9月12日(星期五) 6:23
: "जूलिया लैंग/जुलिया" [email protected];
: "लागू करें" [email protected];
: पुन: [जूलिया] सार प्रकारों के लिए इंटरफेस (#6975)

@ मौरो 3 , मुझे वास्तव में आपका सुझाव पसंद है। मेरे लिए, यह बहुत "जूलियन" और स्वाभाविक लगता है। मुझे यह भी लगता है कि यह इंटरफेस, एकाधिक विरासत, और अमूर्त प्रकार "फ़ील्ड" का एक अद्वितीय और शक्तिशाली एकीकरण है (हालांकि, वास्तव में नहीं, क्योंकि फ़ील्ड केवल विधियां/कार्य होंगे, मान नहीं)। मुझे यह भी लगता है कि यह "आंतरिक" बनाम "बाहरी" इंटरफ़ेस विधियों को अलग करने के @StefanKarpinski के विचार के साथ अच्छी तरह से

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

@implement बहुत खेद है; सुनिश्चित नहीं है कि हमने आपको कैसे पिंग किया। यदि आप पहले से नहीं जानते थे, तो आप स्क्रीन के दाईं ओर "सदस्यता समाप्त करें" बटन का उपयोग करके स्वयं को उन सूचनाओं से हटा सकते हैं।

नहीं, मैं सिर्फ इतना कहना चाहता हूं कि मैं सर्री कहने में आपकी बहुत मदद नहीं कर सकता

------------------ -------------------
: "पाओ" नोटिफिकेशन @github.com
नंबर: 2014年9月13日(星期六)晚上9:50
: "जूलिया लैंग/जुलिया" [email protected];
: "लागू करें" [email protected];
: पुन: [जूलिया] सार प्रकारों के लिए इंटरफेस (#6975)

@implement बहुत खेद है; सुनिश्चित नहीं है कि हमने आपको कैसे पिंग किया। यदि आप पहले से नहीं जानते थे, तो आप स्क्रीन के दाईं ओर "सदस्यता समाप्त करें" बटन का उपयोग करके स्वयं को उन सूचनाओं से हटा सकते हैं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

हम आपसे यह उम्मीद नहीं करते हैं! यह एक दुर्घटना थी, क्योंकि हम एक जूलिया मैक्रो के बारे में बात कर रहे हैं जिसका नाम आपके उपयोगकर्ता नाम के समान है। धन्यवाद!

मैंने अभी देखा है कि कुछ संभावित दिलचस्प विशेषताएं हैं (शायद इस मुद्दे के लिए प्रासंगिक) जंग में काम किया है: http://blog.rust-lang.org/2014/09/15/Rust-1.0.html , विशेष रूप से: https ://github.com/rust-lang/rfcs/pull/195

टीएचटीटी ("टिम होली Traits.jl । सबसे पहले, (मुझे लगता है) लक्षणों को एक या कई प्रकार के अनुबंध के रूप में देखा जाना चाहिए। इसका मतलब यह है कि इंटरफ़ेस के कार्यों को केवल एक अमूर्त प्रकार से जोड़ना, जैसा कि मैंने और अन्य ने ऊपर सुझाव दिया है, काम नहीं करता है (कम से कम कई प्रकार के गुण के सामान्य मामले में नहीं)। और दूसरा, तरीकों को प्रेषण के लिए लक्षणों का उपयोग करने में सक्षम होना चाहिए, जैसा कि @StefanKarpinski ने ऊपर सुझाव दिया है।

नफ ने कहा, यहां मेरे पैकेज Traits.jl का उपयोग करके एक उदाहरण दिया गया है:

<strong i="12">@traitdef</strong> Eq{X,Y} begin
    # note that anything is part of Eq as ==(::Any,::Any) is defined
    ==(X,Y) -> Bool
end

<strong i="13">@traitdef</strong> Cmp{X,Y} <: Eq{X,Y} begin
    isless(X,Y) -> Bool
end

यह घोषणा करता है कि Eq और Cmp प्रकार X और Y बीच अनुबंध हैं। Cmp में सुपरट्रेट के रूप में Eq , अर्थात Eq और Cmp को पूरा करने की आवश्यकता है। @traitdef बॉडी में, फ़ंक्शन हस्ताक्षर निर्दिष्ट करते हैं कि किन विधियों को परिभाषित करने की आवश्यकता है। वापसी प्रकार इस समय कुछ नहीं करते हैं। प्रकारों को स्पष्ट रूप से एक विशेषता को लागू करने की आवश्यकता नहीं है, केवल कार्यों को लागू करने से ही होगा। मैं जाँच सकता हूँ, कह सकते हैं, Cmp{Int,Float64} वास्तव में एक विशेषता है:

julia> istrait(Cmp{Int,Float64})
true

julia> istrait(Cmp{Int,String})
false

स्पष्ट विशेषता कार्यान्वयन अभी पैकेज में नहीं है, लेकिन जोड़ने के लिए काफी सरल होना चाहिए।

_trait-dispatch_ का उपयोग करने वाले फ़ंक्शन को इस प्रकार परिभाषित किया जा सकता है:

<strong i="31">@traitfn</strong> ft1{X,Y; Cmp{X,Y}}(x::X,y::Y) = x>y ? 5 : 6

यह एक फ़ंक्शन ft1 घोषित करता है जो बाधा के साथ दो तर्क लेता है कि उनके प्रकारों को Cmp{X,Y} को पूरा करने की आवश्यकता होती है। मैं किसी अन्य विशेषता पर प्रेषण की एक और विधि जोड़ सकता हूं:

<strong i="37">@traitdef</strong> MyT{X,Y} begin
    foobar(X,Y) -> Bool
end
# and implement it for a type:
type A
    a
end
foobar(a::A, b::A) = a.a==b.a

<strong i="38">@traitfn</strong> ft1{X,Y; MyT{X,Y}}(x::X,y::Y) = foobar(x,y) ? -99 : -999

इन विशेषता-कार्यों को अब सामान्य कार्यों की तरह ही कहा जा सकता है:

julia> ft1(4,5)
6

julia> ft1(A(5), A(6))
-999

बाद में किसी विशेषता में अन्य प्रकार जोड़ना आसान है (जो कि ft1 के लिए Unions का उपयोग करने के मामले में नहीं होगा):

julia> ft1("asdf", 5)
ERROR: TraitException("No matching trait found for function ft1")
 in _trait_type_ft1 at

julia> foobar(a::String, b::Int) = length(a)==b  # adds {String, Int} to MyTr
foobar (generic function with 2 methods)

julia> ft1("asdf", 5)
-999

विशेषता कार्यों का _कार्यान्वयन_ और उनका प्रेषण टिम की चाल और मंचित कार्यों पर आधारित है, नीचे देखें। विशेषता परिभाषा अपेक्षाकृत तुच्छ है, सभी के मैन्युअल कार्यान्वयन के लिए यहां देखें।

संक्षेप में, विशेषता प्रेषण बदल जाता है

<strong i="51">@traitfn</strong> f{X,Y; Trait1{X,Y}}(x::X,y::Y) = x+y

कुछ इस तरह में (थोड़ा सरलीकृत)

f(x,y) = _f(x,y, checkfn(x,y))
_f{X,Y}(x::X,y::Y,::Type{Trait1{X,Y}}) = x+y
# default
checkfn{T,S}(x::T,y::S) = error("Function f not implemented for type ($T,$S)")
# add types-tuples to Trait1 by modifying the checkfn function:
checkfn(::Int, ::Int) = Trait1{Int,Int}
f(1,2) # 3

पैकेज में, checkfn की पीढ़ी को stagedfuncitons द्वारा स्वचालित किया जाता है। लेकिन अधिक जानकारी के लिए Traits.jl का README देखें।

_Performance_ सरल विशेषता-कार्यों के लिए उत्पादित मशीन कोड उनके बतख-टाइप समकक्षों के समान होता है, यानी जितना अच्छा हो उतना अच्छा होता है। लंबे कार्यों के लिए, लंबाई में ~ 20% तक अंतर होता है। मुझे यकीन नहीं है कि जैसा मैंने सोचा था कि यह सब रेखांकित किया जाना चाहिए।

( Traits.jl में मामूली बदलावों को दर्शाने के लिए 27 अक्टूबर को संपादित)

क्या Traits.jl पैकेज तलाशने के लिए तैयार है? रीडमी कहता है " @traitimpl के साथ इंटरफेस लागू करें (अभी तक नहीं किया गया ...)" - क्या यह एक महत्वपूर्ण कमी है?

यह खोज के लिए तैयार है (बग सहित :-)। लापता @traitimpl अर्थ है कि इसके बजाय

<strong i="7">@traitimpl</strong> Cmp{T1, T2} begin
   isless(t1::T1, t2::T2) = t1.t < t2.f
end

आप केवल फ़ंक्शन को मैन्युअल रूप से परिभाषित करते हैं

Base.isless(t1::T1, t2::T2) = t1.t < t2.f

आपके दो प्रकारों के लिए T1 और T2 ।

मैंने @traitimpl मैक्रो जोड़ा, इसलिए उपरोक्त उदाहरण अब काम करता है। मैंने उपयोग के विवरण के साथ README को भी अपडेट किया। और मैंने @lindahua Graphs.jl इंटरफ़ेस के हिस्से को लागू करने वाला एक उदाहरण जोड़ा:
https://github.com/mauro3/Traits.jl/blob/master/examples/ex_graphs.jl

यह वास्ताव में अच्छा है। मुझे विशेष रूप से यह पसंद है कि यह पहचानता है कि सामान्य रूप से इंटरफेस प्रकार के टुपल्स की संपत्ति हैं, व्यक्तिगत प्रकार नहीं।

मुझे यह भी बहुत अच्छा लगता है। इस दृष्टिकोण के बारे में पसंद करने के लिए बहुत कुछ है। अच्छा काम।

:+1:

अच्छी प्रतिक्रिया के लिए धन्यवाद! मैंने कोड को थोड़ा सा अपडेट/रिफैक्टर किया और इसे उचित रूप से बग-मुक्त और खेलने के लिए अच्छा होना चाहिए।
इस बिंदु पर यह शायद अच्छा होगा, अगर लोग यह देखने के लिए इसे एक स्पिन दे सकते हैं कि यह उनके उपयोग के मामलों में फिट बैठता है या नहीं।

यह उन पैकेजों में से एक है जो किसी को अपने कोड को नई रोशनी में देखता है। बहुत ही शांत।

क्षमा करें, मेरे पास अभी तक इसे गंभीरता से देखने का समय नहीं है, लेकिन मुझे पता है कि एक बार ऐसा करने के बाद मैं कुछ सामानों को दोबारा करना चाहता हूं ...

मैं अपने पैकेज भी दोबारा कर दूंगा :)

मैं सोच रहा था, मुझे ऐसा लगता है कि यदि लक्षण उपलब्ध हैं (और ऊपर दिए गए सुझाव की तरह एकाधिक प्रेषण की अनुमति देते हैं) तो एक अमूर्त प्रकार पदानुक्रम तंत्र, या अमूर्त प्रकारों की कोई आवश्यकता नहीं है। ऐसा हो सकता है?

लक्षणों के आधार पर प्रत्येक कार्य को लागू करने के बाद और बाद में पूरे पारिस्थितिकी तंत्र में अंततः पूरी तरह से लक्षणों पर आधारित एक सार्वजनिक एपीआई का पर्दाफाश होगा, और अमूर्त प्रकार गायब हो जाएंगे। बेशक अमूर्त प्रकारों को हटाकर प्रक्रिया को उत्प्रेरित किया जा सकता है

इस पर थोड़ा और विचार करते हुए, अमूर्त प्रकारों को लक्षणों द्वारा प्रतिस्थापित करने के लिए इस तरह के पैरामीट्रिजिंग प्रकारों की आवश्यकता होगी:

Array{X; Cmp{X}} # an array of comparables
myvar::Type{X; Cmp{X}} # just a variable which is comparable

मैं उपरोक्त मौरो 3 बिंदु से सहमत हूं, जिसमें लक्षण हैं (उनकी परिभाषा के अनुसार, जो मुझे लगता है कि बहुत अच्छा है) अमूर्त प्रकारों के बराबर है जो

• एकाधिक विरासत की अनुमति दें, और
• सामान्य कार्यों को फ़ील्ड के रूप में अनुमति दें

मैं यह भी जोड़ूंगा कि लक्षणों को उनकी परिभाषा के बाद प्रकारों को असाइन करने की अनुमति देने के लिए किसी को "आलसी विरासत" की अनुमति देने की भी आवश्यकता होगी यानी संकलक को यह बताने के लिए कि एक प्रकार को परिभाषित करने के बाद कुछ सार प्रकार से विरासत में मिला है।

तो सब कुछ मुझे लगता है कि अमूर्त प्रकारों के बाहर कुछ विशेषता/इंटरफ़ेस अवधारणा विकसित करना कुछ दोहराव को प्रेरित करेगा, एक ही चीज़ को प्राप्त करने के विभिन्न तरीकों को पेश करेगा। अब मुझे लगता है कि इन अवधारणाओं को पेश करने का सबसे अच्छा तरीका धीरे-धीरे अमूर्त प्रकारों में सुविधाओं को जोड़ना है

संपादित करें : निश्चित रूप से किसी बिंदु पर अमूर्त लोगों से ठोस प्रकार विरासत में लेना होगा और अंत में अस्वीकृत होना चाहिए। प्रकार के लक्षण स्पष्ट रूप से या स्पष्ट रूप से निर्धारित किए जाएंगे लेकिन विरासत से कभी नहीं

क्या अमूर्त प्रकार केवल लक्षणों का "उबाऊ" उदाहरण नहीं हैं?

यदि हां, तो क्या वर्तमान वाक्य-विन्यास को बनाए रखना संभव हो सकता है और बस इसके अर्थ को विशेषता में बदलना संभव हो सकता है (यदि उपयोगकर्ता इसे चाहता है तो ओर्टोगोनल स्वतंत्रता आदि देना)?

_मुझे आश्चर्य है कि क्या यह Point{Float64} <: Pointy{Real} उदाहरण को भी संबोधित करने में सक्षम हो सकता है (सुनिश्चित नहीं है कि कोई समस्या संख्या है या नहीं)?_

हाँ, मुझे लगता है कि तुम सही हो। वर्तमान जूलिया अमूर्त प्रकारों को बढ़ाकर विशेषता कार्यक्षमता प्राप्त की जा सकती है। उन्हें जरूरत है
1) एकाधिक विरासत
2) फंक्शन सिग्नेचर
3) "आलसी विरासत", पहले से परिभाषित प्रकार को स्पष्ट रूप से एक नया गुण देने के लिए

ऐसा लगता है कि बहुत सारे काम हैं, लेकिन हो सकता है कि इसे समुदाय के लिए बहुत अधिक टूट-फूट के बिना धीरे-धीरे विकसित किया जा सके। तो कम से कम हमें वह मिल गया;)

मुझे लगता है कि हम जो भी चुनेंगे वह एक बड़ा बदलाव होगा, एक जिसे हम 0.4 में काम शुरू करने के लिए तैयार नहीं हैं। अगर मुझे अनुमान लगाना होता, तो मैं दांव लगाता कि हम पारंपरिक कई विरासतों को जोड़ने की दिशा में लक्षणों की दिशा में आगे बढ़ने की अधिक संभावना रखते हैं। लेकिन मेरी क्रिस्टल बॉल फ़्रिट्ज़ पर है, इसलिए यह सुनिश्चित करना मुश्किल है कि बिना कोशिश किए क्या होगा।

एफडब्ल्यूआईडब्ल्यू, मैंने साइमन पेटन-जोन्स की टाइपक्लास की चर्चा को नीचे की बातचीत में वास्तव में जानकारीपूर्ण पाया कि सबटाइपिंग के बदले लक्षणों की तरह कुछ कैसे उपयोग किया जाए: http://research.microsoft.com/en-us/um/people/simonpj/ पेपर्स/हास्केल-रेट्रोस्पेक्टिव/ईसीओओपी-जुलाई09.पीडीएफ

हाँ, कीड़े की एक पूरी कैन!

@johnmyleswhite , लिंक के लिए धन्यवाद, बहुत दिलचस्प। यहां इसके वीडियो का लिंक दिया गया है, जो अंतराल को भरने के लिए देखने लायक है। ऐसा लगता है कि यह प्रस्तुति हमें यहां मिले बहुत सारे प्रश्नों पर स्पर्श करती है। और दिलचस्प बात यह है कि टाइप-क्लास का कार्यान्वयन काफी हद तक Traits.jl (टिम की चाल, डेटाटाइप होने के लक्षण) के समान है। हास्केल का https://www.haskell.org/haskellwiki/Multi-parameter_type_class बहुत कुछ Traits.jl जैसा है। बातचीत में उनका एक सवाल है: "एक बार जब हमने पूरे दिल से जेनरिक को अपनाया, तो क्या हमें वास्तव में सबटाइपिंग की ज़रूरत है।" (जेनेरिक पैरामीट्रिक-पॉलीमॉर्फिक फ़ंक्शंस हैं, मुझे लगता है, देखें ) जो कि @skariel और @hayd ऊपर के बारे में सोच रहे हैं।

@skariel और @hayd का जिक्र करते हुए, मुझे लगता है कि एकल पैरामीटर लक्षण (जैसे Traits.jl में) वास्तव में अमूर्त प्रकारों के बहुत करीब हैं, सिवाय इसके कि उनके पास एक और पदानुक्रम हो सकता है, यानी एकाधिक विरासत।

लेकिन मल्टी-पैरामीटर लक्षण थोड़े अलग लगते हैं, कम से कम वे मेरे दिमाग में थे। जैसा कि मैंने उन्हें देखा, अमूर्त प्रकारों के टाइप-पैरामीटर ज्यादातर इस बारे में प्रतीत होते हैं कि एक प्रकार के भीतर अन्य प्रकार क्या निहित हैं, उदाहरण के लिए, Associative{Int,String} कहता है कि ताना में Int कुंजियाँ और String मान। जबकि Tr{Associative,Int,String}... कहना है कि Associative , Int s और Strings बीच कुछ "अनुबंध" है। लेकिन फिर, शायद Associative{Int,String} को भी इस तरह से पढ़ा जाना चाहिए, यानी getindex(::Associative, ::Int) -> String , setindex!(::Associative, ::Int, ::String) जैसी विधियां हैं ...

@ मौरो 3 महत्वपूर्ण बात यह होगी कि किसी फ़ंक्शन के तर्क के रूप में Associative प्रकार की वस्तुओं को पास किया जाए, ताकि वह तब Associative{Int,String} स्वयं बना सके:

function f(A::Associative)
  a = A{Int,String}()  # create new associative
  a[1] = "one"
  return a
end

आप इसे उदाहरण के लिए f(Dict) कहेंगे।

@eschnett , क्षमा करें, मुझे समझ में नहीं आता कि आपका क्या मतलब है।

@ मौरो 3 मुझे लगता है कि मैं बहुत जटिल तरीके से सोच रहा था; मुझपर ध्यान मत दो।

मैंने इसके साथ Traits.jl को अपडेट किया:

• विशेषता अस्पष्टताओं का समाधान
• संबद्ध प्रकार
• सहायता के लिए @doc का उपयोग करना
• विशेषता-कल्पना विधियों का बेहतर परीक्षण

विवरण के लिए https://github.com/mauro3/Traits.jl/blob/master/NEWS.md देखें। प्रतिक्रिया का स्वागत है!

@ रोरी-फिननेगन ने एक इंटरफेस पैकेज https://github.com/Rory-Finnegan/Interfaces.jl को एक साथ रखा

मैंने हाल ही में @mdcfrancis के साथ इस पर चर्चा की और हमें लगता है कि

protocol Iterable
    start(::_)
    done(::_, state)
    next(::_, state)
end

और हमारे पास isa(Iterable, Protocol) और Protocol <: Type । स्वाभाविक रूप से, आप इन पर प्रेषण कर सकते हैं। आप जांच सकते हैं कि एक प्रकार T <: Iterable का उपयोग करके प्रोटोकॉल लागू करता है या नहीं।

यहाँ सबटाइपिंग नियम हैं:

P, Q को प्रोटोकॉल प्रकार होने दें
टी को एक गैर-प्रोटोकॉल प्रकार होने दें

| इनपुट | परिणाम |
| --- | --- |
| पी <: कोई भी | सच |
| नीचे <: पी | सच |
| (संघ, संघ, वर) <: पी | सामान्य नियम का उपयोग करें; पी को आधार प्रकार के रूप में मानें |
| पी <: (संघ, संघ, वर) | सामान्य नियम का प्रयोग करें |
| पी <: पी | सच |
| पी <: क्यू | जाँच विधियाँ (Q) <: विधियाँ (P) |
| पी <: टी | झूठा |
| टी <: पी | P की विधियाँ _ | . के स्थान पर T के साथ मौजूद हैं

आखिरी वाला बड़ा है: टी <: पी का परीक्षण करने के लिए, आप पी की परिभाषा में _ के लिए टी को प्रतिस्थापित करते हैं और प्रत्येक हस्ताक्षर के लिए method_exists करते हैं। बेशक, इसका मतलब है कि फॉलबैक परिभाषाएं जो फेंकती हैं "आपको इसे लागू करना होगा" त्रुटियां बहुत बुरी चीज बन जाती हैं। उम्मीद है कि यह एक कॉस्मेटिक समस्या का अधिक है।

एक और समस्या यह है कि यह परिभाषा परिपत्र है यदि उदाहरण के लिए start(::Iterable) परिभाषित किया गया है। ऐसी परिभाषा का वास्तव में कोई मतलब नहीं है। हम किसी तरह इसे रोक सकते हैं, या सबटाइप चेकिंग के दौरान इस चक्र का पता लगा सकते हैं। मुझे 100% यकीन नहीं है कि सरल चक्र पहचान इसे ठीक करती है, लेकिन यह व्यावहारिक लगता है।

चौराहे के प्रकार के लिए हमारे पास है:

| इनपुट | परिणाम |
| --- | --- |
| पी (संघ, Unionall, tvar) | सामान्य नियम का प्रयोग करें |
| पी ∩ क्यू | पी |
| पी टी | टी |

P Q के लिए कुछ विकल्प हैं:

1. पी या क्यू को वापस करके अधिक अनुमानित (उदाहरण के लिए जो भी पहले शब्दावली है)। यह प्रकार के अनुमान के संबंध में ध्वनि है, लेकिन कहीं और कष्टप्रद हो सकता है।
2. एक नया एड-हॉक प्रोटोकॉल लौटाएं जिसमें पी और क्यू में हस्ताक्षरों का संघ शामिल है।
3. चौराहे के प्रकार। शायद केवल प्रोटोकॉल तक ही सीमित है।

पी ∩ टी मुश्किल है। T एक अच्छा रूढ़िवादी सन्निकटन है, क्योंकि गैर-प्रोटोकॉल प्रकार प्रोटोकॉल प्रकारों की तुलना में "छोटे" होते हैं, इस अर्थ में कि वे आपको पदानुक्रम के एक क्षेत्र तक सीमित रखते हैं, जबकि प्रोटोकॉल प्रकार नहीं होते हैं (चूंकि कोई भी प्रकार किसी भी प्रोटोकॉल को लागू कर सकता है) ) ऐसा लगता है कि इससे बेहतर करने के लिए सामान्य चौराहे के प्रकारों की आवश्यकता होती है, जिसे मैं प्रारंभिक कार्यान्वयन में टालना चाहूंगा क्योंकि इसके लिए सबटाइपिंग एल्गोरिदम को ओवरहाल करने की आवश्यकता होती है, और वर्म-कैन के बाद वर्म-कैन खोलता है।

विशिष्टता: P केवल Q से अधिक विशिष्ट है जब P<:Q। लेकिन चूंकि पी ∩ क्यू हमेशा गैर-रिक्त होता है, एक ही स्लॉट में विभिन्न प्रोटोकॉल के साथ परिभाषाएं अक्सर अस्पष्ट होती हैं, जो ऐसा लगता है कि आप क्या चाहते हैं (उदाहरण के लिए आप कहेंगे "अगर एक्स इटेबल है तो ऐसा करें, लेकिन अगर एक्स प्रिंट करने योग्य है तो करें वह")।
हालांकि आवश्यक असंबद्ध परिभाषा को व्यक्त करने का कोई आसान तरीका नहीं है, इसलिए यह शायद एक त्रुटि होनी चाहिए।

#13412 के बाद, एक प्रोटोकॉल को UnionAll _ के रूप में टपल प्रकार के संघ पर "एन्कोडेड" किया जा सकता है (जहां प्रत्येक आंतरिक टपल का पहला तत्व प्रश्न में फ़ंक्शन का प्रकार है)। यह उस डिज़ाइन का एक लाभ है जो मुझे पहले नहीं हुआ था। उदाहरण के लिए, प्रोटोकॉल का संरचनात्मक उपप्रकार स्वतः ही समाप्त हो जाता है।

बेशक, ये प्रोटोकॉल "एकल पैरामीटर" शैली हैं। मुझे इसकी सादगी पसंद है, साथ ही मुझे यकीन नहीं है कि प्रकारों के समूहों को सुरुचिपूर्ण ढंग से कैसे संभालना है T <: Iterable ।

अतीत में इस विचार के बारे में कुछ टिप्पणियां थीं, x-ref https://github.com/JuliaLang/julia/issues/5#issuecomment -37995516।

क्या हम समर्थन करेंगे, उदा

protocol Iterable{T}
    start(::_)::T
    done(::_, state::T)
    next(::_, state::T)
end

वाह, मुझे वास्तव में यह पसंद है (विशेषकर @ केनो के विस्तार के साथ)!

+1 यह वही है जो मैं चाहता हूँ!

@ केनो इस सुविधा के लिए निश्चित रूप से एक अच्छा अपग्रेड पथ है, लेकिन इसे स्थगित करने के कारण हैं। रिटर्न प्रकार से जुड़ी कोई भी चीज निश्चित रूप से बहुत ही समस्याग्रस्त है। पैरामीटर स्वयं अवधारणात्मक रूप से ठीक है और यह बहुत बढ़िया होगा, लेकिन इसे लागू करना थोड़ा मुश्किल है। इसके लिए प्रक्रिया के चारों ओर एक प्रकार का वातावरण बनाए रखने की आवश्यकता होती है जो सभी विधियों के अस्तित्व की जाँच करता है।

ऐसा लगता है कि आप इस योजना में लक्षणों में जूता-सींग (जैसे ओ (1) सरणी-जैसी प्रकारों के लिए रैखिक अनुक्रमण) कर सकते हैं। आप hassomeproperty(::T) = true (लेकिन _not_ hassomeproperty(::Any) = false ) जैसी एक डमी विधि परिभाषित करेंगे और उसके बाद

protocol MyProperty
hassomeproperty(::_)
end

क्या _ प्रोटोकॉल परिभाषा में एक ही विधि में कई बार प्रकट हो सकता है, जैसे

protocol Comparable
  >(::_, ::_)
  =(::_, ::_0
end

प्रोटोकॉल परिभाषा में एक ही विधि में _ कई बार प्रकट हो सकता है

हां। आप _ के प्रत्येक उदाहरण के लिए उम्मीदवार प्रकार को छोड़ दें।

@JeffBezanson वास्तव में इसके लिए तत्पर हैं। मेरे लिए विशेष रूप से नोट प्रोटोकॉल की 'दूरस्थता' है। उसमें मैं प्रोटोकॉल के अस्तित्व के बारे में किसी भी प्रकार के लेखक के बिना एक प्रकार के लिए एक विशिष्ट/कस्टम प्रोटोकॉल लागू कर सकता हूं।

इस तथ्य के बारे में क्या है कि विधियों को किसी भी समय गतिशील रूप से परिभाषित किया जा सकता है (उदाहरण के लिए @eval )? फिर क्या कोई प्रकार किसी दिए गए प्रोटोकॉल का उप-प्रकार है जो सामान्य रूप से स्थिर रूप से जानने योग्य नहीं है, जो कई मामलों में गतिशील प्रेषण से बचने वाले अनुकूलन को हराने के लिए प्रतीत होता है।

हां, यह #265 को बदतर बना देता है :) यह वही मुद्दा है जहां तरीकों को जोड़ने पर प्रेषण और जेनरेट कोड को बदलने की जरूरत है, बस अधिक निर्भरता किनारों के साथ।

इसे आगे बढ़ते हुए देखना अच्छा है! बेशक, मैं तर्क दूंगा कि बहु-पैरामीटर लक्षण आगे का रास्ता हैं। लेकिन 95% लक्षण शायद वैसे भी एकल पैरामीटर होंगे। यह सिर्फ इतना है कि वे कई प्रेषण के साथ इतनी अच्छी तरह फिट होंगे! जरूरत पड़ने पर इसे बाद में फिर से देखा जा सकता है। पर्याप्त कथन।

टिप्पणियों की एक जोड़ी:

@ केनो (और वास्तव में जेफ के मूल में state ) के सुझाव को संबद्ध प्रकार के रूप में जाना जाता है। ध्यान दें कि वे रिटर्न प्रकारों के बिना भी उपयोगी हैं। जंग में एक अच्छी मैनुअल प्रविष्टि है । मुझे लगता है कि वे एक अच्छे विचार हैं, हालांकि रस्ट के रूप में आवश्यक नहीं हैं। मुझे नहीं लगता कि यह विशेषता का पैरामीटर होना चाहिए: Iterable पर प्रेषण फ़ंक्शन को परिभाषित करते समय मुझे नहीं पता कि T है।

मेरे अनुभव में, method_exists इस (#8959) के लिए अपने वर्तमान स्वरूप में अनुपयोगी है। लेकिन संभवत: यह #8974 (या इसके साथ) में ठीक हो जाएगा। मैंने विशेषता-हस्ताक्षर के खिलाफ मिलान विधि हस्ताक्षर को Traits.jl करते समय सबसे कठिन हिस्सा पाया, विशेष रूप से पैरामीटरयुक्त और vararg कार्यों के लिए खाते ( देखें )।

संभवतः विरासत भी संभव होगी?

मैं वास्तव में एक तंत्र देखना चाहता हूं जो डिफ़ॉल्ट कार्यान्वयन की परिभाषा की अनुमति देता है। क्लासिक एक यह है कि तुलना के लिए आपको केवल = , < , > , <= , >= दो को परिभाषित करने की आवश्यकता है। शायद यही वह जगह है जहां जेफ द्वारा उल्लिखित चक्र वास्तव में उपयोगी है। उपरोक्त उदाहरण को जारी रखते हुए, start(::Indexable) = 1 और done(i::Indexable,state)=length(i)==state को परिभाषित करने से वे डिफ़ॉल्ट बन जाएंगे। इस प्रकार कई प्रकारों को केवल next को परिभाषित करने की आवश्यकता होगी।

अच्छे अंक। मुझे लगता है कि संबंधित प्रकार Iterable{T} में पैरामीटर से कुछ अलग हैं। मेरे एन्कोडिंग में, पैरामीटर केवल अंदर सब कुछ पर मौजूद होगा --- "क्या कोई टी मौजूद है जैसे कि फू इस प्रोटोकॉल को लागू करता है?"।

हां, ऐसा लगता है कि हम आसानी से protocol Foo <: Bar, Baz अनुमति दे सकते हैं, और बस बार और बाज से हस्ताक्षर को फू में कॉपी कर सकते हैं।

बहु-पैरामीटर लक्षण निश्चित रूप से शक्तिशाली हैं। मुझे लगता है कि यह सोचना बहुत दिलचस्प है कि उन्हें सबटाइपिंग के साथ कैसे एकीकृत किया जाए। आपके पास TypePair{A,B} <: Trait जैसा कुछ हो सकता है, लेकिन यह बिल्कुल सही नहीं लगता।

मुझे लगता है कि आपका प्रस्ताव (सुविधाओं के संदर्भ में) वास्तव में क्लोजर की तुलना में स्विफ्ट की तरह है।

नाममात्र (प्रकार) और संरचनात्मक (प्रोटोकॉल) सबटाइपिंग (लेकिन मुझे लगता है कि यह अपरिहार्य है) मिश्रण करने के लिए यह अजीब लगता है (और मुझे लगता है कि भविष्य के भ्रम का स्रोत)।

मैं मैथ/मैट्रिक्स संचालन के लिए प्रोटोकॉल की अभिव्यंजक शक्ति पर भी थोड़ा संदेह करता हूं। मुझे लगता है कि अधिक जटिल उदाहरणों (मैट्रिक्स ऑपरेशंस) के माध्यम से सोचना इटरेशन से अधिक ज्ञानवर्धक होगा जिसमें स्पष्ट रूप से निर्दिष्ट इंटरफ़ेस है। उदाहरण के लिए core.matrix लाइब्रेरी देखें।

मैं सहमत हूँ; इस बिंदु पर हमें प्रोटोकॉल के उदाहरण एकत्र करने चाहिए और देखना चाहिए कि क्या वे वही करते हैं जो हम चाहते हैं।

जिस तरह से आप इसकी कल्पना कर रहे हैं, क्या प्रोटोकॉल नामस्थान होंगे जो उनके तरीकों से संबंधित हैं? यानी जब आप लिखते हैं

protocol Iterable
    start(::_)
    done(::_, state)
    next(::_, state)
end

इसके लिए सामान्य कार्यों को परिभाषित करना start , done और next और उनके पूरी तरह से योग्य नामों के लिए Iterable.start , Iterable.done होना स्वाभाविक प्रतीत होगा। Iterable.next । एक प्रकार Iterable लागू करेगा लेकिन Iterable प्रोटोकॉल में सभी सामान्य कार्यों को लागू करेगा। मैंने कुछ समय पहले इसी तरह का कुछ प्रस्तावित किया था (अब इसे नहीं ढूंढ सकता), लेकिन दूसरी तरफ यह है कि जब आप प्रोटोकॉल लागू करना चाहते हैं, तो आप यह करते हैं:

implement T <: Iterable
    # in here `start`, `done` and `next` are automatically imported
    start(x::T) = something
    done(x::T, state) = whatever
    next(x::T, state) = etcetera, nextstate
end

यह " दूरस्थता " का विरोध करेगा @mdcfrancis ने किया है, अगर मैं इसे समझ रहा हूं, लेकिन फिर, मुझे प्रोटोकॉल को "गलती से" लागू करने में सक्षम होने का लाभ वास्तव में नहीं दिखता है। क्या आप विस्तार से बता सकते हैं कि आपको क्यों लगता है कि यह फायदेमंद है, @mdcfrancis? मुझे पता है कि गो इसमें से बहुत कुछ बनाता है, लेकिन ऐसा लगता है क्योंकि गो डक टाइपिंग नहीं कर सकता, जो जूलिया कर सकती है। मुझे लगता है कि होने implement ब्लॉक का उपयोग करने के लिए लगभग सभी जरूरतों को खत्म करेगा import के बजाय using , व्यापक सुधार होगा।

मैंने कुछ समय पहले इसी तरह का कुछ प्रस्तावित किया था (अब इसे नहीं ढूंढ सकता)

शायद https://github.com/JuliaLang/julia/issues/6975#issuecomment -44502467 और इससे पहले https://github.com/quinnj/Datetime.jl/issues/27#issuecomment -31305128? (संपादित करें: इसके अलावा https://github.com/JuliaLang/julia/issues/6190#issuecomment-37932021।)

हाँ, बस इतना ही।

@StefanKarpinski त्वरित टिप्पणियाँ,

• वर्तमान में चलने योग्य सभी वर्गों को प्रोटोकॉल को स्पष्ट रूप से लागू करने के लिए संशोधित करना होगा यदि हम आपके प्रस्ताव के अनुसार करते हैं, तो वर्तमान प्रस्ताव केवल आधार को परिभाषा जोड़कर प्रोटोकॉल में सभी मौजूदा वर्गों को 'लिफ्ट' करेगा।
• अगर मैं MyModule.MySuperIterable को परिभाषित करता हूं जो चलने योग्य परिभाषा में एक अतिरिक्त फ़ंक्शन जोड़ता है तो मुझे एक अतिरिक्त विधि जोड़ने के बजाय प्रत्येक वर्ग के लिए बहुत सारे बॉयलर प्लेट कोड लिखना होगा।
• मुझे नहीं लगता कि आप जो प्रस्ताव देते हैं वह दूरदर्शिता का प्रतिकार करता है, इसका सीधा सा मतलब है कि मुझे उसी लक्ष्य को प्राप्त करने के लिए बहुत सारे अतिरिक्त कोड लिखने होंगे।

यदि प्रोटोकॉल पर किसी प्रकार की विरासत की अनुमति दी गई थी, MySuperIterabe,
मौजूदा तरीकों का पुन: उपयोग करने के लिए बेस.इटरेबल का विस्तार कर सकता है।

मुद्दा यह होगा कि यदि आप केवल तरीकों का चयन करना चाहते हैं a
प्रोटोकॉल, लेकिन ऐसा प्रतीत होता है कि मूल प्रोटोकॉल को होना चाहिए
शुरू से एक समग्र प्रोटोकॉल हो।

@mdcfrancis - पहला बिंदु एक अच्छा है, हालांकि जो मैं प्रस्तावित कर रहा हूं वह किसी भी मौजूदा कोड को नहीं

क्या आप MyModule.MySuperIterable पॉइंट पर विस्तार कर सकते हैं? मैं नहीं देख रहा हूं कि अतिरिक्त वर्बोसिटी कहां से आती है। आपके पास ऐसा कुछ हो सकता है, उदाहरण के लिए:

protocol Enumerable <: Iterable
    # inherits start, next and done; adds the following:
    length(::_) # => Integer
end

जो अनिवार्य रूप से @ivarne ने कहा है।

उपरोक्त मेरे विशिष्ट डिज़ाइन में, प्रोटोकॉल नामस्थान नहीं हैं, केवल अन्य प्रकारों और कार्यों के बारे में बयान हैं। हालांकि यह शायद इसलिए है क्योंकि मैं कोर टाइप सिस्टम पर ध्यान केंद्रित कर रहा हूं। मैं सिंटैक्स चीनी की कल्पना कर सकता हूं जो मॉड्यूल और प्रोटोकॉल के संयोजन तक फैलती है, उदाहरण के लिए

module Iterable

function start end
function done end
function next end

jeff_protocol the_protocol
    start(::_)
    done(::_, state)
    next(::_, state)
end

end

फिर उन संदर्भों में जहां Iterable को एक प्रकार के रूप में माना जाता है, हम Iterable.the_protocol ।

मुझे यह दृष्टिकोण पसंद है क्योंकि jeff/mdcfrancis प्रोटोकॉल यहां बाकी सभी चीजों के लिए बहुत ही ऑर्थोगोनल महसूस करते हैं। जब तक आप मुझे "जूलियन" महसूस नहीं करना चाहते, तब तक "एक्स इम्प्लीमेंट्स प्रोटोकॉल वाई" कहने की आवश्यकता नहीं है।

मुझे नहीं पता कि मैंने इस मुद्दे को क्यों सब्सक्राइब किया और कब किया। लेकिन ऐसा होता है कि यह प्रोटोकॉल प्रस्ताव मेरे द्वारा यहां उठाए गए प्रश्न का समाधान कर सकता

मेरे पास तकनीकी आधार पर जोड़ने के लिए कुछ नहीं है, लेकिन जूलिया में जंगली में इस्तेमाल होने वाले "प्रोटोकॉल" के उदाहरण के रूप में (प्रकार) एक सॉल्वर की कार्यक्षमता का निर्धारण करने वाला JuMP होगा, उदाहरण के लिए:

https://github.com/JuliaOpt/JuMP.jl/blob/master/src/solvers.jl#L223 -L246

        # If we already have an MPB model for the solver...
        if m.internalModelLoaded
            # ... and if the solver supports updating bounds/objective
            if applicable(MathProgBase.setvarLB!, m.internalModel, m.colLower) &&
               applicable(MathProgBase.setvarUB!, m.internalModel, m.colUpper) &&
               applicable(MathProgBase.setconstrLB!, m.internalModel, rowlb) &&
               applicable(MathProgBase.setconstrUB!, m.internalModel, rowub) &&
               applicable(MathProgBase.setobj!, m.internalModel, f) &&
               applicable(MathProgBase.setsense!, m.internalModel, m.objSense)
                MathProgBase.setvarLB!(m.internalModel, copy(m.colLower))
                MathProgBase.setvarUB!(m.internalModel, copy(m.colUpper))
                MathProgBase.setconstrLB!(m.internalModel, rowlb)
                MathProgBase.setconstrUB!(m.internalModel, rowub)
                MathProgBase.setobj!(m.internalModel, f)
                MathProgBase.setsense!(m.internalModel, m.objSense)
            else
                # The solver doesn't support changing bounds/objective
                # We need to build the model from scratch
                if !suppress_warnings
                    Base.warn_once("Solver does not appear to support hot-starts. Model will be built from scratch.")
                end
                m.internalModelLoaded = false
            end
        end

कूल, यह उपयोगी है। क्या यह m.internalModel लिए पर्याप्त है जो प्रोटोकॉल को लागू करता है, या दोनों तर्क महत्वपूर्ण हैं?

हां, प्रोटोकॉल को लागू करने के लिए m.internalModel लिए यह पर्याप्त है। अन्य तर्क ज्यादातर सिर्फ वैक्टर हैं।

हां, प्रोटोकॉल को लागू करने के लिए m.internalModel लिए पर्याप्त है

जंगली में प्रोटोकॉल के उदाहरण खोजने का एक अच्छा तरीका शायद applicable और method_exists कॉल की खोज करना है।

अमृत भी प्रोटोकॉल को लागू करने लगता है, लेकिन मानक पुस्तकालय में प्रोटोकॉल की संख्या (परिभाषा से हटकर) काफी सीमित लगती है।

प्रोटोकॉल और अमूर्त प्रकारों के बीच क्या संबंध होगा? मूल समस्या विवरण ने प्रोटोकॉल को एक सार प्रकार से जोड़ने जैसा कुछ प्रस्तावित किया। वास्तव में, मुझे ऐसा लगता है कि अधिकांश (अब अनौपचारिक) प्रोटोकॉल वर्तमान में अमूर्त प्रकारों के रूप में लागू किए गए हैं। जब प्रोटोकॉल के लिए समर्थन जोड़ा जाता है तो अमूर्त प्रकारों का क्या उपयोग किया जाएगा? अपने एपीआई घोषित करने के किसी भी तरीके के बिना एक प्रकार का पदानुक्रम बहुत उपयोगी नहीं लगता है।

बहुत अच्छा प्रश्न। वहां बहुत सारे विकल्प हैं। सबसे पहले, यह इंगित करना महत्वपूर्ण है कि अमूर्त प्रकार और प्रोटोकॉल काफी ऑर्थोगोनल हैं, भले ही वे वस्तुओं को समूहबद्ध करने के दोनों तरीके हैं। सार प्रकार विशुद्ध रूप से नाममात्र हैं; वे वस्तुओं को सेट से संबंधित के रूप में टैग करते हैं। प्रोटोकॉल विशुद्ध रूप से संरचनात्मक हैं; कोई वस्तु समुच्चय से संबंधित होती है यदि उसमें कुछ गुण हों। तो कुछ विकल्प हैं

1. बस दोनों हो।
2. एक सार प्रकार के साथ प्रोटोकॉल को जोड़ने में सक्षम हो, उदाहरण के लिए, ताकि जब कोई प्रकार खुद को एक उपप्रकार घोषित करे, तो प्रोटोकॉल के अनुपालन के लिए इसकी जांच की जाए।
3. अमूर्त प्रकारों को पूरी तरह से हटा दें।

अगर हमारे पास (2) जैसा कुछ है, तो मुझे लगता है कि यह पहचानना महत्वपूर्ण है कि यह वास्तव में एक विशेषता नहीं है, बल्कि नाममात्र और संरचनात्मक टाइपिंग का संयोजन है।

एक चीज अमूर्त प्रकार उनके पैरामीटर के लिए उपयोगी लगती है, उदाहरण के लिए convert(AbstractArray{Int}, x) लिखना। यदि AbstractArray एक प्रोटोकॉल थे, तो तत्व प्रकार Int को प्रोटोकॉल परिभाषा में उल्लेख करने की आवश्यकता नहीं होगी। यह प्रकार के बारे में अतिरिक्त जानकारी है, _aside_ जिससे विधियों की आवश्यकता है। तो AbstractArray{T} और AbstractArray{S} समान विधियों को निर्दिष्ट करने के बावजूद अभी भी अलग-अलग प्रकार के होंगे, इसलिए हमने नाममात्र टाइपिंग को फिर से शुरू किया है। तो टाइप पैरामीटर के इस उपयोग के लिए किसी प्रकार की नाममात्र टाइपिंग की आवश्यकता होती है।

तो क्या 2. हमें कई अमूर्त विरासत देंगे?

तो क्या 2. हमें कई अमूर्त विरासत देंगे?

नहीं। यह सुविधाओं को एकीकृत या संयोजित करने का एक तरीका होगा, लेकिन प्रत्येक सुविधा में अभी भी गुण होंगे।

मुझे यह जोड़ना चाहिए कि कई अमूर्त विरासत की अनुमति देना अभी तक एक और लगभग-ऑर्थोगोनल डिज़ाइन निर्णय है। किसी भी मामले में, अमूर्त नाममात्र प्रकारों का उपयोग करने में समस्या बहुत अधिक है (1) आप प्रोटोकॉल के वास्तविक कार्यान्वयन को खो सकते हैं (व्यक्ति ए प्रकार को परिभाषित करता है, व्यक्ति बी प्रोटोकॉल को परिभाषित करता है और ए के लिए इसका कार्यान्वयन), (2) आप प्रोटोकॉल के संरचनात्मक उपप्रकार खो सकते हैं।

क्या मौजूदा सिस्टम में टाइप पैरामीटर किसी तरह से निहित इंटरफ़ेस का हिस्सा नहीं हैं? उदाहरण के लिए यह परिभाषा उस पर निर्भर करती है: ndims{T,n}(::AbstractArray{T,n}) = n और कई उपयोगकर्ता परिभाषित कार्य भी करते हैं।

तो, एक नए प्रोटोकॉल + अमूर्त विरासत प्रणाली में हमारे पास AbstractArray{T,N} और ProtoAbstractArray । अब एक प्रकार जो नाममात्र रूप से AbstractArray उसे यह निर्दिष्ट करने में सक्षम होने की आवश्यकता होगी कि T और N पैरामीटर क्या हैं, संभवतः हार्ड-कोडिंग eltype और ndims । फिर AbstractArray s पर सभी पैरामीटरयुक्त फ़ंक्शंस को पैरामीटर के बजाय eltype और ndims उपयोग करने के लिए फिर से लिखना होगा। तो, शायद यह अधिक समझ में आता है कि प्रोटोकॉल में पैरामीटर भी हैं, इसलिए संबंधित प्रकार बहुत उपयोगी हो सकते हैं। (ध्यान दें कि ठोस प्रकारों को अभी भी पैरामीटर की आवश्यकता होगी।)

इसके अलावा, @malmaud की चाल का उपयोग करके प्रोटोकॉल में प्रकारों का समूह: https://github.com/JuliaLang/julia/issues/6975#issuecomment -161056795 नाममात्र टाइपिंग के समान है: समूह पूरी तरह से प्रकार चुनने के कारण है और प्रकार साझा नहीं (प्रयोग करने योग्य) इंटरफ़ेस। तो शायद अमूर्त प्रकार और प्रोटोकॉल काफी हद तक ओवरलैप करते हैं?

हां, अमूर्त प्रकार के पैरामीटर निश्चित रूप से एक प्रकार का इंटरफ़ेस हैं, और कुछ हद तक eltype और ndims साथ बेमानी हैं। मुख्य अंतर यह प्रतीत होता है कि आप बिना किसी अतिरिक्त विधि कॉल के सीधे उन पर प्रेषण कर सकते हैं। मैं सहमत हूं कि संबद्ध प्रकारों के साथ हम अमूर्त प्रकारों को प्रोटोकॉल/लक्षणों के साथ बदलने के बहुत करीब होंगे। वाक्यविन्यास कैसा दिख सकता है? आदर्श रूप से यह विधि कॉलिंग से कमजोर होगा, क्योंकि मेरे पास उप-टाइपिंग और विधि कॉलिंग के बीच गोलाकार निर्भरता नहीं होगी।

शेष प्रश्न यह है कि क्या संबंधित सार प्रकार का हिस्सा बनने के बिना प्रोटोकॉल को लागू करना उपयोगी है। एक उदाहरण तार हो सकता है, जो चलने योग्य और अनुक्रमित होते हैं, लेकिन अक्सर कंटेनरों के बजाय "स्केलर" मात्रा के रूप में माना जाता है। मुझे नहीं पता कि यह कितनी बार उठता है।

मुझे नहीं लगता कि मैं आपके "विधि कॉलिंग" कथन को काफी समझता हूं। तो सिंटैक्स के लिए यह सुझाव वह नहीं हो सकता है जो आपने मांगा था:

protocol PAbstractArray{T,N}
    size(_)
    getindex(_, i::Int)
    ...
end

type MyType1
    a::Array{Int,1}
    ...
end

impl MyType for PAbstractArray{Int,1}
    size(_) = size(_.a)
    getindex(_, i::Int) = getindex(_.a,i)
    ...
end

# an implicit definition could look like:
associatedT(::Type{PAbstractArray}, :T, ::Type{MyType}) = Int
associatedT(::Type{PAbstractArray}, :N, ::Type{MyType}) = 1
size(mt::MyType) = size(mt.a)
getindex(mt::MyType, i::Int) = getindex(mt.a,i)


# parameterized type
type MyType2{TT, N, T}
    a::Array{T, N}
    ...
end

impl MyType2{TT,N,T} for PAbstractArray{T,N}
    size(_) = size(_.a)
    getindex(_, i::Int) = getindex(_.a,i)
    ...
end

प्रोटोकॉल प्रकारों के उपप्रकार को कैसे परिभाषित किया जाता है, इसके आधार पर यह काम कर सकता है। उदाहरण के लिए, दिया गया

protocol PAbstractArray{eltype,ndims}
    size(_)
    getindex(_, i::Int)
    ...
end

protocol Indexable{eltype}
    getindex(_, i::Int)
end

क्या हमारे पास PAbstractArray{Int,1} <: Indexable{Int} ? मुझे लगता है कि अगर पैरामीटर नाम से मेल खाते हैं तो यह बहुत अच्छा काम कर सकता है। हम शायद उस परिभाषा को भी स्वचालित कर सकते हैं जो eltype(x) को eltype पैरामीटर को x के प्रकार को लौटा देती है।

मैं विशेष रूप से impl ब्लॉक के अंदर विधि परिभाषाएं डालना पसंद नहीं करता, क्योंकि ज्यादातर एक विधि परिभाषा कई प्रोटोकॉल से संबंधित हो सकती है।

तो ऐसा लगता है कि इस तरह के एक तंत्र के साथ, हमें अब अमूर्त प्रकारों की आवश्यकता नहीं होगी। AbstractArray{T,N} एक प्रोटोकॉल बन सकता है। फिर हम स्वचालित रूप से एकाधिक विरासत (प्रोटोकॉल के) प्राप्त करते हैं। इसके अलावा, ठोस प्रकारों से विरासत में मिलने की असंभवता (जो कि एक शिकायत है जिसे हम कभी-कभी नवागंतुकों से सुनते हैं) स्पष्ट है, क्योंकि केवल प्रोटोकॉल विरासत का समर्थन किया जाएगा।

इसके अलावा: Callable विशेषता को व्यक्त करने में सक्षम होना वाकई अच्छा होगा। इसे कुछ इस तरह देखना होगा:

protocol Callable
    ::TupleCons{_, Bottom}
end

जहां TupleCons अलग से एक टपल के पहले तत्व और बाकी तत्वों से मेल खाता है। विचार यह है कि यह तब तक मेल खाता है जब तक _ लिए विधि तालिका गैर-रिक्त है (नीचे प्रत्येक तर्क टपल प्रकार का उप प्रकार है)। वास्तव में हम कर सकते हैं कि Tuple{a,b} के लिए वाक्यविन्यास TupleCons{a, TupleCons{b, EmptyTuple}} (देखें भी # 11,242)।

मुझे नहीं लगता कि यह सच है, सभी प्रकार के पैरामीटर अस्तित्व में मात्राबद्ध हैं _ बाधाओं के साथ_ इसलिए अमूर्त प्रकार और प्रोटोकॉल सीधे प्रतिस्थापन योग्य नहीं हैं।

@jakebolewski क्या आप एक उदाहरण के बारे में सोच सकते हैं? जाहिर है कि वे कभी भी एक जैसे नहीं होंगे; मैं कहूंगा कि सवाल अधिक है कि क्या हम एक मालिश कर सकते हैं जैसे कि हम दोनों के बिना प्राप्त कर सकते हैं।

हो सकता है कि मैं इस बिंदु को याद कर रहा हूं, लेकिन प्रोटोकॉल मामूली जटिल अमूर्त प्रकारों को बाधाओं के साथ कैसे एन्कोड कर सकते हैं, जैसे कि:

typealias BigMatrix ∃T, T <: Union{BigInt,BigFloat} AbstractArray{T,2}

नाममात्र की हर संभावना की गणना किए बिना?

प्रस्तावित Protocol प्रस्ताव अमूर्त सबटाइपिंग की तुलना में सख्ती से कम अभिव्यक्तिपूर्ण है जिसे मैं हाइलाइट करने का प्रयास कर रहा था।

मैं निम्नलिखित की कल्पना कर सकता था (स्वाभाविक रूप से, डिजाइन को इसकी व्यावहारिक सीमाओं तक खींचना):

BigMatrix = ∃T, T<:Union{BigInt, BigFloat} protocol { eltype = T, ndims = 2 }

अवलोकन के साथ जा रहा है कि मौजूदा अमूर्त प्रकारों की अभिव्यक्ति से मेल खाने के लिए हमें संबंधित प्रकार या नामित प्रकार के गुणों की आवश्यकता है। इसके साथ, हम संभावित रूप से निकट-संगतता प्राप्त कर सकते हैं:

AbstractArray = ∃T ∃N protocol { eltype=T, ndims=N }

ऑब्जेक्ट्स के डेटा फ़ील्ड के लिए स्ट्रक्चरल सबटाइपिंग मुझे कभी भी बहुत उपयोगी नहीं लग रहा था, लेकिन _types_ के गुणों पर लागू होने के बजाय यह बहुत समझ में आता है।

मैंने यह भी महसूस किया कि यह अस्पष्टता की समस्याओं से बचने की हैच प्रदान कर सकता है: दो प्रकार का प्रतिच्छेदन खाली है यदि उनके पास कुछ पैरामीटर के लिए परस्पर विरोधी मान हैं। तो अगर हम एक स्पष्ट Number प्रकार चाहते हैं तो हमारे पास हो सकता है

protocol Number
    super = Number
    +(_, _)
    ...
end

यह super को केवल एक अन्य प्रकार की संपत्ति के रूप में देख रहा है।

मुझे प्रस्तावित प्रोटोकॉल सिंटैक्स पसंद है, लेकिन मेरे पास कुछ नोट्स हैं।

लेकिन तब मैं सब कुछ गलत समझ सकता हूं। मैंने हाल ही में जूलिया को वास्तव में कुछ ऐसा देखना शुरू किया है जिस पर मैं काम करना चाहता हूं, और मुझे अभी तक टाइप सिस्टम की पूरी समझ नहीं है।

(ए) मुझे लगता है कि यह विशेषता सुविधाओं के साथ और अधिक दिलचस्प होगा @ मौरो 3 ऊपर काम किया। विशेष रूप से क्योंकि यदि आपके पास एकाधिक प्रेषण प्रोटोकॉल नहीं हो सकते हैं तो एकाधिक प्रेषण क्या अच्छा है! मैं अपने विचार को बाद में लिखूंगा कि वास्तविक दुनिया का उदाहरण क्या है। लेकिन इसका सामान्य सार "क्या इन दो वस्तुओं को बातचीत करने की इजाजत देने वाला व्यवहार है"। मुझसे गलती हो सकती है, और उन सभी को प्रोटोकॉल में शामिल किया जा सकता है, जैसे:

protocol Foo{bar}
    ...
end

protocol Bar{foo<:Foo}
   ...
end

और यह फू प्रोटोकॉल को उसी परिभाषा में बार प्रोटोकॉल को संदर्भित करने की अनुमति नहीं देने की प्रमुख समस्या को भी उजागर करता है।

(बी)

क्या हमारे पास PAbstractArray{Int,1} <: Indexable{Int} है? मुझे लगता है कि अगर पैरामीटर नाम से मेल खाते हैं तो यह बहुत अच्छा काम कर सकता है।

मुझे यकीन नहीं है कि हमें _name_ द्वारा पैरामीटर का मिलान क्यों करना है (मैं इसे eltype नाम के रूप में ले रहा हूं, अगर मुझे गलत समझा गया तो कृपया इस अनुभाग को अनदेखा करें)। क्यों न केवल संभावित फ़ंक्शन हस्ताक्षरों का मिलान किया जाए। नामकरण का उपयोग करने में मेरी प्राथमिक समस्या है क्योंकि यह निम्नलिखित को रोकता है:

module SomeBigLibrary
  # Assuming required definitions

  protocol Baz{el1type}
    Base.foo(_, i::el1type) # say `convert`
    baz(_)
  end
end

module SomeOtherLibrary
  # Assuming required definitions

  protocol Bar{el2type}
    Base.foo(_, i::el2type)
    bar(_)
  end
end

module My
  # Assuming required definitions

  protocol Protocol{el_type} # What do I put here to get both subtypes correctly!
    Base.foo(_, i::el_type)
    SomeBigLibrary.baz(_)
    SomeOtherLibrary.bar(_)
  end
end

दूसरी ओर यह सुनिश्चित करता है कि आपका प्रोटोकॉल केवल उस विशिष्ट प्रकार के पदानुक्रम को उजागर करता है जिसे हम भी चाहते हैं। यदि हम मिलान Iterable नाम नहीं देते हैं तो हमें पुनरावर्तनीय लागू करने के लाभ नहीं मिलते हैं (और निर्भरता में बढ़त भी नहीं लेते हैं)। लेकिन मुझे यकीन नहीं है कि एक उपयोगकर्ता _gain_s क्या है, इसके अलावा निम्नलिखित करने की क्षमता ...

(सी) तो, मुझे कुछ याद आ रहा है, लेकिन प्राथमिक उद्देश्य नहीं है जहां नामित प्रकार उपयोगी होते हैं यह वर्णन करना है कि सुपरसेट के विभिन्न भाग कैसे व्यवहार करते हैं? Number पदानुक्रम और अमूर्त प्रकार Signed और Unsigned , दोनों Integer प्रोटोकॉल को लागू करेंगे, लेकिन कभी-कभी काफी अलग व्यवहार करेंगे। उनके बीच अंतर करने के लिए क्या अब हम केवल Signed प्रकारों पर एक विशेष negate को परिभाषित करने के लिए मजबूर हैं (विशेष रूप से वापसी प्रकारों के बिना कठिन जहां हम वास्तव में Unsigned प्रकार को नकारना चाहते हैं)?

मुझे लगता है कि यह वह समस्या है जिसका आप super = Number उदाहरण में वर्णन करते हैं। जब हम bitstype Int16 <: Signed घोषित करते हैं (मेरा दूसरा प्रश्न यह भी है कि कैसे Number या Signed प्रोटोकॉल के रूप में उनके प्रकार के गुणों को कंक्रीट प्रकार पर लागू किया जाता है?) Signed ( super = Signed ) प्रोटोकॉल इसे Unsigned प्रोटोकॉल द्वारा चिह्नित प्रकारों से अलग होने के रूप में चिह्नित कर रहा है? क्योंकि यह मेरे विचार से एक अजीब समाधान है, और सिर्फ इसलिए नहीं कि मुझे नामित प्रकार के पैरामीटर अजीब लगते हैं। यदि दो प्रोटोकॉल सुपर में रखे गए प्रकार को छोड़कर बिल्कुल मेल खाते हैं, तो वे वैसे भी कैसे भिन्न होते हैं? और अगर अंतर एक बड़े प्रकार (प्रोटोकॉल) के सबसेट के बीच व्यवहार में है तो क्या हम वास्तव में अमूर्त प्रकारों के उद्देश्य को फिर से नहीं बना रहे हैं?

(डी) समस्या यह है कि हम व्यवहार के बीच अंतर करने के लिए अमूर्त प्रकार चाहते हैं और हम कुछ क्षमताओं (अक्सर अन्य व्यवहार की परवाह किए बिना) सुनिश्चित करने के लिए प्रोटोकॉल चाहते हैं, जिसके माध्यम से व्यवहार व्यक्त किए जाते हैं। लेकिन हम उन क्षमताओं को संकलित करने की कोशिश कर रहे हैं जो प्रोटोकॉल हमें सुनिश्चित करने की अनुमति देते हैं और व्यवहार सार प्रकार विभाजन करते हैं।

जिस समाधान के लिए हम अक्सर कूद रहे हैं, वह "एक अमूर्त वर्ग को लागू करने और अनुपालन की जांच करने के अपने इरादे की घोषणा करता है" की तर्ज पर है जो कार्यान्वयन में समस्याग्रस्त है (परिपत्र संदर्भ, प्रकार ब्लॉक के अंदर फ़ंक्शन परिभाषाओं को जोड़ने के लिए अग्रणी है या impl ब्लॉक), और मौजूदा तरीकों और उनके द्वारा संचालित प्रकारों के आधार पर प्रोटोकॉल की अच्छी गुणवत्ता को हटा देता है। ये समस्याएं वैसे भी अमूर्त पदानुक्रम में प्रोटोकॉल डालने से रोकती हैं।

लेकिन अधिक महत्वपूर्ण बात यह है कि प्रोटोकॉल व्यवहार का वर्णन नहीं करते हैं, वे कई कार्यों (जैसे पुनरावृत्ति) में जटिल क्षमताओं का वर्णन करते हैं, उस पुनरावृत्ति के व्यवहार को अमूर्त प्रकारों द्वारा वर्णित किया जाता है (चाहे इसे क्रमबद्ध किया गया हो, या यहां तक ​​​​कि आदेश दिया गया हो, उदाहरण के लिए)। दूसरी ओर प्रोटोकॉल + अमूर्त प्रकार का संयोजन उपयोगी होता है जब हम वास्तविक प्रकार पर अपना हाथ प्राप्त कर सकते हैं क्योंकि यह हमें क्षमताओं (क्षमता उपयोगिता विधियों), व्यवहार (उच्च स्तरीय विधियों), या दोनों (कार्यान्वयन विवरण) को दूर करने की अनुमति देता है। तरीके)।

(ई) यदि हम प्रोटोकॉल को कई प्रोटोकॉल प्राप्त करने की अनुमति देते हैं (वे मूल रूप से संरचनात्मक हैं) और ठोस प्रकार के रूप में कई सार प्रकार (उदाहरण के लिए एकाधिक सार विरासत के बिना, एक) हम शुद्ध प्रोटोकॉल प्रकार, शुद्ध सार प्रकार के निर्माण की अनुमति दे सकते हैं, और प्रोटोकॉल + सार प्रकार।

मेरा मानना ​​है कि यह उपरोक्त Signed बनाम Unsigned समस्या को ठीक करता है:

• दो प्रोटोकॉल परिभाषित करें, दोनों सामान्य IntegerProtocol (जो भी प्रोटोकॉल संरचना विरासत में मिले, NumberAddingProtocol , IntegerSteppingProtocol , आदि) से विरासत में मिले एक AbstractSignedInteger और दूसरा इससे AbstractUnsignedInteger )।
• फिर Signed प्रकार के उपयोगकर्ता को कार्यक्षमता (प्रोटोकॉल से) और व्यवहार (सार पदानुक्रम से) दोनों की गारंटी दी जाती है।
• प्रोटोकॉल के बिना एक AbstractSignedInteger ठोस प्रकार प्रयोग करने योग्य _anyway_ नहीं है।
• लेकिन दिलचस्प बात यह है कि (और एक भविष्य की विशेषता के रूप में पहले ही ऊपर उल्लेख किया गया है) हम अंततः लापता सुविधाओं को हल करने की क्षमता बना सकते हैं, यदि केवल IntegerSteppingProtocol (जो कि तुच्छ है और मूल रूप से केवल एक फ़ंक्शन के लिए एक उपनाम) मौजूद है ठोस AbstractUnsignedInteger हम इसके संदर्भ में अन्य प्रोटोकॉल को लागू करके Signed को हल करने का प्रयास कर सकते हैं। शायद convert जैसी किसी चीज़ के साथ भी।

सभी मौजूदा प्रकारों को रखते हुए उनमें से अधिकांश को प्रोटोकॉल + अमूर्त प्रकारों में बदलकर, और कुछ को शुद्ध सार प्रकारों के रूप में छोड़ दें।

संपादित करें: (एफ) सिंटेक्स उदाहरण (भाग (ए) सहित)।

संपादित करें 2 : कुछ गलतियों को ठीक किया ( :< बजाय <: ), एक खराब विकल्प को ठीक किया ( Foo बजाय ::Foo )

protocol {T<: Number}(Foo <: AbstractFoo; Bar <: AbstractBar) # Abstract inheritance
    IterableProtocol(::Foo) # Explicit protocol inheritance.

    # Implicit protocol inheritance.
    start(::Bar)
    next(::Bar, state) # These states should really share an anonymous internal type
    done(::Bar, state)

    # Custom method for protocol involving both participants, defines Foo / Bar relationship.
    set(::Foo, ::Bar, v::T)

    # Custom method only on Bar
    bar(::Bar)
end

# Protocols both Foo{T} and Bar{T}.

मुझे इस वाक्यविन्यास के साथ समस्याएं दिखाई देती हैं:

• प्रोटोकॉल के लिए अनाम आंतरिक प्रकार (जैसे राज्य चर)।
• वापसी के प्रकार।
• शब्दार्थ को कुशलता से लागू करना मुश्किल है।

_सार प्रकार_ परिभाषित करता है कि एक इकाई क्या है । _Protocol_ परिभाषित करता है कि एक इकाई क्या करती है । एक पैकेज के भीतर, ये दो अवधारणाएं विनिमेय हैं: एक इकाई _is_ यह क्या करता है _। और "अमूर्त प्रकार" अधिक प्रत्यक्ष है। हालांकि, दो पैकेजों के बीच, एक अंतर है: आपको अपने क्लाइंट "है" की आवश्यकता नहीं है, लेकिन आपको यह चाहिए कि आपका क्लाइंट "क्या करता है"। यहाँ, "अमूर्त प्रकार" इसके बारे में कोई जानकारी नहीं देता है।

मेरी राय में, एक प्रोटोकॉल एक एकल प्रेषित सार प्रकार है। यह पैकेज के विस्तार और सहयोग में मदद कर सकता है। इस प्रकार, एक पैकेज के भीतर, जहां संस्थाएं निकट से संबंधित हैं, विकास को आसान बनाने के लिए अमूर्त प्रकार का उपयोग करें (एकाधिक प्रेषण से लाभ प्राप्त करके); पैकेजों के बीच, जहां संस्थाएं अधिक स्वतंत्र हैं, कार्यान्वयन जोखिम को कम करने के लिए प्रोटोकॉल का उपयोग करें।

@ राजमिस्त्री

मुझे यकीन नहीं है कि हमें नाम से मापदंडों का मिलान क्यों करना है

मेरा मतलब है नाम से मिलान करना _as के विपरीत_ स्थिति के अनुसार मिलान करना। ये नाम संरचनात्मक रूप से सबटाइप किए गए रिकॉर्ड की तरह काम करेंगे। अगर हमारे पास है

protocol Collection{T}
    eltype = T
end

फिर एक संपत्ति के साथ कुछ भी कहा जाता है eltype की एक उप-प्रकार है Collection । इन "पैरामीटर" का क्रम और स्थिति कोई मायने नहीं रखती।

यदि दो प्रोटोकॉल सुपर में रखे गए प्रकार को छोड़कर बिल्कुल मेल खाते हैं, तो वे वैसे भी कैसे भिन्न होते हैं? और अगर अंतर एक बड़े प्रकार (प्रोटोकॉल) के सबसेट के बीच व्यवहार में है तो क्या हम वास्तव में अमूर्त प्रकारों के उद्देश्य को फिर से नहीं बना रहे हैं?

यह एक उचित बिंदु है। नामित पैरामीटर, वास्तव में, सार प्रकार के कई गुणों को वापस लाते हैं। मैं इस विचार से शुरू कर रहा था कि हमें प्रोटोकॉल और अमूर्त प्रकार दोनों की आवश्यकता हो सकती है, फिर सुविधाओं को एकीकृत और सामान्यीकृत करने का प्रयास करना चाहिए। आखिरकार, जब आप वर्तमान में type Foo <: Bar घोषित करते हैं, तो किसी स्तर पर आपने वास्तव में जो किया है वह Foo.super === Bar सेट है। तो हो सकता है कि हमें किसी अन्य कुंजी/मूल्य जोड़े के साथ सीधे इसका समर्थन करना चाहिए जिसे आप संबद्ध करना चाहते हैं।

"प्रकारों ने एक अमूर्त वर्ग को लागू करने और अनुपालन की जांच करने के अपने इरादे की घोषणा की है"

हां, मैं उस दृष्टिकोण को मुख्य विशेषता बनाने के खिलाफ हूं।

यदि हम प्रोटोकॉल को कई प्रोटोकॉल ... और कई सार प्रकारों को इनहेरिट करने की अनुमति देते हैं

क्या इसका मतलब यह है कि उदाहरण के लिए "टी प्रोटोकॉल पी का उप प्रकार है यदि इसमें एक्स, वाई, जेड है, और खुद को सार एरे का उप प्रकार घोषित करता है"? मुझे लगता है कि इस तरह का "प्रोटोकॉल + एब्स्ट्रैक्ट टाइप" मेरे super = T संपत्ति प्रस्ताव के साथ आपको मिलने वाले समान है। बेशक, मेरे संस्करण में मुझे अभी तक पता नहीं चला है कि उन्हें एक पदानुक्रम का परिचय कैसे दिया जाए (जैसे Integer <: Real <: Number )।

एक (नाममात्र) सार प्रकार से एक प्रोटोकॉल का उत्तराधिकारी होना उस पर एक बहुत मजबूत बाधा प्रतीत होता है। क्या सार प्रकार के उपप्रकार होंगे जो _not_ प्रोटोकॉल को लागू करते थे? मेरी आंत महसूस कर रही है कि प्रोटोकॉल और अमूर्त प्रकारों को ऑर्थोगोनल चीजों के रूप में रखना बेहतर है।

protocol {T :< Number}(Foo :< AbstractFoo; Bar :< AbstractBar) # Abstract inheritance
    IterableProtocol(Foo) # Explicit protocol inheritance.

    # Implicit protocol inheritance.
    start(Bar)
...

मैं इस वाक्य रचना को नहीं समझता।

• क्या इस प्रोटोकॉल का कोई नाम है?
• { } और ( ) अंदर की सामग्री का वास्तव में क्या अर्थ है?
• आप इस प्रोटोकॉल का उपयोग कैसे करते हैं? क्या आप उस पर प्रेषण कर सकते हैं? यदि हां, तो f(x::ThisProtocol)=... को परिभाषित करने का क्या अर्थ है, यह देखते हुए कि प्रोटोकॉल कई प्रकारों से संबंधित है?

तो eltype नामक संपत्ति के साथ कुछ भी संग्रह का उप प्रकार है। इन "पैरामीटर" का क्रम और स्थिति कोई मायने नहीं रखती।

आह, मेरी गलतफहमी थी, जो अधिक समझ में आता है। अर्थात् असाइन करने की क्षमता:

el1type = el_type
el2type = el_type

मेरी उदाहरण समस्या को हल करने के लिए।

तो हो सकता है कि हमें किसी अन्य कुंजी/मूल्य जोड़े के साथ सीधे इसका समर्थन करना चाहिए जिसे आप संबद्ध करना चाहते हैं।

और यह की/वैल्यू फीचर सभी प्रकार पर होगा, क्योंकि हम इसके साथ एब्सट्रैक्ट को बदल देंगे। यह एक अच्छा सामान्य समाधान है। आपका समाधान अब मेरे लिए बहुत अधिक समझ में आता है।

बेशक, मेरे संस्करण में मैंने अभी तक यह पता नहीं लगाया है कि उन्हें एक पदानुक्रम का परिचय कैसे दिया जाए जैसे हमारे पास अभी है (उदाहरण के लिए पूर्णांक <: वास्तविक <: संख्या)।

मुझे लगता है कि आप उपयोग कर सकते हैं super (उदाहरण के लिए Integer के सुपर के रूप में Real ) और फिर या तो super विशेष बनाएं और नामित प्रकार की तरह कार्य करें या जोड़ें कस्टम प्रकार रिज़ॉल्यूशन कोड (अला पायथन) जोड़ने और super पैरामीटर के लिए एक डिफ़ॉल्ट नियम बनाने का एक तरीका।

एक (नाममात्र) सार प्रकार से एक प्रोटोकॉल का उत्तराधिकारी होना उस पर एक बहुत मजबूत बाधा प्रतीत होता है। क्या सार प्रकार के उपप्रकार होंगे जो प्रोटोकॉल को लागू नहीं करते थे? मेरी आंत महसूस कर रही है कि प्रोटोकॉल और अमूर्त प्रकारों को ऑर्थोगोनल चीजों के रूप में रखना बेहतर है।

अरे हाँ, अमूर्त बाधा पूरी तरह से वैकल्पिक थी! मेरा पूरा मुद्दा यह था कि प्रोटोकॉल और अमूर्त प्रकार ऑर्थोगोनल हैं। आप यह सुनिश्चित करने के लिए सार + प्रोटोकॉल का उपयोग करेंगे कि आपको कुछ व्यवहार _और_ संबद्ध क्षमताओं का संयोजन प्राप्त हो। यदि आप केवल क्षमताओं (उपयोगिता कार्यों के लिए) या केवल व्यवहार चाहते हैं तो आप उन्हें ऑर्थोगोनली उपयोग करते हैं।

क्या इस प्रोटोकॉल का कोई नाम है?

दो नामों के साथ दो प्रोटोकॉल ( Foo , और Bar ) जो एक ब्लॉक से आते हैं, लेकिन फिर मुझे मैक्रोज़ का उपयोग इस तरह की कई परिभाषाओं का विस्तार करने के लिए किया जाता है। मेरे सिंटैक्स का यह भाग part (a) को हल करने का एक प्रयास था। यदि आप इसे अनदेखा करते हैं तो पहली पंक्ति केवल protocol Foo{T <: Number, Bar <: AbstractBar} <: AbstractFoo (दूसरे के साथ, Bar प्रोटोकॉल के लिए अलग, परिभाषा)। साथ ही, सभी Number , AbstractBar और AbstractFoo वैकल्पिक होंगे, जैसे सामान्य प्रकार की परिभाषाओं में,

{ } और ( ) के अंदर की सामग्री का वास्तव में क्या मतलब है?

{} मानक पैरामीट्रिक प्रकार परिभाषा अनुभाग है। उदाहरण के लिए Float64 का उपयोग करके Foo प्रोटोकॉल को लागू करने वाले प्रकार का वर्णन करने के लिए Foo{Float64} के उपयोग की अनुमति देना। () मूल रूप से प्रोटोकॉल बॉडी के लिए एक वैरिएबल बाइंडिंग लिस्ट है (इसलिए एक साथ कई प्रोटोकॉल का वर्णन किया जा सकता है)। आपका भ्रम शायद मेरी गलती है क्योंकि मैंने अपने मूल में <: बजाय :< गलत टाइप किया था। <<name>> <<parametric>> <<bindings>> संरचना को बनाए रखने के लिए उन्हें स्वैप करना भी इसके लायक हो सकता है, जहां <<name>> कभी-कभी बाइंडिंग की सूची हो सकती है।

आप इस प्रोटोकॉल का उपयोग कैसे करते हैं? क्या आप उस पर प्रेषण कर सकते हैं? यदि हां, तो f(x::ThisProtocol)=... को परिभाषित करने का क्या अर्थ है, यह देखते हुए कि प्रोटोकॉल कई प्रकारों से संबंधित है?

आपका प्रेषण उदाहरण मेरी राय में वाक्य रचना के अनुसार इसके लिए सही लगता है, वास्तव में निम्नलिखित परिभाषाओं पर विचार करें:

protocol FooProtocol # Single protocol definition shortcut
    foo(::FooProtocol) # I changed my syntax here, protocol names inside the protocol block should referenced as types
end

abstract FooAbstract

# This next line could use better syntax, like a type alias with an Intersection or something.
protocol Foo <: FooAbstract
    FooProtocol(::Foo)
end

type Bar <: FooAbstract
  a
end

type Baz
  b
end

type Bax <: FooAbstract
  c
end

f(f::Any) = ... # def (0)

foo(x::Bar) = ... # def (1a)
foo(x::Baz) = ... # def (1b)

f(x::FooProtocol) = ... # def (2); Least specific type (structural)

f(Bar(...)) # Would call def (2)
f(Baz(...)) # Would call def (2)
f(Bax(...)) # Would call def (0)

f(x::FooAbstract) = ... # def (3); Named type, more specific than structural

f(Bar(...)) # Would call def (3)
f(Baz(...)) # Would call def (2)
f(Bax(...)) # Would call def (3)

f(x::Foo) = ... # def (4); Named structural type, more specific than equivalent named type

f(Bar(...)) # Would call def (4)
f(Baz(...)) # Would call def (2)
f(Bax(...)) # Would call def (3)

प्रभावी रूप से प्रोटोकॉल नामित शीर्ष प्रकार (कोई भी) का उपयोग कर रहे हैं जब तक कि संरचना की जांच के लिए अधिक विशिष्ट सार प्रकार नहीं दिया जाता है। वास्तव में ऐसा करने के लिए प्रोटोकॉल सिंटैक्स का उपयोग करने के बजाय typealias Foo Intersect{FooProtocol, Foo} (_एडिट: इंटरसेक्ट गलत नाम था, शायद इसके बजाय इंटरसेक्ट सही पहली बार_) जैसे कुछ की अनुमति देने के लायक हो सकता है।

आह बढ़िया, यह अब मुझे और अधिक समझ में आता है! एक ही ब्लॉक में एक साथ कई प्रोटोकॉल को परिभाषित करना दिलचस्प है; मुझे इसके बारे में कुछ और सोचना होगा।

मैंने कुछ मिनट पहले अपने सभी उदाहरण साफ़ कर दिए हैं। इससे पहले सूत्र में किसी ने विचारों का परीक्षण करने के लिए प्रोटोकॉल का एक संग्रह एकत्र करने का उल्लेख किया था, मुझे लगता है कि यह एक अच्छा विचार है।

एक ही ब्लॉक में एकाधिक प्रोटोकॉल एक पालतू शिखर की तरह है जब मैं वस्तुओं के बीच जटिल संबंधों का वर्णन करने का प्रयास करता हूं, जब आप भाषाओं को लोड करते हैं तो परिभाषित/संकलित करते हैं (उदाहरण के लिए पाइथन; जावा उदाहरण के लिए ' टी समस्या है)। दूसरी तरफ, उनमें से अधिकतर शायद आसानी से तय हो जाते हैं, उपयोगिता के अनुसार, बहु-विधियों के साथ वैसे भी; लेकिन प्रदर्शन के विचार प्रोटोकॉल के भीतर सही ढंग से टाइप की गई सुविधाओं से बाहर आ सकते हैं (प्रोटोकॉल को vtables कहने के लिए उन्हें विशेषज्ञता देकर अनुकूलित करना)।

आपने पहले उल्लेख किया था कि ::Any का उपयोग करके विधियों द्वारा प्रोटोकॉल (नकली रूप से) कार्यान्वित किया जा सकता है, मुझे लगता है कि अगर यह आया तो इसे अनदेखा करना एक बहुत ही आसान मामला होगा। यदि कार्यान्वयन विधि ::Any पर भेजी जाती है तो ठोस प्रकार प्रोटोकॉल के रूप में वर्गीकृत नहीं होगा। दूसरी ओर मैं नहीं बेच रहा हूँ कि यह जरूरी एक समस्या है।

शुरुआत के लिए यदि तथ्य के बाद ::Any विधि जोड़ी जाती है (कहते हैं क्योंकि कोई इसे संभालने के लिए अधिक सामान्य प्रणाली के साथ आया था) यह अभी भी एक वैध कार्यान्वयन है, और यदि हम प्रोटोकॉल का उपयोग अनुकूलन सुविधा के रूप में भी करते हैं तो ::Any प्रेषण विधियों के विशेष संस्करण अभी भी प्रदर्शन लाभ के लिए काम करते हैं। तो अंत में मैं वास्तव में उन्हें अनदेखा करने के खिलाफ रहूंगा।

लेकिन यह इसके लायक हो सकता है कि एक सिंटैक्स हो जो प्रोटोकॉल को दो विकल्पों के बीच चयन करने देता है (जिसे हम कभी भी डिफ़ॉल्ट बनाते हैं, दूसरे को अनुमति देते हैं)। पहले के लिए, ::Any प्रेषण विधि के लिए एक अग्रेषण वाक्यविन्यास, वैश्विक कीवर्ड कहें (अगला अनुभाग भी देखें)। दूसरे तरीके के लिए एक अधिक विशिष्ट विधि की आवश्यकता है, मैं एक मौजूदा उपयोगी कीवर्ड के बारे में नहीं सोच सकता।

संपादित करें: व्यर्थ सामान का एक गुच्छा हटा दिया।

आपका Join बिल्कुल प्रोटोकॉल प्रकारों का प्रतिच्छेदन है। यह वास्तव में एक "मिलना" है। और खुशी से, Join प्रकार आवश्यक नहीं है, क्योंकि प्रोटोकॉल प्रकार पहले से ही चौराहे के तहत बंद हैं: चौराहे की गणना करने के लिए, बस एक नया प्रोटोकॉल प्रकार लौटाएं जिसमें दो विधियों की सूची शामिल है।

मैं ::Any परिभाषाओं द्वारा प्रोटोकॉल को तुच्छ बनाने के बारे में बहुत चिंतित नहीं हूं। मेरे लिए नियम " Any को छोड़कर मिलान करने वाली परिभाषाओं की तलाश करें" ओकाम के रेजर से दूर चलता है। उल्लेख नहीं है कि सबटाइपिंग एल्गोरिदम के माध्यम से "किसी को भी अनदेखा करें" ध्वज को थ्रेड करना बहुत परेशान होगा। मुझे यह भी यकीन नहीं है कि परिणामी एल्गोरिदम सुसंगत है।

मुझे प्रोटोकॉल का विचार बहुत पसंद है (मुझे कुछ CLUsters की याद दिलाता है), मैं बस उत्सुक हूं, यह नए उपप्रकार के साथ कैसे फिट होगा जिस पर जेफ द्वारा जूलियाकॉन में चर्चा की गई थी, और लक्षणों के साथ? (दो चीजें जो मैं अभी भी वास्तव में जूलिया में देखना चाहूंगा)।

यह अपने स्वयं के सबटाइपिंग नियमों (https://github.com/JuliaLang/julia/issues/6975#issuecomment-160857877) के साथ एक नया प्रकार जोड़ देगा। पहली नज़र में वे बाकी सिस्टम के साथ संगत प्रतीत होते हैं और बस प्लग इन किया जा सकता है।

ये प्रोटोकॉल काफी हद तक @mauro3 के लक्षणों का "एक पैरामीटर" संस्करण हैं।

आपका Join बिल्कुल प्रोटोकॉल प्रकारों का प्रतिच्छेदन है।

मैंने किसी तरह अपने आप को आश्वस्त किया कि मैं पहले गलत था जब मैंने कहा कि यह चौराहा था। हालाँकि हमें अभी भी एक पंक्ति में प्रकारों को प्रतिच्छेद करने के तरीके की आवश्यकता होगी (जैसे Union )।

संपादित करें:

मुझे अभी भी एक सिस्टम में प्रोटोकॉल और अमूर्त प्रकारों को सामान्य बनाना और उनके समाधान के लिए कस्टम नियमों की अनुमति देना पसंद है (उदाहरण के लिए super लिए वर्तमान सार प्रकार प्रणाली का वर्णन करने के लिए)। मुझे लगता है कि अगर सही किया जाता है तो यह लोगों को कस्टम टाइप सिस्टम और अंततः उन प्रकार के सिस्टम के लिए कस्टम ऑप्टिमाइज़ेशन जोड़ने की अनुमति देगा। हालांकि मुझे यकीन नहीं है कि प्रोटोकॉल सही कीवर्ड होगा, लेकिन कम से कम हम abstract को मैक्रो में बदल सकते हैं, यह अच्छा होगा।

गेहूँ के खेतों से: गंतव्य के रूप में उनके सामान्यीकरण की तलाश करने की तुलना में प्रोटोकॉल और सार के माध्यम से समानता को उठाना बेहतर है।

क्या?

प्रोटोकॉल और अमूर्त प्रकारों की मंशा, क्षमता और क्षमता को सामान्य बनाने की प्रक्रिया उनके गुणात्मक रूप से सबसे संतोषजनक संश्लेषण को हल करने का एक तरीका कम प्रभावी है। यह उद्देश्य, पैटर्न, प्रक्रिया की उनकी आंतरिक समानताओं को समेटने के लिए सबसे पहले बेहतर काम करता है। और उस समझ को विकसित करें, जिससे किसी के परिप्रेक्ष्य के शोधन को संश्लेषण बनाने की अनुमति मिलती है।

जूलिया के लिए जो भी फलदायी अहसास हो, वह उस मचान पर निर्मित होता है जो संश्लेषण प्रदान करता है। स्पष्ट संश्लेषण रचनात्मक शक्ति और आगमनात्मक शक्ति है।

क्या?

मुझे लगता है कि वह कह रहे हैं कि हमें पहले यह पता लगाना चाहिए कि हम प्रोटोकॉल से क्या चाहते हैं और वे क्यों उपयोगी हैं। फिर एक बार जब हमारे पास वह और अमूर्त प्रकार हो जाते हैं तो उनके सामान्य संश्लेषण के साथ आना आसान हो जाएगा।

मात्र प्रोटोकॉल

(1) वकालत करना

एक प्रोटोकॉल (अधिक विस्तृत) प्रोटोकॉल बनने के लिए बढ़ाया जा सकता है।
एक प्रोटोकॉल (कम विस्तृत) प्रोटोकॉल बनने के लिए कम किया जा सकता है।
एक प्रोटोकॉल को [सॉफ्टवेयर में] अनुरूप इंटरफेस के रूप में महसूस किया जा सकता है।
एक इंटरफ़ेस के अनुरूपता निर्धारित करने के लिए एक प्रोटोकॉल से पूछताछ की जा सकती है।

(2) सुझाव देना

प्रोटोकॉल को डिफ़ॉल्ट रूप से प्रोटोकॉल-विशिष्ट संस्करण संख्याओं का समर्थन करना चाहिए।

ऐसा करने के किसी तरीके का समर्थन करना अच्छा होगा:
जब कोई इंटरफ़ेस प्रोटोकॉल के अनुरूप हो, तो सही प्रतिक्रिया दें; जब एक इंटरफ़ेस
प्रोटोकॉल के एक उपसमुच्चय के प्रति वफादार है और संवर्धित होने पर अनुरूप होगा,
अधूरा जवाब दें, और अन्यथा गलत जवाब दें। एक फ़ंक्शन को सभी को सूचीबद्ध करना चाहिए
एक प्रोटोकॉल के लिए अधूरा है कि एक इंटरफेस के लिए आवश्यक वृद्धि।

(3) संगीत

एक प्रोटोकॉल एक विशिष्ट प्रकार का मॉड्यूल हो सकता है। इसका निर्यात काम करेगा
प्रारंभिक तुलना के रूप में यह निर्धारित करते समय कि कुछ इंटरफ़ेस अनुरूप है या नहीं।
किसी भी प्रोटोकॉल निर्दिष्ट [निर्यात] प्रकार और कार्यों का उपयोग करके घोषित किया जा सकता है
@abstract , @type , @immutable और @function सहज अमूर्तता का समर्थन करने के लिए।

[पाओ: कोड-कोट्स पर स्विच करें, हालांकि ध्यान दें कि जब आप इस तथ्य के बाद ऐसा कर रहे हैं तो घोड़ा पहले ही खलिहान छोड़ चुका है ...]

(आपको @mentions उद्धृत करने की आवश्यकता है!)

धन्यवाद - इसे ठीक करना

बुधवार, 16 दिसंबर, 2015 को सुबह 3:01 बजे, मौरो नोटिफिकेशन @github.com ने लिखा:

(आपको @उल्लेखों को उद्धृत करने की आवश्यकता है!)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/JuliaLang/julia/issues/6975#issuecomment -165026727।

क्षमा करें, मुझे और अधिक स्पष्ट होना चाहिए था: कोड-उद्धरण ` का उपयोग कर रहा है और नहीं "

उद्धरण फिक्स फिक्स्ड।

धन्यवाद - मेरी पूर्व अज्ञानता क्षमा करें

मैंने प्रोटोकॉल प्रकार जोड़ने के बारे में इस हालिया चर्चा को समझने की कोशिश की। हो सकता है कि मैं कुछ गलत समझ रहा हूं लेकिन प्रोटोकॉल का वर्णन करने वाले संबंधित सार प्रकार के नाम का उपयोग करने के बजाय प्रोटोकॉल नामित करना क्यों जरूरी है?

मेरे विचार में वर्तमान अमूर्त प्रकार प्रणाली को उस प्रकार से अपेक्षित व्यवहार का वर्णन करने के लिए किसी भी तरह से विस्तारित करना काफी स्वाभाविक है। बहुत कुछ शुरू में इस धागे में प्रस्तावित किया गया था, लेकिन शायद जेफ्स सिंटैक्स के साथ

abstract Iterable
    start(::_)
    done(::_, state)
    next(::_, state)
end

इस मार्ग पर जाते समय विशेष रूप से यह इंगित करने की आवश्यकता नहीं होगी कि एक उपप्रकार इंटरफ़ेस को लागू करता है। यह परोक्ष रूप से सबटाइपिंग द्वारा किया जाएगा।

बेहतर त्रुटि संदेश प्राप्त करने और बेहतर सत्यापन परीक्षण करने के लिए एक स्पष्ट इंटरफ़ेस तंत्र का प्राथमिक लक्ष्य IMHO है।

तो एक प्रकार की घोषणा जैसे:

type Foo <: Iterable
  ...
end

क्या हम ... अनुभाग में कार्यों को परिभाषित करते हैं? यदि नहीं, तो हम लापता कार्यों (और उससे संबंधित जटिलताओं) के बारे में कब त्रुटि करते हैं? साथ ही, कई प्रोटोकॉल लागू करने वाले प्रकारों के लिए क्या होता है, क्या हम एकाधिक सार विरासत को सक्षम करते हैं? हम सुपर-विधि संकल्प को कैसे संभालते हैं? यह एकाधिक प्रेषण के साथ क्या करता है (ऐसा लगता है कि इसे हटा दें और वहां जावा-एस्क्यू ऑब्जेक्ट सिस्टम चिपकाएं)? पहले प्रकार को परिभाषित करने के बाद हम विधियों के लिए नए प्रकार की विशेषज्ञता को कैसे परिभाषित करते हैं? प्रकार को परिभाषित करने के बाद हम प्रोटोकॉल को कैसे परिभाषित करते हैं?

एक नया प्रकार बनाकर (या एक नया प्रकार का सूत्रीकरण बनाकर) इन प्रश्नों को हल करना आसान है।

प्रत्येक प्रोटोकॉल के लिए आवश्यक रूप से एक संबंधित सार प्रकार नहीं है (शायद वास्तव में कोई भी नहीं होना चाहिए)। वर्तमान इंटरफेस के गुणकों को एक ही प्रकार से लागू किया जा सकता है। जो वर्तमान सार प्रकार प्रणाली के साथ वर्णन योग्य नहीं है। इसलिए समस्या है।

• सार एकाधिक वंशानुक्रम (एकाधिक प्रोटोकॉल को लागू करना) इस सुविधा के लिए ऑर्थोगोनल है (जैसा कि ऊपर जेफ द्वारा कहा गया है)। तो ऐसा नहीं है कि हमें वह सुविधा सिर्फ इसलिए मिलती है क्योंकि प्रोटोकॉल भाषा में जोड़े जाते हैं।
• आपकी अगली टिप्पणी इस प्रश्न के बारे में है कि इंटरफ़ेस को कब सत्यापित किया जाए। मुझे लगता है कि इसे इन-ब्लॉक फ़ंक्शन परिभाषाओं से जोड़ने की ज़रूरत नहीं है, जो मुझे जूलियन नहीं लगता। इसके बजाय तीन सरल उपाय हैं:
  
  
  
  1. जैसे # 7025 में लागू किया गया एक verify_interface विधि का उपयोग करें जिसे या तो सभी फ़ंक्शन परिभाषाओं के बाद या एक इकाई परीक्षण में कहा जा सकता है
  
  
  2. कोई इंटरफ़ेस को बिल्कुल भी सत्यापित नहीं कर सकता है और इसे "MethodError" में एक बेहतर त्रुटि संदेश के लिए स्थगित कर सकता है। असल में यह 1 के लिए एक अच्छा फॉलबैक है।
  
  
  3. संकलन समय इकाई के अंत में या मॉड्यूल लोडिंग चरण के अंत में सभी इंटरफेस को सत्यापित करें। वर्तमान में यह भी संभव है:
  
  

function a()
  b()
end

function b()
end

इस प्रकार, मुझे नहीं लगता कि यहां इन-ब्लॉक फ़ंक्शन परिभाषाओं की आवश्यकता होगी।

• आप अंतिम बिंदु यह है कि ऐसे प्रोटोकॉल हो सकते हैं जो अमूर्त प्रकारों से जुड़े नहीं हैं। यह वर्तमान में निश्चित रूप से सच है (उदाहरण के लिए अनौपचारिक "इटरेबल" प्रोटोकॉल)। हालांकि, मेरे विचार में यह कई अमूर्त विरासत की कमी के कारण है। यदि यह चिंता का विषय है, तो कृपया इसे हल करने के उद्देश्य से एक नई भाषा सुविधा जोड़ने के बजाय केवल सार एकाधिक वंशानुक्रम जोड़ने दें। मुझे यह भी लगता है कि एकाधिक इंटरफेस लागू करना बिल्कुल महत्वपूर्ण है और यह जावा/सी # में पूर्ण आम है।

मुझे लगता है कि "प्रोटोकॉल" जैसी चीज़ और एकाधिक विरासत के बीच का अंतर यह है कि परिभाषित होने के बाद प्रोटोकॉल में एक प्रकार जोड़ा जा सकता है। यह उपयोगी है यदि आप अपने पैकेज (प्रोटोकॉल को परिभाषित करना) को मौजूदा प्रकारों के साथ काम करना चाहते हैं। कोई भी सृजन के बाद एक प्रकार के सुपरटेप्स को संशोधित करने की अनुमति दे सकता है, लेकिन उस समय इसे "प्रोटोकॉल" या कुछ ऐसा कहना बेहतर होगा।

एचएम तो यह मौजूदा प्रकारों के लिए वैकल्पिक/उन्नत इंटरफेस को परिभाषित करने की अनुमति देता है। मुझे अभी भी यह स्पष्ट नहीं है कि वास्तव में इसकी आवश्यकता कहाँ होगी। जब कोई मौजूदा इंटरफ़ेस में कुछ जोड़ना चाहता है (जब हम ओपी में प्रस्तावित दृष्टिकोण का पालन करते हैं) तो कोई बस उप-प्रकार करेगा और उप-प्रकार में अतिरिक्त इंटरफ़ेस विधियों को जोड़ देगा। उस दृष्टिकोण के बारे में यह अच्छी बात है। यह काफी अच्छी तरह से स्केल करता है।

उदाहरण: मान लें कि मेरे पास कुछ पैकेज था जो क्रमबद्ध करता है। एक प्रकार के लिए एक विधि tobits को लागू करने की आवश्यकता है, फिर उस पैकेज के सभी फ़ंक्शन प्रकार के साथ काम करेंगे। आइए इसे Serializer प्रोटोकॉल कहते हैं (यानी tobits परिभाषित किया गया है)। अब मैं जोड़ सकते हैं Array को लागू करने से यह करने के लिए (या किसी भी अन्य प्रकार) tobits । एकाधिक विरासत के साथ मैं Array Serialzer साथ काम नहीं कर सका क्योंकि मैं इसकी परिभाषा के बाद Array एक सुपरटाइप नहीं जोड़ सकता। मुझे लगता है कि यह एक महत्वपूर्ण उपयोग-मामला है।

ठीक है, इसे समझो। https://github.com/JuliaLang/IterativeSolvers.jl/issues/2 एक समान समस्या है, जहां समाधान मूल रूप से डक-टाइपिंग का उपयोग करना है। अगर हमारे पास ऐसा कुछ है जो इस मुद्दे को सुरुचिपूर्ण ढंग से हल करता है तो यह वास्तव में अच्छा होगा। लेकिन यह एक ऐसी चीज है जिसका प्रेषण स्तर पर समर्थन किया जाना है। अगर मैं उपरोक्त प्रोटोकॉल विचार को सही ढंग से समझता हूं तो कोई भी एक सार प्रकार या प्रोटोकॉल को फ़ंक्शन में टाइप एनोटेशन के रूप में रख सकता है। यहां इन दोनों अवधारणाओं को एक ऐसे उपकरण के साथ मिलाना अच्छा होगा जो पर्याप्त शक्तिशाली हो।

मैं सहमत हूं: अमूर्त प्रकार और प्रोटोकॉल दोनों का होना बहुत भ्रमित करने वाला होगा। अगर मुझे सही से याद है, तो ऊपर यह तर्क दिया गया था कि अमूर्त प्रकारों में कुछ शब्दार्थ होते हैं जिन्हें प्रोटोकॉल के साथ तैयार नहीं किया जा सकता है, अर्थात अमूर्त प्रकारों में कुछ विशेषता होती है जो प्रोटोकॉल में नहीं होती है। यहां तक ​​​​कि अगर यह आवश्यक रूप से मामला है (मैं आश्वस्त नहीं हूं), यह अभी भी भ्रमित करने वाला होगा क्योंकि दो अवधारणाओं के बीच इतना बड़ा ओवरलैप है। तो, प्रोटोकॉल के पक्ष में अमूर्त प्रकारों को हटा दिया जाना चाहिए।

जहां तक ​​प्रोटोकॉल के बारे में ऊपर आम सहमति है, वे इंटरफेस निर्दिष्ट करने पर जोर देते हैं। उस अनुपस्थित प्रोटोकॉल में से कुछ को करने के लिए सार प्रकारों का उपयोग किया जा सकता है। इसका मतलब यह नहीं है कि यह उनका सबसे महत्वपूर्ण उपयोग है। मुझे बताएं कि प्रोटोकॉल क्या हैं और क्या नहीं हैं, तो मैं आपको बता सकता हूं कि अमूर्त प्रकार कैसे भिन्न होते हैं और उनमें से कुछ क्या लाते हैं। मैंने कभी भी अमूर्त प्रकारों को इंटरफ़ेस के बारे में उतना नहीं माना है जितना कि टाइपोलॉजी के बारे में। टाइपोलॉजिकल लचीलेपन के लिए एक प्राकृतिक दृष्टिकोण को फेंकना महंगा है।

@JeffreySarnoff +1

संख्या प्रकार पदानुक्रम के बारे में सोचें। विभिन्न सार प्रकार जैसे हस्ताक्षरित, अहस्ताक्षरित, उनके इंटरफ़ेस द्वारा परिभाषित नहीं हैं। विधियों का कोई सेट नहीं है जो "हस्ताक्षरित" को परिभाषित करता है। यह बस एक बहुत ही उपयोगी घोषणा है।

मुझे समस्या नहीं दिख रही है, वास्तव में। यदि Signed और Unsigned प्रकार के तरीकों के एक ही सेट का समर्थन करते हैं, तो हम समान इंटरफेस के साथ दो प्रोटोकॉल बना सकते हैं। फिर भी, के रूप में एक प्रकार की घोषणा Signed के बजाय Unsigned (अलग ढंग से एक ही समारोह अधिनियम के यानी तरीकों) प्रेषण के लिए इस्तेमाल किया जा सकता है। यहां कुंजी यह है कि यह विचार करने से पहले एक स्पष्ट घोषणा की आवश्यकता है कि एक प्रकार एक प्रोटोकॉल लागू करता है, इसके बजाय इसे लागू करने के तरीकों के आधार पर इसका पता लगाने के बजाय।

लेकिन परोक्ष रूप से संबद्ध प्रोटोकॉल होना भी महत्वपूर्ण है, जैसे कि https://github.com/JuliaLang/julia/issues/6975#issuecomment -168499775

प्रोटोकॉल न केवल उन कार्यों को परिभाषित कर सकते हैं जिन्हें बुलाया जा सकता है, बल्कि दस्तावेज़ (या तो निहित रूप से, या मशीन-परीक्षण योग्य तरीकों से) गुणों को धारण करने की आवश्यकता है। जैसे कि:

abs(x::Unsigned) == x
signbit(x::Unsigned) == false
-abs(x::Signed) <= 0

Signed और Unsigned बीच बाहरी रूप से दिखने वाला यह व्यवहार अंतर इस अंतर को उपयोगी बनाता है।

यदि ऐसे प्रकारों के बीच अंतर मौजूद है जो इतना "अमूर्त" है कि इसे तुरंत सत्यापित नहीं किया जा सकता है, कम से कम सैद्धांतिक रूप से, बाहर से, तो संभव है कि किसी को सही विकल्प बनाने के लिए किसी प्रकार के कार्यान्वयन को जानने की आवश्यकता हो। यह वह जगह है जहां वर्तमान abstract उपयोगी हो सकता है। यह शायद बीजीय डेटा प्रकारों की दिशा में जाता है।

ऐसा कोई कारण नहीं है कि प्रोटोकॉल का उपयोग केवल समूह प्रकारों के लिए नहीं किया जाना चाहिए, अर्थात बिना किसी परिभाषित विधियों की आवश्यकता के (और यह चाल का उपयोग करके "वर्तमान" डिज़ाइन के साथ संभव है: https://github.com/JuliaLang/julia/issues/ 6975#मुद्दे-161056795)। (यह भी ध्यान दें, यह निहित रूप से परिभाषित प्रोटोकॉल में हस्तक्षेप नहीं करता है।)

(Un)signed उदाहरण को ध्यान में रखते हुए: यदि मेरे पास एक प्रकार है जो Signed लेकिन किसी कारण से किसी अन्य सार प्रकार का उप-प्रकार भी होना चाहिए तो मैं क्या करूंगा? यह संभव नहीं होगा।

@eschnett : अमूर्त प्रकार, इस समय, उनके उपप्रकारों के कार्यान्वयन से कोई लेना-देना नहीं है। हालांकि इस पर चर्चा की गई है: #4935।

बीजीय डेटा प्रकार एक अच्छा उदाहरण हैं जहां क्रमिक शोधन आंतरिक रूप से सार्थक है।
कोई भी वर्गीकरण अधिक स्वाभाविक रूप से दिया जाता है, और प्रोटोकॉल विनिर्देशों के मेलजोल की तुलना में एक अमूर्त प्रकार पदानुक्रम के रूप में अधिक सीधे उपयोगी होता है।

एक से अधिक सार प्रकार के पदानुक्रम के उपप्रकार वाले प्रकार के बारे में नोट भी महत्वपूर्ण है। उपयोगितावादी शक्ति का एक अच्छा सौदा है जो अमूर्तता की कई विरासत के साथ आता है।

@ मौरो3 हाँ, मुझे पता है। मैं भेदभाव वाले यूनियनों के बराबर कुछ सोच रहा था, लेकिन टाइप सिस्टम के बजाय टुपल्स के रूप में कुशलतापूर्वक कार्यान्वित किया गया (जैसा कि वर्तमान में यूनियनों को लागू किया गया है)। यह एनम, अशक्त प्रकारों को कम कर देगा, और कुछ अन्य मामलों को वर्तमान में अमूर्त प्रकारों की तुलना में अधिक कुशलता से संभालने में सक्षम हो सकता है।

उदाहरण के लिए, अनाम तत्वों के साथ टुपल्स की तरह:

DiscriminatedUnion{Int16, UInt32, Float64}

या नामित तत्वों के साथ:

discriminated_union MyType
    i::Int16
    u::UInt32
    f::Float64
end

जिस बिंदु को मैं बनाने की कोशिश कर रहा था वह यह है कि जूलिया के लिए इस तरह के निर्माण को मैप करने के लिए अमूर्त प्रकार एक अच्छा तरीका है।

ऐसा कोई कारण नहीं है कि प्रोटोकॉल का उपयोग केवल समूह प्रकारों के लिए नहीं किया जाना चाहिए, यानी बिना किसी परिभाषित विधियों की आवश्यकता के (और यह चाल का उपयोग करके "वर्तमान" डिज़ाइन के साथ संभव है: # 6975 (टिप्पणी))। (यह भी ध्यान दें, यह निहित रूप से परिभाषित प्रोटोकॉल में हस्तक्षेप नहीं करता है।)

मुझे लगता है कि आपको प्रदर्शन हासिल करने के लिए इससे सावधान रहना होगा, ऐसा विचार जो बहुत से लोग अक्सर पर्याप्त नहीं मानते हैं। उदाहरण में ऐसा लगता है कि कोई गैर-किसी भी संस्करण को परिभाषित करना चाहता है ताकि संकलक अभी भी संकलन समय पर फ़ंक्शन चुन सके (रनटाइम पर सही चुनने के लिए फ़ंक्शन को कॉल करने के बजाय, या कंपाइलर निरीक्षण कार्यों के बजाय उनके परिणाम निर्धारित करने के लिए)। व्यक्तिगत रूप से मेरा मानना ​​​​है कि टैग के रूप में एकाधिक सार "विरासत" का उपयोग करना बेहतर समाधान होगा।

मुझे लगता है कि हमें टाइप सिस्टम के आवश्यक ट्रिक्स और ज्ञान को कम से कम रखना चाहिए (हालांकि इसे मैक्रो में लपेटा जा सकता है, यह मैक्रो के एक अजीब हैक की तरह महसूस होगा; अगर हम टाइप सिस्टम में हेरफेर करने के लिए मैक्रोज़ का उपयोग कर रहे हैं तो मुझे लगता है @ जेफबेजानसन का एकीकृत समाधान इस समस्या को बेहतर ढंग से ठीक करेगा)।

(अन) हस्ताक्षरित उदाहरण को ध्यान में रखते हुए: यदि मेरे पास एक प्रकार है जो हस्ताक्षरित है, लेकिन किसी कारण से किसी अन्य सार प्रकार का उप-प्रकार भी होना चाहिए तो मैं क्या करूंगा? यह संभव नहीं होगा।

एकाधिक सार विरासत।

मेरा मानना ​​​​है कि यह सब मैदान पहले कवर किया गया है, यह बातचीत मंडलियों में जा रही है (यद्यपि हर बार कड़े घेरे)। मेरा मानना ​​​​है कि यह उल्लेख किया गया था कि एक कॉर्पस या प्रोटोकॉल का उपयोग करने वाली समस्याओं का अधिग्रहण किया जाना चाहिए। यह हमें समाधानों का अधिक आसानी से न्याय करने की अनुमति देगा।

जबकि हम चीजों को दोहरा रहे हैं :) मैं सभी को याद दिलाना चाहता हूं कि अमूर्त प्रकार नाममात्र हैं जबकि प्रोटोकॉल संरचनात्मक हैं, इसलिए मैं ऐसे डिजाइनों का समर्थन करता हूं जो उन्हें ऑर्थोगोनल के रूप में मानते हैं, _unless_ हम वास्तव में प्रोटोकॉल में अमूर्त प्रकारों के स्वीकार्य "एन्कोडिंग" के साथ आ सकते हैं (शायद संबद्ध प्रकारों के चतुर उपयोग के साथ)। बोनस अंक, निश्चित रूप से, यदि यह कई अमूर्त विरासत भी देता है। मुझे लगता है कि यह संभव है लेकिन हम अभी तक पूरी तरह से नहीं हैं।

@JeffBezanson क्या "संबद्ध प्रकार" "[ए] प्रोटोकॉल से जुड़े ठोस प्रकार" से अलग हैं?

हां, मेरा ऐसा मानना ​​है; मेरा मतलब है "संबद्ध प्रकार" प्रोटोकॉल के तकनीकी अर्थों में कुछ कुंजी-मूल्य जोड़ी निर्दिष्ट करते हैं जहां "मान" एक प्रकार है, वैसे ही प्रोटोकॉल विधियों को निर्दिष्ट करते हैं। उदाहरण के लिए "टाइप फू कंटेनर प्रोटोकॉल का पालन करता है यदि उसके पास eltype " या "टाइप फू मैट्रिक्स प्रोटोकॉल का पालन करता है यदि इसका ndims पैरामीटर 2 है"।

सार प्रकार नाममात्र के होते हैं जबकि प्रोटोकॉल संरचनात्मक होते हैं और
सार प्रकार गुणात्मक होते हैं जबकि प्रोटोकॉल ऑपरेटिव होते हैं और
सार प्रकार (एकाधिक विरासत के साथ) प्रोटोकॉल आचरण करते समय ऑर्केस्ट्रेट करते हैं

यहां तक ​​​​कि अगर एक दूसरे में एक एन्कोडिंग थी, "अरे वहाँ, हाय .. आप कैसे हैं? चलो करते हैं!" जूलिया को दोनों को स्पष्ट रूप से प्रस्तुत करने की आवश्यकता है - प्रोटोकॉल की आम तौर पर उद्देश्यपूर्ण धारणा और बहु-विरासत योग्य सार प्रकार (सामान्यीकृत उद्देश्य की धारणा)। यदि कोई कलात्मक खुलासा है जो जूलिया को दोनों को अलग-अलग संलग्न करता है, तो यह एक से एक और दूसरे की तुलना में अधिक होने की संभावना है।

@ मेसन-बिली: तो हमें कई विरासत भी जोड़नी चाहिए? यह अभी भी इस समस्या को छोड़ देगा कि एक प्रकार के निर्माण के बाद सुपरटेप्स को जोड़ा नहीं जा सकता (जब तक कि इसकी भी अनुमति न हो)।

@JeffBezanson : विशुद्ध रूप से नाममात्र प्रोटोकॉल की अनुमति देने के लिए हमें कुछ भी नहीं रोकेगा।

@ मौरो 3 पोस्ट फैक्टो सुपरटेप सम्मिलन की अनुमति देने का निर्णय एकाधिक विरासत से क्यों जुड़ा होना चाहिए? और सुपरटेप निर्माण के विभिन्न प्रकार हैं, कुछ पेटेंट रूप से हानिरहित हैं जो एक नए को इंटरसेप्ट करने की क्षमता का अनुमान लगाते हैं-वे हैं: मैं रियल और एब्सट्रैक्ट फ्लोट के बीच एक अमूर्त प्रकार जोड़ना चाहता हूं, प्रोटोफ्लोट कहते हैं, ताकि मैं डबल पर प्रेषण कर सकूं- डबल फ्लोट्स और सिस्टम सिस्टम के साथ हस्तक्षेप किए बिना एक साथ फ़्लोट करता है एब्सट्रैक्ट फ्लोट के उपप्रकार के रूप में रहने वाले फ्लोट्स। शायद अनुमति देने में कम आसान, इंटीजर के वर्तमान उपप्रकारों को कम करने की क्षमता होगी, और इसलिए कई "अस्पष्ट .. पहले एफ (बूल) को परिभाषित करें .." संदेशों से बचें; या साइन का एक सुपरटाइप पेश करने के लिए जो इंटीजर का एक उप प्रकार है और संख्यात्मक पदानुक्रम को पारदर्शी संचालन के लिए खोलें, सामान्य संख्या कहें।

क्षमा करें यदि मैंने मंडली का एक और दौर शुरू किया है। विषय काफी जटिल है और हमें वास्तव में यह सुनिश्चित करना होगा कि समाधान का उपयोग करना बहुत आसान है। तो हमें कवर करने की जरूरत है:

• सामान्य समाधान
• कोई प्रदर्शन गिरावट नहीं
• उपयोग में आसानी (और समझने में भी आसान!)

चूंकि शुरुआत में # 6975 में जो प्रस्तावित किया गया था, वह बाद में चर्चा किए गए प्रोटोकॉल विचार से काफी अलग है, कुछ प्रकार का जेईपी होना अच्छा हो सकता है जो बताता है कि प्रोटोकॉल कैसा दिख सकता है।

आप एक औपचारिक इंटरफ़ेस को कैसे परिभाषित कर सकते हैं और वर्तमान 0.4 (मैक्रोज़ के बिना) का उपयोग करके इसे कैसे मान्य कर सकते हैं, इसका एक उदाहरण, प्रेषण वर्तमान में विशेषता शैली प्रेषण पर निर्भर करता है जब तक कि gf.c में संशोधन नहीं किए जाते हैं। यह सत्यापन के लिए उत्पन्न कार्यों का उपयोग करता है, सभी प्रकार की गणना टाइप स्पेस में की जाती है।

मैं इसे एक डीएसएल में रनटाइम चेक के रूप में उपयोग करना शुरू कर रहा हूं जिसे हम परिभाषित कर रहे हैं जहां मुझे यह सुनिश्चित करना है कि आपूर्ति किया गया प्रकार तिथियों का पुनरावर्तक है।

यह वर्तमान में सुपर प्रकार के एकाधिक वंशानुक्रम का समर्थन करता है, _super फ़ील्ड नाम का उपयोग रनटाइम द्वारा नहीं किया जाता है और यह कोई भी मान्य प्रतीक हो सकता है। आप _super Tuple को अन्य प्रकार की आपूर्ति कर सकते हैं।

https://github.com/mdcfrancis/tc.jl/blob/master/test/runtests.jl

यहां केवल यह इंगित करते हुए कि मैंने जूलियाकॉन से https://github.com/JuliaLang/julia/issues/5#issuecomment -230645040 पर संभावित सिंटैक्स के बारे में चर्चा पर एक अनुवर्ती कार्रवाई की है।

गाइ स्टील के पास कई प्रेषण भाषा (किले) में लक्षणों में कुछ अच्छी अंतर्दृष्टि है, उनका जूलियाकॉन 2016 मुख्य वक्ता के रूप में देखें: https://youtu.be/EZD3Scuv02g ।

कुछ हाइलाइट्स: बीजीय गुणों के लिए बड़ी विशेषता प्रणाली, एक विशेषता को लागू करने वाले प्रकारों के लिए विशेषता-गुणों का इकाई परीक्षण, और यह कि उन्होंने जो प्रणाली लागू की थी वह शायद बहुत जटिल थी और वह अब कुछ आसान करेगा।

प्रोटोकॉल के लिए टेंसरफ़्लो कंपाइलर AD उपयोगकेस के लिए नई स्विफ्ट:
https://gist.github.com/rxwei/30ba75ce092ab3b0dce4bde1fc2c9f1d
@timholy और @Keno को

मुझे लगता है कि इस समस्या के लिए डिज़ाइन स्थान की खोज करते समय यह प्रस्तुति ध्यान देने योग्य है।

गैर-विशिष्ट विचारों और प्रासंगिक पृष्ठभूमि कार्य के लिंक की चर्चा के लिए, एक संबंधित प्रवचन सूत्र शुरू करना और वहां पोस्ट करना और चर्चा करना बेहतर होगा।

ध्यान दें कि सांख्यिकीय रूप से टाइप की गई भाषाओं में जेनेरिक प्रोग्रामिंग पर शोध में सामने आई और चर्चा की गई लगभग सभी समस्याएं जूलिया के लिए अप्रासंगिक हैं। स्टेटिक भाषाएं लगभग अनन्य रूप से उस कोड को लिखने के लिए पर्याप्त अभिव्यक्ति प्रदान करने की समस्या से संबंधित हैं जो वे चाहते हैं जबकि अभी भी स्थिर रूप से टाइप करने में सक्षम हैं कि कोई प्रकार सिस्टम उल्लंघन नहीं है। हमें अभिव्यक्ति के साथ कोई समस्या नहीं है और स्थिर प्रकार की जांच की आवश्यकता नहीं है, इसलिए इनमें से कोई भी वास्तव में जूलिया में मायने नहीं रखता है।

हम जिस चीज की परवाह करते हैं, वह लोगों को एक संरचित तरीके से प्रोटोकॉल की अपेक्षाओं का दस्तावेजीकरण करने की अनुमति देती है, जिसे भाषा तब गतिशील रूप से सत्यापित कर सकती है (अग्रिम में, जब संभव हो)। हम लोगों को लक्षणों जैसी चीज़ों पर भेजने की अनुमति देने की भी परवाह करते हैं; यह खुला रहता है कि क्या उन्हें जोड़ा जाना चाहिए।

निचला रेखा: जबकि स्थिर भाषाओं में प्रोटोकॉल पर अकादमिक कार्य सामान्य रुचि का हो सकता है, यह जूलिया के संदर्भ में बहुत उपयोगी नहीं है।

हम जिस चीज की परवाह करते हैं, वह लोगों को एक संरचित तरीके से प्रोटोकॉल की अपेक्षाओं का दस्तावेजीकरण करने की अनुमति देती है, जिसे भाषा तब गतिशील रूप से सत्यापित कर सकती है (अग्रिम में, जब संभव हो)। हम लोगों को लक्षणों जैसी चीज़ों पर भेजने की अनुमति देने की भी परवाह करते हैं; यह खुला रहता है कि क्या उन्हें जोड़ा जाना चाहिए।

_वह है_:टिकट:

परिवर्तन को तोड़ने से बचने के अलावा, क्या जूलिया में अमूर्त प्रकारों का उन्मूलन और गोलंग-शैली के निहित इंटरफेस की शुरूआत संभव होगी?

नहीं, ऐसा नहीं होता।

ठीक है, यह नहीं है कि कौन से प्रोटोकॉल/लक्षण हैं? कुछ चर्चा हुई कि क्या प्रोटोकॉल को निहित या स्पष्ट करने की आवश्यकता है।

मुझे लगता है कि 0.3 (2014) के बाद से, अनुभव ने दिखाया है कि निहित इंटरफेस (यानी भाषा/संकलक द्वारा लागू नहीं) ठीक काम करते हैं। इसके अलावा, यह देखने के बाद कि कुछ पैकेज कैसे विकसित हुए, मुझे लगता है कि सबसे अच्छे इंटरफेस को व्यवस्थित रूप से विकसित किया गया था, और बाद में केवल औपचारिक रूप से (= प्रलेखित) किया गया था।

मुझे यकीन नहीं है कि किसी भी तरह भाषा द्वारा लागू किए गए इंटरफेस का औपचारिक विवरण आवश्यक है। लेकिन जब यह तय किया जाता है, तो निम्नलिखित को प्रोत्साहित करना बहुत अच्छा होगा (दस्तावेज़ीकरण, ट्यूटोरियल और स्टाइल गाइड में):

1. "इंटरफ़ेस" सस्ते और हल्के होते हैं, प्रकारों के एक सेट के लिए निर्धारित व्यवहार के साथ कार्यों का एक समूह (हां, प्रकार ग्रैन्युलैरिटी का सही स्तर हैं - x::T , T पर्याप्त होना चाहिए यह तय करने के लिए कि x इंटरफ़ेस लागू करता है या नहीं)। इसलिए यदि कोई एक्स्टेंसिबल व्यवहार वाले पैकेज को परिभाषित कर रहा है, तो इंटरफ़ेस को दस्तावेज़ित करना वास्तव में समझ में आता है।

2. इंटरफेस को उपप्रकार संबंधों द्वारा वर्णित करने की आवश्यकता नहीं है । एक सामान्य (गैर-तुच्छ) सुपरटेप के बिना प्रकार एक ही इंटरफ़ेस को लागू कर सकते हैं। एक प्रकार कई इंटरफेस को लागू कर सकता है।

3. अग्रेषण/रचना परोक्ष रूप से इंटरफेस की आवश्यकता है। "कैसे एक रैपर को माता-पिता के सभी तरीकों का उत्तराधिकारी बनाया जाए" एक ऐसा सवाल है जो अक्सर फसल होता है, लेकिन यह सही सवाल नहीं है। व्यावहारिक समाधान एक कोर इंटरफ़ेस होना है और इसे केवल रैपर के लिए लागू करना है।

4. लक्षण सस्ते होते हैं और इन्हें उदारतापूर्वक इस्तेमाल किया जाना चाहिए। Base.IndexStyle एक उत्कृष्ट विहित उदाहरण है।

निम्नलिखित स्पष्टीकरण से लाभान्वित होंगे क्योंकि मुझे यकीन नहीं है कि सबसे अच्छा अभ्यास क्या है:

1. क्या इंटरफ़ेस में एक क्वेरी फ़ंक्शन होना चाहिए, जैसे Tables.istable यह तय करने के लिए कि कोई ऑब्जेक्ट इंटरफ़ेस लागू करता है या नहीं? मुझे लगता है कि यह अच्छा अभ्यास है, अगर कोई कॉलर विभिन्न वैकल्पिक इंटरफेस के साथ काम कर सकता है और कमियों की सूची में नीचे जाने की जरूरत है।

2. डॉकस्ट्रिंग में इंटरफ़ेस दस्तावेज़ीकरण के लिए सबसे अच्छी जगह क्या है? मैं ऊपर क्वेरी फ़ंक्शन कहूंगा।

1. हां, प्रकार ग्रैन्युलैरिटी का सही स्तर हैं

ऐसा क्यों है? प्रकारों के कुछ पहलुओं को इंटरफेस (प्रेषण उद्देश्यों के लिए), जैसे पुनरावृत्ति में विभाजित किया जा सकता है। अन्यथा आपको कोड को फिर से लिखना होगा या अनावश्यक संरचना लागू करनी होगी।

1. इंटरफेस को उपप्रकार संबंधों द्वारा वर्णित करने की आवश्यकता नहीं है ।

शायद यह जरूरी नहीं है, लेकिन क्या यह बेहतर होगा? मेरे पास एक पुनरावर्तनीय प्रकार पर एक फ़ंक्शन प्रेषण हो सकता है। क्या एक टाइल वाले चलने योग्य प्रकार को पूरी तरह से पूरा नहीं करना चाहिए? जब उपयोगकर्ता केवल इंटरफ़ेस की परवाह करते हैं तो उन्हें नाममात्र प्रकारों के आसपास क्यों आकर्षित करना चाहिए?

नाममात्र सबटाइपिंग का क्या मतलब है यदि आप अनिवार्य रूप से उन्हें केवल सार इंटरफेस के रूप में उपयोग कर रहे हैं? लक्षण अधिक बारीक और शक्तिशाली प्रतीत होते हैं, इसलिए एक बेहतर सामान्यीकरण होगा। तो ऐसा लगता है कि प्रकार लगभग लक्षण हैं, लेकिन हमें उनकी सीमाओं (और इसके विपरीत) के आसपास काम करने के लिए लक्षण होना चाहिए।

नाममात्र सबटाइपिंग का क्या मतलब है यदि आप अनिवार्य रूप से उन्हें केवल सार इंटरफेस के रूप में उपयोग कर रहे हैं?

प्रेषण—आप नाममात्र प्रकार की वस्तु पर प्रेषण कर सकते हैं। यदि आपको यह भेजने की आवश्यकता नहीं है कि कोई प्रकार इंटरफ़ेस लागू करता है या नहीं, तो आप इसे केवल बतख टाइप कर सकते हैं। यही वह है जिसके लिए लोग आमतौर पर पवित्र लक्षणों का उपयोग करते हैं: विशेषता आपको एक कार्यान्वयन को कॉल करने के लिए प्रेषण करने देती है जो मानता है कि कुछ इंटरफ़ेस लागू किया गया है (उदाहरण के लिए "ज्ञात लंबाई")। ऐसा लगता है कि लोग संकेत की उस परत से बचना चाहते हैं लेकिन ऐसा लगता है कि यह केवल एक सुविधा है, आवश्यकता नहीं है।

ऐसा क्यों है? प्रकारों के कुछ पहलुओं को इंटरफेस (प्रेषण उद्देश्यों के लिए), जैसे पुनरावृत्ति में विभाजित किया जा सकता है। अन्यथा आपको कोड को फिर से लिखना होगा या अनावश्यक संरचना लागू करनी होगी।

मेरा मानना ​​​​है कि @tpapp कह रहा था कि आपको केवल यह निर्धारित करने के लिए प्रकार की आवश्यकता है कि कोई इंटरफ़ेस लागू करता है या नहीं, न कि सभी इंटरफेस को प्रकार पदानुक्रमों के साथ प्रदर्शित किया जा सकता है।

MacroTools के forward का उपयोग करते समय बस एक विचार:

कई विधियों को अग्रेषित करना कभी-कभी कष्टप्रद होता है

<strong i="9">@forward</strong> Foo.x a b c d ...

क्या होगा यदि हम Foo.x के प्रकार और विधि की एक सूची का उपयोग कर सकते हैं तो अनुमान लगा सकते हैं कि किसको अग्रेषित करना है? यह एक प्रकार का inheritance और इसे मौजूदा सुविधाओं (मैक्रोज़ + जेनरेट फ़ंक्शन) के साथ कार्यान्वित किया जा सकता है, यह किसी प्रकार का इंटरफ़ेस जैसा दिखता है, लेकिन हमें भाषा में किसी और चीज़ की आवश्यकता नहीं है।

मुझे पता है कि हम कभी भी एक सूची के साथ नहीं आए जो विरासत में मिलने वाला है (यही कारण है कि स्थिर class मॉडल कम लचीला है), कभी-कभी आपको केवल उनमें से कुछ की आवश्यकता होती है, लेकिन यह मुख्य कार्यों के लिए सुविधाजनक है ( (के उप-प्रकार जैसे किसी को एक आवरण को परिभाषित करना चाहते AbstractArray के आसपास) Array , कार्यों का सबसे बस अग्रेषित किए जाते हैं)

@datnamer : जैसा कि अन्य ने स्पष्ट किया है, इंटरफेस प्रकारों से अधिक दानेदार नहीं होना चाहिए (यानी इंटरफ़ेस को लागू करना कभी भी मूल्य पर निर्भर नहीं होना चाहिए, प्रकार को देखते हुए)। यह संकलक के अनुकूलन मॉडल के साथ अच्छी तरह से मेल खाता है और व्यवहार में कोई बाधा नहीं है।

शायद मैं स्पष्ट नहीं था, लेकिन मेरी प्रतिक्रिया का उद्देश्य यह बताना था कि हमारे पास पहले से ही उस हद तक इंटरफेस हैं जो जूलिया में उपयोगी हैं, और वे हल्के, तेज और पारिस्थितिक तंत्र के परिपक्व होने के साथ व्यापक होते जा रहे हैं।

एक इंटरफ़ेस का वर्णन करने के लिए एक औपचारिक युक्ति आईएमओ को थोड़ा मूल्य जोड़ती है: यह केवल दस्तावेज़ीकरण और यह जांचना होगा कि कुछ विधियां उपलब्ध हैं। उत्तरार्द्ध एक इंटरफ़ेस का हिस्सा है, लेकिन दूसरा भाग इन विधियों द्वारा कार्यान्वित शब्दार्थ है (उदाहरण के लिए यदि A एक सरणी है, तो axes(A) मुझे निर्देशांक की एक श्रृंखला देता है जो getindex लिए मान्य हैं

हालाँकि, मुझे जो देखना अच्छा लगेगा वह है

1. अधिक से अधिक इंटरफेस के लिए प्रलेखन (एक डॉकस्ट्रिंग में),

2. नए परिभाषित प्रकारों के लिए परिपक्व इंटरफेस के लिए स्पष्ट त्रुटियों को पकड़ने के लिए परीक्षण सूट (उदाहरण के लिए बहुत सारे T <: AbstractArray eltype(::T) और eltype(::Type{T}) ।

@tpapp अब मुझे समझ में आता है, धन्यवाद।

@StefanKarpinski मैं काफी समझ में नहीं आता। लक्षण नाममात्र के प्रकार नहीं हैं (दाएं?), फिर भी, उनका उपयोग प्रेषण के लिए किया जा सकता है।

मेरी बात मूल रूप से @tknopp और @mauro3 द्वारा बनाई गई है: https://discourse.julialang.org/t/why-does-julia-not-support-multiple-traits/5278/43?u=datnamer

कि लक्षण और अमूर्त टाइपिंग होने से, दो समान अवधारणाएं होने से अतिरिक्त जटिलता और भ्रम होता है।

ऐसा लगता है कि लोग संकेत की उस परत से बचना चाहते हैं लेकिन ऐसा लगता है कि यह केवल एक सुविधा है, आवश्यकता नहीं है।

क्या विशेषता पदानुक्रम के वर्गों को यूनियनों और चौराहों जैसी चीजों द्वारा समूहीकृत किया जा सकता है, प्रकार के मापदंडों के साथ, मजबूती से? मैंने इसकी कोशिश नहीं की है, लेकिन ऐसा लगता है कि इसके लिए भाषा समर्थन की आवश्यकता है। प्रकार डोमेन में आईई अभिव्यक्ति समस्या।

संपादित करें: मुझे लगता है कि समस्या इंटरफेस और लक्षणों का मेरा संयोजन था, क्योंकि उनका उपयोग यहां किया जाता है।

बस इसे यहां पोस्ट करना क्योंकि यह मजेदार है: ऐसा लगता है कि अवधारणाओं को निश्चित रूप से स्वीकार कर लिया गया है और सी ++ 20 का हिस्सा होगा। दिलचस्प सामान!

https://herbsutter.com/2019/02/23/trip-report-winter-iso-c-standards-meeting-kona/
https://en.cppreference.com/w/cpp/language/constraints

मुझे लगता है कि लक्षण इस मुद्दे को हल करने का एक बहुत अच्छा तरीका है और पवित्र लक्षण निश्चित रूप से एक लंबा सफर तय कर चुके हैं। हालांकि, मुझे लगता है कि जूलिया को वास्तव में एक विशेषता से संबंधित कार्यों को समूहीकृत करने का एक तरीका चाहिए। यह दस्तावेज़ीकरण कारणों के लिए उपयोगी होगा लेकिन कोड की पठनीयता के लिए भी उपयोगी होगा। मैंने अब तक जो देखा है, उससे मुझे लगता है कि रस्ट की तरह एक

मुझे लगता है कि यह बहुत महत्वपूर्ण है, और सबसे महत्वपूर्ण उपयोग केस इंडेक्सिंग इटरेटर्स के लिए होगा। यहां उस तरह के सिंटैक्स के लिए एक प्रस्ताव दिया गया है जिसकी आपको उम्मीद है कि यह काम करेगा। क्षमा करें यदि यह पहले से ही प्रस्तावित है (लंबा धागा ...)

import Base: Generator
<strong i="6">@require</strong> getindex(AbstractArray, Vararg{Int})
function getindex(container::Generator, index...)
    iterator = container.iter
    if <strong i="7">@works</strong> getindex(iterator, index...)
        container.f(getindex(iterator, index...))
    else
        <strong i="8">@interfaceerror</strong> getindex(iterator, index...)
    end
end