"टाइप-सेफ" का क्या अर्थ है?
"टाइप-सेफ" का क्या अर्थ है?
जवाबों:
टाइप सुरक्षा का मतलब है कि कंपाइलर संकलन करते समय प्रकारों को मान्य करेगा, और यदि आप गलत प्रकार को एक चर में असाइन करने का प्रयास करते हैं तो एक त्रुटि को फेंक देंगे।
कुछ सरल उदाहरण:
// Fails, Trying to put an integer in a string
String one = 1;
// Also fails.
int foo = "bar";
यह विधि तर्कों पर भी लागू होता है, क्योंकि आप उनके लिए स्पष्ट प्रकार पास कर रहे हैं:
int AddTwoNumbers(int a, int b)
{
return a + b;
}
अगर मैंने उस कॉल का उपयोग करने की कोशिश की:
int Sum = AddTwoNumbers(5, "5");
कंपाइलर एक त्रुटि फेंक देगा, क्योंकि मैं एक स्ट्रिंग ("5") पास कर रहा हूं, और यह एक पूर्णांक की उम्मीद कर रहा है।
एक संक्षिप्त टाइप की गई भाषा में, जैसे कि जावास्क्रिप्ट, मैं निम्नलिखित कार्य कर सकता हूं:
function AddTwoNumbers(a, b)
{
return a + b;
}
अगर मैं इसे इस तरह कहता हूं:
Sum = AddTwoNumbers(5, "5");
जावास्क्रिप्ट स्वचालित रूप से 5 को एक स्ट्रिंग में परिवर्तित करता है, और "55" देता है। यह स्ट्रिंग संघनन के लिए + चिह्न का उपयोग करके जावास्क्रिप्ट के कारण है। इसे टाइप-अवेयर करने के लिए, आपको कुछ करने की आवश्यकता होगी:
function AddTwoNumbers(a, b)
{
return Number(a) + Number(b);
}
या, संभवतः:
function AddOnlyTwoNumbers(a, b)
{
if (isNaN(a) || isNaN(b))
return false;
return Number(a) + Number(b);
}
अगर मैं इसे इस तरह कहता हूं:
Sum = AddTwoNumbers(5, " dogs");
जावास्क्रिप्ट स्वचालित रूप से 5 को एक स्ट्रिंग में परिवर्तित करता है, और उन्हें जोड़ता है, "5 कुत्तों" को वापस करने के लिए।
सभी डायनेमिक भाषाएं जावास्क्रिप्ट के रूप में क्षमा नहीं कर रही हैं (वास्तव में एक गतिशील भाषा का अर्थ यह नहीं है कि यह एक ढीली टाइप की गई भाषा है (पायथन देखें)), उनमें से कुछ वास्तव में आपको अमान्य टाइप कास्टिंग पर रनटाइम त्रुटि देंगे।
इसके सुविधाजनक होने के दौरान, यह आपको बहुत सी त्रुटियों को खोलता है जो आसानी से छूट सकते हैं, और केवल चल रहे कार्यक्रम का परीक्षण करके पहचाना जाता है। व्यक्तिगत रूप से, मैं पसंद करता हूं कि मेरा कंपाइलर मुझे बताए कि क्या मैंने वह गलती की है।
अब, C # पर वापस जाएं ...
C # एक भाषा सुविधा का समर्थन करता है जिसे कोवरियन कहा जाता है , इसका मूल रूप से मतलब है कि आप एक बच्चे के प्रकार के लिए आधार प्रकार स्थानापन्न कर सकते हैं और त्रुटि का कारण नहीं बन सकते हैं, उदाहरण के लिए:
public class Foo : Bar
{
}
यहाँ, मैंने एक नया वर्ग (फू) बनाया जो बार को उपवर्गित करता है। मैं अब एक विधि बना सकता हूं:
void DoSomething(Bar myBar)
और इसे एक फू, या एक बार के रूप में एक तर्क के रूप में कहें, दोनों एक त्रुटि पैदा किए बिना काम करेंगे। यह काम करता है क्योंकि C # जानता है कि बार का कोई भी बच्चा वर्ग बार के इंटरफ़ेस को लागू करेगा।
हालाँकि, आप उलटा नहीं कर सकते:
void DoSomething(Foo myFoo)
इस स्थिति में, मैं बार को इस विधि से नहीं जोड़ सकता, क्योंकि कंपाइलर को पता नहीं है कि बार फू के इंटरफ़ेस को लागू करता है। ऐसा इसलिए है क्योंकि एक चाइल्ड क्लास पेरेंट क्लास की तुलना में बहुत अलग हो सकती है (और आमतौर पर)।
बेशक, अब मैं मूल प्रश्न के दायरे से परे गहरे अंत से दूर चला गया हूं, लेकिन इसके सभी अच्छे सामानों को जानना :)
प्रकार-सुरक्षा को स्थिर / गतिशील टाइपिंग या मजबूत / कमजोर टाइपिंग के साथ भ्रमित नहीं होना चाहिए।
एक प्रकार-सुरक्षित भाषा वह है जहां केवल एक ही ऑपरेशन जिसे डेटा पर निष्पादित किया जा सकता है, वह डेटा के प्रकार द्वारा कंडोम किया जाता है। यही है, यदि आपका डेटा प्रकार का है X
और X
ऑपरेशन का समर्थन नहीं करता है y
, तो भाषा आपको निष्पादित करने की अनुमति नहीं देगी y(X)
।
जब यह जाँच की जाती है तो यह परिभाषा नियम निर्धारित नहीं करती है। यह संकलन समय (स्थिर टाइपिंग) या रनटाइम (डायनामिक टाइपिंग) पर हो सकता है, आमतौर पर अपवादों के माध्यम से। यह दोनों का एक सा हो सकता है: कुछ स्थिर टाइप किया भाषाओं एक प्रकार से दूसरे में डाली डेटा की अनुमति, और डाले की वैधता क्रम (कल्पना करें कि आप एक कास्ट करने के लिए कोशिश कर रहे हैं पर जाँच की जानी चाहिए Object
एक करने के लिए Consumer
- संकलक नहीं है यह जानने का तरीका कि यह स्वीकार्य है या नहीं)।
टाइप-सेफ्टी का मतलब जरूरी नहीं कि दृढ़ता से टाइप किया हुआ हो, या तो - कुछ भाषाएं बेहद कमजोर टाइप की हैं, लेकिन फिर भी यकीनन सुरक्षित हैं। उदाहरण के लिए, जावास्क्रिप्ट को लें: इसका प्रकार प्रणाली के रूप में वे आते हैं के रूप में कमजोर है, लेकिन अभी भी सख्ती से परिभाषित किया गया है। यह डेटा की स्वचालित कास्टिंग (जैसे, किलों में तार) की अनुमति देता है, लेकिन अच्छी तरह से परिभाषित नियमों के भीतर। मेरी जानकारी में कोई मामला नहीं है जहां एक जावास्क्रिप्ट प्रोग्राम एक अपरिभाषित फैशन में व्यवहार करेगा, और यदि आप पर्याप्त चतुर हैं (मैं नहीं हूं), तो आपको यह अनुमान लगाने में सक्षम होना चाहिए कि जावास्क्रिप्ट कोड पढ़ते समय क्या होगा।
एक प्रकार की असुरक्षित प्रोग्रामिंग भाषा का एक उदाहरण C है: सरणी की सीमा के बाहर एक सरणी मूल्य को पढ़ना / लिखना विनिर्देश द्वारा अपरिभाषित व्यवहार है । यह भविष्यवाणी करना असंभव है कि क्या होगा। C एक ऐसी भाषा है जिसमें एक प्रकार की प्रणाली है, लेकिन सुरक्षित प्रकार नहीं है।
टाइप सेफ्टी केवल एक संकलन समय की कमी नहीं है, बल्कि एक रन टाइम की कमी है। मुझे लगता है कि इस समय के बाद भी, हम इस पर और स्पष्टता जोड़ सकते हैं।
टाइप सुरक्षा से संबंधित 2 मुख्य मुद्दे हैं। मेमोरी ** और डेटा प्रकार (इसके अनुरूप संचालन के साथ)।
एक char
आम तौर पर चरित्र प्रति 1 बाइट, या 8 बिट की आवश्यकता है (भाषा, जावा और सी # दुकान यूनिकोड वर्ण जो 16 बिट की आवश्यकता पर निर्भर करता है)। एक int
4 बाइट, या 32 बिट (आमतौर पर) की आवश्यकता है।
दिखने में:
char: |-|-|-|-|-|-|-|-|
int : |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-|
एक प्रकार की सुरक्षित भाषा एक इंट को रन-टाइम पर एक चार में डालने की अनुमति नहीं देती है (यह किसी प्रकार की क्लास कास्ट या मेमोरी अपवाद से बाहर फेंकना चाहिए)। हालाँकि, एक असुरक्षित भाषा में, आप मौजूदा डेटा को मेमोरी के 3 और समीपवर्ती बाइट्स में अधिलेखित कर देंगे।
int >> char:
|-|-|-|-|-|-|-|-| |?|?|?|?|?|?|?|?| |?|?|?|?|?|?|?|?| |?|?|?|?|?|?|?|?|
उपरोक्त मामले में, दाईं ओर के 3 बाइट्स को ओवरराइट कर दिया जाता है, इसलिए उस मेमोरी के किसी भी संकेत (जो लगातार 3 वर्ण कहते हैं) जो उम्मीद के मुताबिक चार मूल्य प्राप्त करते हैं, अब कचरा हो जाएगा। यह undefined
आपके प्रोग्राम में व्यवहार का कारण बनता है (या बदतर, संभवतः अन्य कार्यक्रमों में यह निर्भर करता है कि ओएस कैसे मेमोरी आवंटित करता है - इन दिनों बहुत संभावना नहीं है)।
** हालांकि यह पहला मुद्दा तकनीकी रूप से डेटा प्रकार के बारे में नहीं है, लेकिन सुरक्षित भाषाएं इसे स्वाभाविक रूप से संबोधित करती हैं और यह इस बात से अनभिज्ञ है कि इस समस्या से अनजान लोग कैसे स्मृति आवंटन "दिखता है"।
अधिक सूक्ष्म और प्रत्यक्ष प्रकार का मुद्दा है जहां दो डेटा प्रकार एक ही मेमोरी आवंटन का उपयोग करते हैं। एक इंट बनाम अहस्ताक्षरित इंट ले। दोनों 32 बिट्स हैं। (जैसा कि आसानी से एक चार [4] और एक इंट हो सकता है, लेकिन अधिक सामान्य मुद्दा यूंट बनाम इंट है)।
|-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-|
|-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-| |-|-|-|-|-|-|-|-|
एक प्रकार की असुरक्षित भाषा प्रोग्रामर को 32 बिट्स के एक ठीक से आवंटित अवधि को संदर्भित करने की अनुमति देती है, लेकिन जब एक अहस्ताक्षरित इंट का मूल्य एक इंट (या इसके विपरीत) के स्थान पर पढ़ा जाता है, तो हमारे पास फिर से undefined
व्यवहार होता है। एक बैंकिंग कार्यक्रम में इसके कारण होने वाली समस्याओं की कल्पना करें:
"यार! मैंने $ 30 ओवरड्राफ्ट किया और अब मेरे पास $ 65,506 बचे हैं !!"
... 'बेशक, बैंकिंग कार्यक्रम बहुत बड़े डेटा प्रकारों का उपयोग करते हैं। ;) जबरदस्त हंसी!
जैसा कि दूसरों ने पहले ही बताया है, अगला मुद्दा प्रकारों पर कम्प्यूटेशनल संचालन है। यह पहले से ही पर्याप्त रूप से कवर किया गया है।
आज के अधिकांश प्रोग्रामर को कभी भी ऐसी चीजों के बारे में चिंता करने की आवश्यकता नहीं है जब तक कि वे सी या सी ++ जैसी किसी चीज का उपयोग नहीं कर रहे हैं। ये दोनों भाषाएं प्रोग्रामर को जोखिम को कम करने के लिए कंपाइलर्स के बेहतरीन प्रयासों के बावजूद रन टाइम (डायरेक्ट मेमोरी रेफरेंसिंग) पर टाइप सेफ्टी का आसानी से उल्लंघन करने देती हैं। फिर भी, यह सब बुरा नहीं है।
इन भाषाओं के इतनी अधिक तेजी से होने का एक कारण यह भी है कि रन टाइम ऑपरेशंस जैसे, उदाहरण के लिए, जावा में टाइप कम्पैटिबिलिटी को वेरीफाई नहीं किया जाता है। वे मानते हैं कि डेवलपर एक अच्छा तर्कसंगत है जो एक स्ट्रिंग और एक इंट को एक साथ नहीं जोड़ेगा और उसके लिए, डेवलपर को गति / दक्षता के साथ पुरस्कृत किया जाता है।
कई उत्तर यहां स्थैतिक-टाइपिंग और डायनेमिक-टाइपिंग के साथ टाइप-सेफ्टी को भ्रमित करते हैं। एक गतिशील रूप से टाइप की गई भाषा (जैसे कि स्मालटाक) भी सुरक्षित हो सकती है।
एक संक्षिप्त उत्तर: यदि कोई ऑपरेशन अपरिभाषित व्यवहार की ओर जाता है तो एक भाषा को टाइप-सेफ माना जाता है। कई लोग स्पष्ट प्रकार के रूपांतरणों की आवश्यकता को एक भाषा के लिए कड़ाई से टाइप करने के लिए आवश्यक मानते हैं , क्योंकि स्वचालित रूपांतरण कभी-कभी अच्छी तरह से परिभाषित लेकिन अप्रत्याशित / अनपेक्षित व्यवहारों की ओर जाता है।
if no operation leads to undefined behavior
।
एक उदार कला प्रमुख से एक स्पष्टीकरण, एक प्रमुख विज्ञान प्रमुख नहीं:
जब लोग कहते हैं कि भाषा या भाषा की सुविधा टाइप सुरक्षित है, तो उनका मतलब है कि भाषा आपको रोकने में मदद करेगी, उदाहरण के लिए, ऐसा कुछ पास करना जो किसी तर्क के पूर्णांक नहीं है जो पूर्णांक की अपेक्षा करता है।
उदाहरण के लिए, C # में, मैं एक फ़ंक्शन को निम्न के रूप में परिभाषित करता हूं:
void foo(int arg)
कंपाइलर मुझे ऐसा करने से रोकेगा:
// call foo
foo("hello world")
अन्य भाषाओं में, कंपाइलर मुझे नहीं रोकेगा (या कोई कंपाइलर नहीं है ...), इसलिए स्ट्रिंग को लॉजिक में पास किया जाएगा और फिर शायद कुछ बुरा होगा।
सुरक्षित भाषाओं को टाइप करें "संकलन समय" पर अधिक पकड़ने की कोशिश करें।
नीचे की ओर, सुरक्षित भाषाओं के साथ, जब आपके पास "123" जैसा एक स्ट्रिंग होता है और आप उस पर एक इंट की तरह काम करना चाहते हैं, तो आपको स्ट्रिंग को इंट में बदलने के लिए अधिक कोड लिखना होगा, या जब आपके पास कोई इंट होगा 123 की तरह और इसे एक संदेश में उपयोग करना चाहते हैं, जैसे "उत्तर 123 है", आपको इसे स्ट्रिंग में बदलने / डालने के लिए अधिक कोड लिखना होगा।
एक बेहतर समझ पाने के लिए नीचे दिए गए वीडियो को देखें जो कि सुरक्षित भाषा (C #) में कोड प्रदर्शित करता है और सुरक्षित भाषा (जावास्क्रिप्ट) टाइप नहीं करता है।
http://www.youtube.com/watch?v=Rlw_njQhkxw
अब लंबे पाठ के लिए।
टाइप सेफ्टी का मतलब है, टाइप एरर को रोकना। टाइप त्रुटि तब होती है जब एक प्रकार के डेटा प्रकार को अन्य प्रकार के लिए निर्दिष्ट किया जाता है और हमें अवांछनीय परिणाम मिलते हैं।
उदाहरण के लिए जावास्क्रिप्ट एक प्रकार की सुरक्षित भाषा नहीं है। नीचे दिए गए कोड में "संख्या" एक संख्यात्मक चर है और "str" स्ट्रिंग है। जावास्क्रिप्ट मुझे "num + str" करने की अनुमति देता है, अब लगता है कि यह अंकगणित या समाकलन करेगा।
अब नीचे दिए गए कोड के लिए परिणाम "55" हैं, लेकिन महत्वपूर्ण बिंदु यह भ्रम है कि यह किस तरह का ऑपरेशन करेगा।
यह इसलिए हो रहा है क्योंकि जावास्क्रिप्ट एक प्रकार की सुरक्षित भाषा नहीं है। इसके एक प्रकार के डेटा को दूसरे प्रकार के प्रतिबंधों के बिना सेट करने की अनुमति है।
<script>
var num = 5; // numeric
var str = "5"; // string
var z = num + str; // arthimetic or concat ????
alert(z); // displays “55”
</script>
C # एक प्रकार की सुरक्षित भाषा है। यह एक डेटा प्रकार को अन्य डेटा प्रकार को असाइन करने की अनुमति नहीं देता है। नीचे दिए गए कोड विभिन्न डेटा प्रकारों पर "+" ऑपरेटर की अनुमति नहीं देते हैं।
टाइप-सेफ का मतलब है कि प्रोग्रामेटिक रूप से, वैरिएबल, रिटर्न वैल्यू या तर्क के लिए डेटा का प्रकार एक निश्चित मापदंड के भीतर फिट होना चाहिए।
व्यवहार में, इसका मतलब है कि 7 (एक पूर्णांक प्रकार) "7" (स्ट्रिंग प्रकार का एक उद्धृत चरित्र) से अलग है।
PHP, जावास्क्रिप्ट और अन्य गतिशील स्क्रिप्टिंग भाषाएं आमतौर पर कमजोर-टाइप की जाती हैं, इसमें वे a (string) "7" को a (पूर्णांक) 7 में बदल देंगे यदि आप "7" + 3 को जोड़ने का प्रयास करते हैं, हालांकि कभी-कभी आपको ऐसा करना पड़ता है स्पष्ट रूप से (और जावास्क्रिप्ट कॉन्सेप्टन के लिए "+" वर्ण का उपयोग करता है)।
C / C ++ / Java को यह समझ में नहीं आएगा, या परिणाम को "73" में बदलेगा। टाइप-सेफ्टी इस प्रकार के बग्स को कोड में टाइप आवश्यकता को स्पष्ट करके रोकती है।
टाइप-सेफ्टी बहुत उपयोगी है। उपरोक्त "7" + 3 का समाधान कास्ट (int) "7" + 3 (10 के बराबर) टाइप करना होगा।
संकल्पना:
अर्थ की तरह बहुत ही सरल प्रकार सुरक्षित होने के लिए, यह सुनिश्चित करता है कि चर का प्रकार सुरक्षित होना चाहिए
इसलिए यह चर के संदर्भ में आपके भंडारण के प्रकारों की सुरक्षा के बारे में है।
इस स्पष्टीकरण पर प्रयास करें ...
टाइपसेफ़ का मतलब है कि संकलन समय पर उपयुक्त असाइनमेंट के लिए वैरिएबल की जाँच की जाती है। उदाहरण के लिए, एक स्ट्रिंग या एक पूर्णांक सम्मिलित करें। ये दो अलग-अलग डेटा प्रकार क्रॉस-असाइन नहीं किए जा सकते (यानी, आप किसी स्ट्रिंग को पूर्णांक नहीं दे सकते हैं और न ही आप किसी स्ट्रिंग को पूर्णांक को असाइन कर सकते हैं)।
गैर-प्रकार के व्यवहार के लिए, इस पर विचार करें:
object x = 89;
int y;
यदि आप ऐसा करने का प्रयास करते हैं:
y = x;
संकलक एक त्रुटि फेंकता है जो कहती है कि यह एक System.Object को एक Integer में नहीं बदल सकता है। आपको स्पष्ट रूप से ऐसा करने की आवश्यकता है। एक तरीका यह होगा:
y = Convert.ToInt32( x );
ऊपर दिया गया असाइनमेंट टाइपसेफ नहीं है। एक टाइपसेफ़ असाइनमेंट वह जगह है जहाँ प्रकार सीधे एक दूसरे को सौंपे जा सकते हैं।
एएसपी.नेट में गैर-प्रकार के संग्रह लाजिमी हैं (उदाहरण के लिए, एप्लिकेशन, सत्र और दृश्य संग्रह)। इन संग्रहों के बारे में अच्छी खबर यह है कि (कई सर्वर राज्य प्रबंधन विचारों को कम करते हुए) आप तीनों में से किसी भी संग्रह में किसी भी प्रकार का डेटा डाल सकते हैं। बुरी खबर: क्योंकि ये संग्रह असुरक्षित नहीं हैं, इसलिए जब आप इन्हें वापस लाएंगे तो आपको मूल्यों को उचित रूप से डालना होगा।
उदाहरण के लिए:
Session[ "x" ] = 34;
ठीक काम करता है। लेकिन पूर्णांक मान वापस करने के लिए, आपको निम्न की आवश्यकता होगी:
int i = Convert.ToInt32( Session[ "x" ] );
उन तरीकों के लिए जेनेरिक के बारे में पढ़ें, जो आपको टाइपसेफ़ कलेक्शन को आसानी से लागू करने में मदद करते हैं।
C # एक प्रकार की भाषा है, लेकिन C # 4.0 के बारे में लेख देखें; दिलचस्प गतिशील संभावनाएं करघे (क्या यह अच्छी बात है कि सी # अनिवार्य रूप से विकल्प सख्त हो रहा है: बंद ... हम देखेंगे)।
टाइप-सेफ वह कोड है जो केवल मेमोरी स्थानों तक पहुंचता है जो इसे एक्सेस करने के लिए अधिकृत है, और केवल अच्छी तरह से परिभाषित, स्वीकार्य तरीकों से। प्रकार-सुरक्षित कोड उस ऑब्जेक्ट पर एक ऑपरेशन नहीं कर सकता है जो उस ऑब्जेक्ट के लिए अमान्य है। C # और VB.NET भाषा कंपाइलर हमेशा टाइप-सेफ कोड का उत्पादन करते हैं, जिसे JIT संकलन के दौरान टाइप-सुरक्षित होने के लिए सत्यापित किया जाता है।
टाइप-सेफ़ का मतलब है कि प्रोग्राम वेरिएबल को असाइन किए जा सकने वाले मानों का सेट अच्छी तरह से परिभाषित और परीक्षण योग्य मानदंडों के अनुरूप होना चाहिए। प्रकार-सुरक्षित चर अधिक मजबूत कार्यक्रमों की ओर ले जाते हैं क्योंकि एल्गोरिदम जो चर को हेरफेर करते हैं वे भरोसा कर सकते हैं कि चर केवल मूल्यों के एक अच्छी तरह से परिभाषित सेट में से एक ले जाएगा। इस ट्रस्ट को बनाए रखने से डेटा और प्रोग्राम की अखंडता और गुणवत्ता सुनिश्चित होती है।
कई चर के लिए, मानों के सेट को एक चर को सौंपा जा सकता है जिसे कार्यक्रम लिखे जाने के समय परिभाषित किया गया है। उदाहरण के लिए, "रंग" नामक एक चर को "लाल", "हरा", या "नीला" मूल्यों पर लेने की अनुमति दी जा सकती है और कभी भी अन्य मूल्यों को नहीं। अन्य चर के लिए वे मानदंड रन-टाइम में बदल सकते हैं। उदाहरण के लिए, "रंग" नामक एक चर को केवल संबंधपरक डेटाबेस में "रंग" तालिका के "नाम" कॉलम में मान लेने की अनुमति दी जा सकती है, जहां "लाल," हरा "और" नीला "तीन मान हैं। "रंग" तालिका में "नाम" के लिए, लेकिन कंप्यूटर प्रोग्राम के कुछ अन्य भाग कार्यक्रम को चलाने के दौरान उस सूची में जोड़ सकते हैं, और कलर्स तालिका में जोड़े जाने के बाद चर नए मूल्यों पर ले जा सकते हैं ।
कई प्रकार-सुरक्षित भाषाएं चर के लिए सख्ती से परिभाषित प्रकारों पर जोर देकर "टाइप-सेफ्टी" का भ्रम देती हैं और केवल चर को "समान" प्रकार के मान असाइन करने की अनुमति देती हैं। इस दृष्टिकोण के साथ कुछ समस्याएं हैं। उदाहरण के लिए, एक प्रोग्राम में एक चर "yearOfBirth" हो सकता है, जिस वर्ष एक व्यक्ति का जन्म हुआ था, और यह एक छोटे पूर्णांक के रूप में टाइप-कास्ट करने के लिए लुभा रहा है। हालाँकि, यह एक छोटा पूर्णांक नहीं है। इस वर्ष, यह एक संख्या है जो 2009 से कम है और -10000 से अधिक है। हालाँकि, यह सेट हर साल 1 से बढ़ता है क्योंकि कार्यक्रम चलता है। इसे "संक्षिप्त int" बनाना पर्याप्त नहीं है। इस परिवर्तनशील प्रकार को सुरक्षित बनाने के लिए जो आवश्यक है वह एक रन-टाइम सत्यापन फ़ंक्शन है जो यह सुनिश्चित करता है कि संख्या हमेशा -10000 से अधिक हो और अगले कैलेंडर वर्ष से कम हो।
पेरल, पायथन, रूबी, SQLite और लुआ जैसी डायनेमिक टाइपिंग (या डक-टाइपिंग, या प्रकट टाइपिंग) का उपयोग करने वाली भाषाओं में टाइप किए गए चरों की धारणा नहीं है। यह प्रोग्रामर को यह सुनिश्चित करने के लिए प्रोग्रामर को एक रन-टाइम सत्यापन रूटीन लिखने के लिए मजबूर करता है कि यह सही है, या अस्पष्टीकृत रन-टाइम अपवादों के परिणामों को सहन करता है। मेरे अनुभव में, सी, सी ++, जावा, और सी # जैसी सांख्यिकीय रूप से टाइप की जाने वाली भाषाओं में प्रोग्रामर अक्सर यह सोचकर आलसी होते हैं कि सांख्यिकीय रूप से परिभाषित प्रकार वे हैं जिन्हें टाइप-सेफ्टी का लाभ प्राप्त करने के लिए आवश्यक है। यह कई उपयोगी कंप्यूटर कार्यक्रमों के लिए बस सच नहीं है, और यह अनुमान लगाना कठिन है कि क्या यह किसी विशेष कंप्यूटर प्रोग्राम के लिए सच है।
लंबी और छोटी .... क्या आप टाइप-सेफ्टी चाहते हैं? यदि ऐसा है, तो यह सुनिश्चित करने के लिए रन-टाइम फ़ंक्शंस लिखें कि जब एक चर को एक मान सौंपा जाए, तो यह अच्छी तरह से परिभाषित मानदंडों के अनुरूप होता है। डाउन-साइड यह है कि यह अधिकांश कंप्यूटर प्रोग्रामों के लिए डोमेन विश्लेषण को वास्तव में कठिन बनाता है क्योंकि आपको प्रत्येक प्रोग्राम चर के मानदंडों को स्पष्ट रूप से परिभाषित करना होगा।