Julia: मॉड्यूल और आयात अलियासिंग

मुझे कुछ मिनट पहले एहसास हुआ कि आप निम्न कार्य कर सकते हैं:

import ArgParse
ap = ArgParse

ap.add_argument(...)

मुझे अभी भी लगता है कि सिंटैक्टिक चीनी के रूप में "आयात के रूप में" नोटेशन होना अच्छा होगा।

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

कुछ इस तरह

# from the forum post
import Module.(export1,export2,export3)
# or
import Module.[export1,export2,export3]
# or maybe
import Module.{export1,export2,export3}

यह इस से अलग मुद्दा है, लेकिन संबंधित है। क्या मुझे ऐसा करना चाहिए

1. इस समस्या को अपडेट करें, या
2. एक नया मुद्दा बनाएं

(मैं मान रहा हूं कि ऐसी सुविधा की उपयोगिता विवादास्पद नहीं है ...)

संपादित करें : यह अब import Module: export1, export2, export3 के साथ काम करता है

मुझे लगता है कि इसे भी समर्थन करना चाहिए उदा

import ArgParse.add_argument as addarg

आयात पर मॉड्यूल सदस्यों का नाम बदलने में सक्षम होने के लिए।

आश्चर्य है कि नामित फ़ंक्शन नाम प्रेषण में कैसे भाग लेंगे?

इसे मूल रूप से const foo = Base.bar के बराबर उपनाम की तरह काम करना होगा।

इसे मूल रूप से एक उपनाम की तरह काम करना होगा, जो कि const foo = . के बराबर है
बेस बार।

जब हम कोई फ़ंक्शन आयात करते हैं, तो हम या तो इसका उपयोग करने की योजना बनाते हैं या इसे ओवरराइड करते हैं। दिया गया
ऊपर, साथ

बेस.बार को फू के रूप में आयात करें

हम निश्चित रूप से foo को Base.bar के रूप में उपयोग कर सकते हैं, लेकिन foo को परिभाषित करना भी ओवरराइड करेगा
बेस बार? इसे होना चाहिए?

यह एक पुराना मुद्दा है, लेकिन मुझे लगता है कि इस पर फिर से विचार करने का समय आ गया है क्योंकि हम 0.2 . के करीब पहुंच रहे हैं

कोड लिखने में, मैंने पाया कि मैं हमेशा से import NumericExtensions as ne लिखना चाहता था और अंत में मुझे खुद को याद दिलाना था कि यह समर्थित नहीं है।

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

import NumericExtensions
const ne = NumericExtensions

+1

+1

क्या यह अभी भी प्रासंगिक है? मैं व्यक्तिगत रूप से मॉड्यूल अलियासिंग के लिए अतिरिक्त foo = Foo करने पर ध्यान नहीं देता, लेकिन ऐसा लगता है कि एलियासिंग चीनी का समर्थन करने के लिए कुछ आम सहमति थी। कोई व्यक्ति जो पर्याप्त रूप से पर्याप्त महसूस करता है, उसे स्वयं पीआर करना पड़ सकता है।
ध्यान दें कि x as y #1470 में उल्लिखित convert(y,x) सिंटैक्स के लिए सबसे मजबूत दावेदारों में से एक था। ऐसा लगता है कि दोनों को अलग करना बहुत मुश्किल नहीं होगा, लेकिन सिर्फ ध्यान देना।

इस सुविधा का महत्व यह है कि आप मूल नाम को आयात करने से बच सकते हैं।

+1
यह सुविधा होना बहुत अच्छा होगा।

+1

एक नया कीवर्ड as पेश करने के बजाय, => ऑपरेटर का उपयोग कैसे करें, जैसा कि नीचे दिया गया है

import Tlahuixcalpantecuhtli => Venus: xxxxxxxxx => x9, yyyyyyyy => y8, zzz

यह ऑर्थोगोनली मॉड्यूल के अलियासिंग और एक ही सिंटैक्स में चर के किसी भी सबसेट की अनुमति देगा।

मुझे नहीं पता, यह वास्तव में मुझे बदसूरत लगता है।

import Tlahuixcalpantecuhtli as Venus: xxxxxxxxx as x9, yyyyyyyy as y8, zzz

क्या यह बेहतर है? मुझे यह बहुत कम पठनीय लगता है।

मैं व्यक्तिगत रूप से as को => की तुलना में अधिक आत्म-व्याख्यात्मक मानता हूं, जो ऐसा लगता है कि इसका मतलब किसी भी चीज से हो सकता है।

पूर्ण प्रकटीकरण: पायथन पूर्वाग्रह।

मुझे => सिंटैक्स as से बेहतर पसंद है।

मुझे ऐसे बाइकशेड पसंद हैं जो नैश इक्विलिब्रिया में फंस जाते हैं।

आप मॉड्यूल के आंतरिक प्रतीकों को फिर से क्यों बांधेंगे? यह बदसूरत है क्योंकि आपको वास्तव में ऐसा नहीं करना चाहिए।

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

मैं @ssfrr से सहमत हूं, as कीवर्ड बहुत अधिक आत्म-व्याख्यात्मक है, और पाइथन/हास्केल उपयोगकर्ताओं से भी परिचित है। पठनीयता के साथ @StefanKarpinski समस्या को हल करने के लिए, अजगर जैसा दृष्टिकोण भी मदद करेगा:

from Tlahuixcalpantecuhtli as Venus import xxxxxxxxx as x9, yyyyyyyy as y8, zzz

मुझे ऐसा लग रहा है कि मैं आरईपीएल से बात कर रहा हूं। लेकिन मैं जानता हूं कि इस तरह का सुझाव संभव नहीं है।

from Tlahuixcalpantecuhtli as Venus import xxxxxxxxx as x9, yyyyyyyy as y8, zzz

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

:+1: as के लिए, :-1: from के लिए

import a => b: c => d, e => f मुझे थोड़ा बहुत पर्ल-एस्क्यू लगता है।

मैंने नैश संतुलन के बारे में कभी नहीं सुना और इसके बारे में पढ़ने के बाद मुझे नहीं लगता कि यह एक है। लेकिन मजे की बात यह है कि इस बाइकशेड में एक घंटे में 10 प्रतिक्रियाएं हैं, #6984 पर एक प्रस्ताव जो मुझे बहुत महत्वपूर्ण (लेकिन अधिक कठिन) के रूप में प्रभावित करता है, बिना किसी टिप्पणी के 4 घंटे चला गया है!

as बनाम => के लिए: या तो वर्तमान स्थिति में एक अच्छा सुधार होगा।

अच्छा बिंदु @BobPortmann # 6984 पर।

मुझे लगता है कि => इसके लिए बहुत अच्छा है, एफडब्ल्यूआईडब्ल्यू।

लेकिन मजे की बात यह है कि इस बाइकशेड में एक घंटे में 10 प्रतिक्रियाएं हैं, #6984 पर एक प्रस्ताव जो मुझे बहुत महत्वपूर्ण (लेकिन अधिक कठिन) के रूप में प्रभावित करता है, बिना किसी टिप्पणी के 4 घंटे चला गया है!

पार्किंसंस के मूल सादृश्य में, यह मुद्दा बाइक शेड है और #6984 परमाणु रिएक्टर है।

:)

मुझे इस बर्तन को हिलाने से नफरत है लेकिन मुझे लगता है कि मुझे पसंद है as । => थोड़ा अस्पष्ट है, और इसके लिए सिंटैक्स को शब्दकोशों के साथ साझा करना अजीब है। शायद सिर्फ = समझ में आता है: import Foo: x = y , const x = Foo.y के अनुरूप आप अभी करेंगे।

यदि और कुछ नहीं, तो हास्केल दस्तावेज़ीकरण में वह तालिका वास्तव में सहायक है। मैं अक्सर (विशेषकर जब पहली बार जूलिया सीख रहा था) भ्रमित हो गया था कि import / using / require का उपयोग कब करना है, या कब करना है import Mod.thing बनाम import Mod: thing । मैं वास्तव में आयात पर कोलन सिंटैक्स की व्याख्या की तलाश में था और इसे नहीं मिला।

@jakebolewski ऐसा लगता है कि हास्केल सिंटैक्स बहुत करीब है, जूलिया के using हास्केल (गैर-योग्य) import के बराबर है, और जूलिया का import हास्केल के import qualified के बराबर है

एक प्रारंभिक बिंदु के रूप में जो कोई बेहतर जानता है वह पुष्टि कर सकता है कि यह वर्तमान में उपलब्ध आयात/सिंटैक्स का उपयोग करने का एक अच्छा सारांश है? मान लें कि हमारे पास एक मॉड्यूल है Mod जो x और y कार्यों का निर्यात करता है, और इसमें गैर-निर्यातित कार्य भी हैं p और q ।

import Mod लाता है Mod.x , Mod.y , Mod.p , और Mod.q । आयातित कार्य विधि विस्तार के लिए सभी उपलब्ध हैं

using Mod लाता है x , y , Mod.x , Mod.y , Mod.p , और Mod.q . x और y विधि विस्तार के लिए उपलब्ध नहीं हैं, लेकिन Mod.* हैं।

import Mod.x, Mod.p लाता है x , p , Mod.x , Mod.y , Mod.p , और Mod.q . वे सभी विधि विस्तार के लिए उपलब्ध हैं।

import Mod: x, p import Mod.x, Mod.p . के समान है

using Mod.x, Mod.p लाता है x , p , Mod.x , Mod.y , Mod.p , और Mod.q . x और p विधि विस्तार के लिए उपलब्ध नहीं हैं लेकिन Mod.* हैं।

using Mod: x, p using Mod.x, Mod.p . के समान है

जहां तक ​​​​मैं कह सकता हूं using Mod ही एकमात्र उपयोग है जो परवाह करता है कि क्या निर्यात किया जाता है Mod ।

इस सारांश को मॉड्यूल के दस्तावेज़ों पर रखना वास्तव में उपयोगी होगा! क्या कोई इसकी पुष्टि कर सकता है, ताकि मैं पीआर तैयार कर सकूं?

ऐसा लगता है कि कम से कम विवादास्पद संस्करण है:

import Tlahuixcalpantecuhtli as Venus: xxxxxxxxx as x9, yyyyyyyy as y8, zzz

मैं इसके साथ अच्छा हूँ। असाइनमेंट संस्करण दिलचस्प है, हालांकि इसका परीक्षण करना:

import Venus = Tlahuixcalpantecuhtli: x9 = xxxxxxxxx, y8 = yyyyyyyy, zzz

मुझे लगा कि मैं इससे नफरत करने जा रहा हूं, लेकिन यह वास्तव में बहुत अच्छा है। मुझे यह पसंद है कि इस मॉड्यूल में पेश किए गए नाम पहले आते हैं और सबसे प्रमुख हैं - कई मायनों में यह सबसे महत्वपूर्ण बात है।

@ जेकबोलेव्स्की : आप मॉड्यूल के आंतरिक प्रतीकों को फिर से क्यों बांधेंगे? यह बदसूरत है क्योंकि आपको वास्तव में ऐसा नहीं करना चाहिए।

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

कुछ अच्छी तरह से रखी गई नई लाइनें या तो अधिक पठनीय बनाती हैं, आईएमओ:

import Tlahuixcalpantecuhtli as Venus:
    xxxxxxxxx as x9, 
    yyyyyyyy as y8,
    zzz

या

import Venus = Tlahuixcalpantecuhtli: 
    x9 = xxxxxxxxx, 
    y8 = yyyyyyyy, 
    zzz

मुझे लग रहा है कि मैं असाइनमेंट संस्करण को काफी दृढ़ता से पसंद करता हूं। आयात असाइनमेंट का एक रूप है, आखिर।

इस सारांश को मॉड्यूल के दस्तावेज़ों पर रखना वास्तव में उपयोगी होगा! क्या कोई इसकी पुष्टि कर सकता है, ताकि मैं पीआर तैयार कर सकूं?

@ brk00 , इसके लिए जाओ!

@kmsquire , मैं आज इस पर काम करूँगा!

लेकिन ऐसा करने से पहले, मैं यह सुनिश्चित करना चाहता हूं कि मैं इसे अच्छी तरह समझता हूं। @ssfrr उदाहरण में, मान लीजिए कि मैं आरईपीएल पर हूं और using Mod टाइप करें। विधि विस्तार के लिए आयातित फ़ंक्शन x और y उपलब्ध नहीं हैं। इसका मतलब यह है कि, अगर मैं एक और एक्स और वाई फ़ंक्शन घोषित करता हूं, तो मुझे अब Mod की उन विधियों तक पहुंच नहीं होगी जिन्हें मैंने एक बार आयात किया था, केवल नए के लिए?

यदि आप किसी फ़ंक्शन को आयात किए बिना उसका विस्तार करने का प्रयास करते हैं तो ऐसा होता है:

julia> module Mod

       export x, y

       x() = "x"
       y() = "y"
       p() = "p"
       q() = "q"

       end

julia> using Mod

julia> x()
"x"

julia> p()
ERROR: p not defined

julia> x(n) = n
ERROR: error in method definition: function Mod.x must be explicitly imported to be extended

आप इस तरह की एक विधि जोड़ सकते हैं:

julia> import Mod: x # or import Mod.x

julia> x(n) = n
x (generic function with 2 methods)

julia> methods(x)
# 2 methods for generic function "x":
x() at none:5
x(n) at none:1

खैर, मैं नाम समाधान व्यवहार से भ्रमित था:

julia> module Mod

       export x, y

       x() = "x"
       y() = "y"
       p() = "p"
       q() = "q"

       end

julia> using Mod

julia> x(n) = n
x (generic function with 1 method)

अगर मैं _use_ से पहले x को एक नया फ़ंक्शन असाइन करता हूं जिसे मैंने अभी आयात किया है using Mod , तो त्रुटि नहीं उठाई जाती है। लेकिन अगर मैं, उदाहरण के लिए, नए असाइनमेंट से पहले x() पर कॉल करता हूं (जैसे आपने अपने उदाहरण में किया था), त्रुटि वास्तव में उठाई जाती है।

आह, दिलचस्प! मुझे इसके बारे में पता नहीं था। मुझे $#$1 using #$ के बाद नेमस्पेसिंग प्रदर्शित करने के लिए x पर कॉल करना पड़ा।

हो सकता है कि कोर देवों में से एक कुछ प्रकाश डाल सके। क्या हो रहा है जब x को कॉल किया जाता है जो ओवरलोडिंग के प्रयास में त्रुटि को ट्रिगर करता है?

मुझे @carlobaldassi द्वारा सुझाया गया अलियासिंग अभ्यास में बहुत उपयोगी लगता है।

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

const Shortname = import ModuleWithLongName

के बजाय

import ModuleWithLongName
const Shortname = ModuleWithLongName

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

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

हालांकि देखने के लिए बहुत तुच्छ? संक्षिप्त रूप संभवतः लोकप्रिय पैकेज जैसे np के लिए numpy के लिए मानकीकृत होंगे।

मैं अब भी numpy को np और यहां तक ​​कि Arrays से numpy $ को मानकीकृत करना पसंद करूंगा। numpy 1950 के डांस मूव और एक घातक प्लेग के बीच एक क्रॉस की तरह लगता है।

आसानी से बस लिख सकते हैं:

Base.require("ArgParse")
const ap = Main.ArgParse

इसे 1.0 . के लिए सिंटैक्स की आवश्यकता नहीं है

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

संदर्भ https://github.com/fredrikekre/ImportMacros.jl

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

julia> macro foo(a, b, c)                                  
           a, b, c                                         
       end                                                 
<strong i="8">@foo</strong> (macro with 1 method)                                 

julia> macro f(args...)                                    
           Expr(:macrocall, Symbol("@foo"), args...) |> esc
       end                                                 
<strong i="9">@f</strong> (macro with 1 method)                                   

julia> <strong i="10">@f</strong> 1 2 3                                            
(1,2,3)                                                    

ImportMacros.jl में मैं कार्यान्वित कर रहा हूँ:

• <strong i="15">@from</strong> Foo.Bar use foo as f
• <strong i="18">@from</strong> Foo.Bar use <strong i="19">@foo</strong> as @f

देखें: https://github.com/fredrikekre/ImportMacros.jl/pull/3

@ इस्माइल-वीसी

कोशिश

<strong i="7">@eval</strong> const $(Symbol("@foo")) = $(Symbol("@bar"))

जो स्थानीय रूप से मैक्रो को परिभाषित करने की तुलना में बदसूरत, लेकिन छोटा और शायद अधिक स्पष्ट है

@TotalVerb आपकी मदद के लिए फिर से धन्यवाद!

ऐसा लगता है कि जूलिया + इम्पोर्टमैक्रोस से गायब कार्यक्षमता का एकमात्र टुकड़ा मॉड्यूल और इस तरह के मॉड्यूल से वस्तुओं की एक चर संख्या को अलियासिंग करने और अन्य को बिना उपनाम के आयात करने का मिश्रण है:

• <strong i="9">@from</strong> Foo.Bar as B use foo as f, <strong i="10">@bar</strong> as <strong i="11">@b</strong>, baz

या बिना from :

• import Foo.Bar as B: foo as f, <strong i="17">@bar</strong> as <strong i="18">@b</strong>, baz
• import B = Foo.Bar: f = foo, <strong i="21">@b</strong> = <strong i="22">@bar</strong>, baz

मैक्रोज़ के साथ अंतिम संभव नहीं लगता है:

julia> parse("<strong i="26">@from</strong> Foo.Bar as B use foo as f, <strong i="27">@bar</strong> as <strong i="28">@b</strong>, baz")
:(<strong i="29">@from</strong> Foo.Bar as B use foo as (f,@bar(as,(@b(),baz))))

julia> parse("<strong i="30">@import</strong> Foo.Bar as B: foo as f, <strong i="31">@bar</strong> as <strong i="32">@b</strong>, baz")
:(<strong i="33">@import</strong> Foo.Bar as B:foo as (f,@bar(as,(@b(),baz))))

julia> parse("<strong i="34">@import</strong> B = Foo.Bar: f = foo, <strong i="35">@b</strong> = <strong i="36">@bar</strong>, baz")
ERROR: ParseError("unexpected \"=\"")
 in #parse#310(::Bool, ::Bool, ::Function, ::String, ::Int64) at .\parse.jl:184
 in (::Base.#kw##parse)(::Array{Any,1}, ::Base.#parse, ::String, ::Int64) at .\<missing>:0
 in #parse#311(::Bool, ::Function, ::String) at .\parse.jl:194
 in parse(::String) at .\parse.jl:194

यह वास्तव में 1.0 के लिए तय करने की आवश्यकता नहीं है क्योंकि सभी प्रस्तावित वाक्यविन्यास या तो त्रुटियां हैं या कुल बकवास हैं।

मॉड्यूल उपनाम का क्या होना चाहिए जब मूल मॉड्यूल को फिर से परिभाषित किया जाता है, उदाहरण के लिए, आरईपीएल पर reload("...") द्वारा? const M = MyModule दृष्टिकोण के साथ, M अभी भी पुनः लोड करने के बाद पुराने मॉड्यूल को संदर्भित करता है, इसलिए MyModule में कोई भी नया परिभाषित नाम केवल MyModule.name तक ही पहुंच योग्य होगा लेकिन नहीं M.name ।

उस स्थिति में, एक उपनाम सिंटैक्स const M = Module के लिए सिंटैक्टिक चीनी से अधिक होना चाहिए, लेकिन इसके बजाय सुनिश्चित करें कि M हमेशा MyModule जैसी ही चीज़ को संदर्भित करता है।

यह आरईपीएल वर्कफ़्लो को भी सरल करेगा क्योंकि मैं विकास के दौरान एक मॉड्यूल import जारी रख सकता हूं, लेकिन हर बार एक (गैर- const ) उपनाम को फिर से स्थापित किए बिना इसे एक छोटे उपनाम के माध्यम से संदर्भित कर सकता हूं। reload ।

फ़िलहाल, reload को हटा दिया गया है, इसलिए यह चिंता अब लागू नहीं है।

यह include के लिए भी लागू होता है, या क्या मुझे कुछ याद आ रहा है? आम तौर पर, जब एक मॉड्यूल को फिर से परिभाषित किया जाता है, तो import एड मॉड्यूल नाम नई परिभाषा को संदर्भित करता है जबकि असाइनमेंट द्वारा परिभाषित उपनाम पुरानी परिभाषा को संदर्भित करता है, है ना?

नहीं, यह चिंता की बात नहीं होनी चाहिए। सामान्य import सहित मॉड्यूल को फिर से परिभाषित करने पर आयातित नाम कभी नहीं बदला जाएगा। यदि आप इसे फिर से आयात करते हैं तो जो मॉड्यूल बदल गया है वह आयात किया जाएगा। आयातित हमेशा एक बाध्यकारी रहा है।

ठीक है, शायद मैंने खुद को स्पष्ट रूप से व्यक्त नहीं किया, इसलिए यहां एक उदाहरण दिया गया है: यदि आप सामग्री के साथ test.jl फ़ाइल बनाते हैं

module Tst
f() = 1
end

आप इसे लोड कर सकते हैं, Tst आयात कर सकते हैं, एक उपनाम को Tst पर परिभाषित कर सकते हैं, और सब कुछ ठीक है:

julia> include("test.jl")
Tst

julia> import Tst

julia> const Tst2 = Tst
Tst

julia> Tst.f()
1

julia> Tst2.f()
1

अगर आप अब test.jl को . में बदलते हैं

module Tst
f() = 2
end

और फिर से- include इसे आरईपीएल में, मॉड्यूल और इसके उपनाम अलग तरह से व्यवहार करते हैं:

julia> include("test.jl")
WARNING: replacing module Tst
Tst

julia> Tst.f()
2

julia> Tst2.f()
1

मैं देखता हूं कि ऐसा क्यों है, लेकिन मुझे लगता है कि ऐसा तब नहीं होना चाहिए जब आप import Tst as Tst2 जैसी किसी चीज़ के साथ उपनाम बनाते हैं।

मैंने इसे 0.6.2 पर परीक्षण किया, और फिलहाल मैं 0.7 पर इसका परीक्षण नहीं कर सकता, इसलिए मैं अब नहीं करता अगर यह अभी भी मामला है।

आप इसे बिल्कुल आयात नहीं कर रहे हैं। आपके द्वारा शामिल किया गया मॉड्यूल पहले से ही आपके दायरे में परिभाषित है। import एक नो-ऑप है।

सच है, लेकिन यह बात नहीं है। मुद्दा यह है कि जब मैं काल्पनिक import Tst as Tst2 जैसा कुछ करता हूं तो क्या होता है। तब यह कथन नो-ऑप नहीं है बल्कि एक उपनाम बनाता है।

यदि यह उपनाम const Tst2 = Tst की तरह काम करता है, तो मॉड्यूल Tst को फिर से परिभाषित करने से उपनाम मॉड्यूल के पुराने संस्करण की ओर इंगित हो जाएगा। यह किसी भी सूरत में वांछनीय नहीं है। या तो उपनाम को Tst के नए संस्करण को भी इंगित करना चाहिए, या उपयोगकर्ता को उपनाम को फिर से स्थापित करने के लिए मजबूर किया जाना चाहिए। लेकिन बाद के मामले में, पुराने उपनाम का उपयोग करके इसे फिर से स्थापित किए बिना पुराने मॉड्यूल को इंगित करने के बजाय एक त्रुटि फेंकनी चाहिए।

पूरी बात यही है। यह समस्या import में एक फ़ंक्शन जोड़ने के बारे में है जो मॉड्यूल परिभाषा में नहीं है। आपका import नो-ऑप है और इसे हटाने के बाद आपके कोड में कोई import या using नहीं है, इसलिए यह इस मुद्दे से असंबंधित है। कृपया इसे बदलें ताकि मॉड्यूल import के समान दायरे में परिभाषित न हो।

import Tst as Tst2 उस नाम के लिए बाध्यकारी होने के संदर्भ में import Tst के समान काम करेगा, जो हमेशा बाध्यकारी होता है और कुछ भी जादू नहीं जो आप चाहते हैं। यह मॉड्यूल को परिभाषित करते समय उपनाम जोड़ने के बारे में नहीं है।

इसे दूसरे तरीके से रखें, आपका कोड मूल रूप से है,

a = Ref(1) # include
a = a # import
b = a # alias
a = Ref(2) # include again

और b = a के व्यवहार के बारे में शिकायत करने का कोई मतलब नहीं है क्योंकि a a = a #$ से बिल्कुल भी बाध्य नहीं है। जो कुछ आप देखते हैं वह एक खराब उदाहरण में आयात (यानी a = a और a = Ref(...) समान दायरे में) के समान दायरे में मॉड्यूल को परिभाषित करने का दुष्प्रभाव है।

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

यह मुद्दा लंबे समय से है, भले ही कुछ विस्तारों पर अभी भी चर्चा की जानी चाहिए,

import LongPackage as longpkg

अपने आप में काफी उचित लगता है।

टक्कर। मैं सोच रहा हूं कि सबसे अच्छा समाधान क्या है - अभी के लिए - कैसा दिखता है? यहाँ मैं क्या कर रहा हूँ:

import LinearAlgebra
const linalg = LinearAlgebra

अगर कोई बेहतर समाधान है तो कृपया मुझे सुधारें!

यही वर्तमान मानक है।

~ वाक्यविन्यास के बारे में क्या? मैं प्रभाव नहीं जानता, लेकिन इसमें एक अच्छा सौंदर्य है। साथ ही, ~ का प्रयोग सन्निकटन के प्रतीक के रूप में किया जाता है।

import LongPackage ~ lp

@JeffreySarnoff स्टीफन के हवाले से

@StefanKarpinski

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

इस मामले में, ~ का पायथन सिंटैक्स के अंग्रेजी-जैसे पहलू से कोई लेना-देना नहीं होगा। मुझे लगता है कि जब मैं ~ देखता हूं, तो मैं अनुमानित की गणितीय अवधारणा को पहचानता हूं। 10.001 ~ 10.

तो, उस अर्थ में, मुझे वास्तव में ~ काफी अच्छा लगता है।

import LongPackage ~ lp
import HugePackage ~ hp
import MassivePackage ~ mp
import GiantPackage ~ gp

:-)

ठीक है - अजगर को भूल जाओ - मैं उस टिप्पणी को के पक्ष में हटा रहा हूं

lp imports LongPlayingRecords
hp imports HewlettPackard
mp imports MilitaryPolice
gp imports PariForNumberTheory

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

एक प्रोग्रामिंग भाषा जो _trys_ लोगों को बताती है कि इसका क्या अर्थ है!?!

@ जेफरी सरनॉफ

एक प्रोग्रामिंग भाषा जो पायथन से बेहतर बनने की कोशिश करती है !!!

@neilpanchal जूलिया निश्चित रूप से एक ऐसी भाषा है जो कई मायनों में पायथन से बेहतर बनने की कोशिश करती है। दूसरी ओर, यह स्पष्ट रूप से पाइथन की तुलना में _भिन्न_ होने के रास्ते से बाहर नहीं जाता है जहां पायथन को कुछ सही मिला। जूलिया ने बाएं और दाएं पायथन से वाक्यात्मक सम्मेलनों को उधार लिया।

कृपया अजगर as को अपनाएं। उन्हें यह ठीक लगा।

जूलिया> लाइटग्राफ को एलजी के रूप में आयात करें
त्रुटि: वाक्यविन्यास: अभिव्यक्ति के अंत के बाद अतिरिक्त टोकन "के रूप में"

as के पक्ष में बस एक और $0.02 टिप्पणी जो पायथन से दूर हो जाती है। fwiw, अब जब मैं जूलिया w/कुछ नियमितता का उपयोग कर रहा हूं तो मुझे यह याद आती है। पाइथन की तरह नहीं, बल्कि क्लोजर की तरह ( उदाहरण देखें), जहां पैकेज स्कोप्ड नेमस्पेस (जो कि असंबद्धता के लिए अच्छे हैं) को सरल बनाया जा सकता है ताकि पुस्तकालयों के स्पष्ट उपयोग को और अधिक प्रभावी बनाया जा सके। चूँकि मुझे using (यानी वाइल्डकार्ड आयात) से बचने की प्राथमिकता है, जिसमें import Gadlfy as gf के लिए कुछ वाक्यात्मक चीनी होने के कारण const gf = लाइन (जो मैं वर्तमान में करता हूं) के अतिरिक्त होगा आसान हो।

फिर भी as सिंटैक्स का समर्थन करने वाली एक और टिप्पणी: दिल: मैं भविष्य में जूलिया रिलीज के लिए वास्तव में कठिन चाहता हूं।

मैं भी चाहता हूं कि ऐसा हो। खासकर जब से यह एक ब्रेकिंग चेंज नहीं है (दाएं?)

मुझे लगता है कि इसे किसी बिंदु पर लागू किया जाएगा (यदि मैं समय निकाल सकता हूं तो मैं खुद को आजमाउंगा), लेकिन इस बीच, ImportMacros पैकेज में यहां अनुरोध की गई सभी कार्यक्षमताएं हैं (हालांकि इसमें दस्तावेज़ीकरण गुम है) :

<strong i="8">@import</strong> ModuleA as ma
<strong i="9">@using</strong> ModuleB as mb
<strong i="10">@from</strong> ModuleC use long_function_name as func
<strong i="11">@from</strong> Module use <strong i="12">@macroname</strong> as <strong i="13">@alias</strong>

मुझे ImportMacros .jl के बारे में पता नहीं था, इसे इंगित करने के लिए धन्यवाद। यदि यह कार्यक्षमता पैकेज में मौजूद है तो मुझे लगता है कि इसे मूल भाषा में रखना इतना महत्वपूर्ण नहीं है।

मुझे अब भी लगता है कि यह भाषा में होना अच्छा होगा।

आयात IMO ठीक उसी तरह की चीज है जिसके लिए आप लगभग _always_ मूल भाषा सम्मेलनों को स्थगित करना चाहते हैं और मैक्रोज़ में लपेटना नहीं चाहते हैं या पैकेज निर्भरता जोड़ना चाहते हैं। import ... const फॉलबैक करने के लिए एक बेहतर चीज है, यहां तक ​​​​कि (विशेष रूप से) यदि मूल भाषा को कभी भी दो चरणों की प्रक्रिया को और अधिक संक्षिप्त बनाने के लिए विस्तारित नहीं किया जाता है।

विशेष रूप से, यह देखने में थोड़ा बदसूरत है

using ImportMacros
<strong i="6">@using</strong> OtherPackage as ...
<strong i="7">@using</strong> ThirdPackage as ...

क्योंकि गैर-मैक्रो using चिपक जाता है।

कैसे के बारे में import मॉड्यूल/फ़ंक्शन/जो कुछ भी वास्तव में दायरे में लाता है उसे वापस कर रहा है?
तब आप लिख सकते हैं
lg = import LightGraphs
baz = import foo.bar
baz, kit, kat = import foo : bar1, bar2, bar3
केवल एक चीज जिसे बदलने की जरूरत है वह है आयात कार्य

मुझे वास्तव में @DhruvaSambrani का समाधान पसंद है क्योंकि यह जूलिया के समग्र "सब कुछ एक अभिव्यक्ति है" दृष्टिकोण के साथ फिट बैठता है।

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

OCaml में (सर्वोत्तम मॉड्यूल वाली भाषा!), आप कुछ ऐसा कर सकते हैं:

module LG = LightGraphs

यहाँ महत्वपूर्ण अंतर यह है कि OCaml प्रोग्राम के साथ संकलित किए गए प्रत्येक मॉड्यूल का योग्य नाम स्वचालित रूप से दायरे में है।

बेशक, import LightGraphs as LG का उपयोग करने का यह लाभ है कि "हर कोई" इसे पहले से ही पायथन से जानता है, लेकिन मेरा व्यक्तिगत स्वाद यह है कि असाइनमेंट सिंटैक्स का पुन: उपयोग करना बेहतर है जो सचमुच असाइनमेंट है।

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

या बस एक नया फ़ंक्शन import_as_ns(mod_name) :: Namespace जोड़ें जो एक शुद्ध फ़ंक्शन होगा जो एक ही नामस्थान में सभी फ़ंक्शन/मॉड्यूल इत्यादि लौटाता है।

यह जूलिया के समग्र "सब कुछ एक अभिव्यक्ति है" दृष्टिकोण के साथ फिट बैठता है

हालांकि, import और using विशेष हैं क्योंकि इनका उपयोग केवल उनके साइड इफेक्ट के लिए किया जाता है, और केवल शीर्ष स्तर पर।

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

1. import Foo; const Bar = Foo एक सही समाधान प्रदान करता है जब उपयोगकर्ता को नाम स्थान में Foo से कोई आपत्ति नहीं है,
2. ImportMacros.jl को बाकी को संभालना चाहिए,
3. न तो व्यावहारिक कोड में विशेष वाक्यविन्यास को वारंट करने के लिए बहुत बार उपयोग किया जाता है।

मैं कहूंगा कि इतने समय के बाद भी, मुझे अभी भी यह याद आती है (और मैं अपने कोड में ImportMacros का भी उपयोग करता हूं)।

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

इंपोर्टमैक्रोज़ पर्याप्त है। मैं सिर्फ टिप्पणियों से सहमत हूं कि यह उतना साफ नहीं दिखता है।

मैं उस दिन का भी इंतजार कर रहा हूं जब मैं अपने आयात को क्रमबद्ध करने के लिए अपने संपादक में एक ऑटोफॉर्मेटर का उपयोग कर सकता हूं ... लेकिन यह जानने की संभावना कम है कि @using के साथ क्या करना है ...

मैं @kmsquire से भी सहमत हूं कि यह इतना बड़ा मुद्दा नहीं है, और ImportMacros पर्याप्त होना चाहिए। लेकिन जो भी तरीका प्रलेखित किया जाना चाहिए ताकि वह फिर से सामने न आए।

हालांकि मुझे अभी भी m=import Module चीनी पसंद है

मैं अपने संदेश का मतलब यह नहीं कहना चाहता था कि यह कोई बड़ी बात नहीं है।

मैं अभी भी इसके लिए एक वाक्यविन्यास पसंद करूंगा।

इंपोर्टमैक्रोज़ पर्याप्त है। मैं सिर्फ टिप्पणियों से सहमत हूं कि यह उतना साफ नहीं दिखता है।

मैं सहमत हूं। के लिए भी:

using ImportMacros
<strong i="8">@using</strong> OtherPackage as ...

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

न तो व्यावहारिक कोड में विशेष वाक्य रचना की गारंटी देने के लिए बहुत बार उपयोग किया जाता है

लोग इम्पोर्टमैक्रोस का वास्तविक कोड में बहुत अधिक उपयोग नहीं करने का कारण एक ट्रेडऑफ़ के कारण हो सकता है। उदाहरण के लिए, मैं लगभग हर बार import ... as ... का उपयोग करूंगा, लेकिन संभवत: ऐसा करने के लिए पहले दूसरे पैकेज को आयात करने की कीमत पर नहीं। एक अतिरिक्त निर्भरता से अधिक, इसका "फील" के संदर्भ में भी प्रभाव पड़ता है (और कुछ लोग अपने कोड को चिकना दिखने के लिए पसंद करते हैं (विशेषकर अजगर या जूलिया में) ‍♂️ , और यह using/@using बल्कि " हैकी" एक स्क्रिप्ट की शुरूआत के लिए खिंचाव)।

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

मुझे लगता है कि import ... as ... वाक्यात्मक चीनी है जो निश्चित रूप से इसके लायक होगी, इसे समझना और समझाना वास्तव में आसान है, और विशेष रूप से जूलिया जैसी भाषाओं में उपयोगी है जिसमें पैकेज में लंबे नाम होते हैं (जाहिर है, यह मायने रखता है केवल इस धारणा के तहत कि लोग using ... नहीं करना चाहते हैं)।

और यह तथ्य कि पायथन ने इसे पहले लागू किया था, वास्तव में प्रासंगिक नहीं होना चाहिए; जूलिया को अन्य भाषाओं से खुद को दूर करने और/या अपनी पहचान पर जोर देने से पहले सर्वश्रेष्ठ वाक्यविन्यास रखने का प्रयास करना चाहिए।

इसके लिए वाक्यविन्यास और लोकप्रिय मॉड्यूल के आसपास सम्मेलन (मैं सोच रहा हूं कि यह हमेशा import numpy as np और import matplotlib.pyplot as plt कैसे होता है) using SuchAndSuch करने और export पर भरोसा करने का संक्षिप्त विकल्प भी देगा

@DominiqueMakowski :

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

मुझे समझ में नहीं आता कि आपको क्यों लगता है कि यह एक असंगति है, यह केवल नाम स्थान प्रबंधन है, जो बड़े पैमाने पर प्रोग्रामिंग का एक सामान्य हिस्सा है।

इसके अलावा, मॉड्यूल का नाम बदलना कुछ ऐसा नहीं हो सकता है जो जूलिया के नवागंतुकों को पहले सामना करना पड़े।

मैं यह नहीं कह रहा हूं कि उपयोग का कोई मामला नहीं है, लेकिन अपने स्वयं के कीवर्ड को सही ठहराना दुर्लभ हो सकता है। फिलहाल, using ImportMacros की खोज करने पर Github पर <10 अद्वितीय परिणाम मिलते हैं।

मैं लगभग हर बार आयात ... के रूप में ... का उपयोग कर रहा हूं, लेकिन संभवतः इसे करने के लिए पहले दूसरे पैकेज को आयात करने की कीमत पर नहीं

यह दोनों तरीकों से कटौती करता है: यदि ImportMacros या एक अतिरिक्त प्रतीक ( import LongFoo; const Foo = LongFoo ) जैसे लाइटवेट पैकेज का उपयोग करने की (बहुत मामूली) लागत लाभ के लायक नहीं है, तो लाभ इतना बड़ा नहीं हो सकता है .

जूलिया को अन्य भाषाओं से खुद को दूर करने और/या अपनी पहचान पर जोर देने से पहले सर्वश्रेष्ठ वाक्यविन्यास रखने का प्रयास करना चाहिए।

मुझे यकीन नहीं है कि आपको क्यों लगता है कि यह इस चर्चा में एक प्रेरणा है।

ऐसे कुछ मामले हैं जहां आप as का उपयोग करना चाहेंगे जहां const असाइनमेंट काफी काम नहीं करता है:

julia> using Distributed

julia> import Future; const future = Future
Future

julia> Future === Distributed.Future # oops, this is what we wanted
false

julia> Future === future # not what we wanted `Future` to mean
true

हां, आप इसके आसपास काम कर सकते हैं, लेकिन यह अजीब है। यह देखते हुए कि यह अक्सर आसान होता है, कभी-कभी इसकी आवश्यकता होती है और import FooBar as FB आम तौर पर "कम से कम आश्चर्यजनक" वाक्यविन्यास पर सहमत होता है, ऐसा लगता है कि हमें किसके साथ जाना चाहिए। यह सब जरूरत है किसी को इसे लागू करने के लिए पीआर बनाने की।

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

मुझे नहीं पता कि इस सिंटैक्स को जोड़ना कितना जटिल है? क्या यह नौसिखिया के लिए संभव है?

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

एकाधिक मॉड्यूल में फ़ंक्शन नाम संघर्ष से बचने के लिए यह एक अच्छी सुविधा होगी।

सुस्त पर चर्चा से, मैं कुछ विचार जोड़ता हूं

मुझे आश्चर्य है कि क्या यह लोगों को फ़ंक्शन नाम चुनने और सही कार्यों में सही तरीके से जोड़ने के तरीकों को कम सावधान करेगा। तथ्य यह है कि, उदा।

numpy.sin
sympy.sin

यदि आप चाहते हैं कि यह संख्यात्मक और प्रतीकात्मक दोनों इनपुट के लिए काम करे तो आपके फ़ंक्शन के दो संस्करणों को लागू करने का एक निश्चित तरीका है। यदि सुविधा के कारण जूलिया में भी इस तरह के नेमस्पेसिंग व्यापक हो जाते हैं, तो हम बहुत सारे कोड के पुन: उपयोग से चूक सकते हैं? यानी, मुझे डर है कि यह हमें " यह लोगों को एक साथ काम करने के लिए प्रोत्साहित करता है" कम दे सकता है क्योंकि इसे लिंडन ने https://www.oxinabox.net/2020/02/09/whycompositionaljulia.html में रखा था।

@baggepinnen मुझे नहीं लगता कि यह उस संबंध में कुछ भी बदलता है।

जूलिया में विभिन्न मॉड्यूल में लागू विधियों को एक ही नामस्थान में दोनों विधियों को आयात करके विलय नहीं किया जाता है।

julia> module Foo
           export sin
           sin(s::String) = uppercase(s)
       end
Main.Foo

julia> sin(1)
0.8414709848078965

julia> using .Foo
WARNING: using Foo.sin in module Main conflicts with an existing identifier.

julia> sin("wat")
ERROR: MethodError: no method matching sin(::String)
Closest candidates are:
  sin(::BigFloat) at mpfr.jl:727
  sin(::Missing) at math.jl:1197
  sin(::Complex{Float16}) at math.jl:1145
  ...
Stacktrace:
 [1] top-level scope at REPL[4]:1
 [2] run_repl(::REPL.AbstractREPL, ::Any) at /build/julia/src/julia-1.5.1/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:288

julia> Foo.sin("wat")
"WAT"

काम करने के लिए किसी को मूल कार्य में स्पष्ट रूप से एक प्रेषण जोड़ना होगा:

julia> Base.sin(s::String) = Foo.sin(s)

julia> sin("wat")
"WAT"

जहां तक ​​​​मैं कह सकता हूं, मॉड्यूल एलियासिंग को बदलने के तरीके को बदलने के लिए कोई संभावित तरीका नहीं है।

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

@ninjaaron मैं ऊपर अपनी चिंता में कुछ बारीकियों को बताने में विफल रहा हूँ। मुझे इस परिवर्तन से कोई सरोकार नहीं है कि लोग पुस्तकालयों को लागू करते समय जो रणनीति चुनते हैं, उसके अलावा कुछ भी बदल जाए।
Foo को लागू करने वाले व्यक्ति को इस तरह की चेतावनी का सामना करना पड़ रहा है

julia> using .Foo
WARNING: using Foo.sin in module Main conflicts with an existing identifier.

या तो बस import .Foo.sin as sin2 चुन सकते हैं, या इस बारे में सोच सकते हैं कि वह वास्तव में Base.sin के लिए एक नया प्रेषण प्रदान करना चाहता था या नहीं। मेरा कहना था कि अगर उन्हें अलग-अलग कार्यों पर विचार करना बहुत आसान हो जाता है, तो शायद यह बहुत व्यापक हो जाएगा, यहां तक ​​​​कि उन परिस्थितियों में भी जब वे वास्तव में एक ही कार्य के विभिन्न तरीके होने चाहिए। वर्तमान स्थिति, जहां एक ही नाम के साथ विभिन्न कार्यों से निपटना थोड़ा अधिक अजीब है, इसका अच्छा दुष्प्रभाव है कि लोग एक-दूसरे से बात करते हैं और यह पता लगाने की पूरी कोशिश करते हैं कि यह वास्तव में एक ही कार्य है या नहीं। मैं एक ही नाम के साथ अलग-अलग कार्य करने की संभावना के खिलाफ बहस नहीं कर रहा हूं, जो निश्चित रूप से बहुत उपयोगी हो सकता है। मुझे यह भी नहीं पता कि मेरी चिंता महत्वपूर्ण है या नहीं, लेकिन मुझे लगा कि इस पर विचार किया गया है यह सुनिश्चित करने के लिए इसे उठाना इसके लायक है।

@baggepinnen यह समझ में आता है, और इसे लाने में कोई बुराई नहीं है। मुझे नहीं लगता कि इससे पुस्तकालय बनाने वाले लोगों के लिए बहुत बड़ा अंतर आएगा, क्योंकि मॉड्यूल एलियासिंग केवल पुस्तकालय उपयोगकर्ताओं को प्रभावित करेगा। मुझे लगता है कि यह संभव है कि आसान मॉड्यूल अलियासिंग होने से कम उपयोगकर्ता _complaining_ नामकरण संघर्ष के बारे में परिणाम देंगे, लेकिन मुझे आश्चर्य होगा कि इसका एपीआई पर जबरदस्त प्रभाव पड़ता है।

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

@ninjaaron मुझे लगता है कि अगर वर्तमान सम्मेलन प्रेषण के लिए विशिष्ट कार्यान्वयन का उपयोग कर रहा है जैसे

numpy.sin
sympy.sin

उपयोगकर्ता/डेवलपर के लिए अतिरिक्त विकल्प के रूप में import numpy.sin as np_sin का उपयोग करने से वर्तमान कोड आधार प्रभावित नहीं होना चाहिए।
एकमात्र चिंता केवल एक्सपोज़ फ़ंक्शन/इंटरफ़ेस को प्रभावित करेगी।