अपने अधिकांश व्यावसायिक जीवन के लिए, मैं प्रोटोकॉल बफ़र्स का उपयोग करने का विरोध करता हूं। वे शौकीनों द्वारा स्पष्ट रूप से लिखे गए हैं, अविश्वसनीय रूप से अत्यधिक विशिष्ट, कई नुकसान से पीड़ित हैं, एक समस्या को संकलित करना और हल करना मुश्किल है, जो कि वास्तव में Google के पास कोई नहीं है। यदि धारावाहिक निरस्तीकरण की संगरोध में प्रोटो-बफ़र्स की ये समस्याएं बनी रहीं, तो मेरे दावे वहीं समाप्त हो जाएंगे। लेकिन दुर्भाग्य से, प्रोटोबफर्स का खराब डिज़ाइन इतना घुसपैठ है कि ये समस्याएं आपके कोड में लीक हो सकती हैं।

शौकीनों द्वारा संकीर्ण विशेषज्ञता और विकास

बंद करो। अपने ईमेल क्लाइंट को बंद करें, जहां आपने पहले ही मुझे एक पत्र लिखा था जिसमें कहा गया था कि "दुनिया के सर्वश्रेष्ठ इंजीनियर Google पर काम करते हैं", कि "उनके डिजाइन, परिभाषा के अनुसार, शौकीनों द्वारा नहीं बनाए जा सकते हैं।" मैं यह नहीं सुनना चाहता।

आइए इस विषय पर चर्चा न करें। पूर्ण प्रकटीकरण: मैं Google में काम करता था। यह पहली (लेकिन दुर्भाग्य से अंतिम नहीं) जगह थी जिसे मैंने कभी प्रोटोबर्फर्स का इस्तेमाल किया था। Google कोडबेस में मौजूद सभी समस्याओं के बारे में मैं बात करना चाहता हूं; यह सिर्फ "प्रोटोबफ़र्स का दुरुपयोग" और पसंद नहीं है।

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

शौकीनों द्वारा संकीर्ण विशेषज्ञता और विकास हाथ से जाते हैं। अधिकांश विशिष्टताओं को अंतिम क्षण में बोल्ट किया गया था - और यह स्पष्ट रूप से अंतिम क्षण में बोल्ट किया गया था। कुछ प्रतिबंध आपको अपने सिर को खरोंचने और रोकने के लिए मजबूर करेंगे: "व्हाट द हेल?" लेकिन ये एक गहरी समस्या के लक्षण हैं:

जाहिर है, प्रोटोबफ़र्स शौकीनों द्वारा बनाए जाते हैं क्योंकि वे अच्छी तरह से ज्ञात और पहले से हल की गई समस्याओं के लिए खराब समाधान पेश करते हैं।

रचना का अभाव

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

oneof फ़ील्ड्स को repeated नहीं जा सकता।
फ़ील्ड map<k,v> में कुंजियों और मूल्यों के लिए एक विशेष सिंटैक्स है, लेकिन इसका उपयोग किसी अन्य प्रकार में नहीं किया जाता है।
हालाँकि map फ़ील्डों को परिमाणित किया जा सकता है, फिर भी किसी उपयोगकर्ता-परिभाषित प्रकार की अनुमति नहीं है। इसका मतलब है कि आप सामान्य डेटा संरचनाओं में अपनी विशेषज्ञता को मैन्युअल रूप से निर्दिष्ट करने के साथ फंस गए हैं।
map फ़ील्ड को repeated नहीं जा सकता।
map कीज़ string हो सकती हैं, लेकिन bytes नहीं । एनम को भी मना किया जाता है, हालांकि बाद वाले को प्रोटोबफर्स विनिर्देश के अन्य सभी भागों में पूर्णांक के बराबर माना जाता है।
map मान अन्य map नहीं हो सकता है।

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

map फ़ील्ड्स का प्रतिबंध, जिसे repeated नहीं जा सकता है, लगभग एक ही ओपेरा से है, लेकिन प्रकार प्रणाली का एक अलग प्रतिबंध दिखाता है। दृश्यों के पीछे, map<k,v> repeated Pair<k,v> समान कुछ में बदल जाता है। और चूंकि repeated भाषा का जादुई कीवर्ड होता है, न कि सामान्य प्रकार का, यह अपने आप से मेल नहीं खाता।

एनम के साथ समस्या के बारे में आपका अनुमान उतना ही सही है जितना मेरा।

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

समाधान इस प्रकार है:

required संदेश में सभी फ़ील्ड बनाएं। यह प्रत्येक संदेश को एक उत्पाद प्रकार बनाता है।
स्टैंड-अलोन डेटा प्रकारों के लिए oneof फ़ील्ड का मान बढ़ाएँ। यह एक कॉपीप्रोडक्ट प्रकार होगा।
उत्पादों और अन्य प्रकारों के सह-उत्पादों के पैरामीटर को सक्षम करने के लिए।

वह सब है! ये तीन परिवर्तन आप सभी को किसी भी संभावित डेटा को निर्धारित करने की आवश्यकता है। इस सरल प्रणाली के साथ, आप अन्य सभी प्रोटोबॉफ़र विनिर्देशों को फिर से कर सकते हैं।

उदाहरण के लिए, आप optional फ़ील्ड को फिर से कर सकते हैं:

 product Unit { // no fields } coproduct Optional<t> { t value = 0; Unit unset = 1; }

repeated फ़ील्ड बनाना भी सरल है:

 coproduct List<t> { Unit empty = 0; Pair<t, List<t>> cons = 1; }

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

दूब का चुनाव

जावा-शैली के प्रोटोबफर्स स्केलर और संदेश प्रकारों के बीच अंतर करते हैं। मशीन प्राइमेटरी में int32 कम या ज्यादा मेल खाते हैं - int32 , bool और string जैसी चीजें। संदेश प्रकार, दूसरी ओर, सभी शेष हैं। सभी पुस्तकालय और उपयोगकर्ता प्रकार संदेश हैं।

बेशक, दो प्रकार के प्रकार पूरी तरह से अलग शब्दार्थ हैं।

स्केलर प्रकार के साथ फ़ील्ड हमेशा मौजूद होते हैं। भले ही आपने उन्हें स्थापित नहीं किया हो। मैंने पहले ही कहा था कि (कम से कम प्रोटो ^{3 में)} ) सभी प्रोटो-बफ़र्स को शून्य के लिए आरंभीकृत किया जाता है, भले ही उनके पास कोई डेटा न हो? स्केलर फ़ील्ड को नकली मान मिलते हैं: उदाहरण के लिए, uint32 को 0 uint32 प्रारंभ किया जाता है, और string को "" लिए आरंभीकृत किया string है।

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

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

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

 private Foo m_foo; public Foo foo { // only if `foo` is used as an expression get { if (m_foo != null) return m_foo; else return new Foo(); } // instead if `foo` is used as an lvalue mutable get { if (m_foo = null) m_foo = new Foo(); return m_foo; } }

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

ऐसा व्यवहार विशेष रूप से अहंकारी है क्योंकि यह कानून का उल्लंघन करता है! हम नौकरी की उम्मीद करते हैं। msg.foo = msg.foo; काम नहीं करेगा। इसके बजाय, कार्यान्वयन वास्तव में शून्य-आरंभ के साथ foo की एक प्रति में msg को चुपचाप बदल देता है यदि यह पहले मौजूद नहीं था।

स्केलर फ़ील्ड के विपरीत, कम से कम आप यह निर्धारित कर सकते हैं कि संदेश फ़ील्ड सेट नहीं है। bool has_foo() लिए भाषा बाइंडिंग उत्पन्न bool has_foo() विधि की तरह कुछ प्रदान करते हैं। यदि यह मौजूद है, तो एक प्रोटोबफ़र से दूसरे में संदेश क्षेत्र की लगातार प्रतिलिपि बनाने के मामले में, आपको निम्नलिखित कोड लिखना होगा:

 if (src.has_foo(src)) { dst.set_foo(src.foo()); }

कृपया ध्यान दें कि, कम से कम स्थैतिक टाइपिंग वाली भाषाओं में, यह टेम्पलेट foo() , set_foo() और has_foo() बीच नाममात्र संबंध के कारण सार नहीं हो सकता है । चूँकि ये सभी कार्य अपने स्वयं के पहचानकर्ता हैं , इसलिए हमारे पास प्रोग्रेसिव मैक्रो के अपवाद के साथ प्रोग्रामेटिक रूप से उन्हें उत्पन्न करने का साधन नहीं है:

 #define COPY_IFF_SET(src, dst, field) \ if (src.has_##field(src)) { \ dst.set_##field(src.field()); \ }

(लेकिन प्रीप्रोसेसर मैक्रोज़ Google शैली गाइड द्वारा निषिद्ध हैं)।

यदि इसके बजाय सभी अतिरिक्त क्षेत्रों को Maybe रूप में लागू किया गया था, तो आप अमूर्त डायल साथियों को सुरक्षित रूप से सेट कर सकते हैं।

विषय को बदलने के लिए, आइए एक और संदिग्ध निर्णय के बारे में बात करते हैं। यद्यपि आप प्रोटॉफ़र में एक क्षेत्र को परिभाषित कर सकते हैं, उनके शब्दार्थ सह-उत्पाद के प्रकार से मेल नहीं खाते हैं ! नौसिखिया गलती दोस्तों! इसके बजाय, आपको oneof वालों में प्रत्येक oneof केस और मैजिक कोड के लिए एक वैकल्पिक फ़ील्ड मिलेगा, जो सेट होने पर किसी अन्य फ़ील्ड को पूर्ववत कर देगा।

पहली नज़र में, ऐसा लगता है कि यह शब्दार्थ संघ के सही प्रकार के बराबर होना चाहिए। लेकिन इसके बजाय, हमें त्रुटि का घृणित, अवर्णनीय स्रोत मिलता है! जब इस व्यवहार को एक अवैध कार्यान्वयन के साथ जोड़ दिया जाता है msg.foo = msg.foo; , ऐसा प्रतीत होता है कि सामान्य असाइनमेंट चुपचाप डेटा की मनमानी मात्रा को हटा देता है!

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

यह सुनना बहुत सुखद नहीं है, खासकर हममें से जो पैरामीट्रिक बहुरूपता से प्यार करते हैं, जो इसके ठीक विपरीत का वादा करता है ।

पिछड़े और भविष्य की अनुकूलता निहित है

प्रोटोबफर्स के अक्सर उल्लेखित "किलर फीचर्स" में से एक उनकी "पिछड़े और आगे की संगत संगत लिखने की परेशानी मुक्त क्षमता" है। सत्य को अस्पष्ट करने के लिए यह कथन आपकी आँखों के सामने लटका दिया गया था।

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

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

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

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

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

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

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

इसका सामना करते हैं। आप Google के पैमाने पर फिट नहीं होते हैं, और आप कभी भी फिट नहीं होंगे। प्रौद्योगिकी के कार्गो पंथ का उपयोग करना केवल इसलिए बंद कर दें क्योंकि "Google इसका उपयोग करता है," और क्योंकि "ये उद्योग सर्वोत्तम प्रथाएं हैं।"

प्रोटोबफर्स कोडबेस को प्रदूषित करते हैं

यदि प्रोटोबॉफ़र्स के उपयोग को केवल नेटवर्क तक सीमित करना संभव था, तो मैं इस तकनीक के बारे में इतनी कठोर बात नहीं करूंगा। दुर्भाग्य से, हालांकि सिद्धांत रूप में कई समाधान हैं, उनमें से कोई भी वास्तव में वास्तविक सॉफ़्टवेयर में उपयोग करने के लिए पर्याप्त नहीं है।

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

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

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

इसके बजाय, प्रोटोबफर्स का उपयोग करके कोड उन्हें पूरे कोड बेस में वितरित करने की अनुमति देता है। यह एक वास्तविकता है। Google पर मेरी मुख्य परियोजना एक संकलक थी जिसने प्रोटोबफ़र्स के एक भिन्न रूप में लिखा गया "प्रोग्राम" लिया और दूसरे के बराबर "प्रोग्राम" का उत्पादन किया। इनपुट और आउटपुट प्रारूप काफी भिन्न थे ताकि उनके C ++ के सही समानांतर संस्करणों ने कभी काम नहीं किया। नतीजतन, मेरा कोड किसी भी समृद्ध संकलक लेखन तकनीक का उपयोग नहीं कर सका, क्योंकि प्रोटोबफर्स डेटा (और उत्पन्न कोड) उनके साथ कुछ भी दिलचस्प करने के लिए बहुत कठिन थे।

परिणामस्वरूप, पुनरावृत्ति योजनाओं की 50 लाइनों के बजाय, विशेष बफर फेरबदल की 10,000 लाइनों का उपयोग किया गया था। जिस कोड को मैं लिखना चाहता था वह वास्तव में प्रोटो-बफ़र्स के साथ असंभव था।

हालांकि यह एक मामला है, यह अद्वितीय नहीं है। कोड पीढ़ी की कठोर प्रकृति के कारण, भाषाओं में प्रोटो-बफ़र्स की अभिव्यक्तियां कभी भी मुहावरेदार नहीं होंगी, और उन्हें तब तक नहीं बनाया जा सकता है - जब तक आप कोड जनरेटर को फिर से नहीं लिखते।

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

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

सामान्य तौर पर, जो कोई भी अपनी परियोजनाओं में प्रोटोबर्फर्स लागू करता है, उसे उम्मीद छोड़ दें।

1. आज तक, Google पर proto2 के बारे में गर्म चर्चा चल रही है और क्या कभी फ़ील्ड को required रूप से चिह्नित किया जाना चाहिए। मैनिफ़ेस्ट " optional हानिकारक माना जाता है" और " required माना जाता है हानिकारक" उसी समय वितरित किए जाते हैं। सौभाग्य यह लोग बाहर आंकड़ा। ↑

प्रदर्शनकारी गलत हैं

रचना का अभाव

दूब का चुनाव

पिछड़े और भविष्य की अनुकूलता निहित है

प्रोटोबफर्स कोडबेस को प्रदूषित करते हैं

More articles:

प्रदर्शनकारी गलत हैं

रचना का अभाव

दूब का चुनाव

पिछड़े और भविष्य की अनुकूलता निहित है

प्रोटोबफर्स ​​कोडबेस को प्रदूषित करते हैं

More articles:

प्रोटोबफर्स कोडबेस को प्रदूषित करते हैं