سیستم نوع: تفاوت میان نسخه‌ها

محتوای حذف‌شده محتوای افزوده‌شده
Fatranslator (بحث | مشارکت‌ها)
ادغام...
خط ۲۱:
* سیستم انواع باید شفاف باشد. برنامه‌نویس باید قادر باشد بدون ابهام رفتار یک سیستم انواع و بررسی نوع‌داده آن را پیش‌بینی کند.
* بررسی نوع داده در یک سیستم انواع باید قابل تحمیل باشد؛ اعلام انواع متغیرها باید در زمان کامپایل به صورت ایستا قابل بررسی باشد. بررسی‌های بیشتر باید در زمان اجرا به صورت پویا انجام بگیرند.<ref>https://en.wikipedia.org/wiki/Type_system#Static_and_dynamic_type_checking_in_practice</ref> همچنین وجود تناسب بین نوع هر متغیر با مقدار نسبت داده‌شده به آن باید بررسی شود.
 
== بررسی گونه ==
بررسی گونه (Type-checking) فرایندی است برای اثبات اینکه هر عملیاتی که در برنامه اجرا می‌شود قواعد گونه‌ای زبان را رعایت می‌کند. به‌طور کلی به این معناست که تمامی عملوندها در تمامی گزاره‌ها دارای گونه مناسبی هستند.
 
بررسی کردن معنایی بر دو قسم است:
 
* بررسی ایستا: این نوع بررسی در هنگام کامپایل شدن اتفاق می افتد.
* بررسی پویا: این نوع بررسی در هنگام اجرا اتفاق می افتد.<ref>{{یادکرد کتاب|عنوان=Compilers, Principles, Tools ,and Techniques|نام خانوادگی=Aho|نام=Alfred|ناشر=Pearson|سال=1986|شابک=0-201-10088-6|صفحات=Chapter 6}}</ref>
 
=== بررسی گونه‌ای ایستا ===
یک زبان ایستا گونه است اگر گونه متغیرها به جای زمان اجرا در زمان کامپایل مشخص شود. از مثال‌های معروف از زبان‌های ایستا-گونه می‌توان به زبان‌های Ada, C, C++, C#, JADE, Java, Fortran, Haskell, ML, Pascal, and Scala اشاره کرد.
 
مزیت بزرگ زبان‌هایی که از بررسی گونه ایستا استفاده می‌کنند این است که می‌توانند بسیاری از خطاها و اشتباهات را به سرعت در مرحله توسعه شناسایی کنند. ایستا گونگی معمولاً کدهای کامپایل شده‌ای را نتیجه می دهند که سریع تر اجرا می‌شوند زیرا زمانی که کامپایلر می‌داند که دقیقاً از چه گونه اطلاعاتی استفاده می‌کند می‌تواند کدهای ماشین بهینه تری تولید کند. ( کدهایی که سریع ترند یا حافظه کمتری اشغال می‌کنند)
 
استفاده کنندگان از بررسی گونه ایستا تنها از اطلاعاتی که در زمان کامپایل مشخص شده‌است استفاده می‌کنند اما می‌توانند مطمئن باشند که برای تمامی حالات اجرا، برنامه در حالت صحیح باقی می ماند، که این نیاز به تکرار بررسی گونه را در زمان اجرا از بین می برد.
 
یک بررسی‌کننده گونه ایستا به سرعت خطاهای گونه‌ای را در مسیرهای کد کمتر مورد استفاده پیدا می‌کند اما بدون بررسی ایستا گونه حتی با وجود پوشش 100% کد با تست ممکن است این چنین خطاهایی کشف نشوند.
 
نقطه منفی بررسی ایستا این است که اگر شما بخواهید در یک زبان با بررسی‌کننده گونه ایستا یک برنامه با خطا گونه‌ای را به صورت دستی اجرا کنید ، حتماً بررسی‌کننده گونه متوجه می‌شود و یک خطای گونه‌ای را ایجاد می‌کند و مانع اجرا برنامه شما می‌شود.<ref>{{یادکرد کتاب|عنوان=Object Oriented Programming: A Unified Foundation|نام خانوادگی=Castagna|نام=Giuseppe|ناشر=Birkhauser|سال=1997|صفحات=https://www.amazon.com/Object-Oriented-Programming-Foundation-Giuseppe/dp/B010BDQE00}}</ref>
 
=== بررسی گونه‌ای پویا ===
بررسی گونه پویا فرایندی است که ایمن بودن گونه‌های یک برنامه را در زمان اجرا تصدیق کند. زبان‌های معروف با بررسی‌کننده گونه پویا عبارتند از :
 
Groovy, JavaScript, Lisp, Lua, Objective-C, PHP, Prolog, Python, Ruby, Smalltalk and Tcl.
 
بیشتر زبان‌های ایمن-گونه دارای سبکی از بررسی گونه پویا هستند حتی اگر آن‌ها از یک بررسی‌کننده ایستا نیز استفاده کنند. دلیل این امر این است که بررسی گونه‌ای ایستای بسیار از ویژگی‌ها و خواص مفید غیرممکن (یا بسیار دشوار) است. برای مثال برنامه‌ای را در نظر بگیرید که دو گونه A , B را تعریف کرده که A زیرگونه B است. اگر برنامه سعی کند که یک مقدار از گونه A را به گونه B تبدیل کند که تبدیل رو به پایین {{به انگلیسی|Down Casting}} این عمل زمانی مجاز خواهد بود که مقدار تبدیل شونده خود از گونه B باشد بنابراین یک بررسی‌کننده پویا گونه لازم است که تصدیق کند که این عمل ایمن است. از دیگر قابلیت‌های زبانی که بررسی پویا گونه اجازه می دهد می‌توان به dynamic dispatch, late binding, و reflection اشاره کرد.
 
برخلاف بررسی‌کننده‌های گونه ایستا ، بررسی‌کننده‌های گونه پویا ممکن است باعث خرابی برنامه در زمان اجرا به علت خطاهای گونه‌ای شوند. در بعضی از زبان‌های برنامه‌نویسی این قابلیت وجود دارد که از این خطاها به وسیله روش‌های حل خطا و یا روش‌های ایمنی ضعیف خارج شد. در سایر زبان‌ها خطاهای گونه‌ای کشنده قلمداد می‌شود .
 
به علت سخت بودن تشخیص خطاهای گونه‌ای در زبان‌های با بررسی گونه‌ای پویا یک روش مرسوم استفاده از آزمایش واحد{{به انگلیسی|Unit testing}} می‌باشد.
 
در مجموع زبان‌های با بررسی گونه‌ای پویا معمولاً کدهای غیربهینه تری را نسبت به زبان‌های با بررسی گونه ایستا تولید می‌کنند ، احتمال خطای گونه‌ای در زمان اجرا را زیاد می‌کنند و مجبور می‌شوند که بررسی‌های گونه‌ای زمان اجرا داشته باشند. ( در مقابل بررسی‌کننده‌های ایستا که فقط یک بار در زمان کامپایل بررسی می‌کنند).
 
با این حال بررسی‌کننده‌های پویا امکان ساختن زبان‌هایی را می دهند که دارای با قدرت بیشتر و امکانات بهتری باشند و توسعه محصولات را به صورت چشم‌گیری آسان تر کنند.
 
=== فرایند طراحی یک صحت یاب گونه ===
 
# در ابتدا باید گونه‌هایی که در زبان موجود اند را شناسایی کنیم.
# سپس به شناسایی ساختارهایی از زبان که با این گونه‌ها در ارتباط اند می پردازیم
# در انتها قواعد معنایی که بر این زبان هستند را شناسایی می کنیم.<ref>{{یادکرد کتاب|عنوان=Implementing Programming Languages. An Introduction to Compilers and Interpreters|نام خانوادگی=Ranta|نام=Aarne|ناشر=College Publications|سال=2012|صفحات=https://www.amazon.com/Implementing-Programming-Languages-Introduction-Interpreters/dp/1848900643}}</ref>
 
== منابع ==