09-04-2012, 14:25
|
|
|
|
חבר מתאריך: 14.12.09
הודעות: 9,751
|
|
זה תמיד עניין של טעם.
אפילו עקרונות מוסכמים יחסית לעיצוב שפות תכנות ניתנים לפרשנויות כל-כך שונות, שאי-אפשר 'להוכיח' ששפת תכנות אחת עומדת בהם טוב יותר מאחרת. רשימה קריטריונים לדוגמה: http://www.lshift.net/blog/2006/06/...sign-principles
למרות זאת, אני יכול לחשוב על כמה גישות הגיוניות:
- גישה אחת היא גישה של const-correctness בסגנון C++:
אם אובייקט מוגדר כבלתי-ניתן-לשינוי (ב-C++ - const), ניתן לבצע עליו אך ורק פעולות שאינן משנות את מצבו. (†) הקומפיילר דואג לזה באחת משתי דרכים:
- ב-C++ (ובדרך שהצעתי למעלה) הקומפיילר מרשה לך לקרוא ל-mutators רק אם האובייקט שאתה משתמש בו ניתן-לשינוי. כל פעולה על האובייקט מסומנת על-ידי הכותב על-ידי 'mutator bit' והקומפיילר אוכף את זה שלא תוכל לסמן מתודה של מחלקה ככזו שלא משנה את האובייקט, אם אתה כן מנסה לשנות אותו.
- הדרך השנייה היא לאכוף את זה בזמן ריצה - אם אתה מנסה לשנות אובייקט שאסור לשנות, אתה חוטף exception.
- גישה אחרת היא להפוך את כל האובייקטים ל-immutables
זה לדוגמה מה שקורה בשפות פונקציונאליות.
אפשר להשתמש בגישה הזו גם בשפות שאנחנו מדברים עליהן. בגדול, אף פעם לא משנים כלום - תמיד יוצרים אובייקט חדש שהוא f(x), כש-f היא הטרנספורמציה שאנחנו רוצים לבצע (לדוגמה: מיון, שינוי case של טקסט, וכו').
כאן אנחנו משתמשים באף לא אחת מהגישות האלה. אין שום אכיפה של const-correctness. אפשר לעשות אובייקטים שהם לא immutables, אבל האובייקטים האלה מתנהגים בצורה מוזרה כי אתה מקבל 'חצי הגנה'.
(†) או פעולות ששומרות על אינווריאנטים מסוימים. לדוגמה, ב-C++ אפשר להגדיר שדה של מחלקה כ-mutable, ואז מותר למתודה שנחשבת const לשנות אותו (כשהיא נקראת על אוביקט const-י!), כי הגדרנו במפורש שהשדה הזה איננו חלק מהאינווריאנטים של האובייקט, אפילו כשהוא נחשב const.
_____________________________________
(קרדיט למרשי)
אמר לה ינאי מלכא לדביתיה אל תתיראי מן הפרושין ולא ממי שאינן פרושין אלא מן הצבועין שדומין לפרושין שמעשיהן כמעשה זמרי ומבקשין שכר כפנחס
אמר פסטן: שניהם גרועים, אבל עדיף להיות טיפש מאשר שקרן.
|