تيليسكريبت (لغة برمجة)

استُوحِيَتْ لغة Telescript من مفهوم البرامج الصغيرة المعروفة باسم "الوكلاء" ، والتي تتفاعل مع خدمات الحوسبة المعروفة باسم " الأماكن" ، حيث تعمل جميعها على مجموعة من خادم واحد أو أكثر تستضيف ما يُسمى "سحابة Telescript". وكان جهاز المستخدم المحمول أحد هذه الأماكن، وإن كان بإمكانيات محدودة. وافترض النموذج أن معظم المعلومات والخدمات ستُقدَّم من خلال أماكن تعمل على خوادم حاسوبية أكبر تستضيفها شركات الاتصالات مثل AT&T. حتى أن الوثائق المبكرة أشارت إلى ذلك على أنه " تشغيل في السحابة" . ^{[ 1 ]} وتتألف البرامج التي يتعامل معها المستخدم من عدد من هذه الوكلاء، والتي قد تعمل محليًا على خوادم مزود الخدمة، أو حتى تُرسَل إلى خوادم جهات خارجية. ولتنسيق الاتصالات، تضمنت Telescript أيضًا مفهومي "اسم الهاتف" الذي يُعرِّف المستخدمين بشكل فريد، و "عناوين الهاتف" التي تُعرِّف الجهاز حتى أثناء تنقله بين الشبكات. ^{[ 6 ]}

على سبيل المثال، لنفترض تطبيق تسوق يطلب من المستخدم البحث عن أسعار شواية جديدة يرغب في شرائها. في نموذج العميل والخادم التقليدي ، يُنشئ التطبيق عددًا من الاستعلامات، ويرسلها إلى عدد من الخدمات، ثم يجمع النتائج ويعرضها. أما في نموذج Telescript، فيُنشئ التطبيق وكيلًا جديدًا مُزوّدًا ببيانات الطلب، ويُضيف إليه اسم المستخدم وعنوانه، ثم يُرسله إلى متجر على خادم للمعالجة. يمكن لهذا الخادم معالجة الطلب مباشرةً، أو إحالة الوكيل إلى جهات أخرى، مثل متاجر البائعين، لمزيد من المعالجة. يمكن وضع النتائج في حقول البيانات الداخلية للوكيل وإرسالها عبر الشبكة إلى جهاز المستخدم، أو يمكن إنشاء وكيل "مراسلة" جديد يحمل بيانات النتائج فقط ويُرسلها لتقليل نقل البيانات عبر الشبكة. ^{[ 7 ]}

يختلف هذا النموذج أيضًا عن الحلول التقليدية في طريقة تبادل البيانات بين البرامج المتفاعلة. فعلى سبيل المثال، إذا اختار المستخدم شراء أحد أجهزة الشواء التي عثر عليها في بحثه السابق، ففي النظام التقليدي، تتم مهمة ملء نماذج الطلب وتأكيد الدفع عبر اتصالات مباشرة بين جهاز المستخدم والخادم البعيد، مما يتطلب قناة اتصال نشطة طوال العملية. أما في نموذج Telescript، فيتم إرسال وكيل جديد مزود بالمعلومات اللازمة لإتمام عملية الشراء إلى متجر البائع، ويتفاعل مع المتجر أو وكلاء البائع، ثم يعود بنتيجة العملية (نجاح أو فشل). تتم الاتصالات الرئيسية بين الوكلاء والمواقع على الخادم البعيد، لذا لا يلزم الاتصال عبر الشبكة إلا في بداية العملية ونهايتها. ^{[ 8 ]}

كانت لغة Telescript لغة كائنية التوجه (OO) وتستخدم عددًا من المصطلحات غير الشائعة لوصف حالة الكائنات واتصالاتها. تتوافق السمات مع ما تُشير إليه اللغات الأخرى باسم متغيرات أو حقول الكائن. تُعرف استدعاءات الدوال باسم الطلبات ، وتُعرف عملية تنفيذ الدالة باسم أدائها . تستجيب جميع هذه الاستدعاءات دائمًا برسالة تُشير إلى النجاح أو الفشل، وكان على الكائن الطالب، اختياريًا، اعتراض هذه الرسائل والاستجابة لها . تُعرف التلميحات حول كيفية تمرير البيانات من وإلى استدعاءات الدوال باسم القيود ، وتشمل القيود الشائعة " بالمرجع " و" بالقيمة "، من بين قيود أخرى. ^{[ 9 ]}

كانت لغة Telescript عمومًا عديمة الحالة فيما يتعلق بدورة حياة البيانات. فجميع البيانات داخل البرنامج، سواءً كانت متغيرات مثيل أو متغيرات محلية، كانت تُخزّن دائمًا بشكل متسلسل. ويمكن استدعاء الوكلاء أو إيقافهم مؤقتًا في أي لحظة، دون أن يفقدوا حالتهم. كما سمحت هذه الآلية نفسها بتواصل الوكلاء بسهولة بين الأجهزة المضيفة.

على الرغم من أن نظام التحكم والتصميم في لغة Telescript مستوحى من لغة C، إلا أن تركيبها النحوي الدقيق كان مختلفًا بشكل ملحوظ. ومن أبرز هذه الاختلافات استبدال الأقواس المعقوفة (الأقواس المتعرجة) المستخدمة في لغة C بالأقواس العادية على مستوى التعريف، مع الإبقاء على الأقواس المعقوفة لتجميع العبارات داخل عبارات المنطق والتحكم في التدفق ، واستخدام النقطتين الرأسيتين (:) لفصل الاسم عن تعريفه. يوضح الكود التالي تعريف واجهة الكائنات من النوع Pie : ^{[ 10 ] [ N1 ]}

 فطيرة: واجهة (كائن) = ( عام الاسم: سلسلة نصية؛ تهيئة: op(name: String); );

لاحظ استخدام الكلمة المفتاحية op، التي تُقابل functionأو subالموجودة في لغات أخرى. يمكن استخدام تطبيق Pie في classكائن واحد أو أكثر، والتي يمكن تنظيمها في moduless بطريقة مشابهة لبنية Visual Basic .NET . namespaceتُستخدم #includeلاستيراد ملفات الرأس، ولكن الاستيراد محلي لـ modules، وليس للملف ككل. ^{[ 11 ]}

تم استدعاء مفهومي "الوكيل" و"المكان" في لغة Telescript ببساطة عن طريق إنشاء فئات فرعية من فئتي "الوكيل" و"المكان"، وكلاهما فئتان فرعيتان من فئة "العملية". ولتبسيط الكود، يمكن وضع كلتيهما في ملف واحد، بل وجمعهما في وحدة نمطية واحدة. يحدد الكود التالي الوكلاء اللازمين لتنفيذ متجر يبيع الفطائر: ^{[ 12 ]}

 PieStoreModule: module = ( #include "pie.i" مشتري الفطيرة: فئة (الوكيل) = ( عام مباشر: برعاية op() = { *.go(*.destination); myPie = place@PieSeller.sellPie(); *.go(*.originPlace); }; ); بائع الفطائر: فئة (مكان) = ( عام بيع الفطيرة: op() الفطيرة = { aPie: فطيرة | لا شيء؛ aPie = *.getPieFromStock; إذا كانت قيمة aPie تساوي nil { PieBuyer(*.distributorTicket, Permit(nil)); aPie = *.waitForPie(); أعد aPie؛ }; }; ); );

يحتوي كائن PieBuyer، وهو وكيل، على دالة واحدة، liveوهي دالة بدء التشغيل القياسية التي تستخدمها جميع الوكلاء. ^{[ 13 ]} بمجرد إنشاء كائن PieBuyer واستدعائه، سيتم liveاستدعاء الدالة، بطريقة مشابهة للعملية newالموجودة في معظم لغات البرمجة الكائنية، على الرغم من أن هذه الدالة تُستدعى بعد الإعداد. يستبدل الرمز * ما يُنفذ عادةً بـ selfأو Me، مشيرًا إلى الكائن نفسه، وهو في هذه الحالة وكيل PieBuyer. ينص الكود أساسًا على أنه عند إنشاء الكائن، يجب أن يرسل نفسه (*.go) إلى الموقع المُرسل إليه أثناء الإنشاء (*.destination). بمجرد وصوله إلى هناك، يجب أن يُخبر كائن المكان المطابق، وهو في هذه الحالة PieSeller، ببيع الفطائر. عند اكتمال هذا الأمر، سيعود الوكيل إلى مكانه الأصلي. يمكن للتطبيق المُستدعي بعد ذلك فحص النتائج من خلال فحص المتغير myPie. ^{[ 12 ]}

يحتوي كائن PieSeller، وهو كائن من نوع Place، على دالة واحدة sellPie. تُعرّف هذه الدالة متغيرًا محليًا يُسمى aPie، وتُحدد قيمته ككائن Pie، أو "لا شيء" في حالة عدم وجود فطائر. ثم تُحاول الدالة تعيين قيمة لـ aPie عن طريق استدعاء دالة getPieFromStock الخاصة بها (غير موضحة هنا)، ثم تتحقق مما إذا كانت هذه الدالة قد أعادت قيمة. إذا لم تنجح، على سبيل المثال، إذا كان المخزون فارغًا، فإنها تُنشئ كائن PieBuyer جديدًا خاصًا بها، وتُرسل هذا الطلب إلى متجر آخر، ثم تنتظر ردًا. قد يُعيد هذا المتجر توجيه الطلب إلى متجر آخر، وهكذا. عند انتهاء سلسلة الأحداث هذه، سواءً بفطيرة أو بفشل، يُعيد كائن PieSeller الفطيرة أخيرًا إلى كائن PieBuyer المُستدعي. ^{[ 12 ]}

عادةً ما تكون الكائنات "مملوكة" للمكان الذي أنشأها. وتمنح الملكية أيضًا صلاحيات وإعدادات أمان. يمكن للغة أن تتولى ملكية كائن ما من خلال own {}البنية، أو في هذه الحالة، باستخدام sponsoredالكلمة المفتاحية للإشارة إلى أنه يجب تشغيله ضمن ملكية المكان الذي يُشغَّل فيه. يمكن استخدام هذا، على سبيل المثال، لمنح الوكيل القدرة على رؤية المخزون في الجرد، وهي قيم ستكون خاصة لولا ذلك. استخدام sponsoredهذه الطريقة يُعطي نفس نتيجة وضع الكود في own {}كتلة، ولكنه يسمح بتنفيذ ذلك في المُستدعي. ^{[ 14 ]}

تتضمن لغة Telescript عدة أنواع مجموعات مدمجة، منها Set`list` Listو` Dictionarylist` و`list` و`list` Collection، والأخير منها عبارة عن قائمة تحتوي على فهارس نصية (نصف قاموس). كان أحد مصادر الأخطاء الشائعة في Telescript هو أنه على الرغم من إمكانية إرجاع المجموعة ككل في وكيل، إلا أن العناصر الفردية داخلها كانت مملوكة للموقع. وبالتالي، إذا استخدمنا `list` return MyCollection[someIndex];، فستعود إلى جهاز المستخدم كقيمة فارغة (null). كان الحل هو استخدام صيغة إضافية، وهي تلميحات `list` DictOwnedو` ColOwnedlist`، والتي أدت إلى تغيير ملكية القيم المُعادة عند الإرجاع، وبالتالي تسلسلها في النتائج عند العودة إلى الموقع الأصلي. ^{[ 15 ]}

كانت الفئات الفرعية تُعرف باسم "النكهات" ؛ فئة PieBuyer المذكورة أعلاه هي إحدى نكهات فئة Agent. كما تضمنت لغة Telescript مفهوم فئات المزج ، التي قدمت ميزات مشابهة للوراثة المتعددة من خلال السماح بإنشاء فئات تحتوي فقط على التعليمات البرمجية التي يمكن تضمينها لاحقًا في فئات أخرى. لم تكن فئات المزج من النكهات. ^{[ 16 ]}

على غرار العديد من لغات البرمجة الكائنية الحديثة، فصلت لغة Telescript بين الواجهة والتنفيذ، حيث وضعت كل منهما في .iملف منفصل (ملف الواجهة، وملفات .tالتنفيذ، كما في "t"elescript). وبشكل غير معتاد، عرّفت اللغة أيضًا نوعًا ثالثًا من الملفات، .dيجمع عدة .iملفات معًا. ^{[ 17 ]} كان الكود المُجمّع يُوضع في .sملف، ويتم توجيهه بواسطة تعليمات الرابط في .lملف آخر. ^{[ 18 ]} سمح إطار عمل التطبيقات الخارجية باستدعاء كود C++ بواسطة Telescript. ^{[ 19 ]}