प्रोटोटाइप-आधारित OOP के बजाय कई बतख-टाइप की गई गतिशील प्रोग्रामिंग भाषाएं क्लास-आधारित दृष्टिकोण का उपयोग क्यों करेंगी?

Question

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

प्रश्न 1) गतिशील भाषा में कक्षा की क्या आवश्यकता है? भाषा को किसी तरह से "टेम्पलेट" के रूप में वर्ग का उपयोग करने के लिए इस तरह से डिज़ाइन किया गया है कि इसके बजाय प्रोटोटाइप-तरीका और बस एक वस्तु का उपयोग कैसे करें?

साथ ही जावास्क्रिप्ट प्रोटोटाइप-आधारित है, लेकिन कॉफीस्क्रिप्ट (जावास्क्रिप्ट का उन्नत संस्करण) वर्ग-आधारित तरीका चुनता है। और यह लुआ (प्रोटोटाइप-आधारित) और मूनस्क्रिप्ट (वर्ग-आधारित) के लिए समान है। इसके अलावा, वहाँ ईएस 6 में वर्ग है। तो…

प्रश्न 2) क्या यह सुझाव है कि यदि आप एक प्रोटोटाइप-आधारित भाषा को बेहतर बनाने की कोशिश करते हैं, तो अन्य चीजों के अलावा, आपको इसे कक्षा-आधारित में बदलना चाहिए? यदि नहीं, तो इसे इस तरह से क्यों बनाया गया है?

Comments

कई प्रोग्रामर कुछ नया सीखने से परेशान नहीं होना चाहते हैं। (यह बहुत विदेशी है और "मुश्किल")। इसलिए उन सभी वर्ग-आधारित पुस्तकालयों और भाषाओं को जो उन्हें संकलित करते हैं।

— थॉमस एडिंग

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

— लोनी बेस्ट

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

— आमोन

सबसे पहली बात: जावास्क्रिप्ट स्वयं ही classअगले ECMAScript मानक (ECMAScript 6) के रूप में कीवर्ड का समर्थन करता है । जावास्क्रिप्ट में कक्षाओं के लिए समर्थन की योजना लंबे समय से बनाई गई है। अब यह क्या है - कक्षाएं केवल वाक्यविन्यास चीनी हैं, एक ही प्रकार की वस्तुओं के लिए मॉडल के बारे में तर्क करना आसान है। जेएस में यह तरीका है और यह पायथन और अन्य गतिशील भाषाओं में इस तरह से है।

— बेंजामिन ग्रुएनबाम

@BenjaminGruenbaum "... कक्षाएं केवल वाक्यविन्यास चीनी हैं ..." वाह, यह थोड़े उपन्यास विचार है मेरे लिए, वास्तव में, रूबी और अजगर जैसी भाषाओं के लिए, ऐसा लगता है कि यह कोई फर्क नहीं पड़ता कि किसी वस्तु का उपयोग करना है या नहीं टेम्पलेट के रूप में वर्ग - दोनों को वैसे भी मक्खी पर संशोधित किया जा सकता है। और यह वास्तव में कोई फर्क नहीं पड़ता कि वे न तो विरासत को कैसे संभालते हैं। इसलिए, शायद किसी गतिशील भाषा के लिए वर्ग-आधारित दृष्टिकोण और प्रोटोटाइप-आधारित दृष्टिकोण के बीच अंतर करने की कोई आवश्यकता नहीं है :)

— 5

Answer 1

प्रश्न 1) गतिशील भाषा में कक्षा की क्या आवश्यकता है? भाषा को किसी तरह से "टेम्पलेट" के रूप में वर्ग का उपयोग करने के लिए इस तरह से डिज़ाइन किया गया है कि इसके बजाय प्रोटोटाइप-तरीका और बस एक वस्तु का उपयोग करें?

बहुत पहले OO भाषा (भले ही इसे "OO" नहीं कहा जाता था), Simula, वंशानुक्रम नहीं था। सिमुल्या -67 में वंशानुक्रम जोड़ा गया था, और यह कक्षाओं पर आधारित था।

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

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

स्मॉलटॉक -74 के बाद, एलन के ने महसूस किया कि स्मॉलटाक गलत दिशा में आगे बढ़ रहा था और वास्तव में यह प्रतिनिधित्व नहीं करता था कि ओओ क्या है, और उन्होंने प्रस्ताव रखा कि टीम स्मालटाक को छोड़ दे और नए सिरे से शुरुआत करे, लेकिन वह आउटवोट हो गया। इस प्रकार Smalltalk-76, Smalltalk-80 (शोधकर्ताओं के लिए जारी किया जाने वाला Smalltalk का पहला संस्करण), और अंत में Smalltalk-80 V2.0 (व्यावसायिक रूप से जारी होने वाला पहला संस्करण, और वह संस्करण जो ANS स्मॉलटॉक का आधार बन गया) ।

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

दिलचस्प रूप से पर्याप्त, एलन के की वर्तमान भाषा प्रोटोटाइप प्रतिनिधिमंडल पर आधारित है।

Comments

"... एलन के की वर्तमान भाषा ..." जो है ...?

— जेवियर

@ जेवियर: मुझे नहीं लगता कि इसका कोई नाम है, और सिस्टम का नाम बदलता रहता है।

— जोर्ग डब्ल्यू मित्तग

यह अगली बार इंगित करने के लिए एक अच्छा जवाब होना चाहिए कि कोई व्यक्ति OO के लिए आवश्यकता के रूप में विरासत की सूची देता है :)

— अरे

@iceX: एलन के ने अपने विचारों पर काम करने के लिए दृष्टिकोण अनुसंधान संस्थान की स्थापना की । दुर्भाग्य से, जानकारी वास्तव में वेबसाइट पर बिखरी हुई है।

— जोर्ग डब्ल्यू मित्तग

एलन Kay ने OO पर उद्धरण दिया: "मेरे लिए OOP का मतलब केवल मैसेजिंग, स्थानीय अवधारण और संरक्षण और राज्य-प्रक्रिया का छिपाना, और सभी चीजों का चरम देर से बंधन है। यह स्मॉलटाक और LISP में किया जा सकता है। संभवतः अन्य सिस्टम भी हैं। यह संभव है, लेकिन मुझे उनके बारे में जानकारी नहीं है। ”

— जोएरी सेब्रेट्स

Answer 2

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

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

एक अन्य कारण यह भी है कि वर्ग-आधारित भाषाएं पसंद की जाती हैं: उन्हें कुशल कोड के लिए संकलित करना अधिक आसान है। सबसे प्रभावी जावास्क्रिप्ट वीएम अपने तरीकों और प्रोटोटाइप में बदलाव के रूप में जावास्क्रिप्ट वस्तुओं के प्रकार का प्रतिनिधित्व करने के लिए प्रभावी रूप से गतिशील रूप से कक्षाएं बनाते हैं। यह क्यों किया जाता है पर एक तर्क के लिए वी 8 के कार्यान्वयन का यह विवरण देखें ।

Comments

आपका अंतिम पैराग्राफ वास्तव में आप जो कह रहे हैं उसके ठीक विपरीत का समर्थन करता है: V8 यह साबित करता है कि कुशल कक्षा-आधारित कोड को संकलित करने के लिए आपको भाषा में कक्षाओं की आवश्यकता नहीं है।

— जॉर्ग डब्ल्यू मित्तग

हां, आपको उनकी आवश्यकता नहीं है - लेकिन तथ्य यह है कि V8 (और संभवत: स्व, हालांकि मैंने उस प्रणाली के डिजाइन के बारे में उतना नहीं पढ़ा है) प्रभावी रूप से आभासी कक्षाएं बनाता है इसका मतलब है कि मूल रूप से कक्षाओं का उपयोग करने वाली भाषा से शुरू करना निश्चित रूप से आसान है, और इसलिए शायद कोड को संकलित करने में कम समय बिताने के लिए जेआईटी की आवश्यकता होगी।

— जूल्स

निश्चित रूप से, और यह तथ्य कि वी 8 प्रभावी रूप से GOTOएस और रजिस्टर बनाता है, का अर्थ है कि सभी सार और विधानसभा में सीधे लिखना लगभग निश्चित रूप से आसान है, और इसलिए शायद कोड को कम समय बिताने के लिए जेआईटी के साथ समाप्त होने की आवश्यकता होगी। उच्च-स्तरीय अमूर्तताओं का समर्थन करना एक संकलक का काम है।

— जोर्ग डब्ल्यू मित्तग

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

— जूल्स

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

— KChaloux

Answer 3

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

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

इसलिए, एकमात्र कारण मैं गर्भ धारण कर सकता हूं, कि कोई भी व्यक्ति इन भयानक गतिशील भाषाओं द्वारा पेश किए गए लचीलेपन को नहीं चाहेगा, यह है कि वे टीम के विकास, डिबगिंग और ऑटो-प्रलेखन को सरल बनाना चाहते हैं।

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

Answer 4

OOP का मतलब केवल मैसेजिंग, लोकल रिटेंशन और प्रोटेक्शन और स्टेट-प्रोसेस को छुपाना, और सभी चीजों की चरम लेट-बाइंडिंग है - अलिया के

इसलिए वह जो यहां कह रहा है वह यह है कि OO उन सभी ब्लैक बॉक्स बनाने के बारे में है जो संदेशों का जवाब देते हैं। एक तरह से REST अंतिम OO प्रणाली है जिसमें यह क्रियाओं (अर्थात एक संदेश) और संसाधनों (अर्थात एक अपारदर्शी बॉक्स जिसमें कुछ डेटा होता है) का उपयोग करता है।

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