समकालीन भाषाओं के लिए, यह सिंटैक्टिक शुगर है; पूरी तरह से भाषा-अज्ञेय प्रकार में, यह उससे कहीं अधिक है।
पहले इस उत्तर में कहा गया था कि यह सिंटैक्टिक चीनी से अधिक है, लेकिन अगर आप टिप्पणियों में देखेंगे, तो फाल्को ने कहा कि पहेली का एक टुकड़ा था जो समकालीन भाषाएं सभी को गायब लगती हैं; वे एक ही चरण में कॉल करने के लिए किस फ़ंक्शन के गतिशील निर्धारण के साथ विधि अधिभार मिश्रण नहीं करते हैं। इसे बाद में स्पष्ट किया जाएगा।
यहां यह अधिक क्यों होना चाहिए।
ऐसी भाषा पर विचार करें जो ओवरलोडिंग और अनपेड चर दोनों तरीकों का समर्थन करती है। आप निम्न विधि प्रोटोटाइप हो सकते हैं:
bool someFunction(int arg);
bool someFunction(string arg);
कुछ भाषाओं में, आपको संभवतः संकलन के समय यह जानने के लिए इस्तीफा दे दिया जाएगा कि इनमें से किसी एक को कोड की एक पंक्ति कहा जाएगा। लेकिन कुछ भाषाओं में, सभी वेरिएबल्स टाइप नहीं होते हैं (या वे सभी निहित रूप से Objectया जो भी टाइप किए जाते हैं ), इसलिए एक ऐसे शब्दकोश के निर्माण की कल्पना करें, जिसकी कुंजी विभिन्न प्रकारों के मानों के लिए तैयार हो:
dict roomNumber; // some hotels use numbers, some use letters, and some use
// alphanumerical strings. In some languages, built-in dictionary
// types automatically use untyped values for their keys to map to,
// so it makes more sense then to allow for both ints and strings in
// your code.
अब तब, यदि आप someFunctionउन कमरों में से किसी एक पर आवेदन करना चाहते हैं, तो क्या होगा ? आप इसे कॉल करें:
someFunction(roomNumber[someSortOfKey]);
है someFunction(int)कहा जाता है, या है someFunction(string)कहा जाता है? यहां आप एक उदाहरण देखते हैं जहां ये पूरी तरह से रूढ़िवादी तरीके नहीं हैं, खासकर उच्च-स्तरीय भाषाओं में। भाषा का पता लगाना है - रनटाइम के दौरान - इनमें से किसे कॉल करना है, इसलिए इसे अभी भी कम से कम कुछ हद तक एक ही तरीका माना जा रहा है।
क्यों नहीं बस टेम्पलेट्स का उपयोग करें? क्यों नहीं बस एक अनकही बहस का उपयोग करें?
लचीलापन और महीन दानेदार नियंत्रण। कभी-कभी टेम्प्लेट / अनकैप्ड तर्कों का उपयोग करना एक बेहतर दृष्टिकोण होता है, लेकिन कभी-कभी वे नहीं होते हैं।
आपको उन मामलों के बारे में सोचना होगा जहां, उदाहरण के लिए, आपके पास दो तरीके के हस्ताक्षर हो सकते हैं जो प्रत्येक intएक stringतर्क के रूप में लेते हैं , लेकिन जहां प्रत्येक हस्ताक्षर में आदेश अलग है। ऐसा करने के लिए आपके पास बहुत अच्छा कारण हो सकता है, क्योंकि प्रत्येक हस्ताक्षर का कार्यान्वयन बड़े पैमाने पर एक ही काम कर सकता है, लेकिन बस थोड़ा अलग मोड़ के साथ; उदाहरण के लिए लॉगिंग अलग हो सकती है। या यहां तक कि अगर वे एक ही सटीक काम करते हैं, तो आप केवल उस आदेश से कुछ जानकारी को स्वचालित रूप से चमकाने में सक्षम हो सकते हैं जिसमें तर्क निर्दिष्ट किए गए थे। तकनीकी रूप से आप सिर्फ छद्म-स्विच स्टेटमेंट का उपयोग कर सकते हैं, जिसमें पारित किए गए प्रत्येक तर्क के प्रकार को निर्धारित करने के लिए, लेकिन यह गड़बड़ हो जाता है।
तो क्या यह अगला उदाहरण खराब प्रोग्रामिंग अभ्यास है?
bool stringIsTrue(int arg)
{
if (arg.toString() == "0")
{
return false;
}
else
{
return true;
}
}
bool stringIsTrue(Object arg)
{
if (arg.toString() == "0")
{
return false;
}
else
{
return true;
}
}
bool stringIsTrue(string arg)
{
if (arg == "0")
{
return false;
}
else
{
return true;
}
}
हाँ, द्वारा और बड़े। इस विशेष उदाहरण में, यह किसी को कुछ आदिम प्रकारों पर इसे लागू करने की कोशिश कर रहा है और अप्रत्याशित व्यवहार को वापस पा सकता है (जो एक अच्छी बात हो सकती है); लेकिन चलो मान लेते हैं कि मैंने उपरोक्त कोड संक्षिप्त कर दिया है, और वास्तव में, आपने सभी आदिम प्रकारों के लिए, साथ ही साथ Objectएस के लिए भी ओवरलोड किया है । फिर कोड का यह अगला हिस्सा वास्तव में अधिक उपयुक्त है:
bool stringIsTrue(untyped arg)
{
if (arg.toString() == "0")
{
return false;
}
else
{
return true;
}
}
लेकिन क्या होगा यदि आपको केवल intएस और stringएस के लिए इसका उपयोग करने की आवश्यकता है , और क्या होगा यदि आप चाहते हैं कि यह सरल या अधिक जटिल परिस्थितियों के आधार पर सही वापस लौटे? फिर आपके पास ओवरलोडिंग का उपयोग करने का एक अच्छा कारण है:
bool appearsToBeFirstFloor(int arg)
{
if (arg.digitAt(0) == 1)
{
return true;
}
else
{
return false;
}
}
bool appearsToBeFirstFloor(string arg)
{
string firstCharacter = arg.characterAt(0);
if (firstCharacter.isDigit())
{
return appearsToBeFirstFloor(int(firstCharacter));
}
else if (firstCharacter.toUpper() == "A")
{
return true;
}
else
{
return false;
}
}
लेकिन हे, क्यों न केवल उन कार्यों को दो अलग-अलग नाम दिए जाएं? आप अभी भी ठीक-ठीक नियंत्रण की एक ही राशि है, है ना?
क्योंकि, जैसा कि पहले कहा गया है, कुछ होटल संख्याओं का उपयोग करते हैं, कुछ पत्र का उपयोग करते हैं, और कुछ संख्याओं और अक्षरों के मिश्रण का उपयोग करते हैं:
appearsToBeFirstFloor(roomNumber[someSortOfKey]);
// will treat ints and strings differently, without you having to write extra code
// every single spot where the function is being called
यह अभी भी ठीक वही सटीक कोड नहीं है जिसका मैं वास्तविक जीवन में उपयोग करूंगा, लेकिन यह उस बिंदु को स्पष्ट करना चाहिए जिसे मैं अभी ठीक कर रहा हूं।
लेकिन ... यहाँ यह समकालीन भाषाओं में चीनी से अधिक नहीं है।
फाल्को ने टिप्पणियों में इस बात को उठाया कि वर्तमान भाषाएं मूल रूप से एक ही चरण के भीतर विधि अधिभार और गतिशील फ़ंक्शन चयन को मिश्रित नहीं करती हैं। जिस तरह से मैंने पहले कुछ भाषाओं को काम करने के लिए समझा था वह यह था कि आप appearsToBeFirstFloorऊपर दिए गए उदाहरण में ओवरलोड कर सकते हैं, और फिर भाषा रनटाइम पर निर्धारित करेगी कि फ़ंक्शन के कौन से संस्करण को बुलाया जा सकता है, यह बिना अनपेक्षित चर के रनटाइम मान पर निर्भर करता है। यह भ्रम एक्शनस्क्रिप्ट 3.0 की तरह ईसीएमए-प्रकार की भाषाओं के साथ काम करने से आंशिक रूप से उपजी है, जिसमें आप आसानी से रैंडम पर कोड की एक निश्चित लाइन पर किस फ़ंक्शन को कॉल कर सकते हैं।
जैसा कि आप जानते हैं, ActionScript 3 विधि ओवरलोडिंग का समर्थन नहीं करता है। VB.NET के लिए, आप स्पष्ट रूप से एक प्रकार बताए बिना चर घोषित कर सकते हैं और सेट कर सकते हैं, लेकिन जब आप इन चर को ओवरलोड तरीकों से तर्क के रूप में पारित करने का प्रयास करते हैं, तो यह अभी भी रनटाइम मान को पढ़ने के लिए नहीं निर्धारित करता है कि किस विधि को कॉल करना है; इसके बजाय वह प्रकार के तर्कों के साथ एक विधि खोजना चाहता है Objectया कोई प्रकार या ऐसा कुछ नहीं है। तो intबनाम stringउपरोक्त उदाहरण उस भाषा में काम नहीं होता या तो। C ++ में इसी तरह के मुद्दे हैं, जैसे कि जब आप एक शून्य पॉइंटर या उस जैसे कुछ अन्य तंत्र का उपयोग करते हैं, तब भी आपको संकलन समय पर मैन्युअल रूप से इस प्रकार की आवश्यकता होती है।
तो जैसा कि पहले हेडर कहता है ...
समकालीन भाषाओं के लिए, यह सिंटैक्टिक शुगर है; पूरी तरह से भाषा-अज्ञेय प्रकार में, यह उससे कहीं अधिक है। उपर्युक्त उदाहरण की तरह, अधिक उपयोगी और प्रासंगिक बनाने की विधि बनाना, वास्तव में मौजूदा भाषा में जोड़ने के लिए एक अच्छी सुविधा हो सकती है (जैसा कि एएस 3 के लिए व्यापक रूप से अनुरोध किया गया है), या यह कई अलग-अलग मूलभूत स्तंभों में से एक के रूप में भी काम कर सकता है। एक नई प्रक्रियात्मक / वस्तु-उन्मुख भाषा का निर्माण।