الأشكال Shapes

النبذة

الكائنات قلب JavaScript، ونوع الكائن في TypeScript يخفي قراراً تصميمياً جذرياً يفرّقه عن Java و C#: البنيوية (structural typing). هنا نفهم لماذا اختارت TypeScript أن تحكم على الكائنات بشكلها لا باسمها — وهذا بالضبط duck typing الذي تعرفه من Python، لكن مُبرهَناً وقت الترجمة. ثم نواجه أغرب قاعدة في اللغة كلها: "فحص الخصائص الزائدة"، الذي يبدو نقضاً صريحاً للبنيوية حتى تكتشف لماذا وُجد.

اللغز المستفزّ

أربعة مقاطع. توقّع القبول/الرفض والسبب لكلٍّ:

typescript
type Point = { x: number; y: number };

// (1)
const a = { x: 1, y: 2, z: 3 };
const p: Point = a;                         // ؟

// (2)
const q: Point = { x: 1, y: 2, z: 3 };      // ؟  ← نفس القيمة، حرفياً!

// (3)
function dist(pt: Point) { return pt.x + pt.y; }
dist({ x: 1, y: 2, color: "red" });         // ؟

// (4)
class Cat { name = "felix"; }
class Dog { name = "rex"; }
const c: Cat = new Dog();                    // ؟  ← في Java هذا كفرٌ مبين

ركّز على (1) مقابل (2): نفس القيمة بالضبط ({x:1, y:2, z:3}) تُسنَد لنفس النوع Point — مرّة عبر متغيّر، ومرّة مباشرة — فيُقبل أحدهما ويُرفض الآخر. هذا يبدو كخطأ في المترجم. ليس كذلك. لماذا تصنع الطريقة التي تكتب بها القيمة فرقاً في صلاحيتها؟

الدرس

ما الذي تعنيه مجموعة "نوع كائن"؟

ارجع للعدسة. النوع Point = { x: number; y: number } مجموعة من القيم. أي قيم؟ الفخّ أن تظنّها "الكائنات التي لها x و y فقط". خطأ. التعريف الصحيح:

لماذا "على الأقل"؟ لأن النوع عقدٌ على ما تحتاجه لا على ما يوجد بالضبط. دالة dist تحتاج x و y؛ لو أعطيتها كائناً له x و y و z و color، فكلّ ما تحتاجه موجود، والزائد لا يضرّها — لن تلمسه. فمن منظور المجموعات، {x, y, z} عضوٌ في مجموعة {x, y}-type لأنه يستوفي كل شروطها.

هذا يفسّر (1) فوراً: a نوعه {x, y, z}، ومجموعته ⊆ مجموعة Point (كل كائن له الخصائص الثلاث له حتماً الخاصيّتين المطلوبتين). الإسناد سليم. وكذلك (3): الكائن الزائد عليه color يستوفي عقد Point.

لماذا البنيوية؟ ولماذا تختلف عن Java/C#

في Java، Cat c = new Dog() يُرفض حتى لو كان لـ Dog نفس حقول Cat تماماً — لأن Java اسمية (nominal): العلاقة بين نوعين تُقرَّر من أسمائهما وإعلانات الوراثة الصريحة، لا من شكلهما. Dog ليست Cat لأنها لم تُعلَن كذلك، نقطة.

TypeScript عكسها: بنيوية. العلاقة تُحسب من الشكل (البنية) فقط. لذلك (4) يُقبل: Dog له name: string، و Cat يطلب name: string، فمجموعة Dog ⊆ مجموعة Cat. الأسماء لا تعني شيئاً للمُبرهِن؛ المحتوى هو كل شيء.

ليش اختارت TypeScript البنيوية؟ لأنها وُلدت لتصف JavaScript الموجودة سلفاً. في JavaScript تُمرَّر كائنات حرفية {...} بلا أي إعلان صنف، وتعتمد الشيفرة على "إن كان له الخصائص المطلوبة، استعمله" — وهذا duck typing الذي تعرفه من Python: "إن مشى كبطّة ونَعَق كبطّة، فهو بطّة". لو فرضت TypeScript نظاماً اسمياً لأجبرت كل كائن على الانتماء لصنفٍ مُعلَن، وهذا يخالف روح اللغة ويكسر ملايين أسطر الكود القائم.

(وحين تحتاج فعلاً سلوكاً اسمياً — أن يكون نوعان مختلفين رغم تطابق شكلهما — تستطيع محاكاته. هذه حيلة "branded types"، نتركها للإقليم ٩ لأنها تكشف عن طبيعة النظام أكثر مما تكشف عن الكائنات.)

المفارقة: فحص الخصائص الزائدة (excess property checks)

الآن (2)، الذي يبدو ينقض كل ما سبق:

typescript
const q: Point = { x: 1, y: 2, z: 3 };   // ❌ Object literal may only specify known properties

نفس قيمة (1) بالضبط، لكنها مرفوضة. لماذا؟ السبب ليس في المجموعات — {x,y,z} ما زالت ⊆ Point رياضياً. السبب حارسٌ خاص أضافته TypeScript فوق البنيوية، يعمل في حالة واحدة محدّدة: حين تُسنِد كائناً حرفياً (object literal) مباشرةً وجديداً لموضعٍ نوعُه معروف.

ليش هذا الحارس، إن كان يخالف البنيوية؟ لأن الخاصية الزائدة في كائنٍ حرفيّ مكتوب للتو تكاد دائماً تكون خطأً مطبعياً أو سوء فهم:

typescript
type Config = { color: string };
const c: Config = { colour: "red" };   // ❌ — وهذا بالضبط ما يُنقذك

لو طبّقنا البنيوية النقيّة، لكان { colour: "red" } كائناً له خاصية زائدة (colour) ويفتقر للمطلوبة (color)... لكنّ color اختيارية؟ لا، هي مطلوبة فهذا يُرفض. خذ مثالاً أوضح: { color: "red", widht: 5 } لنوعٍ خصائصه الإضافية اختيارية — البنيوية تقبله، لكنك غالباً أخطأت في widht. الحارس يفترض: "إن كتبت كائناً حرفيّاً للتو وفيه خاصية لا يعرفها النوع المستهدف، فأنت على الأرجح غلطت، لا أنك تريد بياناتٍ إضافية." فيشتكي — لكن فقط للحرفيّات الطازجة.

ولهذا (1) يمرّ: مرّرنا عبر متغيّر a. حين تمرّ القيمة عبر متغيّر، تكون قد "استقرّت" بنوعها الخاص، فالمترجم يطبّق البنيوية العادية ويتغاضى عن الزائد. الحارس يستهدف لحظةً واحدة: الحرفيّ المباشر الجديد، حيث الخطأ المطبعي أكثر احتمالاً.

خصائص أخرى تشتقّ من العدسة

• الاختيارية ?: { x: number; y?: number } تعني أن y نوعها فعلياً number | undefined، وأن الكائن صالحٌ بوجودها أو غيابها. مجموعة أوسع من النسخة الإلزامية. اشتقّ: لماذا يجب أن تضيّق y قبل استعمالها رقماً؟ (لأنها قد تكون undefined — تضييق الإقليم ٤.)
• readonly: قيدٌ على الكتابة، وقت الترجمة فقط. اربطه بـ const في C: كلاهما يمنع التعديل، لكن readonly في TypeScript تُمحى تماماً — لا أثر لها وقت التشغيل، لا حماية حقيقية للذاكرة (عكس const في C الذي قد يضع البيانات في ذاكرة للقراءة فقط). إنها وعدٌ يفحصه المُبرهِن ثم يرميه. تذكّر دائماً جدار الإقليم ٠: حتى القيود تختفي.
• index signatures { [k: string]: number }: "أي مفتاح نصّي يُربط بقيمة رقمية" — مجموعة الكائنات ذات المفاتيح المتجانسة (قاموس). اربطها بـ dict في Python.

الدوال أيضاً قيم — وعقودها أعمق

الكائنات لها شكل؛ والدوال كائنات في JavaScript، فلها أيضاً نوع: (x: number) => string. متى تكون دالةٌ ما عضواً في مجموعة هذا النوع؟ الجواب يبدو بديهياً — "تأخذ رقماً وتُرجع نصاً" — لكنه يخفي أعمق وأخدع سؤالٍ في كل اللغة: ماذا لو كانت دالتك تأخذ نوعاً أوسع أو تُرجع نوعاً أضيق؟ هل تبقى عضواً؟ هذا سؤال التباين (variance)، وهو ضخم لدرجة أنه يستحقّ إقليمه كاملاً.

اللغز / التمرين

typescript
type User = { id: number; name: string };
const u1: User = { id: 1, name: "a", age: 5 };            // ؟
const big = { id: 1, name: "a", age: 5 };
const u2: User = big;                                     // ؟  لماذا يختلف عن u1؟
function greet(u: User) {}
greet({ id: 1, name: "a", role: "admin" });              // ؟
const arr: User[] = [{ id: 1, name: "a", x: 9 }];         // ؟  هل الحارس يصل داخل المصفوفة؟

typescript
type Opts = { debug?: boolean };
function run(o: Opts) {}
run({ debg: true });    // المترجم يشتكي

typescript
type Frozen = { readonly x: number };
const f: Frozen = { x: 1 };
// f.x = 2;          // المترجم يرفض
const g = f as { x: number };
g.x = 99;            // ؟
console.log(f.x);    // ؟  ← f و g نفس الكائن

الخلاصة — وصلٌ في الشجرة