2010-04-07 7 views
5

मैं इसे बहुत सुविधाजनक विन्यास और अन्य डेटा या पढ़ा जाता है एक बार गणना की लेकिन फिर पर्ल के use तंत्र का उपयोग करके एक कार्यक्रम के दौरान कई बार इस्तेमाल किया पारित करने के लिए की खोज कर रहा हूँ। मैं कॉलर के नामस्थान में हैश निर्यात करके ऐसा कर रहा हूं।क्या पर्ल में चर निर्यात करने के लिए यह अच्छा अभ्यास है?

package Myconfiguration; 

my %config; 

sub import { 
    my $callpkg = caller(0); 
    my $expsym = $_[1]; 

    configure() unless %config; 

    *{"$callpkg\::$expsym"} = \%config; 
} 

और फिर दूसरे मॉड्यूल में: उदाहरण के लिए:

use MyConfiguration (loc_config_sym); 

if ($loc_config_sym{paramater}) { 
    # ... do stuff ... 
} 

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

उत्तर

5

आप केवल %config के मूल्यों में पढ़ना चाहते हैं, तो क्यों एक दिनचर्या के लिए यह करने की जरूरत नहीं आप?

my %config; 
sub config_value 
{ 
     my ($value) = @_; 
     return $config{$value}; 
} 

यदि आप चाहते थे डिफ़ॉल्ट रूप से इस निर्यात कर सकता है:

package Mypackage; 
require Exporter; 
@EXPORT = qw/config_value/; 

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

sub set_value 
{ 
     my ($key, $value) = @_; 
     $config{$key} = $value; 
} 
+0

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

+0

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

2

मुझे लगता है कि यह config हैश की एक प्रति के साथ काम करना बेहतर है। इस तरह, यदि आप कुछ तत्वों को संशोधित करते हैं, तो यह आपके शेष कोड को प्रभावित नहीं करेगा।

मैं आमतौर पर get_property() की तरह एक भी विधि के साथ इस के लिए सरल वस्तु (वैकल्पिक सिंगलटन) का उपयोग करें।

+0

यह विशेष उदाहरण कॉन्फ़िगरेशन में से एक था, लेकिन इसकी आवश्यकता नहीं है। यानी, मैं * तत्व * तत्वों को बदलना चाहता हूं। – gvkv

+0

आप एक सिंगलटन में मान बदल सकते हैं। –

0

सामान्य तौर पर, यह उपयोगकर्ता को यह तय किया जाए या नहीं प्रतीकों आयात करने के लिए जाने के लिए सबसे अच्छा है। Exporter यह आसान बनाता है। उपयोगकर्ता तय आयातित प्रतीकों दुर्लभ अवसरों पर उपयोगी हो सकता है लेकिन मुझे नहीं लगता यह उनमें से एक है कि क्या नाम करने के लिए जाने के लिए एक कस्टम import विधि लेखन।

package MyConfiguration; 
require Exporter; 

our @ISA  = qw(Exporter); 
our @EXPORT_OK = qw(Config); 

our %Config; 

और फिर, अपनी स्क्रिप्ट में:

use MyConfiguration; 
print $MyConfiguration::Config{key}; 

या

use MyConfiguration qw(Config); 
print $Config{key}; 
+3

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

2

मैं कभी नहीं चर निर्यात सलाह देते हैं:

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

संबंधित मुद्दे

 संबंधित मुद्दे