Julia: आवश्यकता हटाएं, आयात करें, और शायद आयात करें और उपयोग में विलय करें

हमें किसी भी तरह import Foo कार्यक्षमता की भी आवश्यकता होगी, जहां आपको केवल Foo मिलता है और कुछ नहीं

using Foo: ?

using Foo: Foo ?

Foo को फू मॉड्यूल से बांधने के लिए (और कुछ नहीं):
import Foo
Foo को मॉड्यूल फू से, x को Foo.x से, y को Foo.y से बाइंड करने के लिए
import Foo: x, y
मॉड्यूल फू के लिए Foo को बांधने के लिए, और फू के सभी निर्यात किए गए नाम अयोग्य हैं:
import Foo: *

इसके बजाय यह using हो सकता है, लेकिन मुझे लगता है कि यह import की भावना से अधिक है।

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

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

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

तो, संक्षेप में, मुझे @StefanKarpinski का प्रस्ताव पसंद है। संकल्पनात्मक रूप से हमें हार्ड और सॉफ्ट बाइंडिंग दोनों की आवश्यकता होती है, लेकिन हम एक ही कीवर्ड के साथ सभी उपयोगी व्यवहार प्राप्त कर सकते हैं।

तुम्हारी बात सही है। उस स्थिति में मुझे आपका प्रस्ताव पसंद है कि using Foo: (बृहदान्त्र के साथ लेकिन कोई आइटम नहीं) वैचारिक रूप से सुसंगत लगता है। बृहदान्त्र इंगित करता है कि आप सीमित करने जा रहे हैं कि कौन से प्रतीकों को खींचना है, लेकिन आप किसी को सूचीबद्ध नहीं करते हैं।

खाली पिछला : थोड़ा अजीब लगता है, लेकिन मुझे लगता है कि लोगों को इसकी आदत हो जाएगी

खाली अनुगामी बृहदान्त्र के साथ समस्या यह है कि हम वर्तमान में अगली पंक्ति में एक नाम की तलाश करते हैं - दूसरे शब्दों में using Foo: को अपूर्ण माना जाता है।

संबंधित: #4600

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

मुझे यह भी लगता है कि फू का उपयोग करने और फू.बार का उपयोग करने की वर्तमान ओवरलोडिंग है
समस्याग्रस्त; यह फू के अंदर दिखता है लेकिन फू.बार के अंदर नहीं (जब तक कि फू.बार नहीं है
एक मॉड्यूल?)

मुझे लगता है कि स्टीफन के प्रस्ताव में, इसे संबोधित किया गया है

फू का उपयोग करना: फू

गुरुवार, 14 अगस्त 2014 को toivoh [email protected] ने लिखा:

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

मुझे यह भी लगता है कि फू का उपयोग करने और फू.बार का उपयोग करने की वर्तमान ओवरलोडिंग है
समस्याग्रस्त; यह फू के अंदर दिखता है लेकिन फू.बार के अंदर नहीं (जब तक कि फू.बार नहीं है
एक मॉड्यूल?)

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

@kmsquire लेकिन अगर फू मॉड्यूल के अंदर फू मॉड्यूल है तो क्या होगा? यह दुर्भाग्य से अस्पष्ट है।

यह एक डिज़ाइन त्रुटि है (और चेतावनी का कारण बनती है), इसलिए इससे कोई फर्क नहीं पड़ता

मुझे सबसे ऊपर @ssfrr द्वारा प्रस्तावित संस्करण पसंद है।

क्या कोई अंतर्निहित सम्मेलन है कि पैकेज में एक और केवल एक मॉड्यूल प्रविष्टि बिंदु है? -- से import Foo का अर्थ है Foo Foo । कोई अन्य मॉड्यूल Foo का एक सबमॉड्यूल होना चाहिए। जिसका अर्थ है कि पैकेज फू, पैकेज में Foo.jl और इसके भीतर module Foo के बीच एक अंतर्निहित पत्राचार है।

मैं बी/सी से पूछता हूं कि मैं सोच रहा हूं कि क्या import का उपयोग स्थानीय/रिश्तेदार आयात के लिए भी किया जा सकता है। मान लें कि किसी प्रोजेक्ट में src/foo.jl और src/bar.jl है तो foo.jl में:

import bar

src/bar.jl से आयात करेगा। यह include का उपयोग करने पर एक सुधार है क्योंकि यह मॉड्यूल सिस्टम के भीतर संचालित होता है।

हां, पैकेज, पैकेज एंट्री पॉइंट और मॉड्यूल एक-से-एक होने की उम्मीद है। जरूरत पड़ने पर आप इस परंपरा को तोड़ सकते हैं, लेकिन इसकी ज्यादा जरूरत नहीं है क्योंकि मॉड्यूल सिर्फ नामकरण के लिए हैं और कार्यात्मक इकाइयां नहीं हैं। आप जो विचार ला रहे हैं वह #4600 है, सिवाय एक सापेक्ष आयात के लिए सिंटैक्स import .bar है जबकि import bar एक पूर्ण आयात है।

@StefanKarpinski क्या import .bar वास्तव में स्थानीय निर्देशिका में "bar.jl" की तलाश करता है? मैं इस धारणा के तहत था कि import .Bar केवल पहले से ही मौजूदा मूल मॉड्यूल के एक सबमॉड्यूल को संदर्भित करता है।

अद्यतन: दुह, यही आप # 4600 में प्रस्तावित करते हैं। माफ़ करना।

:+1:. अगर हम ऐसा करने जा रहे हैं, तो 0.4 इसे करने का एक अच्छा समय होगा।

:+1: कृपया आगे बढ़ें और इसमें से कुछ को साफ करें (0.4 के लिए!)

विस्तार करने या न करने के बीच अंतर करने के लिए दो आयात तंत्र होने के बजाय, फ़ंक्शन परिभाषा पर कीवर्ड या एनोटेशन के माध्यम से एक्सटेंशन साइट पर ही सिग्नल एक्सटेंशन क्यों नहीं, उदाहरण के लिए फ़ंक्शन से पहले कीवर्ड को ओवरराइड करें? जावा में @Override एनोटेशन के समान।

इसका लाभ यह है कि कोई स्पष्ट रूप से देखता है कि फ़ंक्शन दूसरे को ओवरराइड कर रहा है (और इसलिए एक विधि है)

यह पहले से ही संभव है, @ssagaert। आप इसे फ़ंक्शन परिभाषा में मॉड्यूल नाम स्पष्ट रूप से लिखकर करते हैं (उदाहरण के लिए, Base.print(…) = … ), और यह एक ऐसी शैली प्रतीत होती है जिस पर बहुत से लोग अभिसरण कर रहे हैं। एकमात्र स्टिकिंग पॉइंट यह है कि सिंटैक्स सभी संभावित नामों (जैसे .+ , आदि) के लिए काम नहीं करता है।

(एक तरफ के रूप में, कृपया अन्य गिटहब उपयोगकर्ताओं को परेशान करने से रोकने के लिए मैक्रोज़ को बैकटिक्स के साथ संलग्न करने के लिए सावधान रहें)।

:+1: @override का उपयोग करने के @ssagaert सुझाव के लिए, मूल त्रुटि संदेश जब कोई इसे आयात किए बिना किसी विधि का विस्तार करने का प्रयास करता है तो पहले इस तरह पढ़ता है:

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

तो शायद @extend अधिक उपयुक्त हो सकता है? मैं मूल अंग्रेजी बोलने वाला नहीं हूं, लेकिन मेरी समझ यह है कि _override_ का अर्थ कुछ इस तरह है: रद्द करना, शून्य करना, अमान्य करना, अस्वीकार करना, रद्द करना, रद्द करना, बंद करना, आदि।

मुझे लगता है कि यह अधिक स्पष्ट है:

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

से:

import Base: show

# ... several lines here

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

@ इस्माइल-वीसी Base.show(...) = ... पहले से ही कुछ भी आयात किए बिना काम करता है। import केवल तभी आवश्यक है जब आप show(...) = ... को Base.show का विस्तार करना चाहते हैं।

@ इस्माइल-वीसी ओवरराइड शब्द सिर्फ एक सुझाव था। इसे बढ़ाया जा सकता है या कुछ और सार्थक। इसके अलावा कोई @ नहीं होना चाहिए क्योंकि जूलिया में इसका मतलब है कि इसका मैक्रो ( @Override जावा को संदर्भित है जहां यह एक एनोटेशन है)।

@ सिमोंस्टर धन्यवाद, मुझे यह नहीं पता था!

@ssagaert तो आपका मतलब एक कीवर्ड है? मैंने ऐसा कुछ करने की कोशिश की लेकिन मैं अभी भी मैक्रो-फू पर चूसता हूं:

module Extend

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


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


end

मुझे पता है कि यह सामान्य नहीं है, फिर भी मैं एक अभिव्यक्ति नहीं कर सकता जो कि पार्स करता है:

julia> using Extend

julia> type Foo end

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

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

मुझे लगता है कि एक सामान्य और कामकाजी @extend मैक्रो आयात तंत्र के शब्दार्थ को नहीं बदलेगा।

@ इस्माइल-वीसी मैंने किया लेकिन मुझे @mbauman की 'चाल' भी पसंद है।

मुझे लगता है कि . का उपयोग करने में सक्षम होना अच्छा हो सकता है, जिसका अर्थ है "यह"। तो आप अभिव्यक्ति लिख सकते हैं जैसे कि:
import Base: . (मतलब आयात Base.Base )
या
using ..

मुझे पूरा यकीन है कि इसके लिए https://github.com/JuliaLang/julia/pull/11891#issuecomment -116098481 की आवश्यकता होगी। शायद यह . से पहले रिक्त स्थान की अनुमति देने के लिए पर्याप्त है, लेकिन इसके बाद नहीं, अस्पष्टता मामले को हल करने के लिए?

मेरा मानना ​​​​है कि आवश्यकता पहले से ही बहिष्कृत है। 1.0 से आयात करने वाले मॉड्यूल पर अधिक लचीला डॉट नोटेशन जोड़ना अच्छा हो सकता है, लेकिन मुझे संदेह है कि हम यहां 0.6 फीचर फ्रीज द्वारा कुछ भी बदलने जा रहे हैं

कल इस पर चर्चा के एक समूह के बाद मैं https://github.com/JuliaLang/julia/issues/8000#issuecomment -52142845 और https://github.com/JuliaLang/julia/ जैसे प्रस्तावों की ओर झुक रहा हूं।

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

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

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

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

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

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

वैकल्पिक रूप से import के बजाय using रखना होगा:

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

बाइंडिंग हार्ड या सॉफ्ट है या नहीं, इसके लिए सामान्य नियम सरल होगा: कोई भी स्पष्ट रूप से अनुरोधित नाम एक हार्ड बाइंडिंग है, कोई भी अंतर्निहित बाइंडिंग सॉफ्ट है।

संपादित करें: इस योजना में import A; import A: ... के लिए कुछ शॉर्टहैंड जोड़ने की कुछ इच्छा है जो लगभग using A वर्तमान में करता है (केवल अंतर यह है कि using A वर्तमान में नरम आयात A ); यह या तो using A जारी रह सकता है या import A... प्रस्तावित किया गया है।

हाँ, मुझे लगता है कि यह भी एक अच्छा प्रस्ताव है। मूल रूप से नीचे आता है कि कोई using या import पसंद करता है या नहीं।

परिशिष्ट, हम using A को import A; import A: ... के लिए शॉर्टहैंड के रूप में रख सकते हैं - वर्तमान व्यवहार से छुटकारा पाने के साथ-साथ प्रत्येक मॉड्यूल के लिए एक निर्यात बाध्यकारी है, यही कारण है कि using A कारण A के लिए एक सॉफ्ट बाइंडिंग उपलब्ध है।

अगर इस सब के बाद भी हमारे पास कई कीवर्ड होते तो मुझे बहुत निराशा होती।

मुझे import और export की समरूपता पसंद है। (जैसा कि किसी ने कहीं इशारा किया है।)

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

इस उद्देश्य के लिए हार्ड बाइंडिंग की भी आवश्यकता होती है:

import Package: x
x = 1   # gives an error

और महत्वपूर्ण बात यह है कि यह प्रस्ताव हमेशा कठोर बंधन नहीं करेगा --- केवल उन चीजों के लिए जिन्हें आप स्पष्ट रूप से सूचीबद्ध करते हैं। यह कहने की आवश्यकता है कि import के बजाय using अधिक सुरक्षा नहीं जोड़ता है।

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

क्या हमारे पास अभी भी आयातित बाइंडिंग को अधिलेखित करने की चेतावनी है?

मुझे लगता है कि मॉड्यूल योग्यता की आवश्यकता एक अच्छा विचार है। अभी यह जानने के लिए कि क्या कोई फ़ंक्शन पेश किया जा रहा है या कोई विधि विस्तारित है, आपको import A: func स्टेटमेंट के लिए पूरे पैकेज की सामग्री को देखना होगा।

क्या हमारे पास अभी भी आयातित बाइंडिंग को अधिलेखित करने की चेतावनी है?

मुझे विश्वास है कि यह वास्तव में अब एक त्रुटि है।

एक और प्रस्ताव है जो चारों ओर तैर रहा है जो दोनों खोजशब्दों को रखता है, लेकिन फिर भी चीजों को थोड़ा सरल करता है:

1. सिंटैक्स import A: ... . जोड़ें
2. using A: पदावनत करें
3. using A.B में, मॉड्यूल होने के लिए A.B की आवश्यकता होती है, और दस्तावेज़ कि यह import A.B; import A.B: ... के लिए एक शॉर्टहैंड है।

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

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

मेरा पसंदीदा दृष्टिकोण:

• विस्तार के लिए एक स्पष्ट मॉड्यूल उपसर्ग की आवश्यकता है
• यदि आप केवल मॉड्यूल का नाम चाहते हैं और इसके प्रतीक नहीं, तो using A: A . का उपयोग करें
• import निकालें और यह किस प्रकार का बंधन बनाता है

https://github.com/JuliaLang/julia/issues/8000#issuecomment -327512355 को लागू करने के लिए जिन चीजों की आवश्यकता होगी:

• using A के व्यवहार को कठिन आयात A . में बदलें
• using A: x . के लिए समर्थन निकालें
• using A.x के लिए समर्थन हटाएं जहां x एक सबमॉड्यूल नहीं है
• import A.x के लिए समर्थन हटाएं जहां x एक सबमॉड्यूल नहीं है
• ... सिंटैक्स के लिए import . में समर्थन जोड़ें

using A: x अक्सर प्रयोग किया जाता है और यह बहुत उपयोगी है। आप कह रहे हैं कि आप अपने नामस्थान में x चाहते हैं लेकिन आप इसे विस्तारित नहीं करना चाहते हैं। import A: x में, आप कह रहे हैं कि आप x का विस्तार करने में सक्षम होना चाहते हैं। उपयोग के लिए एक फ़ंक्शन उपलब्ध होने और इसे विस्तारित करने में सक्षम होने के बीच एक सार्थक अंतर है।

इसके बारे में सोचने के लिए आओ, मैं कहूंगा कि यहां सबसे बड़ी समस्या यह है कि using A.B दो चीजें करता है: यदि B एक मॉड्यूल है, तो यह अपने सभी निर्यातों को नरम आयात करता है, और अन्यथा केवल नरम आयात करता है B । मुझे लगता है कि हमें इसे ठीक करना चाहिए, और using A.B केवल मॉड्यूल के लिए अनुमति देना चाहिए, और एक समय में एक विशिष्ट बाइंडिंग को सॉफ्ट आयात करने के लिए using A: a, b होना चाहिए।

मैं पसंद करूंगा अगर import A: x लिखने का एक तरीका था, इसके बजाय यह import A.x के बराबर है।

मैं import A: x के लिए वोट करता हूं क्योंकि हम भी कर सकते हैं; import A: x, y, @z लेकिन import A.x, A.y, a.@z बदसूरत लगेगा।

क्या इसे 1.0 से हटाए जाने का मतलब यह है कि हमारे पास 1.0 के लिए using और import दोनों बचे रहेंगे? मेरी राय में यह थोड़ा दुर्भाग्यपूर्ण है।

कैसा रहेगा:

• विस्तार के लिए बल मॉड्यूल उपसर्ग। यह कोड को स्पष्ट कर देगा कि किसी अन्य फ़ाइल में आयात से आकस्मिक होने के बजाय एक एक्सटेंशन का इरादा है।
• using A बन जाता है import A: ...
• using A.X ( X एक मॉड्यूल है) आयात हो जाता है A.X: ...
• using A: X ( X एक मॉड्यूल नहीं है) import A: X बन जाता है
• import A: X नहीं बदला गया है लेकिन आप स्वचालित रूप से X का विस्तार नहीं कर सकते (पहला बिंदु देखें)
• using कीवर्ड हटाएं

क्या मुझे कुछ उपयोग-मामला याद आ रहा है? शायद यह पहले से ही सुझाया गया था ...

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

मुझे लगता है कि यह अनिवार्य रूप से उपरोक्त मेरे प्रस्ताव के समान है, जिसे उचित मात्रा में समर्थन मिला है। @JeffBezanson वास्तव में कम से कम उपयोग में आसानी के लिए using A रखना चाहता है और using A: x क्योंकि जाहिरा तौर पर (मैं इस पर बेचा नहीं गया हूं), यह एक बाध्यकारी आयात करने में सक्षम होने के लिए एक महत्वपूर्ण उपयोग मामला है इस तरह कि आप इसे बढ़ा नहीं सकते। दूसरी दिशा में जाने और import को using से बदलने के लिए कुछ प्रस्ताव हैं, लेकिन उनमें से किसी को भी वास्तव में अधिक कर्षण नहीं मिला ( import अधिक मौलिक लगता है)।

मुझे लगता है कि अंतर इसमें है:

• आयात A: x, y # x के लिए हार्ड बाइंडिंग और y से A

"हार्ड बाइंडिंग" का अर्थ ऐसा है कि आप इसे मॉड्यूल उपसर्ग के बिना बढ़ा सकते हैं, मेरे संस्करण में कोई हार्ड बाइंडिंग नहीं है। यदि आप विस्तार करना चाहते हैं, तो आप मॉड्यूल को ठीक उसी स्थान पर उपसर्ग करते हैं जहाँ आप इसे विस्तारित करते हैं। अन्य फाइलों में कोई डरावना import बयान नहीं है जो अर्थ बदल रहा है कि कुछ विस्तार है या नहीं।

और using A: x क्योंकि जाहिरा तौर पर (मैं इस पर बेचा नहीं गया हूं), यह एक महत्वपूर्ण उपयोग का मामला है जो एक बाध्यकारी को इस तरह से आयात करने में सक्षम है कि आप इसे विस्तारित नहीं कर सकते।

मॉड्यूल उपसर्ग को उस से निपटने के लिए मजबूर नहीं कर रहा है? या हम गैर मॉड्यूल के बारे में बात कर रहे हैं जैसे:

module M
    x = 1
end

import M: x; x = 2 और using M: x; x = 2 दोनों एक ही चेतावनी संदेश देते हैं इसलिए मुझे नहीं पता कि समस्या क्या है ...

using A को import A: ... से अधिक की आसानी के लिए रखना मेरी राय में थोड़ा अधिक लगता है।

मॉड्यूल उपसर्ग को उस से निपटने के लिए मजबूर नहीं कर रहा है?

हां; यदि आपको उन्हें विस्तारित करने के लिए कार्यों को योग्य बनाना था तो यह बिंदु अप्रासंगिक होगा।

अधिक आयात में आसानी के लिए A का उपयोग करते रहना A: ... मेरी राय में थोड़ा अधिक लगता है।

मैं इसे विपरीत तरीके से देखता हूं; लोगों को using A (जो अच्छा और छोटा है और हम सभी इसके लिए काफी अभ्यस्त हैं) से import A: ... पर स्विच करना केवल एक कृत्रिम आवश्यकता को पूरा करने के लिए है कि केवल 1 कीवर्ड अत्यधिक है।

धागे को पढ़ने से, ऐसा लगता है कि दो कीवर्ड रखने का मुख्य मूल्य उन बाइंडिंग के बीच अंतर करना है जिन्हें बढ़ाया जा सकता है या नहीं (हार्ड बाइंडिंग)। इसे ध्यान में रखते हुए, मुझे लगता है कि दो व्यवहार्य समाधान हैं:

• 1 कीवर्ड + को विस्तारित करने के लिए उपसर्ग की आवश्यकता है
• दो कीवर्ड, एक सामान्य (गैर-विस्तारित) उपयोग के लिए, और दूसरा विस्तारित उपयोग के लिए मैं इस मामले में using और extending का सुझाव देता हूं। import ठीक है, लेकिन extending दूसरे कीवर्ड के अस्तित्व का कारण स्पष्ट करता है

किसी भी मामले में मेरा सुझाव है कि using जैसा होना चाहिए जैसा कि अब केवल मॉड्यूल Foo को बाध्य करने के लिए निम्न में से एक के अतिरिक्त है:

• using Foo: nothing (अभी काम करता है)
• using Foo: Foo (अभी काम करता है)
• using Foo: (बाद में जोड़ा जा सकता है)

फिर extending को using के समान व्यवहार करना चाहिए, केवल अंतर यह है कि आप extending के साथ लाए गए बाइंडिंग का विस्तार कर सकते हैं, और संभवतः extending Foo अस्वीकार कर सकते हैं ताकि उसके पास हो स्पष्ट होना।

वर्तमान व्यवहार

| | उपलब्ध कराएं (उपयोग करके) | विस्तार योग्य (आयात) करें|
| ------------------- | -------------------------- | ----------------------- |
| केवल मॉड्यूल | using module: module या using module: nothing | import module |
| सब कुछ निर्यात किया | using module (दुष्प्रभाव: import module की तरह भी काम करता है) | ? |
| खास बातें | using module: x,y | import module: x,y |

सुझाव

| | उपलब्ध कराएं (उपयोग करके) | विस्तार योग्य (आयात) करें |
| ----------------- | ------------------------ | -------------------------- |
| केवल मॉड्यूल | using module | import module |
| सब कुछ निर्यात किया | using module: * | import module: * |
| खास बातें | using module: x,y | import module: x,y |

इसके बारे में अच्छी बात यह है कि अधिक आयात करना अधिक लिखने के अनुरूप है। यानी आप using module से शुरू करते हैं और यदि आप एक वैरिएबल को सीधे नेमस्पेस में आयात करना चाहते हैं तो आप nothing या module को हटाने के बजाय एक : x जोड़ते हैं। इसका मतलब यह भी है कि आपके द्वारा टाइप की जाने वाली सबसे छोटी चीज़ में सबसे कम शामिल है।

आप निर्यात की गई सभी चीज़ों को उपलब्ध कराने के लिए using: *,x भी कर सकते हैं और x जो निर्यात नहीं किया गया था।

पश्च संगतता के लिए समझौता:

| | उपलब्ध कराएं (उपयोग करके) | विस्तार योग्य (आयात) करें |
| ----------------- | ------------------------ | -------------------------- |
| केवल मॉड्यूल | using module: | import module: |
| सब कुछ निर्यात किया | using module: * | import module: * |
| खास बातें | using module: x,y | import module: x,y |

पश्चगामी संगतता के लिए वर्तमान व्यवहार के साथ using module और import module के आसपास रखें लेकिन इसे हटा दें।

@FelixBenning : import Module वर्तमान में (स्वयं द्वारा) किसी भी चीज़ को using Module से अधिक विस्तार योग्य नहीं बनाता है, यह केवल कोड लोड करता है और Module (और कुछ नहीं) नाम स्थान में लाता है। .

मैंने जो कुछ स्लैक पर कहा है उसे प्रतिबिंबित करने के लिए और ताकि यह स्लैक होल में गायब न हो:

मुझे नहीं लगता कि using X: * को हर निर्यात की गई चीज़ बनाम केवल using X उपलब्ध कराने के लिए डिफ़ॉल्ट बनाना लोगों को उनके द्वारा आयात की जाने वाली चीज़ों से अनिवार्य रूप से अधिक सावधान कर देगा। मुझे पता है, यह इंगित करना कि दूसरे इसे कैसे करते हैं, इसे खराब रूप माना जाता है, लेकिन पायथन में मूल रूप से वे शब्दार्थ हैं उनके import X और import X: * , फिर भी उनका पारिस्थितिकी तंत्र उन स्टार आयातों से अटा पड़ा है 🤷‍♂️ (और वे प्रसिद्ध रूप से उससे नफरत कर रहे हैं) मुझे नहीं लगता कि टाइप करने के लिए थोड़ा लंबा टेक्स्ट लोगों को वह करने से रोकता है जो वे सबसे सुविधाजनक मानते हैं: बस सब कुछ आयात/उपयोग करें और संकलक को इसे समझने दें। इसलिए मैं लोगों को उस तारे को स्पष्ट रूप से लिखने की जादुई गोली से सावधान करता हूं।

इसके अलावा, प्रस्तावित अर्थ के लिए import module: * और using module: * अनुपलब्ध है। इसका पहले से ही एक अर्थ है क्योंकि * एक वैध जूलिया पहचानकर्ता है और इसे + या शब्द mul की तरह ही आयात/उपयोग किया जा सकता है।

@tpapp या तो मैंने फिर से दस्तावेज़ीकरण को गलत समझा है, या import Module Module.x विस्तार योग्य बनाता है। जबकि using Module: x Module.x को विस्तार योग्य नहीं बनाता है। इसलिए import Module विस्तार के लिए कुछ उपलब्ध कराता है और using Module ऐसा भी करता है, यही वजह है कि मैंने नोट किया कि उपयोग करने का वह दुष्प्रभाव है।

(https://docs.julialang.org/en/v1/manual/modules/ से)

यह वास्तव में कोई फर्क नहीं पड़ता कि हम में से कौन सही है - किसी भी मामले में मौजूदा स्थिति स्पष्ट रूप से गड़बड़ है अगर हम यह भी नहीं समझ सकते कि सब कुछ क्या करता है।

@mbauman अच्छा बिंदु - मैं इसके बारे में भूल गया। मुझे वास्तव में * के बारे में परवाह नहीं है, केवल using चीजों को दर्पण करने की संरचना import आयात के अंतर के साथ करती है या नहीं, चीजें विस्तार योग्य हो जाती हैं या नहीं। तो यदि कोई अधिक उपयुक्त प्रतीक है - all , __all__ , everything , exported , ...? इसके लिए मैं उपलब्ध हूं। मुझे लगता है कि अधिक आयात करना शायद अधिक टाइप करके प्रतिबिंबित होना चाहिए।

लेकिन अगर आप ऐसा बिल्कुल नहीं चाहते हैं, तो आप निश्चित रूप से भी जा सकते हैं

| | उपलब्ध कराएं (उपयोग करके) | विस्तार योग्य (आयात) करें |
| ----------------- | ------------------------ | -------------------------- |
| केवल मॉड्यूल | using module: module | import module: module |
| सब कुछ निर्यात किया | using module | import module |
| खास बातें | using module: x,y | import module: x,y |

या

| | उपलब्ध कराएं (उपयोग करके) | विस्तार योग्य (आयात) करें |
| ----------------- | ------------------------ | -------------------------- |
| केवल मॉड्यूल | using module | import module |
| सब कुछ निर्यात किया | using module: module | import module: module |
| खास बातें | using module: x,y | import module: x,y |

लेकिन अंतिम परिणाम जो भी हो, वह सुसंगत होना चाहिए। और फिलहाल ऐसा नहीं है।

using A A.f विस्तार योग्य बनाता है, _not_ f अपने आप में। _just_ f का विस्तार करने के लिए यह घोषित किए बिना कि आप इसे किस मॉड्यूल से विस्तारित करना चाहते हैं, आपको स्पष्ट रूप से import A: f करना होगा। अन्यथा आपको अभी भी इसे अर्हता प्राप्त करनी होगी।

using . के शब्दार्थ के लिए निम्नलिखित की जाँच करें

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

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

julia> using .A

julia> f()
"no args in A"

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

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

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

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

और यह import के अर्थशास्त्र के लिए:

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

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

julia> import .A

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

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

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

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

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

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

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

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

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

@ फ़ेलिक्स बेनिंग : हाँ, मुझे लगता है कि आपने गलत समझा। एफडब्ल्यूआईडब्ल्यू, मुझे लगता है कि "... बनाता है Foo.x विस्तार योग्य" भेद तक पहुंचने का एक भ्रमित तरीका है --- आप हमेशा पूरी तरह से योग्य फ़ंक्शन नामों के तरीकों को परिभाषित कर सकते हैं। using Foo: x के साथ क्या होता है कि Foo को ही नाम स्थान में नहीं लाया जाएगा।

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

इस प्रकार मैं दस्तावेज़ों में यथास्थिति से संपर्क करूंगा:

1. using M मॉड्यूल को लोड करता है, और M और इसके निर्यात किए गए प्रतीकों को नाम स्थान में लाता है। यह एकमात्र मामला है जहां निर्यात मायने रखता है।
2. एक बार आपके पास M हो जाने पर, आप M.y जैसे योग्य नामों का उपयोग कर सकते हैं (ए) गैर-निर्यातित प्रतीकों तक पहुंचें और (बी) कार्यों में विधियां जोड़ें, भले ही वे निर्यात किए गए हों या नहीं
3. जब तक आप योग्य नामों जैसे M.f , या ...
4. ... import M: f , तो आप विधियों को परिभाषित करते समय केवल f का उपयोग कर सकते हैं।
5. import M और using M: x क्रमशः नाम स्थान में क्रमशः M या x (और M नहीं) लाने के लिए हैं। कुछ लोग यह सुनिश्चित करने के लिए पैकेज कोड में इन फॉर्मों का उपयोग करना पसंद करते हैं कि उनके नाम स्थान साफ ​​हैं (यहां प्रासंगिक शैली गाइड लिंक करें)।

आदेश कमोबेश अधिक उन्नत उपयोग के साथ सामने आए उपयोग के मामलों को दर्शाता है। उपरोक्त सभी सबमॉड्यूल पर लागू होते हैं, M M.A के साथ।

इस बारे में क्या:

• using M M के दायरे में लाता है
• using M: x M.x के दायरे में लाता है ( x के रूप में)
• using M: ... M के सभी निर्यात किए गए प्रतीकों को दायरे में लाता है
• using M: x, ... M के सभी निर्यात किए गए प्रतीकों को दायरे में लाता है और x (जिसे निर्यात नहीं किया जा सकता है)
• कोई import नहीं है। किसी फ़ंक्शन को विस्तारित करने के लिए आपको योग्य नाम का उपयोग करने की आवश्यकता है। (या using M; const foo = M.foo जैसा अब कोई पहले ही कर सकता है।)
• उपरोक्त सभी में, M भी एक सबमॉड्यूल हो सकता है, उदाहरण के लिए Foo.Bar और x वर्तमान अर्थ के साथ x as y भी हो सकता है।

या हम using import का उपयोग करते हैं जो तब इसे https://github.com/JuliaLang/julia/issues/8000#issuecomment -355960915 के बराबर बनाता है।

एक बहुत ही सामान्य उपयोग (विशेषकर "स्क्रिप्ट" में, लेकिन कुछ शैलियों के लिए पैकेज भी है)

using Foo, Bar, Baz

और सिर्फ निर्यातित प्रतीकों पर निर्भर है। इसे सबसे सरल, संभवतः उतना ही सरल रखने से कुछ लाभ होगा जितना अभी है।

@tpapp

मुझे लगता है कि आपने गलत समझा। एफडब्ल्यूआईडब्ल्यू, मुझे लगता है कि "... Foo.x को विस्तार योग्य बनाता है" भेद तक पहुंचने का एक भ्रमित तरीका है --- आप हमेशा पूरी तरह से योग्य फ़ंक्शन नामों के तरीकों को परिभाषित कर सकते हैं।

ठीक है, तो क्या मैं Foo.x के बाद using Foo: x का विस्तार कर सकता हूं? क्योंकि यदि हाँ, तो दस्तावेज़ीकरण पूर्ण नहीं है (मेरा स्क्रीनशॉट देखें)। यदि नहीं, तो मैं पूरी तरह से समझ गया हूं कि ये कथन कैसे काम करते हैं और स्पष्ट रूप से import Foo ने Foo.x एक्स्टेंसिबल बनाने के लिए कुछ किया है। इसलिए यह सचमुच Foo.x विस्तार के लिए उपलब्ध कराता है। इन शब्दों के हर मायने में। निश्चित रूप से यह विस्तार के लिए x उपलब्ध नहीं कराता है, लेकिन यही वह है जो import Foo: x के लिए है

ठीक है, तो क्या मैं Foo.x के बाद using Foo: x का विस्तार कर सकता हूं?

तब तक नहीं जब तक कि आप किसी तरह Foo को नेमस्पेस में नहीं लाते (जैसे using Foo )।

मैं पूरी तरह से समझ गया हूं कि ये कथन कैसे काम करते हैं

मैं इसके बारे में निश्चित नहीं हूं - हालांकि, यदि आपके पास मॉड्यूल और नेमस्पेस के बारे में प्रश्न हैं, तो कृपया डिस्कोर्स फोरम का उपयोग करें।

स्पष्ट रूप से import Foo ने Foo.x एक्स्टेंसिबल बनाने के लिए कुछ किया

केवल इस अर्थ में कि आपको किसी विधि को जोड़ने से पहले किसी योग्य नाम का उपयोग करके किसी फ़ंक्शन को संदर्भित करने में सक्षम होना चाहिए।

तो दस्तावेज पूरा नहीं है

मुझे लगता है कि यह एक अजीब तरह से है। उस विशेष उदाहरण में, यदि आप केवल using MyModule: x, p करते हैं; तो विस्तार के लिए कोई विधि उपलब्ध नहीं है, इसलिए तालिका सही है।

मैं सहमत हूं कि इसे बेहतर लिखा जा सकता है, जैसा कि मैंने ऊपर कहा। बहुत से लोग जिन्हें नेमस्पेस की आदत नहीं है, उन्हें यह भ्रमित करने वाला लगता है। और, टीबीएच, संपूर्ण using / import सर्कस थोड़ा भ्रमित करने वाला है, इसलिए यह मुद्दा है।

@tpapp

ठीक है तो यह बात है: यह बिल्कुल स्पष्ट नहीं है कि यदि मॉड्यूल नामस्थान में है तो आप प्रत्येक फ़ंक्शन को पूर्ण नाम से बढ़ा सकते हैं। मुझे पता है कि यह वर्तमान व्यवहार है, लेकिन मुझे नहीं लगता कि जो कोई इसे नहीं जानता वह पहले से ही ऐसा मान लेगा। विशेष रूप से क्योंकि नाम स्थान में होने का मतलब यह नहीं है कि यह विस्तार योग्य भी है। अगर मैं using module:x करता हूं तो मैं x का विस्तार नहीं कर सकता। जबकि मैं x का विस्तार कर सकता हूं, अगर मैं import module:x का उपयोग करता हूं। इसलिए यह एक उचित धारणा है, कि using और import के बीच का अंतर यह है कि आप आयातित कार्यों का विस्तार कर सकते हैं या नहीं।

इस धारणा का उपयोग करना समझ में आता है, अगर using module केवल module.x के उपयोग की अनुमति देगा लेकिन module.x के विस्तार की अनुमति नहीं देगा। जबकि import module module.x के विस्तार की अनुमति देगा। इसलिए यदि आप इस धारणा को लेते हैं और दस्तावेज़ीकरण पढ़ते हैं, तो आप पाएंगे कि इसके बारे में दो बातें गलत हैं।

1. using module आपको module.x का विस्तार करने की अनुमति देता है। इसलिए एक शिक्षार्थी से संबंधित using module का दुष्प्रभाव है , कि यह import module की तरह भी कार्य करता है - अर्थात यह module.x विस्तार योग्य बनाता है। और चीजों को विस्तार योग्य बनाना import चीज है, न कि using चीज
2. import के विपरीत, using न केवल module उपलब्ध कराता है, बल्कि इसमें सब कुछ उपलब्ध कराता है।

तो यही मैंने अपनी तालिका के साथ प्रतिनिधित्व करने की कोशिश की। यदि दो अलग-अलग शब्दों का उपयोग किया जाता है (आयात/उपयोग) तो उन्हें दो अलग-अलग काम करने चाहिए और वह स्पष्ट कट होना चाहिए। यदि using कभी-कभी विस्तार की अनुमति देता है और दूसरी बार ऐसा नहीं होता है तो यह अनुमानित व्यवहार नहीं है।

एक अच्छा विकल्प आयात को पूरी तरह से हटा देना है जैसा कि @martinholters सुझाव देते हैं। आपके पास बस दो शब्द नहीं हो सकते हैं जो कुछ चीजों के लिए यादृच्छिक रूप से उपयोग किए जाते हैं। यदि import का अर्थ है कुछ कार्यों को आयात करते समय चीजों को विस्तार योग्य बनाना, जबकि using module: foo इसकी अनुमति नहीं देता है, तो वही व्यवहार तब होना चाहिए जब आप नेमस्पेस में केवल module शामिल करते हैं।

सिर्फ इसलिए कि आप सब कुछ इसके पूरे नाम से अभी बढ़ा सकते हैं यदि मॉड्यूल नाम स्थान में है, तो इसका मतलब यह नहीं है कि यह एक स्पष्ट या सीधी बात है।

या तो नाम स्थान में होना पर्याप्त है, तो मुझे x का विस्तार करने में भी सक्षम होना चाहिए यदि मैंने इसे नामस्थान में using module:x के साथ शामिल किया है या नामस्थान में होना पर्याप्त नहीं है, और फिर मुझे भी करना चाहिए using कमांड का उपयोग करते समय module.x का विस्तार करने में सक्षम नहीं है।
या तीसरा विकल्प: कोई import नहीं है और आपको हर समय उनके पूर्ण नाम के साथ कार्यों का विस्तार करना होगा।

यह बिल्कुल स्पष्ट नहीं है कि यदि मॉड्यूल नामस्थान में है तो आप प्रत्येक फ़ंक्शन को पूर्ण नाम से बढ़ा सकते हैं।

मैं सहमत हूं, यही कारण है कि मैं दस्तावेज़ों के पुनर्लेखन के लिए तर्क देता हूं। हालाँकि, यह वर्तमान मुद्दे के लिए स्पर्शरेखा है। मौजूदा एपीआई पर दस्तावेज़ीकरण में सुधार के लिए (1) प्रस्तावों को रखना सबसे अच्छा होगा और (2) इसे अलग करने के प्रस्तावों को अलग करना, भले ही दोनों कुछ हद तक संबंधित हों। मैं जल्द ही (1) के लिए पीआर बनाने की योजना बना रहा हूं।

@tpapp आप कुछ ऐसा दस्तावेज नहीं कर सकते जो स्वाभाविक रूप से समझ में न आए। इनमें से कोई भी दस्तावेज सही नहीं है:

1. "आप कुछ भी बढ़ा सकते हैं जो नाम स्थान में है" (क्योंकि using module:x आपको x का विस्तार करने की अनुमति नहीं देता है)
2. "नाम स्थान में होना विस्तार के लिए पर्याप्त नहीं है, यही कारण है कि अलग-अलग शब्द using और import मौजूद हैं" (गलत क्योंकि पूर्ण नामों के लिए यह वास्तव में नामस्थान में होना पर्याप्त है - इसे रोकना पर्याप्त होना मेरा सुझाव था)
3. "आप नामस्थान में किसी भी चीज़ को उसके पूरे नाम से बढ़ा सकते हैं" (जिसे पूर्ण सत्य होने के लिए मौजूदा को रोकने के लिए import module:x की आवश्यकता होगी - @martinholters प्रस्ताव)

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

आप किसी ऐसी चीज का दस्तावेजीकरण नहीं कर सकते जिसका स्वाभाविक रूप से कोई मतलब नहीं है।

वर्तमान मॉड्यूल एपीआई अच्छी तरह से परिभाषित है, इसलिए इसे दस्तावेज किया जा सकता है (यह पहले से ही है, मुझे लगता है कि यह बेहतर होना चाहिए)।

इनमें से कोई भी दस्तावेज सही नहीं है:

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

@tpapp शायद मुझे कहना चाहिए था,

आप किसी गैर-भ्रमित तरीके से किसी चीज़ का दस्तावेज़ीकरण नहीं कर सकते जो स्वाभाविक रूप से समझ में नहीं आता है

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

क्या तुम सच में नहीं देखते कि मैं क्या बताने की कोशिश कर रहा हूँ?

मुझे लगता है कि आम सहमति है कि वर्तमान स्थिति अनावश्यक रूप से जटिल है और अपर्याप्त रूप से प्रलेखित है। और निःसंदेह, मशीनरी को सरल बनाने से दस्तावेज़ीकरण आसान हो जाएगा। लेकिन ऐसा सरलीकरण टूट रहा होगा, इसलिए 2.0 से पहले नहीं किया जा सकता। तो क्या आपकी बात यह है कि इससे पहले दस्तावेज़ीकरण में सुधार का कोई मतलब नहीं होगा? तब मैं असहमत हूं। मुझे दो अलग-अलग मुद्दे दिखाई देते हैं: 2.0 के साथ किया जाने वाला सरलीकरण (जो इस मुद्दे के बारे में है) जिसमें (उम्मीद है) आवश्यक दस्तावेज अपडेट शामिल होंगे और मौजूदा कामकाज के दस्तावेज में सुधार होगा जो इस धागे को पढ़ने से बुरी तरह आवश्यक लगता है लेकिन एक और मुद्दा है .

#38271 करने के बाद, मुझे लगता है कि उत्कृष्ट प्रश्न हैं

अन्य मॉड्यूल में कार्यों में जोड़ने के तरीकों को कैसे संभालें

1. हमेशा पूरी तरह से योग्य नामों की आवश्यकता होती है ( Foo.bar() = ... ),
2. प्रतीक के दायरे में होने पर भी अनुमति दें ( using Foo: bar; bar() = ... )
3. (2), लेकिन एक विशेष तरीके से दायरे में लाएं ( यथास्थिति , import Foo: bar; bar() = ... )

कौन सा सिंटैक्स निर्यात सूचियों और केवल मॉड्यूल नाम को संभालता है

1. using Foo Foo में सभी निर्यात किए गए प्रतीकों को दायरे में लाता है, import Foo बस मॉड्यूल ( यथास्थिति )
2. using Foo: ... या कुछ अन्य समान वाक्यविन्यास, फिर using Foo बस मॉड्यूल।

(1|2) और 2 एकल-पंक्ति को खोने की कीमत पर using या import में एक कीवर्ड में एकीकरण की अनुमति देगा

using LinearAlgebra, Random, StaticArrays

मुझे यकीन नहीं है कि यह इसके लायक है, यहां तक ​​​​कि ब्रेकिंग परिवर्तन पर विचार किए बिना भी।

यह उन समस्याओं में से एक नहीं है जो एक साफ समाधान प्रदान करती हैं जो मूल डिजाइन अभी छूट गई थी; ट्रेडऑफ हैं। मैं इंतजार करूंगा और देखूंगा कि क्या मौजूदा (1.0) सेटअप को बनाए रखते हुए बेहतर दस्तावेज उपयोगकर्ता अनुभव में सुधार कर सकते हैं।

2.0 के लिए मुझे लगता है कि वास्तव में जो हो रहा है उसके बारे में अधिक सुसंगत और वर्णनात्मक होने के लिए सिंटैक्स की सफाई ही अच्छी होगी। कुछ इस तरह:

| इससे पहले | के बाद |
|-|-|
| using Foo | useall from Foo |
| import Foo | use Foo |
| using Foo: a | use a from Foo |
| import Foo: a और import Foo.a | extend a from Foo |