Julia: एपीआई स्थिरता की समीक्षा

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

नहीं, यह उसके लिए एक अच्छी जगह है। और हाँ, हमें उन सभी नामों को खत्म करने का प्रयास करना चाहिए जहाँ अंडरस्कोर आवश्यक हैं :)

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

@Tkelman के दूसरे बिंदु के लिए, https://github.com/JuliaLang/julia/issues/28150 देखें

find और संबंधित कार्यों के लिए एपीआई के संबंध में हाल ही में Julep भी था: https://github.com/JuliaLang/Juleps/blob/master/Find.md

क्या हमें चैनलों पर put! और take! (और शायद वायदा के लिए भी ऐसा ही) करना चाहिए क्योंकि हमारे पास push! और shift! हैं? बस एपीआई में 2 निरर्थक शब्दों को हटाने का सुझाव दे रहा है।

मुझे shift! उपयोगकर्ता के अनुकूल होने का संदेह है। एक उम्मीदवार fetch! हमारे पास पहले से ही fetch जो take! का नॉन-म्यूटिंग संस्करण है

रेफ # 13538 # 12469

@amitmurthy @malmaud

संपादित करें: चैनलों पर send और recv का पुन: उपयोग करना भी समझ में आएगा। (मुझे आश्चर्य है कि ये फिलहाल केवल यूडीपीएस के लिए उपयोग किए जाते हैं)

+1 को put! / take! push! / fetch! साथ बदलने के लिए

मैं @inferred से @test_inferred नाम जोड़ूंगा।

डबल-चेक करें कि विशेषज्ञ अधिक सामान्य कार्यों के अनुरूप हैं, अर्थात # 20233 जैसी कोई चीज़ नहीं।

सभी निर्यात किए गए फ़ंक्शंस की समीक्षा करें कि क्या उन्हें कई प्रेषण के साथ समाप्त करके समाप्त किया जा सकता है, जैसे कि print_with_color

जब एक कतार जैसी डेटा संरचना के साथ काम करते हुए विशिष्ट युग्मन push! और shift! होता है।

यदि हम इस प्रकार की डेटा संरचना के लिए विशिष्ट नाम युग्मन का उपयोग नहीं करने जा रहे हैं, क्योंकि हम चिंतित हैं कि ऑपरेशन संचार ओवरहेड पर जोर देता है जो कि उन नामों से पर्याप्त रूप से अवगत नहीं है, तो मुझे नहीं लगता कि push! या तो समझ में आता है। send और recv वास्तव में बेहतर हो सकता है।

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

शायद इस मुद्दे के लिए बहुत बड़ा है, लेकिन जब कार्य त्रुटियों को फेंकना चाहिए, तो लगातार नियम रखना अच्छा होगा, और जब उन्हें Nullable s या Union s (जैसे parse / tryparse , match , आदि)

कोई बड़ा मुद्दा नहीं, @simonbyrne - यह कपड़े धोने की सूची है।

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

हमारे पास @code_xxx जैसे बहुत सारे उपकरण हैं जो अंतर्निहित कार्यों जैसे code_xxx के साथ जोड़े जाते हैं

सुनिश्चित नहीं हैं कि यह वही है जिसके बारे में आप बात कर रहे हैं, लेकिन CreateMacrosFrom.jl देखें

• चाहे "आउटपुट टाइप" एपीआई तत्व प्रकार या समग्र कंटेनर प्रकार के संदर्भ में होना चाहिए (Ref # 11557 और # 16740)

• सभी निर्यात किए गए फ़ंक्शंस दस्तावेज़ (सहित सिद्धांत)

सभी निर्यात किए गए फ़ंक्शंस दस्तावेज़ (सहित सिद्धांत)

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

@dpsanders : और मैक्रोज़ को निर्यात किया! जैसे @fastmath का कोई डॉकस्ट्रिंग नहीं है।

यह बहुत मामूली है, लेकिन string और Symbol फ़ंक्शंस लगभग एक ही काम करते हैं और बड़े पूंजीकरण होते हैं। मुझे लगता है कि symbol अधिक समझ में आएगा।

@amellnik अंतर यह है कि Symbol एक प्रकार का निर्माता है और string एक नियमित कार्य है। IIRC में हमारे पास symbol लेकिन यह प्रकार के निर्माणकर्ता के पक्ष में पदावनत किया गया था। मुझे यकीन नहीं है कि इसके लिए एक बदलाव आवश्यक है, लेकिन अगर मुझे लगता है कि हमें String स्थान पर string String कन्स्ट्रक्टर का उपयोग करना चाहिए।

अगर मुझे लगता है कि हमें स्ट्रिंग के स्थान पर स्ट्रिंग कंस्ट्रक्टर का उपयोग करना चाहिए।

नहीं, वे अलग-अलग कार्य हैं और इन्हें मर्ज नहीं किया जाना चाहिए

julia> String(UInt8[])
""

julia> string(UInt8[])
"UInt8[]"

नहीं, वे अलग-अलग कार्य हैं और इन्हें मर्ज नहीं किया जाना चाहिए

यह एक ऐसी स्थिति लगती है, जहां string(args...) को sprint(print, args...) पक्ष में चित्रित किया जाना चाहिए, फिर - string और String होना भ्रामक है। हम किसी भी खोए हुए प्रदर्शन को पुनर्प्राप्त करने के लिए sprint(::typeof(print), args...) पर विशेषज्ञ कर सकते हैं। इन पंक्तियों के साथ, यह repr(x) लिए sprint(showall, args...) repr(x) को कम करने के लिए भी समझ में आ सकता है।

यह ठीक लगता है, हालांकि एक स्ट्रिंग में कुछ मोड़ करने के लिए string कॉल करना काफी मानक लगता है ...।

एक स्ट्रिंग में कुछ मोड़ करने के लिए स्ट्रिंग को कॉल करना बहुत मानक लगता है

हां, लेकिन यह वह जगह है जहां String और string बीच का डिस्कनेक्ट आता है।

sprint(print, ...) बेमानी लगता है। अगर हम string से छुटकारा पा लेते हैं, तो हम sprint से string नाम बदल सकते हैं, इसलिए हमें string(print, foo) और string(showall, foo) जो मेरी राय में अच्छा है ।

यह एक ऐसा मामला हो सकता है जहां स्थिरता अधिक हो। मुझे लगता है कि "बस मुझे एक स्ट्रिंग का प्रतिनिधित्व दे" के लिए string(x) ठीक है। यदि यह उससे अधिक जटिल होने जा रहा है, जैसे आपको यह निर्दिष्ट करने की आवश्यकता है कि किस प्रिंटिंग फ़ंक्शन का उपयोग करना है, तो sprint जैसे किसी अन्य नाम का उपयोग करने से समझ में आता है।

मेरे साथ String(UInt8[]) किसी और चीज़ का नाम देना भी ठीक होगा, और String बजाय string । string हमें भविष्य में थोड़ा अधिक लचीलापन देता है कि हम किस प्रकार के स्ट्रिंग को बदल दें, लेकिन ऐसा होने की संभावना नहीं है।

क्या reinterpret(String, ::Vector{UInt8} मतलब बिल्कुल नहीं है, या क्या यह reinterpret पर एक दंड है?

यह समझ में आता है।

एक मुद्दा यह है कि यह फ़ंक्शन कभी-कभी नकल कर रहा है, इसलिए यह नाम कुछ भ्रामक है।

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

एक String(::IOBuffer) विधि भी है, लेकिन ऐसा लगता है कि readstring लिए पदावनत किया जा सकता है।

मैंने आपके प्रस्तावित एपीआई परिवर्तन के बारे में सोचा है, लेकिन string(a, b...) का इंटरफ़ेस यह है कि यह अपने तर्कों को कठोर और संक्षिप्त करता है, और यह कॉल करने योग्य प्रथम तर्कों के लिए एक कष्टप्रद गेटा अपवाद बना देगा। यदि हम string से कॉनटेनैशन को हटाते हैं तो यह काम करने के लिए बनाया जा सकता है।

हाँ, सहमत; स्थिरता और गॉच से बचना सबसे महत्वपूर्ण है।

"आयाम तर्क" श्रेणी में नोटिंग # 18326 और # 3893 अंक।

यदि मैं किसी अन्य वस्तु पर सौदा कर सकता हूं: तो यह सुनिश्चित करना कि उत्परिवर्तनों के कंटेनरों का व्यवहार प्रलेखित और सुसंगत दोनों है।

@ JaredCrean2 : क्या आप इसका विस्तृत मतलब

मुझे निश्चित रूप से उम्मीद है कि इसमें बहुत सारी "रक्षात्मक प्रतियां" शामिल नहीं हैं।

उदाहरण के लिए, यदि मेरे पास उत्परिवर्तित प्रकारों की एक सरणी है और मैं उस पर sort कॉल करता हूं, तो लौटा हुआ सरणी इनपुट ऑब्जेक्ट के रूप में समान ऑब्जेक्ट्स को इंगित करता है, या क्या यह ऑब्जेक्ट्स की प्रतिलिपि बनाता है और रिटर्न किए गए सरणी बिंदु को इंगित करता है उन्हें?

वही वस्तुएं। मुझे पूरा यकीन है कि हमारे सभी संग्रह छंटनी कर रहे हैं, getindex, छानने, खोज, आदि तरीके इस नियम का पालन करते हैं, नहीं?

मुझे नहीं लगता कि उस बिंदु पर स्पष्टता या निरंतरता की कोई कमी है - यह हमेशा एक ही वस्तु है।

वास्तव में, मुझे लगता है कि एकमात्र मानक फ़ंक्शन जहां यह मामला नहीं है deepcopy जहां पूरे बिंदु यह है कि आपको नई वस्तुएं मिलती हैं।

क्या वह दस्तावेज कहीं है?

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

नमस्ते। मैंने देखा नहीं है कि मैं डेटा क्रमांकन के बारे में कोई टिप्पणी मानता हूं।

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

क्या हम https://github.com/JuliaLang/julia/blob/v0.5.1/base/serialize.jl के करीब रहने के लिए उपयोगकर्ता डेटा के क्रमबद्धता की उम्मीद कर सकते हैं?

फ़ंक्शंस अनावश्यक रूप से प्रतियां क्यों बनाएंगे? आपको यह धारणा कहां से मिली कि वे हो सकते हैं?

मैं नहीं जानता कि वे करते हैं या नहीं। जहां तक ​​मैं बता सकता हूं, व्यवहार अपरिभाषित है। @JeffBezanson की टिप्पणी से, ऐसे लोग हैं जो रक्षात्मक प्रतियां बनाने की वकालत करते हैं, जिसका वह विरोध करते हैं। तो प्रलेखन को रक्षात्मक प्रतियों के प्रश्न को संबोधित करना चाहिए।

आप किसी प्रकार के कम-से-कम सिद्धांत को लागू कर रहे हैं, लेकिन एल्गोरिथ्म के विवरण के आधार पर, "कम से कम कार्रवाई" क्या अस्पष्ट है। पूरे एपीआई में स्थिरता प्राप्त करने के लिए, मुझे लगता है कि अधिक विशिष्ट मार्गदर्शन की आवश्यकता है।

@ o314 : यह एक एपीआई स्थिरता समीक्षा मुद्दा है, मुझे यकीन नहीं है कि क्रमबद्धता कैसे संबंधित है।

@ JaredCrean2 : शीर्ष-स्तरीय ऑब्जेक्ट की प्रतिलिपि बनाई गई है या नहीं, निश्चित रूप से प्रलेखित होने की आवश्यकता नहीं है। मैं जो कह रहा हूं वह यह है कि गहरी वस्तुओं को कभी भी कॉपी नहीं किया जाता है, केवल डीकोपी (स्पष्ट रूप से) को छोड़कर।

मैं जो कह रहा हूं वह यह है कि गहरी वस्तुओं को कभी भी कॉपी नहीं किया जाता है, केवल डीकोपी (स्पष्ट रूप से) को छोड़कर।

सरणी रैपर के लिए copy के संदर्भ में इस बारे में हाल ही में एक चर्चा हुई थी, उदाहरण के लिए SubArray और SparseMatrixCSC लेकिन Symmetric , LowerTriangular । मुझे ऐसा लगता है कि उपर्युक्त नीति के तहत, ऐसे रैपर प्रकारों के लिए copy होगा। क्या नीति आप अमूर्त के सही स्तर का उल्लेख करते हैं? उदाहरण के लिए, मुझे लगता है कि अगर जूलिया में Array s को लागू किया गया था (बफर को लपेटते हुए), तो copy Array s का व्यवहार तब एक नॉओप में बदल जाना चाहिए।

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

संपादित करें: एंड्रियास पोस्ट नहीं देखा। यह एक दिलचस्प विचार है।

@StefanKarpinski मैं आपकी बात से सहमत हूं।
और यहां लगाए गए सभी मुख्य विषय बहुत अच्छे और चतुर हैं।

लेकिन मुझे कभी-कभी जूलिया में प्रक्रिया और डेटा के बीच संतुलन को लेकर थोड़ा डर है:

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

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

मैंने कुछ बहुत अच्छे अजगर पुस्तकालय को इस तरह से डूबते देखा है और यह एक दया है।

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

हो सकता है कि इस विषय में वह बात न हो।

@StefanKarpinski मुझे आपकी पोस्ट गलत समझ सकती है। तुमने कब कहा था

क्या शीर्ष-स्तरीय ऑब्जेक्ट की प्रतिलिपि बनाई गई है या नहीं, निश्चित रूप से प्रलेखित होने की आवश्यकता नहीं है

"शीर्ष-स्तरीय वस्तु" का क्या अर्थ है? यदि मेरे पास x::Vector{MyMutableType} , तो शीर्ष स्तर की वस्तु x या x के तत्व है?

शीर्ष-स्तरीय वस्तु x स्वयं को संदर्भित करती है, न कि x के तत्व।

@andreasnoack शीर्ष-स्तरीय ऑब्जेक्ट की धारणा को लागू किए गए सार संरचना को संदर्भित करना चाहिए, न कि कार्यान्वयन विवरण।

शायद float और अन्य समान फ़ंक्शन जोड़ें जो दोनों प्रकार के मूल्यों पर कार्य करते हैं?

0.6 रिलीज़ नोटों के ऊपर जाने पर, यह अजीब लगता है कि iszero(A::Array{T}) पेश किया जाता है, जबकि कई अन्य कार्य (जैसे sumabs , isinteger , isnumber ) से अधिक बकाया हैं। all(f,A) पक्ष में पदावनत किया गया।

शून्य सरणियाँ हैं, और वे अपने वेक्टर स्थान में शून्य तत्व हैं। iszero उदारतापूर्वक परीक्षण कि क्या कुछ योजक व्युत्क्रम है, जो शून्य सरणियाँ हैं।

पुन। समारोह के नामों में अंडरस्कोर की स्थिरता, यहाँ count_ones और count_zeros ब्रेडक्रम्ब है।

यह मुझे लगता है कि यदि आप जूलिया एपीआई को लगातार बनाए रखना चाहते हैं, तो आपको कुछ ऐसे सॉफ़्टवेयर की आवश्यकता होगी जो आपको (क) यह निर्दिष्ट करें कि एपीआई नियम / नियम क्या हैं, (ख) पता लगाने के लिए जूलिया कोड का स्थैतिक विश्लेषण करें उन नियमों / सम्मेलनों से विचलन, और (ग) सुझाव देते हैं। इस तरह के उपकरण से जूलिया बेस और जूलिया पैकेज दोनों को फायदा होगा। एक नया जूलिया पैकेज कर सकता है। (गाल में जीभ: पहली बात यह है कि इस पैकेज को अपना नाम सुझाना चाहिए; APICheck.jl, ApiCheck.jl, API_Check.jl, APIChecker.jl, JuliaAPICLer.jl, आदि) मैं जूलिया के लिए नया हूँ। इसलिए ऐसी किसी चीज पर बढ़त नहीं लेना चाहता। हालांकि, मुझे योगदान करने में कोई दिक्कत नहीं होगी। यह कैसे प्राप्त करने के लिए कोई सुझाव?

हम Lint.jl में है कि प्यार करता हूँ!

num2hex और hex2num (# 22031 और # 22088)

मेरा भी मानना ​​है कि Lint.jl जूलिया एपीआई स्थिरता जाँच के लिए सही पैकेज है। लेकिन अगर हम उस मार्ग पर जाते हैं, तो स्टीफन की मूल सूची को और अधिक सटीक बनाया जाना चाहिए। उदाहरण के लिए जब वह लिखते हैं "हमें यह सुनिश्चित करना चाहिए कि DataStructures में सभी संग्रह में संगत API हैं" सवाल जो मन में आते हैं वे हैं:

• क्या डेटा संरचना को एक संग्रह बनाता है? (आधार में संग्रह की सूची)
• वे कौन से कार्य हैं जिनका एक संग्रह MUST सपोर्ट करता है? (संग्रह द्वारा कार्यों की स्प्रेडशीट)
• उन कार्यों में से प्रत्येक के हस्ताक्षर क्या होने चाहिए?
• क्या आधार द्वारा संग्रह के लिए उपलब्ध कराई गई एपीआई वास्तव में पहले से ही सुसंगत हैं?

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

लेकिन इन पंक्तियों के साथ और अधिक प्रगति करने से पहले, मैं @StefanKarpinski से पूछना पसंद करता

मैं सहमत हूं कि इसे विशेष रूप से कल्पना करना एक अच्छा विचार है। यह पता लगाना कि उस सूची का क्या काम होना चाहिए, यहाँ काम है - यदि आप उस पर एक दरार लेना चाहते हैं, तो यह बहुत अच्छा होगा।

क्या हमें वास्तव में Base.datatype_module और Base.function_module की आवश्यकता है?

एक एकीकृत फ़ंक्शन "मॉड्यूल" (शायद गेटमॉडल) डेटाटाइप और फ़ंक्शन पर भेजना मेरे लिए अधिक सुसंगत लगता है।

@code_typed और दोस्तों में अंडरस्कोर के बारे में क्या?

यह एक अच्छा अवसर है कि रिफैक्टरिंग (अंडरस्कोर प्रतिबंध के लिए कारण बताया गया है)। आपके पास पहले तर्क के साथ @code मैक्रो हो सकता है जिस तरह का कोड आपको चाहिए।

( @bramtayl , कृपया मैक्रोज़ के चारों ओर @code );

एफडब्ल्यूआईडब्ल्यू, टैब समापन केवल फ़ंक्शन नामों के साथ काम करता है। करने में सक्षम होने के नाते @code_<TAB> अच्छा है ...।

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

अंडरस्कोर ऑडिट।

प्रति-प्रस्ताव: हम अभी भी इन नामों का ऑडिट करते हैं, लेकिन हम इसके बजाय अधिक अंडरस्कोर जोड़ते हैं जहां यह कोड को पढ़ना आसान बना देगा (कोडेटिपेड बनाम कोड_typed, isos2 बनाम is_os2)।

मैं इस बारे में निरपेक्ष नहीं हूं। मुझे लगता है कि code_typed ठीक है, उपयोगी रूप से टैब @KristofferC के रूप में पूरा होता है, और वास्तव में कुछ भी स्पष्ट नहीं है कि आप जो आउटपुट चाहते हैं उसे चुनने के लिए एक तर्क के रूप में पारित करें।

मेरे लिए ऐसा लगता है कि जहाज अधिक अंडरस्कोर जोड़ने पर रवाना हो गया है, क्योंकि हमें मूल रूप से बेस का आधा भाग निकालना होगा। एक उदाहरण के रूप में, 74 विधेय कार्य हैं जो is शुरू होते हैं और केवल 6 जो is_ । जो अधिक समझ में आता है, 6 या 74 का चित्रण?

ठीक है, यहाँ कई परस्पर विरोधी लक्ष्य हैं:

1) नाम अधिक पठनीय बनाना
2) कोड मंथन कम करना
3) रिफैक्टरिंग को प्रोत्साहित करना

शब्दों को आपस में टकराकर अंडरस्कोर को खत्म करना सभी 3 मोर्चों पर विफल है।

उस show एक स्ट्रीम को स्वीकार करने के तरीके ! आमतौर पर होने वाले सम्मेलन के साथ असंगत लगता है? संदर्भ। https://github.com/JuliaLang/julia/pull/22604/commits/db9d70a279763ded5088016d9c3d4439a49e3fca#r125115063। श्रेष्ठ! (संपादित करें: मुझे लगता है कि यह एक स्ट्रीम को स्वीकार करते हुए write विधियों से मेल खाता है।)

लक्षण एपीआई के साथ विसंगतियां हैं। कुछ लक्षणों की गणना विशेषता को कॉल करके की जाती है जैसे
TypeArithmetic(Float64)
जबकि दूसरों को इस कार्य को लोअरकेस में लिखा जाना चाहिए:
iteratorsize(Vector{Float64})

size -> shape (xref # 22665) का नाम बदलने पर विचार करें

Array{T,1}() शायद भी पदावनत होना चाहिए:

julia> Array{Int,1}()                                                                                                                  
0-element Array{Int64,1}                                                                                                               

julia> Array{Int,2}()                                                                                                                  
WARNING: Matrix{T}() is deprecated, use Matrix{T}(0, 0) instead.                                                                       

संग्रह के बारे में सोचते रहे हैं। हमारे पास मूल रूप से तीन प्रकार हैं:

• सरल सेट-जैसे (या बैग-जैसे) संग्रह, जिनमें बस कुछ मूल्य शामिल हैं।
• अर्रे-जैसे संग्रह, जो डेटा के साथ एक सूचकांक जोड़ते हैं।
• डिक्ट-जैसे संग्रह, जिनके पास डेटा के हिस्से के रूप में सूचकांक हैं, अर्थात k=>v जोड़े।

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

• keys eachindex मेल खाती है
• mapindexed और filterindexed dicts और arrays दोनों के लिए उपयोगी होगा। ये मानचित्र और फ़िल्टर की तरह हैं सिवाय आपके फ़ंक्शन को प्रश्न में आइटम के सूचकांक को पास करने के।
• Arrays और dicts (और नाम tuples, और शायद अन्य चीजें) pairs iterator का उपयोग कर सकते हैं, जो मूल रूप से zip(keys(c), values(c)) लिए एक शॉर्टकट है।

ind2sub और sub2ind नाम बदलने पर विचार करें, जो जाहिरा तौर पर matlabisms हैं, और जो एक गैर-matlab उपयोगकर्ता के लिए एक गैर-जूलियन और अजीब नाम है। संभावित नाम क्रमशः indice और linearindice होंगे। मैंने एक पीआर बनाने की हिम्मत नहीं की क्योंकि मुझे यकीन नहीं है कि लोग उस बारे में क्या सोचते हैं, लेकिन समर्थन होगा तो क्या करेंगे।

rad2deg और deg2rad साथ एक ही चीज़।

संदर्भ। # 22791 ( select -> partialsort )। श्रेष्ठ!

एक बात जो मैंने यहाँ नहीं देखी है: क्या वैकल्पिक स्थिति संबंधी तर्क पहले या अंतिम चलते हैं? कभी-कभी वैकल्पिक स्थिति संबंधी तर्क पहले जाते हैं, जैसे sum(f, itr) और rand([rng,] ..) । लेकिन कहीं और वे आखिरी बार जाते हैं, जैसे median(v[, region]) या split(s::AbstractString[, chars]) । कभी-कभी वे पहले या आखिरी जा सकते हैं, लेकिन दोनों नहीं! (उदाहरण के लिए, mean पहले एक फ़ंक्शन या अंतिम आयाम ले सकते हैं, लेकिन दोनों नहीं।)

वर्तमान भाषा शब्दार्थ पिछले जाने के लिए वैकल्पिक तर्कों को बाध्य करता है: आप f(a, b=1) लिख सकते हैं लेकिन f(b=1, a) । लेकिन यदि सभी वैकल्पिक तर्क अंतिम हो जाते हैं, तो सुविधाजनक ब्लॉक क्या होता है?

यदि और कुछ नहीं है, तो यह एक मामूली मस्सा है जिसे भाषा को rand.jl : shuffle!(a::AbstractVector) = shuffle!(GLOBAL_RNG, a) जैसे तरीकों को परिभाषित करना है। वैकल्पिक स्थिति तर्क वाक्यविन्यास को इस उपयोग के मामले में बिल्कुल ध्यान रखना चाहिए।

शायद एक अलग मुद्दे पर जाना चाहिए, लेकिन यह संभव है कि आप जहां चाहें वैकल्पिक तर्क को स्थानांतरित कर सकें। तो उदाहरण के लिए, f(a = 1, b, c = 2) f(x) = f(1, x, 2) और f(x, y) = f(x, y, 2) परिभाषित करेगा

किसी भी स्थिति में डिफ़ॉल्ट आर्गन्स को सक्षम करने के लिए एक (अलोकप्रिय) प्रयास के लिए xref # 22460।

शायद warn warning (matlab भी इस का उपयोग करता है) का नाम बदलें, एक बड़ा सौदा नहीं है, लेकिन सोचा था कि मैं उल्लेख करूंगा?

मुझे warn क्योंकि यह एक क्रिया है, जैसे throw ।

मैं इससे बहुत भ्रमित हो गया:

julia> f(;a=1,b=1) = a+b                                                                                                                              
f (generic function with 1 method)                                                                                                                    

julia> f(a=4,5)            # I intended to write f(a=4,b=5)                                                                                                                           
ERROR: MethodError: no method matching f(::Int64; a=4)                                                                                                
Closest candidates are:
  f(; a, b) at REPL[13]:1

मैं सुझाव देता हूं कि केवल कॉलिंग फ़ंक्शन को अंतिम रूप देने की अनुमति दें, कीवर्ड फ़ंक्शन को परिभाषित करने के समान।

मैं सुझाव देता हूं कि केवल कॉलिंग फ़ंक्शन को अंतिम रूप देने की अनुमति दें, कीवर्ड फ़ंक्शन को परिभाषित करने के समान।

बहुत सारे API हैं जहाँ अन्य स्थितियों में पासिंग कीवर्ड्स उपयोगी और एर्गोनोमिक दोनों हैं।

जिज्ञासा से बाहर, क्या स्थिति और खोजशब्द तर्क के लिए एक निर्धारित मूल्यांकन आदेश है? मैंने कुछ पुराने मुद्दों और https://docs.julialang.org/en/latest/manual/functions/#Evaluation -Scope-of-Default-Values-1 में स्कोप के बारे में बात की, लेकिन मुझे ऐसा कुछ नहीं मिला, जो मुझे पसंद नहीं है तर्कों का मूल्यांकन दाएं से बाएं किया जाता है, या सभी स्थिति संबंधी तर्कों का मूल्यांकन सभी कीवर्ड तर्कों से पहले किया जाता है, या यदि कोई निर्धारित मूल्यांकन क्रम (या कुछ और) नहीं है।

@yurivish , खोजशब्दों के लिए डॉक्स (https://github.com/JuliaLang/julia/issues/23926 भी देखें)। वैकल्पिक लोगों के लिए कहानी थोड़ी अधिक जटिल है, शायद यहाँ पढ़ें। (ध्यान दें कि प्रश्न https://discourse.julialang.org/ पर बेहतर पूछे गए हैं)

ऐसा प्रतीत नहीं होता है कि यह स्वयं का मुद्दा है, लेकिन यह मुझे हमेशा अजीब लगता है कि bits(1) String , ऐसा लगता है कि यह BitVector या Vector{Bool} ।

मैं Function या Callable पर भेजने वाली पद्धति तालिकाओं की समीक्षा का सुझाव देना चाहूंगा। आइए हम यह सुनिश्चित करने का प्रयास करें कि ये API वे तरीके हैं जो हम उन्हें चाहते हैं ... और यह कि हम तालिकाओं के पुनर्गठन के लिए एक अवसर को याद नहीं कर रहे हैं जैसे कि हम किसी भी ऑब्जेक्ट को डक-कॉल करने की अनुमति दे सकते हैं।

के रूप में all और any , वे सीधे all(f(x) for x in xs) लिए पदावनत करने के लिए सरल लगते हैं, जो कि पहले से ही all(Generator(f, xs)) और इसलिए कोई ओवरहेड नहीं होना चाहिए।

यह निश्चित नहीं है कि यह आपके लिए क्या है, लेकिन मुझे लगा कि यह केवल मामले में बताते हुए लायक है: मैं जनरेटर के लिए किसी भी कार्यात्मक शैली एपीआई को अपदस्थ करने के खिलाफ कट्टर हूं। हमारे पास any(f, x) और all(f, x) और उनका व्यापक रूप से उपयोग किया जाता है; -10000000 उन (या इस तरह के किसी भी तरीके को हटाने के लिए, वास्तव में)।

Im समर्थक जनरेटर। आलसी प्रोग्रामिंग के एक मौलिक बिल्डिंग ब्लॉक की तरह लगता है और इसे निर्यात किया जाना चाहिए। all(Generator(f, xs)) कभी कभी से परिभाषित कार्यों के लिए और अधिक सुविधाजनक all(f(x) for x in xs) । संतुलन को बहाल करने के लिए भी +10000000

यदि संभव हो तो मैं यहां कम वाक्यविन्यास करना पसंद करता हूं। यदि यह "एक्स एक्स, सब कुछ के लिए एफ लागू करें और उन सभी के सच होने पर वापस लौटना" के विचार को व्यक्त करने के लिए आसान और पठनीय और निष्पादन योग्य है, तो हमें इसे एक क्रिया में क्यों रखा जाना चाहिए?

यदि चिंता की जरूरत है, तो अनावश्यक संज्ञा x f(x) for x in xs , तो @bramtayl का Generator निर्यात करने का सुझाव (शायद Map जैसे बेहतर नाम का उपयोग कर रहा है?) समझ में आता है।

जैसी चीजें all(isnull, x) की तुलना में काफी सरल हैं all(isnull(v) for v in x) । हम पदावनत कर दिया है allnull के पक्ष में NullableArrays से समारोह all(isnull, x) ; अगर वह वाक्य रचना चली गई तो हमें शायद उसे फिर से लागू करना होगा।

strwidth stringwidth नाम बदलने के बारे में (मुझे लगता है कि यह एकमात्र निर्यातित स्ट्रिंग हेरफेर फ़ंक्शन है जिसने स्ट्रिंग को str में संक्षिप्त किया है)

वास्तव में इसका नाम बदलकर textwidth (https://github.com/JuliaLang/julia/pull/23667) कर दिया गया है।

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

इसके अलावा, यह एक और जगह है जहाँ FemtoCleaner 1.0 को पोस्ट करते हुए कई चीजों को ऑटो-अपडेट कर सकता है, भले ही यह सब ठीक हो जाए।

पाठ्यपुस्तक पर सिर्फ एक टिप्पणी:

INFO: Testing Cairo
Test Summary:   | Pass  Total
Image Surface   |    7      7
Test Summary:   | Pass  Total
Conversions     |    4      4
Test Summary:   | Pass  Total
TexLexer        |    1      1
WARNING: both Compat and Cairo export "textwidth"; uses of it in module Main must be qualified
Samples        : Error During Test
  Got an exception of type LoadError outside of a <strong i="6">@test</strong>
  LoadError: UndefVarError: textwidth not defined
  Stacktrace:
   [1] include_from_node1(::String) at .\loading.jl:576
   [2] include(::String) at .\sysimg.jl:14
   [3] macro expansion at C:\Users\appveyor\.julia\v0.6\Cairo\test\runtests.jl:86 [inlined]
   [4] macro expansion at .\test.jl:860 [inlined]
   [5] anonymous at .\<missing>:?
   [6] include_from_node1(::String) at .\loading.jl:576
   [7] include(::String) at .\sysimg.jl:14
   [8] process_options(::Base.JLOptions) at .\client.jl:305
   [9] _start() at .\client.jl:371
  while loading C:\Users\appveyor\.julia\v0.6\Cairo\samples\sample_pango_text.jl, in expression starting on line 28

त्रुटि संदेश बहुत स्पष्ट लगता है कि समस्या क्या है? Cairo आधार विधि का विस्तार करने की आवश्यकता है।

help?>  Base.textwidth
  No documentation found.

  Binding Base.textwidth does not exist.

julia> versioninfo()
Julia Version 0.6.0

julia> Compat.textwidth
textwidth (generic function with 2 methods)

मुझे कोई संदेह नहीं था कि संदेश (जो मुझे ट्रैविस के माध्यम से मिला) ठीक है, लेकिन अगर यह 0.6 में नहीं है तो संगत एक्सपोज़र टेक्स्ट एक्सपोज़र क्यों करता है?

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

मेरा सुझाव है कि copy shallowcopy और deepcopy से copy का परिवर्तन करें क्योंकि हाल ही में मुझे यह महसूस करने में काफी समय लगा कि कॉपी "उथली" कॉपी है और मैंने जो फ़ंक्शन लिखा था, वह सरणियों के सरणी को बदल रहा था। मुझे लगता है कि यह बहुत अधिक सहज होगा यदि copy "गहरी" कॉपी और shallowcopy तरह उथली प्रतियों के लिए उपयोग किया जाता है? मुझे पता है अब जब deepcopy , लेकिन मुझे लगता है कि कई अन्य उपयोगकर्ता एक ही मुद्दे में चलेंगे।

चलिए कृपया इस मुद्दे को एपीआई की संगति के लिए रखने की कोशिश करें, न कि "विशिष्ट चीजों को पसंद नहीं करते हैं"।

Associative जूलिया में अन्य सभी प्रकार के नामों के साथ नाम काफी असंगत लगता

सबसे पहले, प्रकार आमतौर पर विशेषण नहीं होते हैं। संज्ञा Association , और कम से कम कुछ गणितज्ञ डॉक्स द्वारा उपयोग किया जाता है जो मुझे मिला।

मुझे लगता है कि AbstractDict अति अधिक की तरह अन्य प्रकार के अनुरूप होगा AbstractArray , AbstractRange , AbstractSet और AbstractString , जिनमें से प्रत्येक की है एक प्रोटोटाइप कंक्रीट प्रकार Dict , Array , Range , Set और String ।

हमारे अपवाद प्रकार पूरे स्थान पर थोड़े हैं: कुछ का नाम FooError , अन्य का नाम BarException ; कुछ निर्यात किए जाते हैं, अधिकांश नहीं। यह स्थिरता के लिए एक पास का उपयोग कर सकता है।

तो क्या पसंद किया जाएगा, FooError या BarException ? निर्यात हुआ या नहीं?

मेरे लिए, BarException में कहीं न कहीं एक प्रतिमान / पकड़ने का पैटर्न शामिल है।

मैं बहुत कुछ पसंद करता हूं, और कार्यात्मक दुनिया में कुछ अन्य लोग भी Some / None पैटर्न (*) का उपयोग करते हैं, जहां नियंत्रण प्रवाह अधिक प्रत्यक्ष और अनुमानित है।

तो +1 FooError

(*) Some / Void ex Optional जूलिया # 23642 में।

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

कृपया देख लीजिये! मुझे व्यवस्थित रूप से इन मुद्दों से गुजरने का मौका नहीं मिला है।

BTW, मैंने लक्षण के नामकरण में एक विसंगति का उल्लेख किया है: हमारे पास iteratorsize , iteratoreltype , लेकिन IndexStyle , TypeRangeStep , TypeArithmetic और TypeOrder । ऐसा लगता है कि CamelCase वेरिएंट अधिक से अधिक हाल ही में हैं, इसलिए शायद हमें हर जगह उस सम्मेलन को अपनाना चाहिए?

जिन्हें निश्चित रूप से सुसंगत बनाया जाना चाहिए। क्या आप एक पीआर बनाना चाहते हैं?

मुझे लगता है कि इसे https://github.com/JuliaLang/julia/pull/25356 के हिस्से के रूप में तय किया जाना चाहिए

EDIT: https://github.com/JuliaLang/julia/issues/25440 भी

यह ज्यादातर 1.x रिलीज में किया जाता है या किया जा सकता है। मैं चेकबॉक्स को अपडेट कर सकता हूं, लेकिन हम सिर्फ ट्राइएज कॉल और सब कुछ पर उनके माध्यम से चले गए लेकिन # 25395 और अंडरस्कोर ऑडिट किया गया।

अंडरस्कोर ऑडिट

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

मैंने चीजों को श्रेणी से अलग कर दिया है। उम्मीद है कि यह अधिक उपयोगी है कि यह कष्टप्रद है।

प्रतिबिंब

हमारे पास निम्नलिखित कार्यों के साथ निम्नलिखित मैक्रोज़ हैं:

• [] @code_llvm , code_llvm
• [] @code_lowered , code_lowered
• [] @code_native , code_native
• [] @code_typed , code_typed
• [] @code_warntype , code_warntype

मैक्रोज़ पर जो भी परिवर्तन लागू किया जाता है, यदि कोई हो, तो इसी तरह कार्यों के लिए लागू किया जाना चाहिए।

• [x] module_name -> nameof (# 25622)
• [x] module_parent -> parentmodule (# 25629, नाम बदलने के पिछले प्रयास के लिए # 25436 देखें)
• [x] method_exists -> hasmethod (# 25615)
• [x] object_id -> objectid (# 25615)
• [] pointer_from_objref

pointer_from_objref शायद अधिक वर्णनात्मक नाम के साथ कर सकता है, शायद address जैसा कुछ?

सी इंटरोप के लिए उपनाम

अंडरस्कोर वाले प्रकार के उपनाम C_NULL , Cintmax_t , Cptrdiff_t , Csize_t , Cssize_t , Cuintmax_t , और Cwchar_t । _t में समाप्त होने वाले लोगों को रहना चाहिए, क्योंकि उनका नाम उनके संगत C प्रकार के अनुरूप होना चाहिए।

C_NULL यहाँ एक अजीब है, केवल सी उर्फ ​​एक अंडरस्कोर है जो सी में प्रतिबिंबित नहीं है (क्योंकि सी में यह सिर्फ NULL )। हम इस CNULL कॉल करने पर विचार कर सकते हैं।

• [] C_NULL

बिट की गिनती

• [] count_ones
• [] count_zeros
• [] trailing_ones
• [] trailing_zeros
• [] leading_ones
• [] leading_zeros

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

असुरक्षित संचालन

• [] unsafe_copyto!
• [] unsafe_load
• [] unsafe_pointer_to_objref
• [] unsafe_read
• [] unsafe_store!
• [] unsafe_string
• [] unsafe_trunc
• [] unsafe_wrap
• [] unsafe_write

इनको इस तरह रखना शायद ठीक है; अंडरस्कोर की बदसूरती आगे उनकी अनिश्चितता को रेखांकित करती है।

इंडेक्सिंग

• [] broadcast_getindex
• [] broadcast_setindex!
• [] to_indices

जाहिरा तौर पर broadcast_getindex और broadcast_setindex! मौजूद हैं। मुझे समझ नहीं आया कि वे क्या करते हैं। शायद वे अधिक वर्णनात्मक नाम का उपयोग कर सकते थे?

दिलचस्प बात यह है कि to_indices , Base.to_index का एकल इंडेक्स संस्करण निर्यात नहीं किया गया है।

निशान

• [] catch_backtrace
• [x] catch_stacktrace -> stacktrace(catch_backtrace()) (# 25615)

मुमकिन है इन कर रहे हैं catch के ब्लॉक समकक्ष backtrace और stacktrace , क्रमशः।

कार्य, प्रक्रियाएं और संकेत

• [] current_task
• [] task_local_storage
• [] disable_sigint
• [] reenable_sigint
• [] process_exited
• [] process_running

स्ट्रीम

• [] redirect_stderr
• [] redirect_stdin
• [] redirect_stdout
• [x] nb_available -> bytesavailable (# 25634)

अधिक सामान्य IO -> IO पुनर्निर्देशन फ़ंक्शन होना अच्छा होगा, जिसमें इन सभी को जोड़ा जा सकता है, जैसे redirect(STDOUT, io) , जिससे अंडरस्कोर और निर्यात दोनों को हटाया जा सके।

पदोन्नति

• [] promote_rule
• [] promote_shape
• [] promote_type

promote_rule संबंधित एक प्रासंगिक चर्चा के लिए # 23999 देखें।

मुद्रण

• [x] print_with_color -> printstyled (# 25522 देखें)
• [] print_shortest (# 25745 देखें)
• [] escape_string (# 25620 देखें)
• [] unescape_string

escape_string और unescape_string थोड़े अजीब हैं कि वे एक स्ट्रीम में प्रिंट कर सकते हैं या एक स्ट्रिंग वापस कर सकते हैं। इन्हें स्थानांतरित करने / नाम बदलने के प्रस्ताव के लिए # 25620 देखें।

कोड लोड हो रहा है

• [] include_dependency
• [] include_string

include_dependency । क्या इसका उपयोग आधार के बाहर भी किया जाता है? मैं ऐसी स्थिति के बारे में नहीं सोच सकता जहाँ आप किसी विशिष्ट परिदृश्य में include बजाय ऐसा चाहते हों।

include_string । क्या यह eval(parse()) आधिकारिक रूप से स्वीकृत संस्करण नहीं है?

चीजें जो मैंने वर्गीकृत करने की जहमत नहीं उठाईं

• [x] gc_enable -> GC.enable (# 25616)
• [] get_zero_subnormals
• [] set_zero_subnormals
• [] time_ns

get_zero_subnormals और set_zero_subnormals अधिक वर्णनात्मक नामों के साथ कर सकते थे। क्या उन्हें निर्यात करने की आवश्यकता है?

+1 method_exists => methodexists और object_id => objectid । यह भी मूर्खतापूर्ण है कि catch_stacktrace भी मौजूद है। इसे इसकी परिभाषा में stacktrace(catch_backtrace()) से निकाला जा सकता है।

हम C_NULL de-underscoring के बारे में कैसा महसूस करते हैं? मुझे इसकी बहुत आदत है, लेकिन मैं यह तर्क भी खरीदता हूं कि अन्य C* नामों में से कोई भी अंडरस्कोर नहीं है।

अन्य C नाम टाइप हैं, जबकि C_NULL एक स्थिर है। मुझे लगता है कि यह अच्छा है कि यह कैसा है और दिशानिर्देशों का नामकरण।

और नामकरण दिशानिर्देशों का पालन करता है।

ऐसा कैसे?

लगातार सभी अंडरस्कोर वाले सभी कैप होते हैं - C_NULL इस प्रकार। जैसा कि @ iamed2 ने कहा, यह एक मूल्य है, एक प्रकार नहीं है, इसलिए Cfoo नामकरण सम्मेलन आवश्यक रूप से लागू नहीं होता है।

मैंने गलती से https://github.com/JuliaLang/julia/blob/master/doc/src/manual/variables.md#stylistic -conventions संदर्भित संदर्भों को गलत समझा, लेकिन ऐसा नहीं होता। यह शायद करना चाहिए।

मैं एक सुसंगत, गणितीय ध्वनि, सामान्य हिल्बर्ट रिक्त स्थान के लिए इंटरफ़ेस का सुझाव देता हूं जिसमें वैक्टर जूलिया एरेस नहीं हैं। vecdot , vecnorm इत्यादि जैसे फ़ंक्शन नाम, सामान्य रूप से inner और norm की सामान्य अवधारणाओं द्वारा प्रतिस्थापित किए जा सकते हैं जैसा कि https: // github में चर्चा की गई है

जैसा कि मैंने कुछ बार कहा है, यह उन चीजों के लिए एक catchall मुद्दा नहीं है जिन्हें कोई बदलना चाहता है।

मेरा मानना ​​है कि 1.0 के लिए इस छतरी के नीचे बची हुई एकमात्र वस्तुएं # 25501 और # 25717 हैं।

मैं (get|set)_zero_subnormals साथ कुछ करना चाहता हूं, लेकिन शायद सबसे अच्छा अल्पकालिक समाधान उन्हें unexport करना है।

कुछ जो कि शायद समीक्षा करना चाहिए कि map और collect जैसे संग्रह संचालन के संदर्भ में संख्याओं का व्यवहार कैसे किया जाता है। यह इंगित किया गया था कि पूर्व एक स्केलर देता है लेकिन बाद वाला 0D सरणी देता है।