அக்டோபர் 2019 இல், பைதான் 3.8 வால்ரஸ் ஆபரேட்டரை அறிமுகப்படுத்தியது (:=) வழியாக பிஇபி 572 – இதன் மூலம் நிரலாக்க மொழி வரலாற்றில் மிகப்பெரிய சர்ச்சைகளில் ஒன்றைத் தூண்டியது. விவாதம் மிகவும் கசப்பானதாக இருந்ததால் பைதான் கண்டுபிடிப்பாளர் கைடோ வான் ரோசம் ஜூலை 2018 இல் - வெளியீட்டிற்கு முன்பே - BDFL ஆக அவரது பதவி (வாழ்நாள் முழுவதும் கருணையுள்ள சர்வாதிகாரி). 2019 ஆம் ஆண்டின் தொடக்கத்திலிருந்து, பைதான் தேர்ந்தெடுக்கப்பட்ட ஸ்டீயரிங் கவுன்சிலால் நிர்வகிக்கப்படுகிறது.
if (n := len(items)) > 10:
print(f"List is too long ({n} elements)")வால்ரஸ் விவாதத்தைத் தொடர்ந்து உடனடியாக நிர்வாகப் பிளவு ஏற்பட்டது - ஒற்றை மொழி அம்சம் கட்டமைப்பு விளைவுகளை ஏற்படுத்திய ஒரு அரிய நிகழ்வு. வான் ரோசம் தனது அறிக்கையில் விளக்கினார்: "இறுதி வைக்கோல் மிகவும் சர்ச்சைக்குரிய பைதான் மேம்பாட்டு முன்மொழிவு. நான் அதை ஏற்றுக்கொண்ட பிறகு, மக்கள் ட்விட்டர் போன்ற சமூக ஊடகங்களுக்குச் சென்று என்னை தனிப்பட்ட முறையில் புண்படுத்தும் விஷயங்களைச் சொன்னார்கள்."
அவர் தொடர்ந்தார்: "இப்போது PEP 572 முடிந்துவிட்டது, நான் மீண்டும் ஒரு PEP-க்காக இவ்வளவு கடுமையாகப் போராட வேண்டியிருக்கக் கூடாது, என் முடிவுகளை இவ்வளவு பேர் வெறுக்கிறார்கள் என்பதைக் காண வேண்டும். முடிவெடுக்கும் செயல்முறையிலிருந்து நான் என்னை முற்றிலுமாக விலக்கிக் கொள்ள விரும்புகிறேன்." இந்த விமர்சனம் பரந்த சமூகத்திடமிருந்து மட்டுமல்ல, முக்கிய டெவலப்பர்களிடமிருந்தும் வந்தது.
பைதான் ஜென்னின் அடிப்படை பைதான் கொள்கைகளுக்கு - குறிப்பாக சிக்கலான தன்மையை விட எளிமைக்கான விருப்பத்திற்கு - இந்த ஆபரேட்டர் முரண்படுவதாக அவர்கள் வாதிட்டனர். கிட்டத்தட்ட மூன்று தசாப்தங்களாக மறுக்க முடியாத மொழி வடிவமைப்பாளராக இருந்த பிறகு, இது ஒரு சகாப்தத்தின் முடிவைக் குறித்தது. ஆனால் பைதான் ஒரு புதிய வால்ரஸ் ஆபரேட்டரை அறிமுகப்படுத்த வேண்டியிருந்தது, இந்த செயல்பாட்டில் அதன் சமூகத்தைப் பிரித்தது, கேள்வி எழுகிறது: மற்ற மொழிகள் இதே போன்ற கருத்துக்களை எவ்வாறு கையாளுகின்றன?
பைதான் ஆபரேட்டர் := ("வால்ரஸ்" என்ற அசைன்மென்ட் எக்ஸ்பிரஷன்) PHP-யில் இல்லை - ஏனெனில் அது தேவையில்லை. PHP-யில், அசைன்மென்ட் ஆபரேட்டர் = எப்போதும் ஒரே நேரத்தில் கூற்றும் வெளிப்பாடும்: ஒரு ஒதுக்கீடு ஒதுக்கப்பட்ட மதிப்பைத் திருப்பித் தருகிறது. இதனால்தான் "ஒதுக்கீடு-மற்றும்-சோதனை" போன்ற மரபுசார் வடிவங்கள் வேலை செய்கின்றன if- அவற்றின் சொந்த மொழி அம்சம் இல்லாத நிலைமைகள்.
function get_some_field() {
return 'foo';
}
if ($a = get_some_field()) {
echo $a; // foo
}
// Hinweis: $a ist *gesetzt*, selbst wenn die Bedingung falsy wäre.$a = get_some_field() வலது பக்கத்திற்கு ஒதுக்கி மதிப்பீடு செய்கிறது. இது "உண்மையாக" இருந்தால், நீங்கள் உள்ளிடவும் if-தடுப்பு. பின்னணி: பைத்தானில், := (PEP 572) ஏனெனில் எளிய பணிகள் வெளிப்பாடுகள் அல்ல. PHP-யில், இது எப்போதும் வேறுபட்டது, எனவே அதற்கு சமமான தேவை இல்லை. இரண்டு விஷயங்கள் பெரும்பாலும் பிழைகளுக்கு வழிவகுக்கும்.: = (பணி) பெரும்பாலான தொடர்புடைய ஆபரேட்டர்களை விட குறைந்த முன்னுரிமையைக் கொண்டுள்ளது; அடைப்புக்குறிகள் மதிப்பீட்டைத் தீர்மானிக்கின்றன.
மிகவும் சிக்கலான வெளிப்பாடுகளில், வாசிப்புத்திறன் மற்றும் தெளிவை அதிகரிக்க நீங்கள் எப்போதும் அடைப்புக்குறிகளைப் பயன்படுத்த வேண்டும். ?? இது அதன் சொந்த, மாறாக குறைந்த முன்னுரிமையைக் கொண்டுள்ளது. இது போன்ற வெளிப்பாடுகளில் ஆச்சரியங்களை விளக்குகிறது $x ?? null === null. அடைப்புக்குறிகள் இல்லாமல், முதலில் null === null மதிப்பிடப்பட்டது. எப்போதும் வெளிப்படையாக அடைப்புக்குறியிடுவது நல்லது: ($x ?? null) === null. $a வெளியேயும் உள்ளது if-தொகுதிகள் - தவறான மதிப்புடன் இருக்கலாம்.
function get_some_field() {
return 'bar';
}
if ( ($a = get_some_field()) === 'bar' ) {
echo $a; // bar
}எனவே அது தெளிவாகிறது === 'bar' ஒதுக்கப்பட்ட மதிப்புக்குப் பயன்படுத்தப்படுகிறது. படிக்கும் தன்மை மற்றும் முன்னுரிமைக்கு அடைப்புக்குறிகள் இங்கே முக்கியம். நடைமுறையில், இந்த முறை வினவல் முடிவைச் சேமித்து பின்னர் அதைச் சரிபார்ப்பதன் மூலம் தேவையற்ற நகல் அழைப்புகளை (எ.கா., வினவல் உருவாக்குநரின்) தவிர்க்கிறது. லாராவெல் அடிப்படையிலான திட்டங்கள் போன்ற உற்பத்தி பயன்பாடுகளில், பின்வரும் வடிவத்தை அடிக்கடி காணலாம்.:
if ( ($foo = Foo::where('foo', 'bar')) && $foo->count() > 0 ) {
dd($foo->get());
}&& ஷார்ட்-சர்க்யூட்டிங்: இடது பகுதி உண்மையாக இருந்தால் மட்டுமே வலது பகுதி மதிப்பீடு செய்யப்படும். அறிக்கையை மேல்நோக்கி ஒதுக்குவதன் மூலம், if அறிக்கைக்கு வெளியே அறிக்கையை ஒதுக்குவதைத் தவிர்க்கிறீர்கள். இது நல்ல நடைமுறையா என்பது உங்கள் குழுவின் குறியீடு மற்றும் பகுப்பாய்வு கருவிகளைப் பொறுத்தது; சொற்பொருளியல் ரீதியாக, அது சரியானது. குறைந்தபட்சம், நீங்கள் அதை காட்டுப்பகுதியில் சந்தித்தால் குறியீடு என்ன செய்கிறது என்பதை நீங்கள் அறிந்திருக்க வேண்டும்.
PHPக்கு "வால்ரஸ் ஆபரேட்டர்" தேவையில்லை, ஏனெனில் பணிகள் ஏற்கனவே வெளிப்பாடுகளாகும். இது "ஒதுக்கீடு-மற்றும்-சோதனை" போன்ற மொழியியல் வடிவங்களை சாத்தியமாக்குகிறது - செயல்திறன் மற்றும் சுருக்கமானது. அதே நேரத்தில், ஒழுக்கத்தின் மீதான கோரிக்கைகள் அதிகரிக்கின்றன: அடைப்புக்குறிகள், கடுமையான ஒப்பீடுகள், உண்மை/தவறு பற்றிய விழிப்புணர்வு மற்றும் தெளிவான குழு மரபுகள் கட்டாயமாகும். இந்த வழிகாட்டுதல்களைப் பின்பற்றுபவர்கள் கூடுதல் மொழி அம்சம் தேவையில்லாமல் வால்ரஸ் யோசனையின் பலன்களைப் பெறுகிறார்கள்.