בדיקות חיבור

בדיקות חיבור קובעות אילו חיבורים (ולכן חסימות) יכולים להתחבר שתי רשתות נוירונים זו מול זו.

בדיקות חיבור הן שימושיות ליצירת סוגי מודלים. לדוגמה, בשלושה בלוקים לא מחוברים עסק, כי הם מייצגים קוד מחזירה סוגים שונים:

אפשר להשתמש בבדיקות חיבור כדי למנוע את החיבור של הבלוקים האלה. הזה מספק למשתמשים משוב מיידי ומונע טעויות פשוטות רבות.

איך זה עובד

אפשר לשייך כל חיבור ל'בדיקת חיבור' שהוא ערך ריק מערך של מחרוזות.

שני חיבורים יכולים להתחבר אם:

1. הם תואמים סוגים תואמים (למשל, פלט שמתחבר אל קלט).
2. יש לפחות מחרוזת אחת משותפת בבדיקת החיבור שלהם.

לדוגמה, שתי הבדיקות הבאות יכולות להתחבר, מכיוון שהן חופפות מחרוזת 'apple':

['apple', 'ball', 'cat']
['apple', 'bear', 'caterpillar']

אבל לא הצלחנו לחבר בין שתי הבדיקות האלה, כי הן לא משתפות מחרוזות:

['apple', 'ball', 'cat']
['ape', 'bear', 'caterpillar']

יש עוד מקרה מיוחד אחד. אם אחד מהמערכי הוא null, אז 2 המערך יכולים להתחבר. כך אפשר להגדיר חיבורים שיכולים להתחבר לכל דבר.

null
['ape', 'bear', 'caterpillar]

חשוב: יש הבדל בין סוגי בלוקים ובדיקות חיבור. הם לחלוטין קבוצות נפרדות של מחרוזות. הכללת סוג בלוק בבדיקת חיבור כן לא לגרום לו להתחבר לבלוקים מהסוג הזה.

הגדרת בדיקות

כברירת מחדל, לכל החיבורים יש בדיקת חיבור null, כלומר הם יכולים להתחבר לכל דבר. צריך להקצות את בדיקות החיבור באופן ידני.

הדרך שבה מקצים בדיקות חיבור לחיבורים משתנה בהתאם ל האם אתם משתמשים בהגדרות של בלוק JSON או בהגדרות של בלוק JavaScript.

JSON

בחיבורים ברמה העליונה, צריך להקצות את הבדיקה ישירות לנכס מגדיר את החיבור. הערך שניתן להקצות יכול להיות null, מחרוזת הופך לערך היחיד בבדיקת החיבור), או למערך מחרוזות.

{
  'type': 'custom_block',

  'output': null,
  'nextStatement': 'a connection check entry',
  'previousStatement': ['four', 'connection', 'check', 'entries']
}

לקלטים, אפשר להקצות את הבדיקה למאפיין check של הקלט להגדרה. אם הנכס check לא קיים, הבדיקה מתבצעת null. הערך שמקצים יכול להיות מחרוזת או מערך של מחרוזות.

{
  'type': 'custom_block',
  'message0': '%1 %2',

  'args0': [
    {
      'type': 'input_value',
      'check': 'a connection check entry'
    },
    {
      'type': 'input_statement',
      'check': ['four', 'connection', 'check', 'entries']
    }
  ]
}

JavaScript

עבור חיבורים ברמה העליונה, אפשר להעביר את הבדיקה ישירות לשיטה מגדיר את החיבור. אם לא מעבירים ערך, הבדיקה תיחשב null הערך שמעבירים יכול להיות מחרוזת (שהופכת לערך היחיד בשדה או מערך של מחרוזות.

Blockly.Blocks['custom_block'] = {
  init: function() {
    this.setOutput(true); // null check
    this.setNextStatement(true, 'a connection check entry');
    this.setPreviousStatement(true, ['four', 'connection', 'check', 'entries']);
  }
}

לקלטים, ניתן להעביר את הבדיקה ל-method setCheck, לאחר הגדיר את הקלט. אם לא מתבצעת קריאה לשיטה setCheck, הבדיקה null. הערך שמעבירים יכול להיות מחרוזת או מערך של מחרוזות.

Blockly.Blocks['custom_block'] = {
  init: function() {
    this.appendValueInput('NAME')
        .setCheck('a connection check entry');
    this.appendStatementInput('NAME')
        .setCheck(['four', 'connection', 'check', 'entries']);
  }
}

מחרוזות ביקורת מובנות

הבלוקים המובְנים כוללים בדיקות חיבור עם הערכים 'Array', 'Boolean', 'Colour', 'Number' וגם 'String'. אם רוצים שהבלוקים לפעול באופן הדדי עם הבלוקים המובְנים, אפשר להשתמש בערכים האלה כדי ליצור תואמת.

דוגמאות לערכים

כשמגדירים בדיקות חיבור לקלט ולפלט, בדרך כלל צריך לחשוב על הבדיקות בתור סוגים שמייצגים סוגים.

'כניסות' צריך לכלול את כל "סוג" הם מקבלים, ויוצרת פלט בדיקות צריך לכלול בדיוק את מה שהם "מחזירים".

אישור של סוג יחיד

במקרה הבסיסי ביותר שבו רוצים ליצור בלוק ש"מקבל" או "החזרות" אחד, צריך לכלול את הסוג הזה בבדיקת החיבור של החיבור.

אישור של כמה סוגים

כדי ליצור בלוק ש"מקבל" כמה סוגים, צריך לכלול את כל בבדיקת החיבור של הקלט.

לפי המוסכמה, אם פלט יכול לפעמים להתקבל במצבים מרובים (למשל, אם מאפשרים שימוש במספרים כמחרוזות), הפלט צריך להיות מגבילים יותר, והקלט צריך להיות מתירני יותר. המוסכמה הזו מוודאים שמשתני הפלט לא מחוברים במקומות שבהם הם לא נתמכים.

אפשר לקבל כל סוג

כדי ליצור בלוק ש"מקבל" מכל סוג, צריך להגדיר בדיקת חיבור אל null.

סוגי משנה של החזרה

ליצור בלוק ש"חוזר" תת-סוג, צריך לכלול גם את הסוג ואת סוג-העל בבדיקת החיבור של הפלט.

במקרה של סוגי משנה, זה בסדר לכלול מספר בדיקות בבדיקת הפלט, כי הבלוק תמיד "חוזר" משני הסוגים.

החזרת סוגים עם פרמטרים

ליצור בלוק ש"חוזר" סוג פרמטר, צריך לכלול גם את הגרסה עם הפרמטרים ואת הגרסה ללא פרמטרים בפלט בדיקת חיבור.

ייתכן שתרצו גם להגביל את שפת הבלוקים, בהתאם למגבלות כוללים את השונות של הסוג.

בדיוק כמו בסוגי המשנה, מותר לכלול כמה בדיקות בבדיקת הפלט במקרה הזה, כי הבלוק תמיד "חוזר" משני הסוגים.

דוגמאות לערימה או להצהרה

יש כמה דרכים נפוצות שבהן מפתחים מגדירים את הבדיקות לשלב הקודם ולבדיקה הבאה בחיבורים. בדרך כלל מדובר בהגבלה של סדר הבלוקים.

החיבורים הבאים צריכים לכלול את הבלוקים שאמורים לעקוב אחרי הבלוק הנוכחי, וגם החיבורים הקודמים כוללים את מה "הוא" של הבלוק הנוכחי.

חשוב: סוגי הבלוקים ובדיקות החיבור הם שונים. כשאומרים "אילו בלוקים צריכים לעקוב אחרי הבלוק הנוכחי", פירוש הדבר הוא שבדיקת החיבור. לכלול מחרוזות ביקורת רלוונטיות, ולא סוגי בלוקים.

שומרים על הסדר של הבלוקים

כדי ליצור קבוצה של בלוקים שמתחברים בסדר מוגדר, צריך לכלול אילו בלוקים צריכים לעקוב אחרי הבלוק הנוכחי בבדיקת החיבור הבאה, וגם מה הבלוק הנוכחי בבדיקת החיבור הקודמת.

מאפשרים הרבה בלוקים אמצעיים

כדי ליצור סדרה של בלוקים סדורים שמאפשרים הרבה בלוקים אמצעיים, אתם צריכים לכלול לפחות רשומה אחת מבדיקת החיבור הקודמת של הבלוק האמצעי לבדיקת החיבור הבאה של הבלוק האמצעי. כך אפשר לעקוב אחרי החסימה של עצמו.

אין לאפשר בלוקים אמצעיים

כדי ליצור קבוצה של בלוקים סדורים שבהם הבלוקים האמצעיים הם אופציונליים, צריך כך שתכלול לפחות רשומה אחת גם מהחיבור הקודם של הבלוק האמצעי ובדיקת החיבור הקודמת של הבלוק האחרון בבלוק הבא בדיקת חיבור. כך יכול להיות שאחרי הבלוק הראשון יופיע או בלוק אחרון.

או מקבצים

כדי ליצור בלוק שאפשר לעקוב אחריו רק באמצעות בלוקים מקבוצה אחת, או בלוקים. משני הסוגים (ולא משניהם), אתם צריכים לעשות שני דברים:

1. עליך לכלול לפחות רשומה אחת משתי הקבוצות הקודמות. ובבדיקת החיבור הבאה של הבלוק הראשון.

2. צריך להגדיר את הקבוצות בבדיקות החיבור הבאות, כדי לכלול רק ערכים שנמצאות בבדיקות החיבור הקודמות (כך שאפשר רק לעקוב אחריהן לפי בלוקים של אותה קבוצה).

מגבלות

המערכת הזו יציבה ויכולה לפתור תרחישי שימוש רבים, אך יש לה כמה מגבלות בפועל.

הגבלת ההקשר הרחב

מערכת זו כשלעצמה לא תומכת בהגבלת 'הקשר רחב יותר' באזור שמותר לחבר בין החיבורים. לדוגמה, אי אפשר לומר בלוק break יכול להתקיים רק בתוך בלוק loop. החיבור בודקת רק אם שני החיבורים המיידיים מחוברים.

אתם יכולים לתמוך בכך באמצעות מערכת האירועים כדי להאזין אירועי חסימה של העברה ובודקים אם הבלוק במיקום שגוי.

Blockly.Blocks['custom_block'] = {
  init: function() { }

  onchange: function(e) {
    if (this.workspace.isDragging()) return;
    if (e.type !== Blockly.Events.BlockMove) return;
    if (!this.getSurroundLoop()) this.outputConnection.disconnect();
  }

  loopTypes: new Set(); // Your valid *block types* (not connection checks).

  getSurroundLoop: function () {
    let block = this.getSurroundParent();
    do {
      if (loopTypes.has(block.type)) return block;
      block = block.getSurroundParent();
    } while (block);
    return null;
  },
}

סוגים כלליים

המערכת הזו כשלעצמה לא תומכת בהגדרת סוגים כלליים. לדוגמה, אי אפשר ליצור זהות ש"חוזרת" ללא קשר לקלט הזה.

אפשר במידה מסוימת לתמוך בכך על ידי שינוי פעיל של בדיקת החיבור של הפלט של הבלוק כדי להתאים לקלט שלו. ניתן לעשות זאת באמצעות מערכת האירועים כדי האזנה כדי לחסום אירועי העברה.

Blockly.Blocks['custom_block'] = {
  init: function() { }

  onchange: function(e) {
    if (e.type !== Blockly.Events.BlockMove) return;
    this.setOutput(
        true, this.getInputTargetBlock()?.outputConnection.getCheck());
  }
}

אבל אם הבלוק המחובר הוא גם גנרי, אז הפעולה הזו לא תפעל כמו שצריך. אין דרך טובה לעקוף את המקרה הזה.

בודקי חיבור

אם המערכת הזו לא מתאימה לתרחיש לדוגמה שלכם, אפשר גם לשנות את האופן שבו כדי להשוות בין בדיקות חיבור, צריך ליצור בודק חיבור בהתאמה אישית.

לדוגמה, אם רציתם ליצור מערכת מתקדמת יותר שמטפלת בחלק המגבלות האלה, אפשר ליצור את התכונה 'בדיקת חיבור'.