Powershell: सुझाव: टर्नरी सशर्त लागू करें

ध्यान दें कि बयानों से असाइनमेंट की अनुमति देने के लिए परिवर्तन के साथ, टर्नरी ऑपरेटर की आवश्यकता कम हो जाती है। आप बस कर सकते हैं
$var = if ($x) { $x } else { $y }
यह टर्नरी ऑपरेटर जितना संक्षिप्त नहीं है, लेकिन यकीनन अधिक पठनीय है।

हां, हालांकि आपको अभी भी $(...) _in अतिरिक्त_ का उपयोग करना होगा यदि सशर्त एक बड़ी अभिव्यक्ति का हिस्सा है:

'The current sec. is ' + $(if ((get-date).tostring("ss") % 2) { 'odd'  } else  { 'even' })

बनाम

powershell 'The current sec. is ' + ((get-date).tostring("ss") % 2 ? 'odd' : 'even')

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

इस तरह की अक्सर उपयोग की जाने वाली सुविधा के साथ, मुझे लगता है कि अधिक अमूर्त टर्नरी सिंटैक्स को याद रखना कोई समस्या नहीं होगी (और, निश्चित रूप से, लोग if का उपयोग करना जारी रख सकते हैं, यदि वे चाहें)।

@ mklement0 मुझे बाद में सहमत होना होगा कि संज्ञानात्मक भार कम है।

यह निश्चित रूप से मेरी शीर्ष सूची में है।
@ ब्रूसपे , क्या कोई कारण है कि यह एक बुरा विचार होगा? या यह सिर्फ 'जहाज से चुनना है' के बारे में है?

अतीत में, इस सुविधा अनुरोध को कम अनुभवी पटकथाकारों के लिए समझने में कठिन होने के कारण ठुकरा दिया गया था, और यह कि अगर कथन का अभिव्यक्ति रूप एक स्पष्ट था, हालांकि अधिक क्रिया विकल्प।

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

@lzybkr :

यह किसी सुविधा के _सक्रिय उपयोग_ बनाम _पहचानने_ की क्षमता और इसे समझने के बीच अंतर करने लायक है।

स्पष्ट रूप से, हर किसी को यह चुनने का अधिकार है कि इस तरह की सुविधा का उपयोग करना है या नहीं, लेकिन क्या आप कह रहे हैं कि "इसमें परेशानी है" का अर्थ है कि कम अनुभवी लोग इसे दूसरों के कोड में देखने पर _समझ नहीं पाएंगे?

@ mklement0 - हमने $psitem को $_ लिए एक उपनाम के रूप में पेश किया क्योंकि पर्याप्त प्रतिक्रिया के कारण $_ गूढ़ और भ्रमित करने वाला था, इसलिए मुझे विश्वास है कि टर्नरी ऑपरेटर कुछ कम के लिए मुश्किल होगा अनुभवी लोगों को समझने के लिए।

दूसरी ओर, पॉवरशेल में कई ऐसे तत्व हैं जो शुरुआती लोगों या यहां तक ​​कि काफी अनुभवी डेवलपर्स को भ्रमित कर रहे हैं।

किसी भी अन्य भाषा की तरह, भाषा निर्माणों के वाक्य-विन्यास और अर्थ को सीखने के लिए कुछ प्रयास करने पड़ते हैं।
मुझे नहीं पता कि क्या मुझे लगता है कि टर्नरी ऑपरेटर को समझना विशेष रूप से कठिन है।

क्या आपके पास यह सुझाव देने वाला डेटा है कि यह है?

मेरा मानना ​​​​है कि केवल डेटा ही वास्तविक है, लेकिन आलोचना किसी भी गुप्त भाषा पर लागू होती है - बैश, पर्ल, आदि।

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

यह भी ध्यान रखें - कुछ संक्षिप्त भाषाएं अभी भी टर्नरी ऑपरेटर के रूप में उपयोग करती हैं, उदाहरण के लिए एफ #।

उस ने कहा, शायद कम वर्णों का उपयोग करना संभव है और बहुत गूढ़ नहीं होना चाहिए:

if ($x) { $y } else { $z }
$x -then $y -else $z
$x ? $y : $z

-then/-else पावरशेल सिंटैक्स के साथ अच्छी तरह से फिट बैठता है - लेकिन, एक ऑपरेटर (या ऑपरेटर यदि यह एक एकल ऑपरेटर के रूप में सोचने के लिए बहुत भ्रमित है), तो आपको माता-पिता और ब्रेसिज़ की आवश्यकता नहीं होने का लाभ मिलता है।

फिर फिर, यह foreach बनाम foreach-object जैसी समस्या के लिए पूछ रहा है। लेकिन शायद यह उतना बुरा नहीं है, मुझे नहीं पता।

@lzybkr :

होम्योपैथिक खुराक में गुप्त स्वस्थ है:

पावरशेल सराहनीय रूप से समग्र रूप से गुप्त नहीं है, लेकिन कुछ मामलों में _अक्सर उपयोग किए जाने वाले निर्माणों के लिए संक्षिप्त _alternative_ (आप अभी भी वर्बोज़ हो सकते हैं) के रूप में गुप्त वाक्यविन्यास प्रदान करते हैं, विशेष रूप से ? लिए Where-Object और % लिए ForEach-Object ।

उपलब्ध कराना $x ? $y : $z करने के लिए एक संक्षिप्त विकल्प के रूप में if ($x) then { $y } else { $z } मेरे लिए एक ही आत्मा में है।

गुप्त पहलू को ? द्वारा एक _question_ की याद ताजा करने और इसलिए एक सशर्त (यद्यपि एक _preceding_ इस मामले में ? ) का सुझाव देकर बेहतर किया जाता है, और - अधिक महत्वपूर्ण बात - कई से संभावित रूप से परिचित निर्माण होने के नाते अन्य भाषाएँ_, समान मौलिक शब्दार्थ के साथ।

आपको $x -then $y -else $z साथ समान लाभ नहीं मिलता है: यह परिचित नहीं है।

इसके अलावा, जबकि कई पीएस ऑपरेटरों के प्रतीकात्मक नाम होते हैं, कई नहीं: * / + % ...
ये स्वाभाविक रूप से गूढ़ भी हैं, हम उन्हें अब उस तरह से नहीं देखते हैं, क्योंकि वे बहुत परिचित और सर्वव्यापी हैं।

मेरी समझ में यह है कि $x ? $y : $z भी पहले से ही कई लोगों से परिचित है, और संक्षिप्त शर्तों की लगातार आवश्यकता को देखते हुए, भाषा में पेश किए जाने के बाद और भी अधिक हो जाएगा।

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

(test-path foo.txt) ? (get-content foo.txt) : (get-content bar.txt)

के साथ तुलना

if (test-path foo.txt) {get-content foo.txt} else {get-content bar.txt}

या

get-content ((test-path foo.txt) ? "foo.txt" : "bar.txt")

बनाम

get-content $(if (test-path foo.txt) {"foo.txt"} else {"bar.txt"})

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

विशेष रूप से आप कमांड का उपयोग तब तक नहीं कर पाएंगे जब तक कि आप उन्हें कोष्ठक में लपेट नहीं देते:

यह _any_ पावरशेल ऑपरेटर पर लागू होता है।

सभी पावरशेल स्टेटमेंट में कमांड शामिल नहीं होते हैं, और जब वे ऐसा करते हैं, तो उपयोगकर्ता पहले से ही जानते हैं कि (...) कमांड के लिए प्रवेश की कीमत है (ज्यादातर मामलों में)।

आपके अपने उदाहरण में, मेरे लिए ((test-path foo.txt) ? "foo.txt" : "bar.txt") धड़कता है $(if (test-path foo.txt) {"foo.txt"} else {"bar.txt"}) , दोनों की जरूरत की अस्पष्टता के लिए $(...) और घुंघराले ब्रेसिज़ द्वारा पेश किए गए शोर।

शायद यह सिर्फ मैं हूं लेकिन मुझे यह मिल गया है:

get-content ((test-path foo.txt) ? "foo.txt" : "bar.txt")

इससे दृष्टि से स्कैन/पार्स करने का

get-content $(if (test-path foo.txt) {"foo.txt"} else {"bar.txt"})

इस मुद्दे के बारे में मेरी एकमात्र शिकायत यह है कि यदि आप टर्नरी ?: करने जा रहे हैं तो आपको ?? नल-कोलेसिंग भी करना चाहिए:

$logDir = $env:LogDir ?? "$PSScriptRoot\Log"

मैंने जंगली में कई Invoke-Tternary और Invoke-NullCoalescing कार्यान्वयन देखे हैं (उदाहरण के लिए https://github.com/dahlbyk/posh-git/blob/master/src/Utils.ps1#L12)। इस तरह का संकेत भाषा में पके हुए इस तरह की सुविधा के लिए एक सामान्य इच्छा है।

@rkeithhill : मैं सहमत हूं; पुन: नल-कोलेसिंग: पहले से ही एक समस्या है, जिसमें नल-भिगोना भी शामिल है: #3240

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

POSH में व्यावहारिक उदाहरण, मेरे पास यह पंक्ति है:
$mc_object = ($Message.fields | where Name -Match appname).Content
जो ठीक और बांका है सिवाय इसके कि जब $Message ऑब्जेक्ट में एक दायर संपत्ति नहीं है जिसका नाम "ऐप नाम" है, और चूंकि मैं JSON स्वरूपित डेटा को नियंत्रित नहीं करता हूं, इसलिए मुझे यह निर्धारित करना होगा कि क्या करना है।

तो एक नल-कोलेस ऑपरेशंस के साथ मुझे यह सुनिश्चित करने के लिए अंत में ?? "" जोड़ना है कि $mc_object हमेशा एक वैध स्ट्रिंग था, भले ही मूल सेटर शून्य था। अन्यथा, 4 कीस्ट्रोक्स क्या कर सकते हैं, इसे पूरा करने के लिए मुझे कुछ अलग तकनीकें करनी होंगी, जैसे कि
$mc_object = if(-not ($Message.fields | where Name -Match appname).Content)){""}else{($Message.fields | where Name -Match appname).Content}
वह मेरे लिए बहुत अपठनीय है, लेकिन फिर मैं कुछ ऐसा करके इसे थोड़ा साफ कर सकता हूं, जो मैं कर रहा हूं।
$mc_object = ($Message.fields | where Name -Match appname).Content if(-not $mc_object){$mc_object = ""}

भयानक नहीं होने पर, यह 4 से अधिक चाबियों की एक बिल्ली है जिसे नल-कोलेसेस के लिए दबाया जा रहा है।

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

@lzybkr मैंने अभी तक किसी को भी वास्तव में $PSItem को अपनाते हुए नहीं देखा है। मैं स्क्रिप्ट लिखने वाले लोगों की एक बड़ी टीम पर काम करता हूं और वे अभी भी $_ , यहां तक ​​​​कि कम-अनुभवी पावरशेल उपयोगकर्ता भी।

@tibmeister या ....

if (-not ($mc_object = $Message.fields.where{$_.Name -match 'appname'}.Content)) {
    $mc_object = ''
}

भाव के रूप में असाइनमेंट पासथ्रू होंगे, लेकिन अविश्वसनीय रूप से अपठनीय हैं।

मैं नियमित रूप से $psitem . का उपयोग करता हूं

स्क्रिप्टिंग गेम्स को जज करने के कई वर्षों के दौरान उत्तरों में $psitem का बहुत उपयोग किया गया

@RichardSiddaway : यदि हम 2014_ से पूछे गए PowerShell-टैग किए गए प्रश्नों पर स्टैक ओवरफ़्लो को देखते हैं, तो हमें (इस लेखन के अनुसार) मिलता है:

• सीए। 106, 000 पोस्ट powershell टैग किए गए (इसमें उत्तर भी शामिल हैं; यदि आप प्रश्नों को प्रश्नों तक सीमित रखते हैं, तो आपको लगभग 46,000 मिलते हैं)
• इनमें से 71 में PSItem शब्द है (उनमें से 13 प्रश्न हैं), यानी 1% से कम

$PSItem को सितंबर 2012 में v3 में पेश किया गया था, इसलिए सुरक्षित रहने के लिए मैंने 2014 को क्वेरी के लिए प्रारंभ तिथि के रूप में चुना।

हालांकि यह एक सटीक मीट्रिक नहीं है, - दुर्भाग्य से, साइट आपको $_ या _ खोज करने की अनुमति नहीं देती है, और मुझे यकीन है कि ऐसे प्रश्न हैं जिनमें _neither_ $_ और न ही $PSItem , और पूर्व-v3 प्रश्न अभी भी पूछे जा रहे हैं - मुझे अभी भी लगता है कि यह निष्कर्ष निकालना सुरक्षित है कि $_ का उपयोग $PSItem तुलना में कहीं अधिक बार किया जाता है।

हालाँकि, बड़ी बात यह है कि _choose_ की कोई आवश्यकता नहीं है:

जिस तरह $PSItem और $_ खुशी से सह-अस्तित्व में हैं, उसी तरह ForEach-Object और % , Where-Object और ? , .. ।:

$a ? $b : $c if ($a) { $b } else { $c } / $(if ($a) { $b } else { $c }) साथ सह-अस्तित्व में हो सकता है

$a ? $b : $c को पेश करने के _positive_ कारणों को फिर से तैयार करने के लिए

• अधिकांश प्रोग्रामर से परिचित सिंटैक्स का उपयोग करते हुए, अधिक संक्षिप्त, कम नेत्रहीन।

• अधिक कुशल, क्योंकि $(...) की कोई आवश्यकता नहीं है, जो if बयानों को एक बड़ी अभिव्यक्ति के हिस्से के रूप में उनके उपयोग की अनुमति देने के लिए आवश्यक है (जो शोर है, कम कुशल है, और अनपेक्षित पक्ष हो सकता है प्रभाव)

अस्पष्टता चिंता के लिए:

कोई व्यक्ति _expressions_ (केवल _invoking कमांड_ (सरल) तर्कों के साथ लिखने के विपरीत) को कुछ डेवलपर अनुभव माना जा सकता है, और मेरी (उपाख्यानात्मक) भावना यह है कि अधिकांश डेवलपर्स कम से कम _मान्यता_ $a ? $b : $c एक संघनित if विवरण, चाहे वे सक्रिय रूप से इसका उपयोग करते हों या नहीं।

भले ही वे नहीं करते हैं, हालांकि, यह आसानी से समझाया गया है, और गैर-स्पष्ट _symbols_ के उपयोग के अलावा, वैचारिक जटिलता if ($a) { $b } else { $c } , और इससे भी कम
$(if ($a) { $b } else { $c })

यह मानते हुए कि यह एक बार शुरू हो जाता है - निश्चित रूप से, यह चर्चा दर्शाती है कि इसकी मांग है - इसका बार-बार सामना करने से यह एक परिचित और आसानी से पहचाने जाने योग्य मुहावरा बन जाएगा (जो कि अधिक संक्षिप्त, टाइप करने में आसान और, कम से कम मेरे और कुछ अन्य लोगों के लिए है) यहाँ, अधिक पठनीय) - जैसे अधिकांश लोग $_ से अधिक $PSItem ।

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

इसे फिर से पढ़ना और फिर से देखना और कुछ सवालों को देखते हुए, मैं खुद को सुझाए गए कुछ अधिक वर्बोज़ सिंटैक्स की ओर झुका हुआ पाता हूं:

$value = $a -eq $b -then $trueVal -else $falseval

या, अधिक अर्थपूर्ण रूप से पठनीय वाक्यविन्यास के लिए:

$value = $trueVal -if $a -eq $b -else $falseVal

@ vexx32 जबकि मुझे आपके पहले उदाहरण से कोई आपत्ति नहीं है, मुझे एक अभिव्यक्ति के बीच की स्थिति बेहद भारी

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

यह देखते हुए कि पावरशेल का उद्देश्य सी # के लिए "रैंप पर" भाषा होना है, मुझे लगता है कि ? : का उपयोग करने का तरीका है। जावास्क्रिप्ट भी इस सिंटैक्स का उपयोग करता है और यह इन दिनों सबसे लोकप्रिय भाषाओं में से एक है। :-)

सहमत, @rkeithhill , दोनों कई अन्य भाषाओं से निर्माण की परिचितता के लिए नल-कोलेसिंग, नल-भिगोने, और शून्य-सशर्त असाइनमेंट की इच्छा, जो सी # में ? भी आधारित हैं।

बाद के दो - जैसे $foo?.bar और $var ?= 'default val' - प्रतीक-आधारित प्रतिनिधित्व के बिना वास्तव में संभव नहीं हैं, और यहां तक ​​​​कि शून्य-कोलेसिंग के लिए भी $a ?? 'value-if-null' $a -elseifnull 'value-if-null' जैसी किसी चीज़ के लिए बेहतर लगता है

याद रखें कि ? , Where-Object लिए अक्सर उपयोग किए जाने वाले उपनाम के रूप में, पहले से ही _कंडीशनल_ का प्रतिनिधित्व करने के रूप में मजबूती से जुड़ा हुआ है, इसलिए उस ज्ञान को इसके उपयोग की विविधताओं में स्थानांतरित करना तार्किक लगता है।

क्या PowerShell वास्तव में C# के लिए एक ऑन-रैंप है? मुझे पता है कि 10-12 साल पहले यह एक घोषित इरादा था लेकिन क्या यह वास्तव में हो रहा है? मेरा संदेह यह है कि अधिकांश पावरशेल उपयोगकर्ताओं के लिए सी # कहीं नहीं जाना चाहते हैं।

अगर टर्नरी सशर्त होने जा रहे हैं तो मैं कुछ ऐसा देखना पसंद करूंगा
$value = $trueVal -if $a -eq $b -else $falseVal

जैसा कि @vexx32 . ने बताया है

यह औसत पावरशेल उपयोगकर्ता के लिए अधिक समझ में आता है।

@mklement0 $psitem के बारे में मेरी टिप्पणियाँ मेरे व्यक्तिगत अनुभव पर आधारित थीं। यदि आपके पास एक अलग अनुभव है तो यह मेरे अनुभव को अमान्य नहीं करता है

मुझे पता है कि 10-12 साल पहले एक घोषित इरादा था

हाँ, जेफ्री द्वारा अन्य स्थानों के बीच प्रारंभिक एमवीपी शिखर सम्मेलन में। मैंने तब से कोई अलग नहीं सुना।

इसके अलावा, लगभग सभी सशर्त/लूप निर्माण सी # (और सी वंश) से लेते हैं, if {} , while {} , do {} while , स्विच {} , {} , foreach {} , {} पकड़ने की कोशिश करें {} अंत में {}`। यह मेरे लिए समझ में आता है कि यह सशर्त निर्माण भी होगा।

वे भाषा कीवर्ड हैं, हालांकि, @rkeithhill। ऑपरेटर पूरी तरह से अलग हैं।

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

मैं मानता हूं कि अधिक वर्बोज़ सिंटैक्स विकल्प उपलब्ध होने के बाद टर्नरी व्यवहार भी लेना चाहिए। पावरशेल को सी # के लिए 'ऑन-रैंप' के रूप में माना जा सकता है, लेकिन इसका मतलब यह नहीं है कि इसे इसके अधिक प्रतीकात्मक वाक्यविन्यास प्राप्त करना चाहिए। वास्तव में, ऐसी कई जगहें हैं जहाँ से बड़ी मेहनत से परहेज किया गया है।

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

यदि पावरशेल सी # या किसी अन्य भाषा के लिए 'ऑन-रैंप' भाषा है (जो, मुझे लगता है, यह अब तक काफी अच्छा करता है) तो हमें यहां सबसे कम आम भाजक पर विचार करने की जरूरत है और इस बारे में सोचें कि सबसे अनुभवहीन व्यक्ति क्या पाएंगे समझदार और सहज ज्ञान युक्त ।

मैं यह नहीं कह रहा हूँ मेरी proffered समाधान यह है, लेकिन मुझे लगता है कि वे संभवतः इस नजरिए से एक अधिक समझदार दिशा में आगे बढ़ रहे हैं।

@vexx32
इन ऑपरेटरों के बारे में क्या?

.
=
[]
,
+ - * / %
++ --
+=  -=  *=  /= %=

आम तौर पर, मैं मानता हूं कि सी # के नेतृत्व का पालन करना हमेशा उचित नहीं होता है, और पावरशेल की भावना को संरक्षित करना प्राथमिकता होनी चाहिए।

इसके विपरीत, मैं उन मामलों में सी # से विचलित होने के खिलाफ सलाह दूंगा जहां एक ही वाक्यविन्यास एक व्यावहारिक फिट की तरह प्रतीत होता है, और मेरे लिए प्रस्ताव - # 3240 के साथ - इसका एक उदाहरण है।

अगर हम दूसरी भाषाओं को छोड़ दें:

• ? का वर्तमान शब्दार्थ संभवतः प्रस्तावित ऑपरेटरों तक विस्तारित है।

• यदि आप _संबंधित_ ऑपरेटरों में मूल्य देखते हैं - नल-सोकिंग ( ?. ), नल-कोलेसिंग ( ?? ) और शून्य-सशर्त असाइनमेंट ( ?= ) - फिर विकल्प चुनना एक वर्बोज़ टर्नरी फॉर्म के लिए जैसे -then / -else एक विकल्प नहीं है, यदि आप चाहते हैं कि ये सभी संबंधित ऑपरेटर एक समानता को प्रतिबिंबित करें (जो उनके पास स्पष्ट रूप से अवधारणात्मक है)।

एक विशेषता जितनी अधिक विदेशी होती है, उतनी ही अधिक वाचालता महत्वपूर्ण होती है।

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

मेरे साथ चर्चा किए जा रहे सभी ऑपरेटर बाद की श्रेणी में आते हैं।

@ रिचर्डसिडवे :

$Psitem के बारे में मेरी टिप्पणियाँ मेरे व्यक्तिगत अनुभव पर आधारित थीं। यदि आपके पास एक अलग अनुभव है तो यह मेरे अनुभव को अमान्य नहीं करता है

हाँ, आपकी टिप्पणियाँ _व्यक्तिगत_ अनुभव पर आधारित थीं।
मेरा _सामान्य_ उपयोग पैटर्न (कथित बाधाओं के भीतर) का अनुमान लगाने के लिए लोकप्रिय क्यू एंड ए साइट स्टैक ओवरफ्लो से _analyzing data_ पर आधारित थे - जो मेरे व्यक्तिगत अनुभव से असंबंधित है।

यदि आप मानते हैं कि आपकी व्यक्तिगत टिप्पणियों में "पारस्परिक" सत्य को प्रतिबिंबित करने के लिए मेरी टिप्पणियों को अमान्य करने का एकमात्र कारण है - एक ऐसा दावा जो आपने अपनी टिप्पणियों में नहीं किया था। क्या आपका मतलब इसे बनाना था? यदि ऐसा है, तो हमें _that_ पर चर्चा करने की आवश्यकता है।

लगभग वे सभी ऑपरेटर गणितीय संचालिका हैं जिनका अपेक्षाकृत स्पष्ट अर्थ है,

एक टर्नरी ऑपरेटर एक सशर्त ऑपरेटर है, और पीएस के बूलियन/सशर्त ऑपरेटरों के _all_ अधिक वर्बोज़ फॉर्म के हैं: -and , -or , -eq , -ne , -contains , आदि।

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

ऑपरेटर गणितीय ऑपरेटर हैं

सूचीबद्ध लोगों में, केवल + - * / % का (विशुद्ध रूप से) गणितीय अर्थ है, लेकिन स्पष्ट रूप से समझा जाने वाला पहलू दूसरों पर भी लागू होता है ( = के अपवाद के साथ, यह देखते हुए कि यह अक्सर समानता परीक्षण के साथ भ्रमित होता है )

<condition> ? <if-true> : <else> तुलना करने के लिए बेहतर निर्माण if _statement_ है, अन्य ऑपरेटर नहीं। जबकि if निश्चित रूप से अधिक वर्बोज़ है, यह ठीक वह पहलू है जिसे टर्नरी ऑपरेशन संबोधित करने के लिए है (एक सच्ची, रचना योग्य अभिव्यक्ति होने के अलावा, if विपरीत)।

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

हममें से उन लोगों के लिए जो बार-बार इसके संपर्क में नहीं आए हैं।

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

@ mklement0 आप ? को एक वैध नाम वर्ण होने के नाते संबोधित करने का सुझाव कैसे देते हैं? ब्रेकिंग चेंज? मैं पावरशेल कोर पर लोगों को पावरशेल में अच्छी तरह से वाकिफ मानता हूं और यह अतिरिक्त सिंटैक्स (जो कि लगभग 50 वर्षों से अन्य भाषाओं में मौजूद है) एक बाधा नहीं होगी। यदि वे अधिक वाचालता चाहते हैं तो वे हमेशा if/else उपयोग कर सकते हैं।

? कमांड मोड में केवल एक मान्य उपनाम है; अभिव्यक्ति मोड के सभी रूपों में यह वर्तमान में केवल एक अमान्य वर्ण है। कोई टक्कर नहीं है।

यदि आप इस कोड को दर्ज करने का प्रयास करते हैं, तो यह केवल त्रुटिपूर्ण होगा:

$Value = $true
$Value ? "Hello!" : "Goodbye!"

परिणाम:

At line:1 char:8
+ $Value ? "Hello!" : "Goodbye!"
+        ~
Unexpected token '?' in expression or statement.
+ CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnexpectedToken

@vexx32

$what? # <- example of a valid variable name

अपने शून्य-भिगोने वाले उदाहरण में: $var?.maybenull() परवाह नहीं है कि वहां एक प्रश्न चिह्न है और यदि कोई अत्यधिक घनीभूत होने की कोशिश कर रहा है, तो उनका टर्नरी टूट जाएगा।

क्षमा करें, उस पर मुख्य रूप से दूसरे मुद्दे पर चर्चा की जा रही थी, इसलिए मुझे नहीं लगा कि आप इसका जिक्र कर रहे हैं।

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

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

$var = $test?$thing1:$thing2

लेकिन मैं खोल में रहने वाले हम में से उन लोगों के लिए किनारे के मामलों पर बालों को बहुत ज्यादा विभाजित कर सकता हूं।

सुधारा गया:

$var = ${test}?${thing1}:$thing2

@ mklement0 - मैं जरूरी नहीं कि इससे सहमत हूं:

तुलना करने के लिए बेहतर निर्माण?:to if स्टेटमेंट है, अन्य ऑपरेटर नहीं। जबकि if निश्चित रूप से अधिक वर्बोज़ है, यह ठीक वह पहलू है जिसे टर्नरी ऑपरेशन संबोधित करने के लिए है (एक सच्ची, रचना योग्य अभिव्यक्ति होने के अलावा, इसके विपरीत)।

विशेष रूप से, टर्नरी ऑपरेटर मौजूद है क्योंकि सी/सी # कथन उन्मुख भाषाएं हैं लेकिन सशर्त अभिव्यक्ति की आवश्यकता है।

अभिव्यक्ति उन्मुख भाषाओं (जैसे एफ # या जंग) में, कोई संक्षिप्त वाक्यविन्यास नहीं है क्योंकि इसे अनावश्यक माना जाता है। मुझे लगता है कि रस्ट पर टर्नरी ऑपरेटर को हटाने की यह पुरानी चर्चा दिलचस्प है।

एक चीज जो मुझे वास्तव में रस्ट में पसंद है वह है त्रुटि प्रबंधन के लिए ? ऑपरेटर का उपयोग। मेरे पास PowerShell में ? का उपयोग करने का कोई ठोस प्रस्ताव नहीं है, लेकिन ऐसा लगता है कि सशर्त अभिव्यक्ति की तुलना में त्रुटि प्रबंधन के लिए ? का बेहतर उपयोग किया जा सकता है।

@ TheIncorrigible1 , @ vexx32 : हां, नल-भिगोना तकनीकी रूप से एक ब्रेकिंग बदलाव होगा, लेकिन उम्मीद है कि बकेट 3 टाइप करें (वास्तव में, आइए वहां चर्चा जारी रखें); टर्नरी ऑपरेशन के लिए, अस्पष्टता के लिए {...} /व्हाट्सएप से पहले ? का सुझाया गया उपयोग उस समस्या को हल करता प्रतीत होता है।

@lzybkr :

विशेष रूप से, टर्नरी ऑपरेटर मौजूद है क्योंकि सी/सी # कथन उन्मुख भाषाएं हैं लेकिन सशर्त अभिव्यक्ति की आवश्यकता है।

खैर, पावरशेल में प्रवाह-नियंत्रण कथन जैसे if _हाफ_-अभिव्यक्तियाँ हैं; _simple_ अभिव्यक्तियों में, प्रस्तावित टर्नरी ऑपरेशन समकक्ष होगा; _nested_ वाले में, यह नहीं होगा:

$foo = $True  ?     1   :      0    # proposed ternary
$foo = if ($True) { 1 } else { 0 }  # equivalent `if` statement

$foo = 1 + ($True  ?     1   :      0)   # nesting OK; note that + would have higher precedence
$foo = 1 + if ($True) { 1 } else { 0 }  # !! doesn't work
$foo = 1 + (if ($True) { 1 } else { 0 })  # !! doesn't work, even with parentheses
$foo = 1 + $(if ($True) { 1 } else { 0 })  # only $(...) (and situationally @(...)) work

$() / @() की आवश्यकता सिर्फ एक सिंटैक्स असुविधा से अधिक है: इसमें व्यवहार और प्रदर्शन प्रभाव हैं।

उस ने कहा, मैं _wish_ कि if और foreach जैसे बयान वास्तविक अभिव्यक्ति थे (वर्तमान में विफल होने वाली चीजों के दो और उदाहरण: foreach ($i in 1..5) { $i } | Write-Output या foreach ($i in 1..5) { $i } > out.txt )।
मैं यह तय करने के लिए पर्याप्त नहीं जानता कि क्या वे _नहीं हो सकते हैं, हालांकि और/या यदि कोई पिछड़ा-संगतता चिंता है।
यह भी देखें: #6817

यदि if को PowerShell में एक पूर्ण अभिव्यक्ति बनना था, तो आप तर्क दे सकते हैं जिसके कारण रस्ट से टर्नरी सशर्त को हटा दिया गया: यह अब _necessary_ नहीं है।

हालांकि, इस प्रस्ताव के लिए मेरी प्रेरणा कभी भी _necessity_ नहीं थी - यह संक्षिप्तीकरण, सुविधा और पठनीयता (दृश्य अव्यवस्था) के बारे में है।

मेरे पास उपयोग करने के लिए कोई ठोस प्रस्ताव नहीं है? PowerShell में, लेकिन ऐसा लगता है? सशर्त अभिव्यक्ति की तुलना में त्रुटि प्रबंधन के लिए बेहतर उपयोग किया जा सकता है।

मुझे लगता है कि C# की तुलना में मौलिक रूप से भिन्न शब्दार्थों के साथ ? शुरुआत करना हमेशा के लिए भ्रम का स्रोत होगा।

अलग से, पावरशेल की त्रुटि प्रबंधन में सुधार चर्चा के लायक हैं।

अगर हम अगर/फिर/अन्य के लिए एक संक्षिप्त लेकिन अनजान विकल्प की तलाश में हैं, तो हमारे पास पहले से ही एक है।

( 'False', 'True' )[( Test-Condition )]

और यह भावों में काम करता है।

"This statement is " + ( 'False', 'True' )[( Test-Condition )]

@TimCurwick : यह संक्षिप्त (और अधिक अस्पष्ट) है, लेकिन समकक्ष नहीं है: प्रस्तावित टर्नरी सशर्त _short-circuiting_ (बस if स्टेटमेंट की तरह) होगा, जबकि आपका सिंटैक्स हमेशा _both_ विकल्पों का मूल्यांकन करता है।

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

पावरशेल में टर्नरी विकल्पों को कैसे प्रदर्शित किया जाए, इस पर चर्चा के संबंध में, क्या किसी ने उसी प्रारूप में एक विकल्प पर विचार किया है जैसा कि -replace / .replace() द्वारा उपयोग किया जाता है?

$a -eq $b -ternary $a,$c
$true -ternary 1,0

या

($a -eq $b).ternary($a,$c)
($true).ternary(1,0)

इससे यह स्पष्ट हो जाएगा कि ऑपरेटर इसे टर्नरी कहकर सचमुच एक टर्नरी क्रिया कर रहा है। यह वर्बोज़ है, लेकिन लिखने के लिए अभी भी छोटा है, और यह -operator $first,$second के मौजूदा सामान्य व्यवहार का उपयोग करता है, इसलिए इसे अनुभव की सभी श्रेणियों में पॉवरशेल उपयोगकर्ताओं के लिए परिचित होना चाहिए

यह काम कर सकता है, लेकिन यह प्रस्तावित विकल्पों में से किसी से भी अधिक अजीब होगा। -replace इस तरह से काम करता है क्योंकि यह सिर्फ तर्कों की एक वास्तविक सरणी को स्वीकार करता है। .Replace() का प्रबंधन PS टीम द्वारा नहीं किया जाता है -- यह .NET System.String वर्ग पर एक विधि है।

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

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

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

@ पॉवरशेल/पॉवरशेल-कमेटी ने इस पर विस्तार से चर्चा की, हम सभी सहमत नहीं हैं, लेकिन अधिकांश सहमत हैं कि इस ऑपरेटर के होने में मूल्य है और सी # सिंटैक्स के साथ संरेखित करने के लिए ?: अपेक्षा के अनुरूप है कि अधिकांश उपयोग होगा सी # डेवलपर्स से हो। यह सुविधा प्रायोगिक लंबित वास्तविक उपयोग प्रतिक्रिया होगी।

@ स्टीवएल-एमएसएफटी तो इसका मतलब है कि यह सुविधा 7.0 के लिए आगे बढ़ रही है? क्या यह उन चरों पर संगतता को तोड़ देगा जो उनके प्रतीक में ? का उपयोग करने में सक्षम हैं?

@ TheIncorrigible1 हाँ, यह सुविधा PS7 में आगे बढ़ रही है। यह ? उपनाम के उपयोग के साथ संगतता को नहीं तोड़ना चाहिए। Where-Object और ternary अंतर करने की कोशिश कर रही स्क्रिप्ट पर नज़र डालने पर ? की दृश्य तीक्ष्णता के बारे में एक चिंता है, लेकिन हम देखेंगे कि इस पर उपयोगकर्ता प्रतिक्रिया क्या है। सामान्य तौर पर, हम अधिकांश उपयोगकर्ताओं से इस ऑपरेटर का उपयोग करने की अपेक्षा नहीं करते हैं, लेकिन इससे इसे आगे बढ़ने से नहीं रोकना चाहिए।

@ स्टीवएल-एमएसएफटी मेरा मतलब है $isValid? या इसी तरह के नाम वाले चर। ये PS के वर्तमान पुनरावृत्ति में मान्य टोकन हैं।

@ TheIncorrigible1 :

पहले ऑपरेंड और ? बीच व्हाइटस्पेस की आवश्यकता उस समस्या को हल करती है, जैसा कि पहले सुझाव दिया गया था, और मेरे लिए यह एक बिल्कुल उचित समाधान है:

• : _also_ को इसके चारों ओर व्हाइटस्पेस की आवश्यकता होती है, क्योंकि $true ? $number:42 जैसी कोई चीज़ काम नहीं करेगी, यह देखते हुए कि $number:42 _as एक पूरे_ को एकल चर संदर्भ के रूप में व्याख्यायित किया जाएगा।

• जबकि सी# _does_ true?number:42 अनुमति देता है, मुझे नहीं लगता कि हमें उस स्तर पर संगतता के बारे में चिंता करने की ज़रूरत है - या, वास्तव में, चिंता कर सकते हैं। मैं व्यक्तिगत रूप से संक्षिप्तता को महत्व देता हूं, लेकिन पठनीयता की कीमत पर नहीं; भले ही मैं $true?$number:42 _लिखूं, मैं नहीं लिखूंगा।

(पिछड़े संगतता वास्तव में एक समस्या होगी जब (संकेत, संकेत) हम नल-सशर्त पहुंच को लागू करते हैं। पहचानकर्ता नामों के संबंध में पावरशेल की अनुमति आमतौर पर समस्याग्रस्त है, जैसा कि वह जहाज रवाना हो गया है )

हाँ, मुझे लगता है कि व्हाइटस्पेस आवश्यकता छोड़ना समझदार है। आखिरकार, यह काफी संक्षिप्त है। मैं

प्रोटोटाइप ने टर्नरी ऑपरेटर (जहां हम जानते हैं कि हम एक अभिव्यक्ति की उम्मीद कर रहे हैं) के संदर्भ में ? और : साथ संख्याओं को पार्स करने के लिए बहुत कठिन प्रयास किया। तो आप ${isWindows}?12:47 जैसी चीजें लिख सकते हैं।
123? या 1:23 जैसी संख्याओं को आज एक सामान्य टोकन के रूप में चिह्नित किया गया है, जो उस मामले में बिल्कुल भी उपयोगी नहीं है जहां हम जानते हैं कि हम एक अभिव्यक्ति की उम्मीद कर रहे हैं।

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

अच्छा बिंदु, @ डैक्सियन-डीबीडब्ल्यू; मैं भूल गया था कि {...} का उपयोग किसी भी चर-नाम सीमा अस्पष्टता को हल करने के लिए किया जा सकता है, इसलिए मुझे लगता है कि कोड गोल्फर ${isWindows}?${number}:47 जैसे कुछ का उपयोग कर सकते हैं

क्या हम इसे अभी बंद कर सकते हैं?

#10367 . के माध्यम से बंद करें