🅿️ 👩🏻‍✈️ 🌾 PHP में सज्जाकार। विस्तार कार्यान्वयन 👨🏾‍✈️ 🌚 🧔🏾

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

आवश्यक शर्तें

यदि आप tl; dr पढ़ने में रुचि नहीं रखते हैं, तो आप तुरंत कार्यान्वयन पर जा सकते हैं।

मैं दूर से शुरू करूँगा

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

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

@decomaker(argA, argB, ...) def func(arg1, arg2, ...): # ... # : func = decomaker(argA, argB, ...)(func)

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

# आंशिक रूप से पदावनत है, इसलिए इसका उपयोग सामान्य //, / * और / ** से अधिक ध्यान देने योग्य होगा;
एक एकल-पंक्ति टिप्पणी गिरती नहीं है और दृष्टि खोना कठिन है;
अचानक, php 5.x में, डेकोरेटर दिखाई देंगे और अजीब सिंटैक्स वाले इस एक्सटेंशन की आवश्यकता गायब हो जाएगी।

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

कुछ php कोड

 <?php function decor($func) { echo "Decorator!\n"; return function () use($func) { return call_user_func_array($func, func_get_args()); }; } function a($v) { var_dump($v); } $b = decor('a'); $b(42); /* : Decorator! int(42) */

PHP में, एक अप्रत्यक्ष फ़ंक्शन कॉल जो इसे पास करने के मापदंडों के साथ है, निश्चित रूप से, क्रिया है, इसे दूर नहीं किया जा सकता है।

परिणाम लेख की शुरुआत में छवि से वाक्य रचना है:

 <?php function decor($func) { return function(){} } # @decor function original() { // ... }

और मैं इसे Zend के lexer को फिर से लिखने के बिना प्राप्त करना चाहता हूं ताकि आपको PHP को फिर से बनाना न पड़े (यह ~~काम करता है - इसे स्पर्श न करें~~ )।

कार्यान्वयन

योजना को पूरा करने के लिए, दो विकल्प हैं:

PHP कोडर में जाने से पहले स्रोत कोड बदलें;
तैयार किए गए ओपकोड को बदलें, लेकिन फिर सिंटैक्स को मौजूदा के साथ संगत होना चाहिए।

दूसरा विकल्प ओपेक कैश और ऑप्टिमाइज़र के सभी प्रकार के साथ संगतता के बारे में संदिग्ध लग रहा था। और डेकोरेटर सिंटैक्स (# टिप्पणी के बिना) का मूल संस्करण इस मामले में काम नहीं करेगा।
पहला विकल्प चुना गया था।
Zend के स्रोत कोड राजस्व के दो स्रोत हैं:

कोड के साथ बस एक लाइन (eval का एनालॉग): zend_eval_string [l] [_ ex] , जो अंततः zend_compile_string को कॉल करने के लिए उबलता है ;
विभिन्न स्रोतों से प्राप्त एक फ़ाइल (स्टडिन, स्ट्रीम, आदि। सभी विकल्प zend_stream_type गणन में सूचीबद्ध हैं)। इस मामले में, हम zend_compile_file में रुचि रखते हैं।

दोनों मामलों में, हमारे पास एक विशिष्ट कार्यान्वयन के साथ कार्य करने के लिए संकेत हैं। मानक कार्यान्वयन zend_startup में शुरुआती बिंदुओं को देखकर पाया जा सकता है:

zend_compile_file को compile_file में लागू किया गया है;
zend_compile_string - समान रूप से स्पष्ट संकलन_string में।

दोनों फ़ंक्शन एक या दूसरे रूप में स्रोत कोड को स्वीकार करते हैं और _zend_op_array संरचना के रूप में ओपकोड की एक सरणी जारी करते हैं। दुर्भाग्य से, प्रदर्शन किए गए कार्यों की समानता के बावजूद, उनका कार्यान्वयन अलग है। इसलिए हम दोनों को प्रभावित करेंगे।

Zend और PHP एक्सटेंशन में ऐसे फंक्शन पॉइंटर्स पर प्रभाव स्ट्रीम पर डाला जाता है। उदाहरण के लिए, ZendAccelerator और Phar में समान zend_compile_file प्रतिस्थापित किया जाता है । यह तृतीय-पक्ष एक्सटेंशन की गणना नहीं कर रहा है।

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

आपको निम्न जैसा कुछ मिलता है

 PHP_MINIT_FUNCTION(decorators); PHP_MSHUTDOWN_FUNCTION(decorators); zend_module_entry decorators_module_entry = { // ... decorators_functions, PHP_MINIT(decorators), PHP_MSHUTDOWN(decorators), // ... }; zend_op_array *(*decorators_orig_zend_compile_string)(zval *source_string, char *filename TSRMLS_DC); zend_op_array *(*decorators_orig_zend_compile_file)(zend_file_handle *file_handle, int type TSRMLS_DC); zend_op_array* decorators_zend_compile_string(zval *source_string, char *filename TSRMLS_DC); zend_op_array* decorators_zend_compile_file(zend_file_handle *file_handle, int type TSRMLS_DC); /* {{{ PHP_MINIT_FUNCTION */ PHP_MINIT_FUNCTION(decorators) { decorators_orig_zend_compile_string = zend_compile_string; zend_compile_string = decorators_zend_compile_string; decorators_orig_zend_compile_file = zend_compile_file; zend_compile_file = decorators_zend_compile_file; return SUCCESS; } /* }}} */ /* {{{ PHP_MSHUTDOWN_FUNCTION */ PHP_MSHUTDOWN_FUNCTION(decorators) { zend_compile_string = decorators_orig_zend_compile_string; zend_compile_file = decorators_orig_zend_compile_file; return SUCCESS; } /* }}} */ zend_op_array* decorators_zend_compile_string(zval *source_string, char *filename TSRMLS_DC) /* {{{ */ { return decorators_orig_zend_compile_string(source_string, filename TSRMLS_CC); } /* }}} */ zend_op_array* decorators_zend_compile_file(zend_file_handle *file_handle, int type TSRMLS_DC) /* {{{ */ { return decorators_orig_zend_compile_file(file_handle, type TSRMLS_CC); } /* }}} */

जब मॉड्यूल (हमारे विस्तार) को प्रारंभ किया गया था, तो पॉइंटर्स को बदल दिया गया था, और काम पूरा होने पर, वे सब कुछ वापस करना नहीं भूले। सीधे बदले हुए कार्यों में, हम मूल कार्यान्वयन कहते हैं।
मॉड्यूल आरंभीकरण के दौरान सब कुछ नहीं किया जा सकता है, लेकिन हमारे मामले में यह काफी पर्याप्त है।

और यदि कंपाइल_स्ट्रिंग (इनपुट लाइन में इनपुट के लिए) के साथ सब कुछ कम या ज्यादा स्पष्ट है, तो कंपाइल_फाइल के साथ सब कुछ इतना रसात्मक नहीं है - हमारे पास स्रोत नहीं है, केवल zend_file_handle में स्रोत का विवरण है। इसके अलावा, विभिन्न मामलों में, खेतों के विभिन्न सेटों का उपयोग किया जाता है।

स्रोत का प्रत्यक्ष पढ़ना काफी दूर दफन है

 ZEND_API zend_op_array *compile_file(zend_file_handle *file_handle, int type TSRMLS_DC) { // ... open_file_for_scanning(file_handle TSRMLS_CC) // ... } ZEND_API int open_file_for_scanning(zend_file_handle *file_handle TSRMLS_DC) { // ... zend_stream_fixup(file_handle, &buf, &size TSRMLS_CC) // ... }

और यहां हमारे लिए सबसे दिलचस्प बात zend_stream_fixup है , एक फ़ंक्शन जो स्रोत कोड के इनपुट के सभी स्रोतों को एकजुट करता है और आउटपुट पर एक रीड बफर और इसके आकार को आउटपुट करता है। ऐसा लगता है कि हमें क्या चाहिए, लेकिन हम zend_stream_fixup और open_file_for_scanning के संचालन को प्रभावित नहीं कर सकते, हमारे पास केवल compile_file पर नियंत्रण है। कोई व्यक्ति इन कार्यों और अपने सभी आश्रितों को खुद की नकल करने के लिए गया था, लेकिन हम इसे आसान बना देंगे। यदि आप zend_stream_fixup के स्रोत कोड को देखते हैं, तो आप देख सकते हैं कि सभी प्रकार अंततः एक ही ZEND_HANDLE_MAPPED हैं, जिसमें फ़ाइल_हैंडल-> हैंडल। । इसके अलावा, यदि यह डेटा प्रकार पहले से ही file_handle में निर्दिष्ट है, तो व्यावहारिक रूप से कुछ भी बदलने की जरूरत नहीं है और सब कुछ जैसा है वैसा ही लौटा दिया जाता है।
यह पता चला है कि यदि हम पहले से ही सभी क्षेत्रों के लिए सही मान के साथ ZEND_HANDLE_MAPPED स्वरूप में पहले से ही कंपाइल_फाइल () zend_file_handle * file_handle पास करते हैं, तो compile_file इसे स्वीकार कर लेगा जैसा कि यह था। और हम ऐसा कर सकते हैं zend_stream_fixup (जो कि एक Zend API फ़ंक्शन है, न कि एक बदली जाने वाला सूचक) कॉल करके compile_file से पहले एक बार। फिर open_file_for_scanning के अंदर फिर से कॉल करने से कुछ भी नहीं बदलेगा।

कोशिश

 zend_op_array* decorators_zend_compile_file(zend_file_handle *file_handle, int type TSRMLS_DC) /* {{{ */ { char *buf; size_t size; if (zend_stream_fixup(file_handle, &buf, &size TSRMLS_CC) == FAILURE) { return NULL; } //   file_handle    ZEND_HANDLE_MAPPED return decorators_orig_zend_compile_file(file_handle, type TSRMLS_CC); } /* }}} */

हुर्रे, यह काम करता है। इसके अलावा, file_handle-> handle.stream.mmap.buf / len में हमारे पास स्रोत होता है, जहाँ भी PHP मिलेगी: stdin, fd, http स्ट्रीम शामिल करें ... यह कोड के हमारे संशोधित संस्करण को वहां रखना और मूल zend_compile_file को कॉल करना है।

मैं यह नहीं लिखूंगा कि डेकोरेटर्स_परप्रोसेसर () कैसे काम करता है: एक स्ट्रिंग की स्पष्ट रसीद, प्रीप्रोसेसर को इसका ट्रांसमिशन, और परिणामस्वरूप स्ट्रिंग की वापसी। नीचे और इसलिए इस फ़ंक्शन से कोड के टुकड़े होंगे।

यह प्रीप्रोसेसर पर विचार करने के लिए ही रहता है।

किसी एकल फ़ंक्शन में असमान स्रोत डेटा पास करना

 void preprocessor(zval *source_zv, zval *return_value TSRMLS_DC) { //    source_zv    return_value } /* {{{ DECORS_CALL_PREPROCESS */ #define DECORS_CALL_PREPROCESS(result_zv, buf, len) \ do { \ zval *source_zv; \ ALLOC_INIT_ZVAL(result_zv); \ ALLOC_INIT_ZVAL(source_zv); \ ZVAL_STRINGL(source_zv, (buf), (len), 1); \ preprocessor(source_zv, result_zv TSRMLS_CC); \ zval_dtor(source_zv); \ FREE_ZVAL(source_zv); \ } while (0); \ /* }}} */ /* {{{ proto string decorators_preprocessor(string $code) */ PHP_FUNCTION(decorators_preprocessor) { char *source; int source_len; zval *result; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &source, &source_len) == FAILURE) { return; } DECORS_CALL_PREPROCESS(result, source, source_len); // ... } /* }}} */ zend_op_array* decorators_zend_compile_string(zval *source_string, char *filename TSRMLS_DC) /* {{{ */ { zval *result; DECORS_CALL_PREPROCESS(result, Z_STRVAL_P(source_string), Z_STRLEN_P(source_string)); // ... } /* }}} */ zend_op_array* decorators_zend_compile_file(zend_file_handle *file_handle, int type TSRMLS_DC) /* {{{ */ { // ... zval *result; DECORS_CALL_PREPROCESS(result, file_handle->handle.stream.mmap.buf, file_handle->handle.stream.mmap.len); // ... } /* }}} */

ढूँढें और फिर से करें!

प्रीप्रोसेसर का कार्य डेकोरेटर्स के विवरणों को खोजना और उन कार्यों के कोड को संशोधित करना है जो डेकोरेटर प्रभावित करते हैं। और इसके लिए, स्रोत पाठ के टोकन के साथ काम करना सबसे अच्छा है। पहिया को सुदृढ़ नहीं करने के लिए, देशी ज़ेंड के lex_scan लेक्सिकल स्कैनर का उपयोग किया गया था, जिसका एक उदाहरण token_get_all के कार्यान्वयन में अपने स्वयं के उद्देश्यों के लिए इस्तेमाल किया जा सकता है और टोकन , token_get_all के अंदर बुलाया जा सकता है।

हम उस स्कैनर के वर्तमान वातावरण को बचाते हैं जिसमें हमारा कोड काम करता है:
zend_lex_state original_lex_state;
zend_save_lexical_state (और original_lex_state TSRMLS_CC);
पार्सिंग के लिए सोर्स लाइन तैयार करें:
zend_prepare_string_for_scanning (और source_z, "" TSRMLS_CC)
हमने लेक्सर की प्रारंभिक स्थिति निर्धारित की है (सभी विकल्प यहां हैं ):
LANG_SCNG (yy_state) = yycST_IN_SCRIPTING;

Token_get_all के विपरीत, हम पहले से ही PHP कोड को पार्स करते हैं, इसलिए हमारे लिए एक ओपनिंग टैग की उपस्थिति आवश्यक नहीं है। तदनुसार, प्रारंभिक अवस्था yycinitial नहीं है, लेकिन yycST_IN_SCRIPTING है।
लूप में हमें स्रोत स्ट्रिंग के सभी टोकन मिलते हैं:
zval token_zv;
int token_type;
जबकि (token_type = lex_scan (& token_zv TSRMLS_CC)) {
// ...
}

token_type - टोकन प्रकार:
- <256 - एक चरित्र वाले टोकन का चरित्र कोड;
- > = 256 स्थिर T_ * का मान है। Token_type का एक स्ट्रिंग विवरण PHP_FUNCTION (token_name) / get_token_type_name के माध्यम से प्राप्त किया जा सकता है।
token_zv में टोकन का अर्थ समाहित है। हालांकि, एक विकल्प के रूप में, आप zend_lex_state संरचना के yy_text और yy_leng फ़ील्ड का उपयोग कर सकते हैं जो वर्तमान टोकन के पहले बाइट का पता और इसकी लंबाई क्रमशः संग्रहीत करते हैं। इन क्षेत्रों तक पहुंच, जैसे Zend में, इसी मैक्रोज़ के माध्यम से कार्यान्वित की जाती है:
#define zendtext LANG_SCNG (yy_text)
# डेफ़िन ज़ेंगलेंग LANG_SCNG (yy_leng)

अब हम चार * zendtext और अहस्ताक्षरित int zendleng का उपयोग करते हैं।

मेमोरी लीक से बचने के लिए, आपको यह विचार करने की आवश्यकता है कि टोकन का मूल्य कभी-कभी लिया जाता है जैसा कि मूल बफर से लिया जाता है, और कभी-कभी इसके लिए मेमोरी आवंटित की जाती है। जिसे मुक्त करने की आवश्यकता है। रुचि रखने वाले लोग lex_scan () कोड को देख सकते हैं, और अब token_get_all से तर्क का आवश्यक टुकड़ा ले सकते हैं।
हम उस स्कैनर के वातावरण को पुनर्स्थापित करते हैं जिसमें हमारा कोड काम करता है:
zend_restore_lexical_state (और original_lex_state TSRMLS_CC);

यह सब है, हमारे पास स्रोत कोड का एक शाब्दिक विश्लेषण है। लेकिन मैं कुछ और पार्सिंग मुद्दों पर प्रकाश डालना चाहूंगा।

यदि PHP पार्सिंग त्रुटियां हैं, तो हैंडलर एक त्रुटि या अपवाद उत्पन्न करता है, जिसके पाठ में फ़ाइल का नाम और लाइन नंबर _zend_compiler_globals स्थिति से लिया जाता है। फ़ाइल का नाम, उदाहरण के लिए, संकलित_फिलनेम फ़ील्ड से लिया गया है। जिसे zend_prepare_string_for_scanning () कहा जाता है। और इसका उपयोग zend_error के अंदर किया जाता है (E_ * त्रुटियों के सभी प्रकार उत्पन्न करने के लिए उपयोग किया जाता है; यह E_PARSE उत्पन्न करने के लिए इस एक्सटेंशन में भी उपयोग किया जाता है)। लेकिन zend_error () में संकलित_filename का उपयोग केवल तभी किया जाता है जब Zend एक संकलन स्थिति में हो (zend_bool in_compilation; सभी एक ही _zend_compiler_globals में)। यदि हम स्रोत को पार्स करते हैं तो स्वयं सक्रिय नहीं होता है।
तो पार्स करने से पहले, हम "संकलन" पर जाते हैं:

zend_bool original_in_compilation = CG (in_compilation);
CG (in_compilation) = 1;

और अंत में हम सब कुछ वापस कर देते हैं:

CG (in_compilation) = original_in_compilation;

अब, यदि हम zend_prepare_string_for_scanning के लिए सही फ़ाइलनाम पास करते हैं, तो संभावित त्रुटियां बहुत अधिक जानकारीपूर्ण होंगी। आप वर्तमान फ़ाइल नाम को zend_get_compiled_filename () के माध्यम से प्राप्त कर सकते हैं, जो, हालांकि, NULL को वापस कर सकता है, जिसमें से php (यदि NULL को zend_prepare_string_for_scanning को segfault में गिर जाएगा)।

यह डेकोरेटर_परप्रोसेसर और डेकोरेटर्स_ज़ेंड_कम्पाइल_फाइल में सही फ़ाइल नाम सेट करने के लिए रहता है

 PHP_FUNCTION(decorators_preprocessor) { // ... char *prev_filename = zend_get_compiled_filename(TSRMLS_CC) ? zend_get_compiled_filename(TSRMLS_CC) : ""; zend_set_compiled_filename("-" TSRMLS_CC); DECORS_CALL_PREPROCESS(result, source, source_len); zend_set_compiled_filename(prev_filename TSRMLS_CC); // ... } zend_op_array* decorators_zend_compile_file(zend_file_handle *file_handle, int type TSRMLS_DC) /* {{{ */ { // ... char *prev_filename = zend_get_compiled_filename(TSRMLS_CC) ? zend_get_compiled_filename(TSRMLS_CC) : ""; const char* filename = (file_handle->opened_path) ? file_handle->opened_path : file_handle->filename; zend_set_compiled_filename(filename TSRMLS_CC); zval *result; DECORS_CALL_PREPROCESS(result, file_handle->handle.stream.mmap.buf, file_handle->handle.stream.mmap.len); zend_set_compiled_filename(prev_filename TSRMLS_CC); // ... }

डेकोरेटर्स_ज़ेंड_कम्पाइल_स्ट्रिंग में, फ़ाइल नाम हमें पहले से ही ज्ञात है।

स्रोत कोड संशोधन

प्रीप्रोसेसिंग के लिए आवश्यक सभी चीज़ों को प्राप्त करने के बाद, यह इसका उत्पादन करने के लिए बना रहता है। परिणामी पाठ में चंक्स (टोकन) से बना पाठ का अनुवाद करने का कार्य सी में इतना सरल नहीं हो सकता है क्योंकि gluing के साथ सक्रिय कार्य है। हालाँकि, /PHP/ext/standard/php_smart_str.h में स्मार्ट लाइनों का कार्यान्वयन है जो हमारे लिए बहुत उपयोगी होगा।

कम

  smart_str str = {0}; smart_str str2 = {0}; smart_str_appendc(&str, '!'); smart_str_appendl(&str, "hello", 5); smart_str_append(&str, &str2); smart_str_append_long(&str, 42); //  .. //    size_t str.len     char* str.c //  : smart_str_free(&str);

पार्सिंग टोकन के चक्र में, टोकन (ज़ेंडटेक्स्ट, ज़ेंड्लेंग) के परिणामस्वरूप स्ट्रिंग को गोंद करें, जहां आपको अपने आप को बदलने / जोड़ने की आवश्यकता होती है। सीधे तौर पर डेकोरेटर, आईएमएचओ को बदलने के लिए एल्गोरिथ्म इतना दिलचस्प नहीं है। संभावित दिलचस्प बिंदु से, यह जांचना कि टाइप T_COMMENT का टोकन डेकोरेटर के विवरण के समान है: नियमितता की जाँच करना ^ ^ [[\ t] * @ '(एक साधारण लूप के साथ, बिना regexp के) और पता @ @ वापस आ गया है।

अंत में थोड़ा PHP

डेकोरेटर्स को संसाधित करते समय, सजाया गया फ़ंक्शन का स्रोत कोड थोड़ा बदल जाता है: फ़ंक्शन का शरीर एक अनाम फ़ंक्शन में लपेटा जाता है, जिसे पैरामीटर द्वारा निकटतम डेकोरेटर को पास किया जाता है। यानी कोड के लिए

 // comment @a(A) @b @c(C, D) /** * yet another comment */ function x(X) { Y }

प्रीप्रोसेसिंग के परिणामस्वरूप, निम्न कोड प्राप्त होगा:

 // comment /** * yet another comment */ function x(X) { return call_user_func_array(a(b(c(function(X) { Y }, C, D)), A), func_get_args());}

A, C, D, X से हमारा तात्पर्य है मनमाना कोड जो इस तरह से कॉपी किया जाता है।
निम्नलिखित परिणाम इस से आते हैं:

यदि सजाया जाने वाला फ़ंक्शन डिफ़ॉल्ट मान वाले मापदंडों के साथ घोषित किया जाता है, तो अनाम फ़ंक्शन में सब कुछ समान होगा:
फ़ंक्शन फू ($ a, $ b = 42, $ c = सरणी (100, 500))
{...
=>
फ़ंक्शन फू ($ a, $ b = 42, $ c = सरणी (100, 500))
{return call_user_func_array (... (फ़ंक्शन ($ a, $ b = 42, $ c = array (100, 500)) {...
यदि डेकोरेटर के नामों के विवरण में त्रुटियां हैं, तो त्रुटि का वर्णन करते समय कोड की लाइन शरीर को खोलने वाले फ़ंक्शन '{' के साथ होगी। इसी तरह डेकोरेटर मापदंडों के साथ - वे शरीर को बंद करने के कार्य '}' के साथ लाइन में होंगे;
डेकोरेटर के मापदंडों को सजाया जा रहा फ़ंक्शन के चर नामों पर सेट किया जा सकता है। यह मापदंडों पर नियंत्रण पढ़ता / लिखता है;
क्योंकि func_get_args () का उपयोग मापदंडों को पारित करने के लिए किया जाता है, फिर सजाया जाने वाले फ़ंक्शन के संदर्भ में एक पैरामीटर पास करना वर्तमान में काम नहीं करता है।

खैर, यह बात है। यदि आप वास्तव में यहाँ तक पढ़ते हैं, तो मुझे उम्मीद है कि यह दिलचस्प था।

मैं इस लेख में github का लिंक दूंगा।

PHP में सज्जाकार। विस्तार कार्यान्वयन

आवश्यक शर्तें

कार्यान्वयन

ढूँढें और फिर से करें!

स्रोत कोड संशोधन

अंत में थोड़ा PHP

More articles: