Typescript: فصول جزئية

أعتقد أنك تستخدم "جزئيًا" في الوحدات أيضًا وتساعد في حل هذه المشكلة المثارة هنا.

https://github.com/Microsoft/TypeScript/issues/447

disshishkov ربما تكون طرق التمديد كافية: # 9

ما نوع المواقف التي تريد استخدام هذا من أجلها ، وكيف تقصر الحلول الحالية عن ذلك؟

لاحظ أن هذا تم تنفيذه في C # لدعم سيناريوهات التحرير من نوع WinForms حيث يكون لديك ملف تم إنشاؤه تلقائيًا وملف محرر بواسطة المستخدم يساهم في نفس النوع ؛ لست متأكدًا من تطبيق هذا النوع من المواقف في JavaScript / TypeScript.

يمكن أن تحتوي بعض الفئات على العديد من أرقام الأسطر ، فقط من أجل قراءة أفضل ، سيساعد التقسيم إلى عدة فئات منفصلة. يمكنك التقسيم حسب نوع مختلف ، على سبيل المثال عن طريق المنطق (في حالة عدم إمكانية نقل هذا المنطق إلى فئة أخرى) ، من خلال الرؤية (الخاصة والعامة) وغيرها. في حالة وجود مشاكل عند تمشيط الفئات الجزئية (على سبيل المثال ، فئتان جزئيتان بنفس الطريقة / إعلان المتغير) يجب على المترجم أن يخطر ويرمي الخطأ.

هذا ليس مقنعًا حقًا. إذا كان فصلك كبيرًا جدًا ، فلا يمكن تحريره بشكل مريح في ملف واحد نظرًا لحجمه الهائل ، فهذه رائحة تصميم كبيرة جدًا (على سبيل المثال ، التعليقات في http://programmers.stackexchange.com/questions/157482). التقسيم حسب نوع مختلف / منطق / رؤية / إلخ شيء يمكن معالجته بواسطة IDE أو بواسطة منظمة داخل ملف واحد.

من الجدير مناقشة سبب كون الفصول الدراسية كبيرة جدًا بحيث لا يمكن التنقل فيها (هل يرجع ذلك إلى أن أدوات التنقل يجب أن تكون أفضل؟) ، وإذا كانت هناك طرق أفضل يمكن للغة أن تدعم _تفكيك_ فصل دراسي بدلاً من _تقسيمه_ فقط.

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

حالة استخدام للفئات الجزئية لفئات الوكيل المُنشأة. على سبيل المثال أغلفة WebAPI أو SignalR. سيكون من الجيد حقًا أن تكون قادرًا على توسيع فئات الوكيل التي تم إنشاؤها باستخدام منطق مخصص. خاصة عند إنشاء فئات للنماذج ، سيكون من الجيد أن تكون قادرًا على إرفاق منطق الأعمال مباشرة بفئات النموذج التي يتم إرجاعها من واجهة برمجة التطبيقات.

+1 كوانتيتور.

حالة الاستخدام هي نفسها تمامًا. يتم إنشاء جزء من الفصل الدراسي (في حالتنا ، من مخططات Avro) وتريد إضافة رمز مساعد إضافي للعمل مع الفئات التي تم إنشاؤها.

أنا أحب هذا الاقتراح. أرغب في الحصول على فئات جزئية من أجل فصل سمات / خصائص الفئات التي تشكل "التسلسل الهرمي للبيانات" الخاص بي والذي يمكن تجميعه في ملف واحد ، عن طرقها التي يمكن تقسيمها إلى عدة ملفات أخرى. سيجعل الكود أكثر وضوحًا وأسهل للفهم في لمحة واحدة.

ملف التسلسل الهرمي للبيانات الخاصة بي :

class A {
  x: number;
  y: number;
  z: number;
}

class B extends A {
  value: string;
  flag1: boolean;
  flag2: boolean;
}

ملف يحتوي على طرق من الفئة أ :

class A {
  constructor(x: number, y: number, z: number) {
    this.x = x;
    this.y = y;
    this.z = z;
  }
  method1(...) { ... }
  ...
  methodN(...) { ... }
}

ملف يحتوي على طرق من الفئة ب :

class B extends A {
  constructor(x: number, y: number, z: number, value: string) {
    super(x, y, z);
    this.value = value;
    this.flag1 = false;
    this.flag2 = false;
  }
  method1(...) { ... }
  ...
  methodN(...) { ... }
}

+1 مني. أرغب في استخدام قوالب tt لإنشاء فئات Typescript ، ولكن أضفها في ملف منفصل لن يتم استبداله بإنشاء القالب.

+1 سيساعدني هذا حقًا في الفصول التي تم إنشاؤها تلقائيًا والتي أحتاج إلى تمديدها

الفصل الجزئي لطيف حقًا ولكن ليس من المنطقي الحصول عليه. لقد أظهر أن لديك مشكلة في التصميم. تتمثل القاعدة الأساسية في البرمجة في إبقائها بسيطة غبية (KISS) ، بغض النظر عن اللغات التي تستخدمها ، هي تقسيم فئة كبيرة إلى فئات أصغر - إما عن طريق 1) تقسيم البرامج النصية إلى فئات واستدعاءها (يمكن للفئات الأخرى أيضًا استدعاء ذلك فئات أصغر أيضًا بدلاً من إعادة اختراع العجلة) ، أو 2) تفكك وتحويلها إلى Abstract / Interface / Inheritance / Virtual وما إلى ذلك أو تعدد الأشكال.

لنفترض أن لديك سيارة بها كل شيء. الفصل الجزئي ليس له معنى وهو يقدم التعقيد والنفقات هنا حيث يكون من المنطقي القيام بذلك بدلاً من ذلك. قم بإنشاء فئة المحرك ، وفئة Tranny ، وفئة Drivetrain ، وفئة الباب ، وفئة الإطارات كفئات منفصلة ونقل البرامج النصية إليها ، والتي عند استدعائها ، لا يزال بإمكانها تحديد مركبة داخل فئة السيارة. يقلل من النصوص الطويلة وتعقيد النص. من المحتمل أن تجد أن لديك نصوص الباب هنا وهناك والتي يمكن تبسيطها من خلال فصل الباب. يمكن استخدام Interface / Abstract / Inheritance / Virtual لتغيير تعريف فئة الباب في بعض البرامج النصية في فئة السيارة.

من المرجح أيضًا أن يكون لديك وقت أقل تطورًا بهذه الطريقة. كان لدي مدونة ASP.NET C # التي تستخدم الكثير من الفصول الدراسية الجزئية. لقد كافحت معها بسبب وجود عدد كبير جدًا من الفصول الجزئية ولا تعرف مكانها. إنه نوع من التعامل مع منطق GOTO في البرمجة. سيئة سيئة !! لم أتمكن أبدًا من إنشاء تصحيح لإصلاح الأخطاء بنجاح ، ولم أتمكن من تخصيص البرنامج النصي لأنه كان مدفونًا جدًا في كومة من الفئات الجزئية (وكذلك فعلت بعض الصيغ التي أعيدت تسميتها).

فقط أقولها على أنها سنت واحد من رأيي.

@ fletchsod-developer: يتم التعامل مع بعض المواقف بشكل صحيح عن طريق الوراثة ، ولكن ليس كلها. وقد يسيء بعض المطورين استخدام الفئات الجزئية ، ولكن ليس جميعها. هناك بعض المواقف التي أجد فيها الفصول الجزئية مفيدة جدًا ، ولكن إذا لم تعجبك ، فلن تضطر إلى استخدامها.

@ jfrank14 ، كما هو مقترح أعلاه من قبل basarat هل # 9 لن يعمل من أجلك؟

// File1.ts
class Dog { 
 ...
}

// File2.ts
extends class Dog {
  woof() { /* ... */ }
}

NoelAbrahams ، هل ستتمكن من الوصول إلى التعريفات من file1 في الملف ولكن ليس العكس؟ هذا جيد بالنسبة لي طالما أنه مستقل عن أمر التضمين.

آمل حقًا أن تفكروا في الفصول الجزئية على أنها la C # لـ TS ... السبب الوحيد بالنسبة لي هو إنشاء الكود ، وهو السبب الرئيسي وراء فئات C # الجزئية ... نحن نقوم حاليًا بالكثير من إنشاء أكواد TS ، ونحن نتوقع أن نقوم بالمزيد والمزيد ... حاليًا علينا الاعتماد على "//

+1 - يمكن حقًا استخدام هذا لإضافة وظائف إلى الفئات التي يتم إنشاؤها تلقائيًا ؛ لا يوجد حل أنيق آخر يمكنني التفكير فيه أو قرأت عنه حتى الآن ...

+1 - الفئات التي تم إنشاؤها بواسطة التعليمات البرمجية. C # / كائنات Java متسلسلة للعميل

تحتاج هذا أيضًا لدمج الفئات التي تم إنشاؤها!

قد تكون هذه ميزة مفيدة للغاية للسماح بدمج بسيط للكود الذي تم إنشاؤه مع التعليمات البرمجية التي لم يتم إنشاؤها.

+1

+1 - نحتاجها أيضًا للفئات التي تم إنشاؤها جزئيًا ، وستكون أكثر أناقة من الميراث الذي يصدر قدرًا كبيرًا من التعليمات البرمجية التي ليست ضرورية لهذا الغرض.

+1

ركض في هذا القيد مرة أخرى - الرجاء إضافة هذه الميزة! : +1:

+1

+1

+1

+1

الأشخاص بشكل عشوائي +1 لن يؤدي هذا إلى المضي قدمًا.

حالات الاستخدام حتى الآن هي:

• لدي بالفعل فصول كبيرة تمتد على ملفات متعددة. أشار RyanCavanaugh إلى أنه من المحتمل أن تكون مشكلة تصميم رئيسية مع التعليمات البرمجية بهذا التعقيد وليست كافية لتبرير تعقيد التنفيذ.
• مثلهم.
• حجة أخرى يبدو أن C # لديها لهم.
• الحجة الأخرى تدور حول رمز تم إنشاؤه من لغات أخرى.

حالة الاستخدام الثانية والثالثة ليست مقنعة والرابعة ، أظن أنها تحتاج إلى مستوى معين من شرح كيف أن التسليم رقم 9 لن يلبي متطلبات مشابهة جدًا وحتى الديكور (# 2249).

يبدو أن رقم 9 سيحقق نفس الشيء ويكون أكثر عمومية (لأنه يمكنك توسيع فصول أخرى غير الخاصة بك). ولكن قد يكون من المعقول أن ترغب في الحصول على محتوى فئة في ملفين (ربما لأن أحدهما مكتوب بخط اليد والآخر تم إنشاؤه بواسطة قالب) ، وأن نقول إن كلا الملفين يحددان الأعضاء الأساسيين للفصل بنفس الأهمية ، ولا يتطلب ذلك أحدهما ملف "تمديد" فئة تعريف في الآخر.

إنه اختلاف وجودي تقريبًا ، ولكن ربما يكون مهمًا لبعض الأشخاص في بعض المواقف.

لا أريد جزئيًا في الفصول الدراسية لأسباب مذكورة ، ولكن في الوحدات النمطية يكون من المنطقي IMHO.

https://github.com/Microsoft/TypeScript/issues/447

تعتبر الفصول الجزئية مفيدة للغاية لتخصص حالات الاستخدام. إنه ليس انتهاكًا لأي نمط OOP ولكنه طريقة لترتيب مستند التعليمات البرمجية ، والذي يوفر:

1. القدرة على تقسيم تعريف الفئة / النوع في ملفات متعددة. بالنسبة لملفات التعليمات البرمجية الضخمة ، فهي ميزة الصيانة ++.
2. فرصة للمترجم / نظام البناء للاستفادة من الارتباط الشرطي في وقت الترجمة. التشابه MSBuild ، حالة استخدام ملموسة في C #: DBML ، فئات المصممين والمزيد من الأشياء الفاخرة مثل https://github.com/dotnet/corefx/pull/2045/files.
3. حماية متأصلة ، لذلك لا يلتقي مطوران (أو أكثر) ببعضهما البعض أثناء التحقق من التعليمات البرمجية. حل النزاع ينفجر! :)
4. تتيح لك إنشاء رمز في الفصل الجزئي الرئيسي ، ثم إنشاء جزء آخر للحمل الزائد المخصص. يعمل بشكل مثالي!

أؤمن بفصل منطق الأعمال وطبقات البيانات إلى فئات منفصلة وأستخدم في الغالب طرقًا ثابتة في هذه الطبقات. لا أرى حقًا كيف يمكن أن يكون رمزًا أكثر وأقل قابلية للصيانة.

في حين أن طريقة الامتداد هي ميزة لغوية أساسية تتأثر بأنماط OO وستتم معالجتها في وقت الترجمة ، تتعامل الفصول الجزئية مع تخطيط المستند / الكود ليتم تثبيته في مرحلة ما قبل التجميع. على الرغم من أوجه التشابه في الفئات الجزئية والفئات المجردة وطرق الإرشاد ، إلا أن هناك تمييزًا واضحًا.

: +1: لجلب "الفئات الجزئية" غير الضارة إلى TypeScript.

حالة استخدامي للفئات الجزئية هي لإنشاء رمز - يحتاج فريقي إلى أن يكون قادرًا على إنشاء جزء من الفصل تلقائيًا في ملف واحد وإضافة أساليب وخصائص مخصصة يدويًا في ملف آخر. أنا في حيرة من أمري لماذا

لا يحل المصممون ولا طرق التمديد مشكلة إنشاء الكود بأناقة مثل الفئات الجزئية ، ولكل منها تعقيدات إضافية كبيرة.

+1

+1

+1 لأغراض إنشاء الكود.

في بيئة C # ، سيؤدي دمج مترجم لفئات C # إلى فئات TypeScript إلى إزالة الحاجة إلى الاحتفاظ بتعريفين مختلفين للفئات بين الخادم وجانب العميل حيث سيتم إنشاء جانب العميل ، المعروف أيضًا باسم فئة TypeScript ، والفئة الجزئية الذي تطلبه هذه المشكلة سيسمح بالتخصيص عند الحاجة مع الاستمرار في التطوير في TypeScript الأصلي.

+1 لسيناريوهات إنشاء الكود

1+ مفيد للغاية لإنشاء الكود

لماذا لا تستخدم الوراثة لتوليد الكود؟

الميراث هو أكثر فوضوية ولها المزيد من النفقات العامة.

في يوم الاثنين ، 10 أغسطس 2015 ، الساعة 10:09 صباحًا ، كتب Gorgi Kosev [email protected] :

لماذا لا تستخدم الوراثة لتوليد الكود؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/563#issuecomment -129468291
.

الميراث يخلق اقتران اسم عديم الفائدة

الوراثة أقل روعة لأنها:

1. يعمق سلسلة النموذج الأولي دون داع ويبطئ إنشاء مثيل لها ،
   على الرغم من أن هذه ليست مشكلة كبيرة بالنسبة لمعظم التطبيقات ، فمن المحتمل أن يكون كل شيء باستثناء الألعاب ؛
2. بسبب الافتقار إلى التجريد والتجاوز إما يفقد نوعًا ما من الأمان أو
   يقدم الحاجة إلى بعض أنماط ackward مثل الصب بين الاثنين
   أنواع.
3. مربك بشكل عام لأن وجود فئة أساسية يوصل الفكرة
   يمكن تمديده بواسطة فئات أخرى ، وهو ما نادرًا ما يحدث مع codegen

لا نقول إن النص المطبوع عليه يحتوي على فئات جزئية لدعم codegen ، فقط
أن الطبقات الجزئية أفضل بكثير في ذلك من الميراث أو
تكوين.

JoshMcCullough Inheritance

@ yahiko00 ما هو نوع "اقتران الاسم غير المجدي" الذي نتحدث عنه هنا؟ هل تشير إلى الأشياء التي تحتاج إلى القيام بها للحصول على رقم 2 أدناه (ترميز اسم الفصل الموسع)؟

تضمين التغريدة

1. هناك بعض النفقات العامة ، لكنها قليلة جدًا - يمكن ملاحظتها فقط إذا كنت تقوم بأشياء تترجم مباشرة إلى بضعة تعليمات للآلة
2. نقطة جيدة - لا تحصل على الفئة الموسعة عندما يتعين عليك الرجوع إلى الفئة التي تم إنشاؤها من الفئات الأخرى التي تم إنشاؤها.
3. من المفترض بالفعل أن يتم توسيع هذه الفئات - وإلا يمكنك إنشاءها والانتهاء من ذلك ، أليس كذلك؟

AFAIK هذا ليس على رادار ES7 + ، أليس كذلك؟ قد يكون ذلك مشكلة ...

على أي حال ، فإن إرفاق أشياء إضافية بالنموذج الأولي لفئة موجودة أمر بسيط للغاية في JavaScript وليس نادرًا على الإطلاق ، لذلك قد يكون من الجيد أن يكون لديك بناء جملة لذلك ...

إنه أمر واضح في TS لكن JS وراء الكواليس سيضاعف
"protoyping" إذا كنت تستخدم الفئات الأساسية لجميع البيانات التي تم إنشاؤها
أشياء. ربما ليس له تأثير خطير على الأداء ما لم يكن لديك الكثير من
كائنات البيانات ، لكنها لا تزال غير ضرورية عندما نعلم أن "جزئية
الطبقات "ممكنة.

يوم الاثنين 10 أغسطس 2015 الساعة 11:03 صباحًا Gorgi Kosev [email protected]
كتب:

JoshMcCullough https://github.com/JoshMcCullough الميراث النفقات العامة
في JS هو الحد الأدنى ، ولا أرى كيف أنه أكثر فوضوية من الفئات الجزئية:
مع هؤلاء ، يمكنك تقسيم الفصل إلى 10 ملفات ومطاردة ملفات
طرق في كل مكان.

@ yahiko00 https://github.com/yahiko00 ما نوع "الاسم عديم الفائدة
اقتران "نتحدث عنه هنا؟ هل تشير إلى الأشياء التي تحتاجها
يجب القيام به للحصول على رقم 2 أدناه (الكود الثابت لاسم الفئة الموسعة)؟

يمتد الفصل MyClass GeneratedMyClass {...}

hdachev https://github.com/hdachev

1.

هناك بعض النفقات العامة ، لكنها ضئيلة للغاية
https://jsperf.com/prototype-chain-vs-direct-calls - ملحوظة فقط
إذا كنت تقوم بأشياء تترجم مباشرة إلى جهازين
تعليمات
2.

نقطة جيدة - لا تحصل على الفصل الموسع عندما تضطر إلى ذلك
الإشارة إلى الفئة المُنشأة من الفئات المُنشأة الأخرى.
3.

من المفترض بالفعل أن يتم تمديد هذه الفئات - وإلا يمكنك ذلك
قم بتوليدها والانتهاء من ذلك ، أليس كذلك؟

AFAIK هذا ليس على رادار ES7 + ، أليس كذلك؟

في أي حال ، إرفاق أشياء إضافية بالنموذج الأولي للفصل الحالي
يعد أمرًا تافهًا تمامًا في JavaScript وليس نادرًا على الإطلاق ، لذلك قد يكون ملف
فكرة جيدة أن يكون لديك بناء جملة لذلك ...

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/563#issuecomment -129483174
.

@ Davidhanson90 هذا الملف يحتوي على صفر فئات فيه. هل تقصد أن تنشر هذا في موضوع مختلف؟

سوف أنشر على الموضوع الصحيح. https://github.com/Microsoft/TypeScript/issues/447

+1

+1

+100

+1

+1

+1 لتوليد الكود.
لقد بدأت في استخدام angularjs و webapi وأريد إنشاء أداة تقوم بشكل أساسي بإنشاء تعريفات JS تلقائية من كائنات وخدمات c # الخاصة بي. أريد بعد ذلك أن أكون قادرًا على تمديد هذه الفئات دون الحاجة إلى تحرير تعريفات JS "سقالة". لقد رأيت أن بعض الأشخاص الآخرين يطلبون ذلك ويبدو أن لدينا حالات استخدام مماثلة.

+1 لتوليد الكود

+1 لإنشاء الكود ، يحتوي angular على الكثير من الشفرات المعيارية ، ونحن بالفعل نقوم بإنشائه كثيرًا ، ولكن مع الفئات الجزئية ، سنكون قادرين على فعل المزيد.

+1 مرة أخرى لإنشاء الكود. محاولة توسيع الفصول في ملف آخر أمر غير منظم في أحسن الأحوال.

RyanCavanaugh ، ما المطلوب لإخراج هذا من وضع "+1" والتحرك في اتجاه إنتاجي؟

-1 تعتبر الصيغة التالية أفضل للمزيجات: # 2919

لست متأكدا لماذا لا يمكننا الحصول على كل من الفئات الجزئية والخلطات ؛ سمتان غير مرتبطتين تمامًا.

+1

سيكون هذا أمرًا رائعًا عند إنشاء الكود ، لكنك لا تريد تعديله لإضافة أشياء إلى الكود الذي تم إنشاؤه.

+1

لدي اقتراح يجب أن يلبي كلا من حالات الاستخدام هذه:

1. تريد أن تكتب طرقًا خاصة بفصلك في أماكن مختلفة.
2. تريد إضافة طرق جديدة إلى فئة شخص آخر ، على سبيل المثال مدمج.

بالنسبة إلى (2) ، عادةً ما تستخدم عامل التشغيل :: للحصول على بنية infix.

ولكن إذا كنت تريد أن تكون فئة قديمة جزءًا من واجهة جديدة ، أو إذا كنت تريد الإرسال ديناميكيًا ، فستحتاج إلى تعديل النموذج الأولي بالفعل.

interface ITimes {
    times(n: number): number
}

Array implements ITimes {
    times(n: number): number {
        return this.length * n
    }
}

// The compiler should check that all methods of ITimes and IOther are implemented.
Number implements ITimes, IOther {
    times(n: number): number {
        return this * n
    }

    other(): void {}
}

// The old types should typecheck with the new interface.
const x: ITimes = true ? [] : 0
x.times(3)

// The interface list can be empty. This essentially gives you partial classes.
MyClass implements {
    anotherMethod(): void {}
}

(في المثال ، أستخدم أسماء طرق السلسلة ، ولكن نظرًا لأن هذه أنواع مضمنة ، فسيكون استخدام الرموز أفضل بمجرد التحقق من هذه الأنواع.)

إن التحسن الذي حدث في هذا عن الفئات الجزئية الحقيقية هو أن للفصل تعريف واحد ، والأماكن الأخرى تقوم فقط بتوسيعه. هذا يعني أن هناك مكانًا واضحًا لاستيراد الفصل منه ويجعل الترجمة إلى JS أسهل.

: +1: أحب أن أرى دروسًا جزئية أيضًا.

ما هي حالة هذه الميزة؟

حالة الاستخدام هذه على سبيل المثال:

لدي حزمة Math تحدد فئة Set ، بالطرق Set#add ، 'Set # remove'

// math.ts
export partial class Set {
  add(){}
  remove(){}
}

لدي حزمة اختيارية ، ثقيلة ، Relational تحدد الفئات Relation و Tuple .

هذا Relational أن حزمة أيضا إضافة Set#product الأسلوب.

// relational.ts
///<reference path="./../math/tsd.d.ts"/>
partial class Set {
  product(){}
}

export class Relation(){}
export class Tuple(){}

تسمح لي الفصول الجزئية بتكوين فصول بطريقة أكثر مرونة. إذا كنت لا أرغب في استخدام الحزمة الثقيلة relational ، فلا يزال بإمكاني استخدام وظيفة المجموعة الأساسية. ستأتي فصول أخرى partial وتضيف وظائف إضافية إلى الفصل.

أنا أخدش رأسي للقيام بشيء سيكون له واجهة برمجة تطبيقات لطيفة دون استخدام الأجزاء في هذه الحالة.

كل ما يمكنني الحصول عليه هو نمط المستودع.

// Without partials

// base

export class Base {
    static registerOperation(opName, method){
        this.prototype[opName] = method;
    }
    operation(name, ...args){
        return this[name].apply(this, args);
    }
}

// math.ts
import {Base} from './base';
class Set extends Base{
    // Define the methods here
    add(){}
    remove(){}
}

// Or here
Set.registerOperation("add", function(...){});
Set.registerOperation("remove", function(...){});

// relational.ts
import {Set} from './../math/math';

Set.registerOperation("product", function(...){});

// app.ts

import {Set} from 'math';

var set = new Set();
set.add // compiler error
set.remove // compiler error
set.product // compiler error

// have to use something like
set.operation("add", args);
// or
(<any>set).add(arg);

+1 أستخدم t4 لإنشاء فئات ووكلاء عبر WebApi. أعتقد أن التوليد التلقائي يستخدم بشكل كبير في الكتابة المطبوعة وعندما يتعلق الأمر بالتوليد التلقائي ، فإن الفصول الجزئية ضرورية!

سيكون رائعًا لتقسيم جوانب نفس الفئة خاصةً في React
+1

إنشاء رمز +1 و "فصل كافٍ فقط" في حالة كائنات البيانات الخالصة القابلة لإعادة الاستخدام ذات السمات الخاصة بالعميل للتحقق من الصحة مثل التحقق الذي سيكون أنيقًا ليتم تعريفه في الفئة ولكن يتم الاحتفاظ به في جزء منفصل من الكود المصدري.

+1 لإنشاء الكود لفئات جزئية ورمز يدوي لأعضاء إضافيين لهذه الفئات في ملفات منفصلة.

+1

+1 لدي قاعدة كبيرة من الأساليب في خدمة js api الخاصة بنا ، سيكون من الأفضل تقسيمها إلى ملفات ، مما يجعل من السهل فهم كل طريقة.

خدمة api مثل fb (facebook) أو gq (google analytics) ، حيث يتم منحك فئة أو كائنًا عالميًا واحدًا ، يمكنك استخدامه خلال التطوير.

+1

ستكون هذه الميزة إضافة كبيرة لنا أيضًا.

قمنا بتطوير برمجية وسيطة حيث يمكن لجميع أنواع العملاء الاتصال بها والتواصل مع خوادمنا من خلالها.

نقوم بإنشاء بعض رموز العميل بناءً على ما تتعرض له الخوادم.

حتى الآن ، كان كل شيء على ما يرام. لكن الآن ، نود أن نكون قادرين على نقل مجموعات غير متجانسة من الكائنات (ولكن مع نفس الفئة الأساسية). الكائنات المنقولة هي جزء من الكود الذي تم إنشاؤه بناءً على واجهة برمجة تطبيقات الخادم.

لتكون قادرًا على استخدام قوة الوراثة ، فإن الطرق المجردة هي المفتاح في هذه الحالة. لكن المطورين لدينا لن يضيفوا طرقًا إلى الكود الذي تم إنشاؤه ، أفترض أن الجميع يعرف السبب ؛)

بقدر ما فهمت (أنا مطور C #) ، فإن الحل المقترح هنا (https://github.com/Microsoft/TypeScript/issues/9) لن يسمح لنا بالقيام بذلك.

لذا ، فإن الفصول الجزئية ستكون مثالية بالنسبة لنا. سننشئ الفصل على أنه جزئي ، وإذا احتاج المطورون إلى إضافة منطق أو طرق ، فسيتعين عليهم فقط كتابة جزء آخر أينما يريدون.

+1

1+ مفيد جدًا لإنشاء الكود

أتساءل عما إذا كانت زيادة الوحدات النمطية تلغي بشكل أساسي الحاجة إلى هذا كميزة محددة.

إذا كان لديك فصل تم إنشاؤه ، فيجب أن تكون قادرًا على القيام بشيء مثل ...

import {MyClass} from "./MyClass.generated"

MyClass.prototype.partialMethod1 = function() {
  return true;
}
MyClass.prototype.partialMethod2 = function(abc: string) {
  this.doSomething(abc);
}

declare module './MyClass.generated' {
  interface MyClass {
    partialMethod1(): boolean;
    partialMethod2(abc: string): void;
  }
}

disshishkov تبدو هذه طريقة جيدة لتنفيذه تحت الغلاف ، لكني ما زلت أرغب في الحصول على دعم مناسب من الدرجة الأولى في اللغة دون الحاجة إلى تعديل النماذج الأولية يدويًا والحفاظ على تلك الواجهة.

أنا أتفق مع Elephant-Vessel. يجب أن يكون الجزء المصنوع يدويًا من الفئة الجزئية مقترنًا بشكل فضفاض (في وقت التصميم في TS) قدر الإمكان من الجزء الذي تم إنشاؤه.

يعمل اقتراح @ david-driscoll مع العديد من الحالات. ومع ذلك ، بقدر ما أستطيع أن أقول ، لا يمكن للنماذج الأولية الوصول إلى المتغيرات الداخلية. يحد هذا من فائدة هذا الأسلوب في سياقات إنشاء التعليمات البرمجية حيث تريد إنشاء الأجزاء الأساسية لفئاتك ثم زيادتها باستخدام تعليمات برمجية مخصصة.

+1

@ david-driscoll يبدو أنه طريقة ممتازة لإلغاء تحديد هذه الميزة. (سيحتاج إلى إضافة القدرة على الوصول إلى الممتلكات الخاصة / المحمية). أتساءل ماذا سيحدث مع إعلان الفصل الجزئي المتعدد؟ ماذا ستكون الرؤية المتبادلة لهؤلاء؟

++ 1 عدم وجود جزء جزئي يؤذيني حقًا عند محاولة تمديد النماذج التي تم إنشاؤها تلقائيًا ..

أعتقد أن الشيء الوحيد في النطاق هنا هو أساسًا ما اقترحه @ david-driscoll - يمكنك الإعلان عن طرق جديدة (سيتم وضعها في النموذج الأولي) وخصائص جديدة غير مُهيأة (لا تحتوي على كودجين) ، ولكن ليس خصائص مُهيأة جديدة (لأن هذه لها آثار جانبية على كود الباني).

التصويت المعزول ، عفواً ، فصول اللغة الفرنسية الجزئية هي محاولة غبية لتقسيم فئات الإله الخاصة بك ، والتي لا مفر منها في OOP ، إلى ملفات متعددة بحيث يسهل إدارتها (على الرغم من أنها لا تزال فئات إلهية)

مع OOP لا يوجد مستقبل لك أيها الناس (كنت هناك ، أعرف ما أتحدث عنه)

تعال إلى FP ، لدينا ملفات تعريف الارتباط وطريقة لكتابة برنامج بدون فئة واحدة و ** ر مثل هذا

لذلك نحن بالفعل نسمح بهذا بشكل أساسي على أي حال من خلال interface A { method(): void } A.prototype.method = function() { }; ؛ تدوين هذا في سكر لأن هذا منطقي تمامًا.

شيء واحد لركوب الدراجة هو الكلمة الرئيسية partial . نبذة تاريخية موجزة: في C # ، كان partial class في الأصل هو extension class (الذي وضعته في جميع الإعلانات باستثناء إعلان واحد) ، ولكن لم يكن هناك تمييز واضح حول الإعلانات التي ستكون extension وأي إعلان سيكون إعلان عدم التمديد. بدلاً من ذلك ، لديك المُعدِّل partial الذي يجب أن تضعه على _all_ الفئات.

هذه _not_ الحالة في TypeScript؛ بل العكس. هنا ، فئة واحدة فقط (دعنا نسميها "إعلان _ أولي_") قد تحتوي على منشئات / حقول عضو مهيأة ؛ الإعلان الأساسي لا يحصل على أي معدل جديد. قد يحتوي كل إعلان آخر (دعنا نسميها "_إعلانات التمديد") على إحصائيات وطرق وحقول غير مهيأة فقط ، وستحتاج إلى أن يكون لديك بعض التعديل عليها للإشارة إلى أنها ليست أساسية.

أفضل تخمين الحالي هو

class Foo {
  x = 6; // only legal to initialize here
  constructor() { } // only legal to have constructor here
  someMethod() { }
}

// vvvvvvvvv thoughts?
   extension class Foo {
     someOtherMethod() {
     }
   }

: بريق:: دراجة:: منزل:: بريق:

سواء كنت ترتدي الدراجات أم لا ، فإن هذا يبدو فظيعًا مثل رقم 311 الذي تم إبعاده بسبب التداخل المحتمل مع معايير ECMAScript المستقبلية. لماذا يستحق هذا التفكير ، لكن دعم mixin المناسب ليس كذلك؟

استخدام الكلمة الأساسية extension يتعارض مع طرق الامتداد ؟ أم أن هذا سيؤدي إلى إبطال طرق الامتداد تمامًا؟

kitsonk أعتقد أن اقتراح mixin به الكثير من الأسئلة المفتوحة. اقتراح الفصل الجزئي هنا هو مجرد تدوين للأشياء المسموح بها بالفعل في TypeScript ، فقط مع بعض السكر النحوي (يمكن فعل هذه الميزة حرفيًا كإعادة تخطيط نحوي للأشياء التي لدينا بالفعل).

@ Elephant-Vessel لا أعتقد أن طرق التمديد تحدث إذا حدثت فصول جزئية. الفصول هي المكان الوحيد الذي تكون فيه طرق الامتداد منطقية بالنظر إلى قيودنا ، وعامل الربط المقترح ES7 + هو أفضل طريقة للارتداء في بناء جملة يشبه الامتداد.

RyanCavanaugh : بالنسبة لي ، يبدو أنه من المقيد بعض الشيء أن الصفين أساسيًا بينما لا يكون الآخرون كذلك. إذا كنت تريد تقسيم الكود الخاص بك بحيث يحتوي ملف واحد على جميع وظائف فئة والآخر يحتوي على جميع الخصائص ، فلا يبدو أي منهما أساسيًا بشكل أكثر وضوحًا ، ولماذا يجب عليك الاختيار؟ أليس من الأنظف أن يكون لديك أجزاء جزئية حيث تكون جميعها متساوية في الأهمية ، ويتم دمجها بواسطة المترجم؟

RyanCavanaugh ... سأفعل ذلك تمامًا بنفس الطريقة التي يعمل بها c # ... إنه يعمل بشكل رائع لإنشاء الكود ... والذي أعتقد أنه كان المشكلة الأساسية التي تهدف الميزة إلى حلها في c # ... على الرغم من أن ذاكرتي غير واضحة ... لم يكن لديه أي مشاكل ، لقد كان موجودًا منذ سنوات ، وتم اختباره في المعركة ...

إذا لم تتمكن الفصول الجزئية / الممتدة من الحصول على حقول مهيأة ، أعتقد أنه سيكون من الأفضل دعم شيء مثل الأساليب الجزئية التي نعرفها من C # ، وهو عقد خفيف الوزن مخصص للفئات الجزئية. لذلك مثل:

public partial class MyGeneratedClass
 {
     partial void Initialize();
     public constructor()
     {
          //...
         this.Initialize();
    }
 }

 public partial class MyGeneratedClass
 {
     partial void Initialize()  { //... }
 }

يمكن حل الحاجة إلى القدرة على تجزئة / توسيع فئات الجهات الخارجية بسهولة تامة (؟) من خلال جعل partial/extends اختياريًا بشكل عام ولكنه مطلوب لاستخدام الأساليب الجزئية.

أعتقد أن هذا يمكن أن يجلب بعض القوة التعبيرية والتشغيلية للمفهوم الذي نريده هنا.

أولئك الذين يبحثون عن الخلطات.

ضع في اعتبارك أن الكائن يقوم بتهيئة الاقتراح بواسطته (وتحليل التدفق) يمكن إجراء الخلطات بأناقة ، وبطبيعة الحال ، بشكل اصطلاحي بقدر ما تذهب JavaScript:

function enableBeingPositioned<a>(
   // hypothetical syntax
   something: a /* <-- before type */ => a & { x: number; y: number; } /* <-- after type */
): void { 
   something.x = 0;
   something.y = 0;
}
let value = {};
value.x; // <-- should not typecheck
enableBeingPositioned(value);
value.x; // <-- should typecheck

لا تقدم لغات مثل Java فصولًا / هياكل جزئية. إنها ميزة متخصصة لـ C #. إن تقليد مفاهيم C # "الفئة / البنية الجزئية" إلى أقصى حد هو أفضل طريقة للذهاب هنا.
في خطوة ما قبل التجميع ، فإن أول شيء يمكن أن يفعله مترجم TS هو خياطة كتل الكود الجزئية في الذاكرة ثم الانتقال إلى مسار خط أنابيب التجميع العادي. سيكون هذا أكثر من كافٍ للتأهل لميزة الفئات الجزئية v1.0.0-preview1.0000 في TypeScript.
أي شيء يتجاوز ما تقدمه C # هو شيء يمكن تقديمه في الإصدارات الأحدث عندما تتطور الميزة وتتجاوز فترة الإصدار التجريبي / المعاينة الخاصة بها. يمكن مناقشة حالات الركن والنوع المماثل من الأشياء الغامضة بشكل منفصل واحدًا تلو الآخر ويمكننا القلق بشأن الملاءمة والانتهاء لاحقًا ... IMO.

أوافق أيضًا على القيام بكل من الفصول الجزئية والإضافية بالطريقة نفسها c #
هل هي أفضل طريقة للذهاب من حيث النحو والدلالات ، وكلاهما يعمل
بشكل جيد للغاية لحالات الاستخدام الخاصة بهم. الفصول الجزئية تعمل على تحسين
سهولة استخدام الكود الذي تم إنشاؤه. تعمل طرق الامتداد على تحسين قابلية الاستخدام
من الأساليب الثابتة التي تعمل على واجهات ، والأدوية المحددة والثالثة
أنواع الحفلات. كلاهما رائع حقًا ، لكن من فضلك تذكر أنهما ليسا
نفس الميزة ، أنا أقول هذا هنا بسبب بناء الجملة المقترح أعلاه.

تسمح طرق الامتداد للمرء بالقيام بذلك (نأسف لعدم وجود تنسيق ،
الكتابة على الهاتف):

تمديد MyType [] {
somethingSpecificToMyType () {...}
}

تمديد WeirdThirdPartyDatastructure{
كذلك هنا() { ... }
}

هذا من بين أشياء أخرى مثل القدرة على استخدام libs مثل الشرطة السفلية
بدون الخسارة ، وهو ما يعني في الأساس جني الفوائد النحوية لـ
توسيع الأنواع المضمنة دون تلويثها فعليًا.

موجز جدًا - دعنا لا نتعامل مع الاثنين على أنهما واحد ، فهما متشابهان للغاية
رائع ولكن ليس نفس الشيء. أنا شخصيا أحب أن يكون لدينا كلاهما في
لغة.

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

• في المشاريع الحساسة للأداء ، مثل الألعاب ، حيث تفعل ذلك فقط
  كل شيء لتحقيق أقصى قدر من ميزانية وحدة المعالجة المركزية الخاصة بك مع العمل المفيد ، يساعد codegen كثيرًا
  لإنشاء رمز سهل التفكير فيه وقابل للتحسين
  / monomorphic code الذي يعمل بشكل جيد حقًا. على سبيل المثال ، في ملف
  محرك لعبة الكيان / المكون ، يمكن أن تساعد التعليمات البرمجية التي تم إنشاؤها في الكثير من الأشياء
  مثل رمز معياري سريع جدًا لربط المكونات معًا ، حدث
  إيفاد ، إلخ.
• في تطبيقات الأعمال الكبيرة ، تساعد التعليمات البرمجية المُنشأة في الحصول على الكثير من الأميال
  نظام النوع ، على سبيل المثال عن طريق طرق الانبعاث ذات الدقة العالية
  التوقيعات لاستعلامات قاعدة البيانات ، وما إلى ذلك ، والتي تزيد من وقت التجميع
  الشيكات ، ويساعد طنًا في إعادة البناء ، كما أنه يبسط تصحيح الأخطاء بشكل كبير
  لأنه يسمح لك بالمرور عبر رمز تنسيق بسيط للغاية.
• الشيء الكبير هو عندما تحتفظ ببعض المكونات في المزامنة عبر
  بيئات متعددة اللغات ، مثل شيء متعلق بالرسائل
  مثل المخازن المؤقتة للبروتوكول ، أو واجهات رسائل json فقط ، إلخ.

كعقدة جانبية أخرى لصالح أي شخص يتساءل ما هي جزئية
الفئات لها علاقة بـ codegen ، وهي قيمة الاحتفاظ بالأجزاء المولدة
من فئة إلى ملف منفصل يأتي من متطلبات التحكم في المصدر -
عادة ما تكون الأشياء التي تم إنشاؤها أداة بناء سريعة التغير وأنت
لا تريد أن تلتزم في الريبو الخاص بك.

تعجبني فكرة تنفيذ هذا وفقًا لنموذج معروف ومُجرب لهذا المفهوم ، تمامًا مثل C #. "التقليد" له بعض الدلالات السلبية ، لكن له قيمة كبيرة إذا تم بذكاء. من ناحية أخرى ، فإن الجزء "الذكي" من ذلك هو إدراك الظروف والقيود المختلفة ، لذلك لن أعترض على ما إذا كانت الأجزاء الجزئية لـ TypeScript لا تبدو تمامًا مثل الأجزاء الجزئية لـ C #.

@ Elephant-Vessel ، أوافق على أنه لا يلزم أن يكون نسخة مماثلة من C # جزئيات ، يمكن وضع التصميم العام أولاً حول نكهة TypeScript / JavaScript مع أخذ أقصى قدر من الإلهام من C # parts. اقتراحي هو استخدام "تسجيل partial keyword" و "خياطة الأجزاء" كخطوة أولى ، وشحنها كميزة تجريبية / معاينة (حتى لا يبدأ المستهلك في الاعتماد عليها في رمز الإنتاج الصحيح قبالة الخفافيش). لاحقًا ، بناءً على استجابة المجتمع ، قم بتطوير الميزة حتى تصبح جاهزة للإنتاج و RTM. إذا كنا قلقين بشأن جميع أنواع المشاكل والسيناريوهات الصعبة قبل البدء ، فعلى الأرجح أنها ستؤخر الأمر أكثر.

+1 - لتوسيع وصيانة الكائنات المولدة.

+1 للمحافظة على الكود الذي تم إنشاؤه

لقد صنعت بوليفيل وقسمت صفي الكبير.

تحديد فئة كواجهة.

export class C {
  constructor() {
  }
}
export interface C {
  m(): void;
}

تنفيذ أعضاء الفصل.

export default class extends C {
  m(): void {
  }
}

دمج التطبيقات.

import {C} from './core';
import m from './member/m';

compose(C, m);
export {C}

import {assign} from './assign';
import {concat} from './concat';

export function compose<T extends new (...args: any[]) => any>(target: T, ...sources: T[]): T {
  return concat([target], sources)
    .reduce((b, d) => {
      void assign(b.prototype, d.prototype);
      for (const p in d) if (d.hasOwnProperty(p)) b[p] = d[p];
      return b;
    });
}

https://github.com/falsandtru/spica/commit/a6ff30da5319db5f25f703a29da48fc0f7dbe2fe

أعتقد أن هذه فكرة رهيبة لسبب واحد محدد: إنها ستجعل القواعد المعقدة بالفعل لمشكلات الوراثة التي تعتمد على أمر الإعلان العالمي ، والمحيط ، والخارجي ، والمتعلقة بالأسماء ، والهشة أكثر سوءًا. هذا ليس C # وتحليل الاسم وإعلانات الأعضاء مختلفة تمامًا.

ربما استخدم كائنًا أو مساحة اسم بدلاً من فئة ، مثل نمط الوحدة الكاشفة إذا كنت حقًا بحاجة إلى القيام بذلك. وإلا فإن فصلك ربما يكون كبيرًا جدًا.

كما يمكن استخدام المصممين لتنفيذ الارتباطات بين الكود المُنشأ والتعليمات البرمجية المكتوبة بخط اليد.

هل لديك حلول أخرى؟

أود أن أرى هذا مضافًا إلى TS أيضًا

+1 لأغراض إنشاء الكود (DTOs من مرجع خدمة WCF مع تعريفات فئة جزئية إضافية)

+1 لأغراض إنشاء الكود. حالة الاستخدام الخاصة بي هي: لدي مكونات React التي يتم إنشاء وظائفها render() خارجيًا عبر قوالب التفاعل .

باستخدام فئات partial يمكنني التحقق من هذه الوظائف مقابل الفئة الرئيسية ( Component ). بدون الفصول الجزئية ، الشيء الوحيد الذي يمكنني فعله هو ربط الوظيفة بالفصل الرئيسي والأمل في الأفضل.

مع الإصدار 2.0 من TS التالي ، كنت أفكر في إمكانية تغطية بعض حالات إنشاء الكود بميزة النوع this .

على سبيل المثال في الحالة التي وصفتها سابقًا ، بدلاً من

partial class MyComponent extends React.Component<any,any> {
    render() {
        ...
    }
}

أستطيع أن أكتب

function render<this extends MyComponent>()
        ...
}
MyComponent.prototype.render = render;

+1 بصفتي مطورًا ، أريد فئات جزئية بحيث يمكن للقوالب المتعددة إنشاء / تعديل نفس الفئة موزعة على ملفات متعددة.

كانت تعليقاتي على وجه التحديد فيما يتعلق بالفصول الجزئية ، وليس الخلطات. الاثنان مختلفان اختلافا جوهريا. تدور الفصول الجزئية حول تفكيك الكود المادي ، بينما تدور الخلطات حول تفكيك السلوك المنطقي إلى سمات قابلة لإعادة الاستخدام تثري الكائنات الأخرى على كل من النوع ومستوى القيمة.
لا أعتقد أن الفئات الجزئية فكرة جيدة لـ TypeScript. من ناحية أخرى ، تعد Mixins فكرة جيدة ، حيث توفر مزيدًا من التعبيرات والتشابك بشكل جيد للغاية مع كل من نظام كتابة TypeScript وتعبيرات JavaScript كما هو موضح بواسطة @ aleksey-bykov

wendellm هل يمكنك التفكير في طريقة نظيفة للقيام بذلك نظرًا لأن وحدات ES مادية. تعمل الفصول الجزئية بشكل جيد ولها معنى كبير في لغة مثل C # حيث تكون الوحدات النمطية منطقية وليست مادية. من وجهة نظر CLR ، مساحات الأسماء غير موجودة ، فقط أسماء الفئات يمكن أن تحتوي على نقاط فيها (مصدر مقابلة معahejlsberg)

+1 أحتاج فصل دراسي جزئي!

هل يمكننا تمديد الواجهة؟ يمكن أن تحتوي الواجهة أيضًا على بعض الوظائف المنفذة ، تمامًا مثل Swift:

interface Rect {
    x: number
    y: number
}

extension Rect {
    area() => this.x * this.y
}

نسخة سويفت:

protocol Rect {
    var x: Float {get}
    var y: Float {get}
}
extension Rect {
    func area() -> Float {
        return self.x * self.y
    }
}

+1

يسير إنشاء الكود والفصول الجزئية جنبًا إلى جنب.

الميراث هو حل ضعيف لما هو في الأساس توجيه مجيد #include .

خذ Angular 2 على سبيل المثال. لن يقرأ البيانات الوصفية من الفئة الأصلية ، مما يجعل الامتداد عن طريق الميراث غير عملي.

tsvetomir هذه مشكلة Angular وليست مشكلة TypeScript.

الميراث هو حل ضعيف لما هو في الأساس توجيه مجيد # include

نعم الميراث حل ضعيف ، لكن المشكلة هي استخدام الطبقات في المقام الأول. لديهم مكانهم لكنه محدود للغاية. تعتبر فئات JavaScript ضعيفة جدًا وغير معبرة مقارنة بالفصول في اللغات الأخرى.

الطباعية ليست لغة "زاويّة" ... لم تكن أبدًا

في 23 تموز (يوليو) 2016 ، الساعة 9:46 مساءً ، كتب ألوان حداد < [email protected] [email protected] >:

tsvet omirhttps: //github.com/tsvetomir هذه مشكلة Angular وليست مشكلة TypeScript.

الميراث هو حل ضعيف لما هو في الأساس توجيه مجيد # include

نعم الميراث حل ضعيف ، لكن المشكلة هي استخدام الطبقات في المقام الأول. لديهم مكانهم لكنه محدود للغاية. تعتبر فئات JavaScript ضعيفة جدًا وغير معبرة مقارنة بالفصول في اللغات الأخرى.

أنت تتلقى هذا لأنك علقت.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم tHubhttps: //github.com/Microsoft/TypeScript/issues/563#issuecomment -234753589 ، أو كتم القراءة التالية: //github.com/notifications/unsubscribe-auth/AJPCIh7n2_0dt00kw- XJv7tc9LB0tPsIks5qYtH4gaJpZM4CcixK.

لا أرى أن المشكلة خاصة بـ Angular بأي شكل من الأشكال. إنها حالة خاصة قد تكون فيها الفصول الجزئية قد ساعدت.

نشأ الطلب من التجربة السابقة مع C # وعدم وجود ميزات مألوفة. المقارنة لا مفر منها لأن TypeScript لا تبذل أي جهد لإبعاد نفسها عن .NET. يتوقع المستخدمون بعض أشكال تكافؤ الميزات.

نشأ الطلب من التجربة السابقة مع C # وعدم وجود ميزات مألوفة. المقارنة لا مفر منها لأن TypeScript لا تبذل أي جهد لإبعاد نفسها عن .NET. يتوقع المستخدمون بعض أشكال تكافؤ الميزات.

tsvetomir بصفتي مطور .NET لفترة طويلة ،

المقالة التي أشرت إليها ليست موثوقة ، ولا تعكس أي مادة رسمية من فريق TypeScript.

علاوة على ذلك ، فإنه يتعارض بشكل مباشر مع فلسفة تصميم TypeScript كما ذكر ahejlsberg في العديد من المحادثات والمقابلات

بالإضافة إلى ذلك ، تعكس وجهة نظر المقالة المستشهد بها سوء فهم أساسي لطبيعة TypeScript.
ومن المفارقات ، أن القواسم المشتركة بين C # مع TypeScript هي في الواقع نفس القواسم الموجودة مع JavaScript.
هذه القواسم المشتركة ليست برمجة قائمة على طبقية ، ولكنها بناءات مثل عمليات الإغلاق ووظائف الترتيب الأعلى.

C # أم لا ، نحتاج إلى فئات جزئية ستساعد TypeScript على الاقتراب من ميزات النموذج الأولي لـ Javascript.

@ yahiko00
يحتوي TypeScript بالفعل على جميع ميزات النموذج الأولي لـ JavaScript.
إنها مجموعة شاملة.

هناك العديد من المشكلات المتعلقة بمفهوم الفئات الجزئية في TypeScript ، بما في ذلك

1. على عكس C # ، تعد تعريفات فئة TypeScript (JavaScript) إلزامية وليست تعريفية. يبدو أنها تصريحية ، لكنها ليست كذلك. هذا يعني أنهم يعتمدون على أمر التنفيذ الحتمي.
2. يعتمد نظام وحدة ECMAScript على استيراد وحدات الشفرة المادية وليس المنطقية.
   على سبيل المثال ، دعنا نقول لدي

_app / my-class-part-1.ts_

TypeScript export partial class MyClass { firstName = "John"; lastName = "Smith"; }

و
_app / my-class-part-2.ts_

TypeScript export partial class MyClass { fullName = this.firstName + ' ' + this.lastName; }

كيف يمكنني استيراد هذه الفئة؟ نظرًا لأنه لا يمكنني الاستيراد من أي من الوحدات النمطية ، فلنتخيل تجريدًا افتراضيًا في TypeScript يسمح لي بالكتابة
_app / main.ts_

TypeScript import { MyClass } from './my-class';

ماذا يعني هذا؟ حتى إذا كان مترجم TypeScript يستنتج أنه يجب تحميل _app / my-class-part-1.ts_ قبل _app / my-class-part-2.ts_ ، فإنه لا يمكن أن يجعل استيراد الأجزاء الفردية غير صالح ولا يمكنه ضمان يتم استيرادها بالترتيب الصحيح بواسطة أداة تحميل وحدة غير متزامنة مثل RequireJS أو ما سيتم تنفيذه في النهاية في المتصفحات.

تتعارض الفكرة الكاملة للفئات الجزئية بشكل أساسي مع نظام وحدة ECMAScript.

تحديث: سيحتاج إلى إجراء استدلال تبعية معقد بشكل تعسفي وإصدار بعض JavaScript غريب جدًا.

يحتوي TypeScript بالفعل على جميع ميزات النموذج الأولي لـ JavaScript.
إنها مجموعة شاملة.

كان يجب أن أعبر عن نفسي بشكل أفضل. بالطبع نعلم جميعًا أن TypeScript هو مجموعة شاملة من JavaScript. لكني أردت أن أقول إن الفئات الجزئية ستساعد فئات TypeScript على الاقتراب من نماذج JS الأولية. في الوقت الحالي ، يمكننا فقط الحصول على فئات "ثابتة" وغير قابلة للتمديد ، بينما ، باستخدام نهج النموذج الأولي ، يمكننا توسيع وظائف تشبه الفئة.

سيؤدي استيراد الفئات الجزئية إلى تمديد بناء جملة ES6 الحالي الذي أوافق عليه. يمكننا تخيل شيء مثل هذا:

import { MyClass } from ['app/my-class-part-1', 'app/my-class-part-2'];

تستند فئات TypeScript إلى فئات ECMAScript وبالتالي تعاني من افتقار الأخير إلى التعبيرية. ضع في اعتبارك استخدام الوظائف أو الوحدات النمطية أو "مساحات الأسماء" أو الكائنات العادية لإنجاز ما تحتاج إليه.

الوظائف هي ما نريد تجنبه مع فكرة الطبقة.
تجلب الوحدات النمطية أو مساحات الأسماء قابلية تمدد بسيطة وليس لها نفس الامتداد مثل فئات TypeScript. أيضًا ، لا يمكن إنشاء مساحة اسم أو وحدة نمطية. إنهم لا يخدمون نفس الغرض مثل الفصول الدراسية.

aluanhaddad أرى ما تعنيه فيما يتعلق بالوحدات. قد يكون الحل المحتمل هو السماح لملف واحد فقط بـ export partial class بينما يحتوي الباقي على تعريفات partial class . تقوم باستيراده من المكان الذي تم تصديره فيه. من مثالك:

_app / my-class.ts_

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

_app / my-class.part.ts_

partial class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

_app / main.ts_

import { MyClass } from './my-class';

ما هو مفقود هو بناء الجملة للسماح للمجمع بمعرفة مكان تحديد الأجزاء. هذه ليست مشكلة في C # حيث تقوم بمعالجة جميع الملفات مرة واحدة. قد يكون هذا بناء جملة خاص ، مثل تلك المستخدمة لدمج التصريح .

ليس مطلوبًا للفئات الجزئية أن تسمح بتعريفات عشوائية. يمكن أن تقتصر فقط على الأساليب والخصائص والمنشئات ، على سبيل المثال. هذا يجعل أمر التنفيذ غير مهم ويسمح للمجمع برمي خطأ في حالة تكرار أحد الأعضاء.

فشلت في معرفة سبب عدم صلاحية " زيادة الوحدة النمطية" لهذه السيناريوهات. لقد نجحنا جيدًا مع Rxjs5.

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

هل هو بديل مثالي للفصول الجزئية؟ لا أفترض ، لكني لا أرى حدوث فصول جزئية ما لم تقرر ECMAScript أن JavaScript بحاجة إليها. دلالات كيفية ربط الفصول الجزئية معًا بين الوحدات الخارجية وحدها تؤذي رأسي.

@ david-driscoll لجعلها أفضل ، يمكن أن تحتوي الطرق المضافة على وسيطة this: معلنة ، من أجل فحص أقوى للنوع.

في المثال المذكور لتكبير الوحدة النمطية :

// observable.ts stays the same
// map.ts
import { Observable } from "./observable";
declare module "./observable" {
    interface Observable<T> {
        map<U>(f: (x: T) => U): Observable<U>;
    }
}
Observable.prototype.map = function (this: Observable, f) {
    // here "this" has the shape of the "Observable" class
}

نعم. Rxjs لم تستخدمه بعد ، لأنها ميزة 2.0 ، ولم يتم إصدار 2.0 بعد. إنه مدرج في قائمة النتائج الخاصة بي لاحقًا.

أرى ما تعنيه فيما يتعلق بالوحدات. قد يكون الحل المحتمل هو السماح لملف واحد فقط بتصدير فئة جزئية بينما يحتوي الباقي على تعريفات فئة جزئية فقط. تقوم باستيراده من المكان الذي تم تصديره فيه. من مثالك:

_app / my-class.ts_

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

app / my-class.part.ts

partial class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

يعجبني المفهوم النحوي ولكن المشكلة هي أنك قدمت للتو نوعًا جديدًا من ملف المصدر الذي يتم استهلاكه كنوع من الوحدات الضمنية ، ويبدو وكأنه برنامج نصي ، ويجب تحميله بطريقة معينة.

ما هو مفقود هو بناء الجملة للسماح للمجمع بمعرفة مكان تحديد الأجزاء. هذه ليست مشكلة في C # حيث تقوم بمعالجة جميع الملفات مرة واحدة. قد يكون هذا بناء جملة خاص ، مثل تلك المستخدمة لدمج التصريح.

يعمل دمج التصريح مع _declarations_ ، وليس ملفات المصدر.

ليس مطلوبًا للفئات الجزئية أن تسمح بتعريفات عشوائية. يمكن أن تقتصر فقط على الأساليب والخصائص والمنشئات ، على سبيل المثال. هذا يجعل أمر التنفيذ غير مهم ويسمح للمجمع برمي خطأ في حالة تكرار أحد الأعضاء.

كل هذه _are_ عادة تعتمد على النظام.

تحرير: وهذا يعني أن تعريفهم يعدل الفئة.

ربما ذكر شخص ما هذا بالفعل ، ولكن هناك حالة أخرى مفيدة عندما تنشئ جزءًا من الفصل الدراسي من بعض منشئ الأكواد ، فأنت ترغب في إضافة بعض الكود يدويًا في التنفيذ الخاص بك.
أنت لا ترغب حقًا في القيام بالخلط أو الفصل المشتق.
لا تزال فئة واحدة - يتم إنشاء جزء فقط تلقائيًا الجزء الآخر يدويًا.

راجع للشغل: إذا احتاج شخص ما إلى إنشاء أنواع TS من فئات C # ، فيمكنك التحقق من TypeScriptBuilder

شكرا لاخذ هذا في الاعتبار!

سأقوم بتجربة TypeScriptBuilder الخاص بك ؛)

اقتراحي...

ماذا لو لم يحاول المترجم إيجاد كل الأجزاء؟ ماذا لو اضطررت إلى استيراد أجزاء أخرى والتحكم في كل شيء؟

/MyClass.partial.ts

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

MyClass.ts

// v- this would NOT throw an error because the definition is marked as partial
import { MyClass } from "./MyClass.partial";

export class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

ثم...

1. إذا كنت أرغب في استخدام MyClass فلا بد لي من استيراده من MyClass.ts
2. عند التجميع ، سينشئ MyClass.partial.ts جافا سكريبت يمتد MyClass.prototype كما هو موضح هنا من قبل. لكنها تصدر دالة تتلقى النموذج الأولي ليتم تمديدها.
3. يتم استيراد MyClass.partial.ts في MyClass بعد تحديد MyClass وتسمى وظيفة الامتداد.

في ملاحظة جانبية ... لا يوجد شيء يمنعني من إنشاء الكود المترجم مباشرة. لكني فقدت كل عظمة الطباعة.

svallory أعتقد أن هذا بالتأكيد هو النهج الصحيح هنا. على وجه التحديد لأنك تقول أن الكود الذي تم إنشاؤه سيصدر وظيفة من شأنها أن تتسبب في الزيادة ، فستعمل حتى مع عمليات الاستيراد غير المتزامنة لأنه يمكن استدعاء الوظائف بالترتيب الحتمي الضروري.

بشكل عام ، وأنا أنسى المشكلة التي تمت الإشارة إليها ، إذا أثرت التعيينات في النموذج الأولي للفصل على شكل الفصل ، فقد يكون هناك العديد من الفوائد. سيؤدي ذلك إلى تحسين مكتبات mixin ، وجعل المصممين أكثر فائدة ، ويشجع عمومًا على تقليل التسلسلات الهرمية الرأسية.

قد يكون من الصعب على المترجم تتبع كل هذا ، ولكن ربما يمكن جعله يعمل من خلال الصراحة كما تقترح.

سيكون تحسينًا لنظام النوع ، حيث تسقط حالة استخدام الفئات الجزئية من هذا التحسين.

لقد فعلت ذلك على النحو التالي:

لقد فعلت ذلك على النحو التالي :
 ملف 1 . ts
 واجهة ifoo {
 أ ( ) : باطل ؛
 }
 class foo تنفذ ifoo {
 أ ( ) { / * افعل شيئًا * / }
 }
 ملف 2 . ts
 /// <مسار المرجع = "file1.ts" /> // ليس ضروريًا
 واجهة ifoo {
 ب ( ) : باطل ؛
 }
 فو . النموذج الأولي . ب = ( ) = > { / * افعل شيئًا * / }
 file3 . ts
 /// <مسار المرجع = "file1.ts" /> // ليس ضروريًا
 واجهة ifoo {
 ج ( ) : باطل ؛
 }
 ( < ifoo > foo . prototype ) . c = ( ) = > { / * افعل شيئًا * / }
 المستهلك . ts
 /// <مسار المرجع = "file1.ts" />
 /// <مسار المرجع = "file2.ts" />
 /// <مسار المرجع = "file3.ts" />
 دع f = new foo ( ) ؛
 و . أ ( ) ؛
 و . ب ( ) ؛
 و . ج ( ) ؛

لا تزال زيادة الوحدة النمطية تحل 90٪ من المشكلة هنا. بالنظر إلى أمثلة svallory .

/MyClass.partial.ts

export partial class MyClass {
    firstName = "John";
    lastName = "Smith";
}

MyClass.ts

// v- this would NOT throw an error because the definition is marked as partial
import { MyClass } from "./MyClass.partial";

export class MyClass {
    get fullName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

ستكون زيادة الوحدة شيئًا مثل ...

MyClass.ts

export class MyClass {
    firstName = 'John';
    lastName = 'Smith';
}

MyClass.generated.ts

import { MyClass } from './test';

Object.defineProperty(MyClass.prototype, "fullName", {
    get(this:MyClass) {
        return this.firstName + ' ' + this.lastName;
    }
});

declare module './test' {
    interface MyClass {
        readonly fullName: string;
    }
}

إنها مطولة أكثر بقليل من فئة جزئية ، ولكن في الحقيقة فإن الفصل الجزئي سيكون مجرد سكر نحوي لهذا التنفيذ.

المشاكل الوحيدة التي لا تملكها اليوم ستكون:

• لا يمكنك الوصول إلى الحقول الخاصة أو المحمية باستخدام بناء الجملة this: MyClass .
  
  
  
  • يمكن حل هذا بسهولة في التعليمات البرمجية التي تم إنشاؤها عن طريق الإرسال إلى any .
  
  
  • ربما هذا شيء يمكن إضافته ، بحيث يمكنك الوصول إلى أعضاء محميين this . قد تكون هناك قواعد أخرى حول ذلك.
  
  
• يبدو الرمز الذي تم إنشاؤه أكثر ترويعًا ، لكن بالنسبة للمستهلك ، بمجرد زيادة الأشياء ، لن يعرف الفرق أبدًا.

تحرير: ضع في اعتبارك أن هذا هو بناء الجملة TS 2.0+.

@ ديفيد دريسكول أوافق. أعتقد أن هذا أبسط وأحب أنه لا يقدم بناء الجملة الإضافي. كما تعلم ، أنا أعارض الفصول الجزئية كميزة لغة معينة ، لكنني أعتقد أنه سيكون من المفيد إذا تتبع TypeScript التعيينات للنماذج الأولية بشكل عام وصقل شكل الكائن وفقًا لذلك. أعتقد أن أسلوبك هو الطريقة الصحيحة لتقسيم الفئات عبر ملفات متعددة.

wongchichong يستخدم المثال الخاص بك أسماء فئات عالمية و /// <reference path="..."/> . لا أعتقد أن هذا سيتسع نطاقًا جيدًا ، على الرغم من أنه يمكنك استخدام مساحة الاسم لتحسين الوضع.
الكود المكتوب كوحدات نمطية (أي وحدات خارجية) هو وحش مختلف تمامًا لأنه يتضمن محملًا يحتاج إلى أن يكون على دراية بالتبعية التي تعتمد على الطلب وضمنية. هذا هو سبب أهمية اقتراح

ماذا لو كان شخص ما لا يستخدم الوحدات؟

pankleks الطبقات الجزئية لا تزال فكرة سيئة.

للتوضيح ، أعني أنها فكرة سيئة في لغة مثل JavaScript حيث تكون إعلانات الفئات إلزامية وليست تعريفية. حتى إذا كنت تستخدم مساحات الأسماء ، فسوف ينتهي بك الأمر بتقسيم التعليمات البرمجية الخاصة بك إلى ملفات متعددة مما يعني أنه يتعين عليك الاعتماد على ترتيب علامات البرنامج النصي لهذه الملفات حتى يعمل هذا على الإطلاق.

في لغة مثل C # ، تعمل الفصول الجزئية بشكل جيد ولكن هذا بسبب اختلافها جوهريًا عن الفصول في JavaScript.

من المهم أن نتذكر أنه في JavaScript ، لا يتم رفع إعلانات الفئات ، ناهيك عن التصريحات.

باستثناء ES6 ، يتم تعريف مفهوم "الفئة" بواسطة TS. JS ليس لديه فكرة فئة _ على الإطلاق_.
لذا فإن الأمر متروك لـ TypeScript لتحديد ما يمكن أن يكون عليه الفصل ، أليس كذلك؟

باستثناء ES6 ،

لا يمكننا حظر ES6 عند مناقشة ميزات لغة TS ، لأن أحد أهداف TS هو اتباع مواصفات ES الحالية / المستقبلية .

صحيح أن :/

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

ما زلت لا أفهم سبب عداء بعض الأشخاص لميزة تم إثبات فائدتها في مكان آخر ، باستثناء قول "إنها فكرة سيئة".

يبدو أن هذا لم تتم مناقشته كثيرًا في esdiscuss ، الموضوع الوحيد الذي وجدته به 9 مشاركات.

@ yahiko00 ليس الأمر أنني معادية لهذا المفهوم. كما تقول إنه مفيد جدًا في لغات مثل C #.

بصفتي مبرمجًا متحمسًا لـ C # ، أجد أن الفصول الجزئية مفيدة جدًا لمهام معينة. ومع ذلك ، فهي لا تتدخل في الجوانب الأخرى للغة. فهي لا تكسر التجريدات الرئيسية ذات الصلة مثل مساحات الأسماء والتجمعات وإعلانات النوع القابلة للترتيب بشكل عشوائي.

من ناحية أخرى ، تحتوي JavaScript على نظام وحدة حديث في أحسن الأحوال. الفصول الدراسية جديدة ، وأنا أزعم أنها ليست سمة معبرة جدًا للغة ، فهي بحاجة إلى وقت للنمو.

إذا أخذنا خطوة للوراء للحظة ونظرنا في طرق الامتداد ، وهي ميزة أخرى قوية وأكثر فائدة بكثير لـ C # ، أود أن أراهم مضافين إلى JavaScript ولكن هناك مشاكل أساسية في القيام بذلك لم يتم حلها بعد.

عندما نصل إلى نقطة يمكن فيها تحديد الفئات الجزئية دون كسر أو تقييد مفاهيم أساسية أكثر مثل الوحدات النمطية ، سأكون جميعًا مع إضافتها.

ومع ذلك ، كما يشير SaschaNaz ، يجب معالجة هذا _does_ في ECMAScript.

ربما يمكن لأي شخص مهتم فتح موضوع جديد على http://esdiscuss.org ونشر عنوان URL هنا حتى نتمكن من مواصلة المناقشة هناك 😄

ملاحظة: أو على المزيد من خطاب ES الذي يشبه GitHub.
PS2: أو على WICG أيضًا مثل GitHub وأكثر نشاطًا.

أود أيضًا أن أرى بعض الإنشاءات التي تسمح بإنشاء رمز لـ TS. تعمل الفصول الجزئية بشكل رائع في C #.

ربما أفتقد شيئًا ما ، لكن يبدو لي أن المشكلة الأساسية هي توسيع فئة مع إمكانية الوصول إلى متغيرات "خاصة" من مكان آخر غير المنشئ ، ويفضل أن يكون ذلك من ملف آخر.

بناءً على المناقشة ، يبدو أن الكثير من ابتكارات TS "الآمنة" قد تم إجراؤها. الآن نحن ننتظر فقط لنرى ما تفعله هيئة الحوكمة ES لأننا لا نريد كسر أي شيء للمضي قدمًا. صحيح تمامًا ، لكنه محبط بعض الشيء لأنني كنت آمل في قطار سريع الحركة مع TS.

الشرط الأساسي هو إيجاد حل جيد :

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

نحتاج أولاً إلى اكتشاف تفصيل جيد للفئات بشكل عام في بدائل أساسية إلزامية وتركيبية ، مثل الطريقة القديمة. ولكن بمجرد أن نحصل على ذلك ، فإن إضافة المزيد من السكر في الأعلى مثل الفئات الجزئية قد يكون أمرًا معقولًا ، اعتمادًا على مدى الراحة - أو عدم - تلك الأوليات في نهاية المطاف.

لست متأكدًا مما يعنيه هذا بالضبط ولكن ربما مثل هذا:

class A {
  foo() { return "foo" }
}
class B extends A {
}

partial(B, class {
  get foo() {
    return super.foo(); // should work
  }
});

(صليب منشور على esdiscuss )

يبدو أن هناك طريقة بسيطة إلى حد ما لتنفيذ فئة جزئية في JS الخالصة (مع ES2017 getOwnPropertyDescriptors ). قد يعتقد الناس ES أن السكر النحوي لن يحتاج فقط لإزالة هذه الشفرة الصغيرة.

function partial(base, extension) {
  extension.prototype.__proto__ = base.prototype.__proto__; // to enable 'super' reference
  const descriptors = Object.getOwnPropertyDescriptors(extension.prototype);
  delete descriptors.constructor; // must not override constructor
  Object.defineProperties(base.prototype, descriptors);
  
  return base;
}

يتطلب استخدام هذا في TS وجود نسخة مكررة من interface لتوسيع نوع الفصل الحالي ، بالطبع.

SaschaNaz أتوقع أن الخصائص المضافة إلى المُنشئ من خلال getOwnPropertyDescriptors ستكون مخفية لـ IDE "autosuggestion" (حيث تتم إضافتها في وقت التشغيل). تذكر ، تم إنشاء التنضيد على هيئة JavaScript مع "اقتراح تلقائي" (يطلق عليه أحيانًا اسم "stronlgy typed" ولكن ما يعجبهم حقًا هو "اقتراح تلقائي").

ملاحظة: لماذا يحتاج الناس إلى فصول جزئية - ترميز. ولكن مرة أخرى ، يجب دعم إنشاء التشفير بواسطة IDE (تعديل "أداة" سهلة لملف المصدر ، أو نتيجة هرمية في مستكشف الملفات ، أو دعم T4 أو دعم "مُنشئ التشفير المشترك") وفي اللغة (الفئات الجزئية ، وطرق التمديد). فقط بعد فهم هذا يصبح من الممكن فهم ما يطلبه المطورون حقًا. إذا كنت لا ترى الصورة الكاملة - بالطبع فإن "الفصول الجزئية" تبدو "هراء".

aluanhaddad : لكن أليست وظيفة TypeScript الرئيسية هي تزويدنا بعناصر لغة غير موجودة في JavaScript؟ لماذا يُعد تقسيم فئة إلى ملفين جزئيين من TypeScript فكرة سيئة ، والتي سيتم تجميعها في ملف JavaScript واحد؟

أنا حقًا لا أرى مشكلة في إعطاء أداة للمجتمع. وأنا متأكد بنسبة 100٪ أنه سيكون هناك مطورو يسيئون استخدامها. ولكن أيضًا المطورين الذين يعرفون بالضبط كيفية استخدامه. لكن ألا نواجه نفس الموقف مع أي بناء لأي لغة؟

+1 لأغراض إنشاء الكود. وأنا أتفق مع rpokrovskij ، لماذا نختار TypeScript ، يمكنني أيضًا استخدام JavsScript مباشرةً ، فقط لأنه يبدو مثل C # ، ولديه دعم بيئة تطوير متكاملة.

greendimka لا أعرف كيف يمكن أن يعمل هذا دون الابتعاد عن وإضافة التعقيد الكبير إلى وحدات ES.

@ xiexin36 يبدو أن TypeScript يشبه JavaScript أكثر من C # بالنسبة لي.
هناك قواسم مشتركة بين JavaScript و C # ، لكن مفاهيمهما عن class مختلفة عن بعضها البعض.

@ xiexin36 لإنشاء الكود ، لا يزال بإمكانك استخدام زيادة الوحدة (كما أشرت سابقًا في هذا الموضوع ). من الناحية النحوية ، ليس الأمر "سهلاً" مثل الفصول الجزئية ، ولكن يمكنك إنجاز نفس المهمة.

aluanhaddad حسنًا ، إنه يعمل ببساطة شديدة: لا تغير الفئات الجزئية بنية الكود بأي شكل من الأشكال. إنها تسمح لنا فقط بكتابة تعريف للفئة نفسها في عدة ملفات (والتي يتم تجميعها في JS واحد على أي حال).

aluanhaddad بالمعنى الدقيق للكلمة: جافا سكريبت ليس لديها مفهوم الفئات (فصول ES6 توفر فقط سكرًا تركيبيًا). لذا ، إذا حاولنا اتباع مفهوم أن TypeScript ضعيف مثل JavaScript - ألا يجب أن نتخلص من الفئات من TypeScript؟ ألا يجب أن نعود ببساطة إلى JavaScript؟

فئات greendimka ES6 وفئات TypeScript هي نفسها.
لا يهدف TypeScript إلى إضافة بنيات إضافية إلى وقت تشغيل JavaScript.

فصول ES6 باهتة للغاية. هذا لا يعني أن JavaScript ليست لغة قوية (إنها كذلك). توفر TypeScript كتابة ثابتة للقبض على الأخطاء في وقت التصميم ، وتوفر أدوات عالية الجودة ، وتسمح بمعايير دقيقة وصارمة للغاية لواجهات المكونات ، وتحسن الإنتاجية بشكل عام.

تعتبر فئات ES6 باهتة للغاية ولكن بالنسبة إلى TypeScript لتقديم مفهومها الخاص عن الفئات سيكون انتهاكًا مباشرًا لأهداف التصميم الخاصة بها.

ببساطة تجنب الفصول الدراسية وسيتم حل مشكلتك.

حسنًا ، إنه يعمل ببساطة شديدة: لا تغير الفئات الجزئية بنية الكود بأي شكل من الأشكال. إنها تسمح لنا فقط بكتابة تعريف للفئة نفسها في عدة ملفات (والتي يتم تجميعها في JS واحد على أي حال).

وتقريباً تنكسر كل أداة يعرفها الإنسان؟ لا، شكرا.

@ david-driscoll شكرًا لك ، سأحاول ذلك ، لكنني أيضًا أستخدم Angular 2.0 ، وأتساءل عما إذا كنت أقوم بإنشاء رمز باستخدام
Input أو Output ، ستعمل ، على أي حال سأحاول ذلك.

aluanhaddad من المؤلم أن ترى كيف تم

وبالمناسبة ، يقدم لنا فريق TypeScript وظائف جزئية أيضًا! ويرجى إخبار فريق C # بنفس الشيء ، حيث لدينا "وظائف في الوظائف" في الوقت الحالي. :)

فقط للتأكد ، أنت تدرك أن الوظائف الجزئية لها معنى محدد للغاية وأن ما تصفه ليس وظائف جزئية بأي حال من الأحوال؟
إنشاء الكود مفيد ، وأنا أستخدمه أيضًا.

تضمين التغريدة هل تفهم مصطلح "وحدة ترجمة واحدة في عدة ملفات"؟ جافا سكريبت بالطبع ليست لغة تجميع ولكن أ) يجب تحليل الوظيفة بالكامل قبل التنفيذ ويمكننا تسمية هذا "التجميع" ب) التنضيد هو لغة تجميع.

لمساعدة خيالك:

function partial func(arguments) {
  return function() {
    return codegenerated(arguments);
  };
}

function partial func(arguments) {
   function codegenerated(arguments){
      // ...
   }
}

أنا أيضًا لا أستخدم الفئات الجزئية كثيرًا: لاستخدامها بفعالية نحتاج إلى تخزين معلمات إنشاء الشفرة في جزء "يدوي" ولقراءة هذا التكوين يجب أن يكون لدينا محلل لغة جيد (وليس انعكاس). ولكن هذا هو الأمر: الفئات الجزئية ليست سوى أداة واحدة من بين العديد من الأدوات لجعل إنشاء التشفير مريحًا.

تضمين التغريدة
أعتذر إذا كنت عدائية. لم أقصد أي إهانة أو عدم احترام.

يحتوي المثال الخاص بك على جوانب تتطلب وصفًا رسميًا إلى حد ما في حد ذاته. لم يكن هذا الاقتراح في الأصل يتعلق بتمكين سيناريوهات إنشاء الكود بشكل مباشر.

aluanhaddad ....
"ببساطة تجنب الفصول الدراسية وسيتم حل مشكلتك" - بجدية ، هل هذا حل لمشكلة ؟! ربما إذا تجنبت استخدام JavaScript - يمكنني حل مشكلة هذه المناقشة بأكملها. أيضا حل ، أليس كذلك؟ للأسف ، لدينا هذه اللغة الغريبة في عالمنا لأنها كانت محظوظة بما يكفي للوصول إلى الويب منذ سنوات عديدة. على أي حال ، هذا هو خارج الموضوع.

"كسر تقريبا كل أداة يعرفها الإنسان" - كيف يكون ذلك ممكنا ؟؟؟ كيف؟!؟! أحاول تخيل كسر شيء ما باستخدام فئات جزئية في TypeScript ، لكن لا يمكنني ذلك. أنا ببساطة لا أستطيع. من فضلكم ، ساعدوني هنا ببعض الأمثلة الواقعية.

تخيل الآن أنك بنيت سيارة لنقل الصناديق. إنه يعمل بدون أي مشاكل. أنت تستأجر عاملاً يقوم بتحميل السيارة. يأخذ العامل صندوقين في كل مرة ويدخل في السيارة. لا يزال كل شيء يعمل بشكل جيد.
في أحد الأيام ، يغادر العامل إلى شركة أخرى وتوظف شركة جديدة. يأخذ الصندوق الجديد صندوقًا واحدًا ، ويقوم بتحميله ، ويأخذ صندوقًا منفردًا آخر ويقوم بتحميله أيضًا. منطقيا: كل شيء على ما يرام. لكنك تجري وتصرخ: توقف ، توقف ، لدينا فشل في النظام! :)

"ببساطة تجنب الفصول الدراسية وسيتم حل مشكلتك" - بجدية ، هل هذا حل لمشكلة ؟! ربما إذا تجنبت استخدام JavaScript - يمكنني حل مشكلة هذه المناقشة بأكملها. أيضا حل ، أليس كذلك؟ للأسف ، لدينا هذه اللغة الغريبة في عالمنا لأنها كانت محظوظة بما يكفي للوصول إلى الويب منذ سنوات عديدة. على أي حال ، هذا هو خارج الموضوع.

ES2015 به العديد من الأشياء الخاطئة بالتأكيد. كان لدى ES5.1 العديد من الأشياء الخاطئة بالتأكيد. في رأيي ، لم يكن نقص الفصول أحد هذه الأشياء. نقطتي هي أنه باستخدام تقنيات مثل نمط الوحدة الكاشفة ، فإنك تتجنب الحاجة إلى الفصول الجزئية. يوفر TypeScript السكر لنمط الوحدة الكاشفة ، مساحات الأسماء.

"كسر تقريبا كل أداة يعرفها الإنسان" - كيف يكون ذلك ممكنا ؟؟؟ كيف؟!؟! أحاول تخيل كسر شيء ما باستخدام فئات جزئية في TypeScript ، لكن لا يمكنني ذلك. أنا ببساطة لا أستطيع. من فضلكم ، ساعدوني هنا ببعض الأمثلة الواقعية.

إذا كنت تستخدم وحدات ES ، فهذا يمثل مشكلة. أي أداة تعتمد على المصنوعات المادية للمترجم الذي لديه مراسلات مع نظرائهم غير المجمعين ستكون خاضعة لهذا. ومع ذلك ، يمكن أن تتكيف TypeScript مع هذا في الانبعاث ، وهو تغيير هائل ، لكنها ستصدر بعد ذلك JavaScript لا يتطابق مع TypeScript التي كتبتها.

لذلك ، بشكل أساسي ، يتم إعاقة تطور اللغة بواسطة الأدوات ، والتي لن تتطور أبدًا بدون تطور اللغة.
آسف ، لكني أرى هنا فقط البحث عن سبب عدم التطور.

ما هي الفوائد التي تقدمها الفصول الجزئية ، والتي لا يمكنك فعلها مع اللغة بطريقة مختلفة؟ إنه سكر نحوي لطيف ، بالتأكيد ، لكن ما المكاسب الحقيقية؟ هل هناك مثال ملموس بخلاف جعله أشبه بـ C #؟

جانبا: بالنسبة للسجل الذي بدأت به كمطور C # ، انتقلت إلى JavaScript / C # من هناك. بمجرد الإعلان عن TypeScript 0.8 ، تم بيعي ، ليس لأنه كان C # لجافا سكريبت ، ولكن لأنه كان يأخذ JavaScript صارمًا ويجعله أفضل للمطورين الذين يتمتعون بأنواع قوية من C #.

TypeScript ليس C # ، ولا يجب أن يرث الميزات من C # فقط لأن C # يمتلكها. تمامًا كما يجب ألا ترث C # ميزات من TypeScript. لا يمكنني حساب المرات التي أردت فيها ميزات مثل أنواع الاتحاد في C # لأنها رائعة جدًا لـ TypeScript ، لكنها ليست مناسبة للغة حتى الآن.

لقد قرأت حتى الآن إنشاء الشفرات وتنظيم الشفرات.

إنشاء الكود ، انظر إلى زيادة الوحدة النمطية ، فهناك بعض أوجه القصور التي أشرت إليها هنا ولكني متأكد من أنه يمكن إصلاحها.

منظمة الكود ، أعتقد استخدام المناطق (لول)؟ هناك العديد من الطرق الأخرى لتنظيم الكود الخاص بك ، إذا كان لديك فئة إله واحدة (لأي سبب كان) يمكنك دائمًا تقسيمها إلى العديد من فئات الله. على السطح ، فإن الطبقة الإلهية هي الاستيراد الذي يراه الجميع ويستخدمه ، تحت الأغطية ، ومع ذلك فهو مصنوع من العديد من الفئات ربما كخصائص لفئة الآلهة. إذا كنت تستخدم فصولًا جزئية للمؤسسة ، فسأجادل أنك بحاجة إلى إعادة بناء الكود الخاص بك قليلاً لمحاولة و SOLID ify الكود الخاص بك.

لقد تمكنت من ملاءمة الزيادة في معظم سيناريوهات إنشاء الكود التي واجهتها حتى الآن.

بالنسبة إلى Omnisharp-Client ، أستخدم امتداد الواجهة هنا حيث يتم إنشاء OmniSharp.Api.V2 عبر الانعكاس في C #. في الجزء السفلي من الملف ، لدي أداة تقوم بإخراج جميع طرق تلك الواجهة.

بالنسبة إلى RxJS ، نستخدم لرسم خريطة لجميع أساليبنا التي يمكن ملاحظتها .

لا يمكنني التفكير في بعض المشكلات المتعلقة بالفصول الدراسية الجزئية. على سبيل المثال ، إذا حصلنا على 3 فئات جزئية.

• MyAwesomeClass1.ts
• MyAwesomeClass2.ts
• MyAwesomeClass3.ts

النطاق: الوحدة النمطية العالمية (باستخدام namespace / module )

التجميع العالمي هو المكان الذي يبدو أن هذا هو الأسهل. نظرًا لأن TypeScript يدمج بالفعل مساحات الأسماء معًا.

إذا كان tsconfig.json يحتوي فقط على مسارات الملفات للفئة 1 و Class2 ، فلن يتم دمج أي شيء موجود في Class3 تلقائيًا.

• في البداية ، يبدو هذا كخطأ من المستخدم ، لكن لن يتضح على الفور سبب عدم تضمين الأساليب من Class3. هذه مشكلة كبيرة في الاستخدام ستؤدي إلى الارتباك.

النطاق: الوحدات الخارجية (استيراد / تصدير)

مع التحويل البرمجي الخارجي ، يعتبر كل ملف حقًا وحدة نمطية (أو تجميع الجحيم في عالم .NET) لأن كل وحدة تحتوي على قائمة صريحة بكل تبعياتها (الواردات) وجميع واجهات برمجة التطبيقات العامة (الصادرات).

كيف تفكر في هذه السيناريوهات؟

بالنظر إلى مرجع ملف واحد فقط ، ما هو سلوك الفصل؟
هل يتم دمج Class2 و Class3 تلقائيًا؟

• هل يقوم التعريف الافتراضي للفئة 1 و 2 و 3 بتصدير نفس القيمة بالضبط؟
• ما الملف الذي يتم إرساله إلى القرص؟
• كيف ستبدو JavaScript الأساسية لجميع التنسيقات المدعومة (amd ، umd ، commonjs ، إلخ)

// somefile.ts
import { MyAwesomeClass } from 'MyAwesomeClass1';

new mac = new MyAwesomeClass();
mac. // What methods are available here?

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

// somefile.ts
import { MyAwesomeClass } from 'MyAwesomeClass1';
import { MyAwesomeClass } from 'MyAwesomeClass2'; // or maybe import 'MyAwesomeClass2';
import { MyAwesomeClass } from 'MyAwesomeClass3'; // or maybe import 'MyAwesomeClass3';

new mac = new MyAwesomeClass();
mac. // What methods are available here?

@ david-driscoll فقط سنتان هنا:

إنه سكر نحوي لطيف ، بالتأكيد ، لكن ما المكاسب الحقيقية؟

أليس السكر النحوي اللطيف هو الهدف الكامل لأي لغة؟ من وجهة نظر المنطوق ، كل ما نحتاجه هو الحلقات ، وجمل if والتكرار لفعل كل شيء. الباقي هو مجرد "سكر نحوي لطيف" من أجل أن تكون أكثر إنتاجية وتوفر صفات غير وظيفية أخرى مماثلة.

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

هناك شيئان أحبهما في TypeScript: 1. يتيح لنا استخدام جافا سكريبت مكتوبًا بحيث يصبح من السهل إدارتها فجأة لبناء أنظمة معقدة في العميل. 2. نظام الكتابة معبر للغاية (لأنه كان مجبرًا على أن يكون قادرًا على التعبير عن جميع أنواع الأنماط في جافا سكريبت التي يمكن للأشخاص كتابتها دون قيود نظام الكتابة).

لكن فيما يتعلق بهيكلة الكود ، لا أعتقد أنه أقل إمتناعًا من أي لغة أخرى. وأتمنى أن نكون أكثر ابتكارًا هنا. امنح المستخدمين مزيدًا من الحرية لتجربة الجزء التنظيمي للغة. الانفتاح والسعي للحصول على تعبير هيكلي جديد بدلاً من أن يكون مقيدًا ومريبًا.

لا تعد الفئات الجزئية ملائمة جدًا لإنشاء الكود على وجه التحديد ، ولكنها تزيد من الحرية في التنظيم بشكل عام. الحرية التي نحتاجها من أجل الخروج من حفرة تنظيم الكود هذه.

@ david-driscoll ما الفائدة من وجود جزئيات؟ حسنًا ، مرة أخرى: إنشاء الكود.
ما هو الخطأ في الحل المقترح الخاص بك؟ إنه حل بديل. حل آخر (وحل بديل قذر جدًا). لدينا بالفعل لغة قذرة (javascrtipt) ، مليئة بالحلول البديلة. بدلاً من التفكير في مهامهم الرئيسية ، يقضي مطورو جافا سكريبت الكثير من الوقت في التفكير في الحلول البديلة. من خلال فلسفتك المقترحة ، يمكننا التخلص من لغة TypeScript بأكملها. لأنه (مفاجأة ، مفاجأة) يمكن محاكاة نظام الأنواع بالكامل في جافا سكريبت خالص - باستخدام الحلول البديلة. لماذا تهتم بلغة أكثر تعبيرًا (مثل تنكوسكربت) إذا كان بإمكانك محاكاة أي شيء باستخدام الحلول البديلة؟ لماذا تكتب سطرًا واحدًا من التعليمات البرمجية بينما يمكن كتابة نفس الشيء في عشرين سطراً؟ استرجع الرواتب بناءً على عدد من أسطر التعليمات البرمجية المكتوبة! رمز قصير معبر للكسس ، أليس كذلك؟

ولا: طلب الحصول على أجزاء في TypeScript لا يعتمد على فكرة أن C # يمتلكها. لا أعتقد أن TypeScript يجب أن تحتوي على شيء لمجرد امتلاكه لأن لغة أخرى تمتلكه.

وأخيرًا: لماذا تعتقد أنك إذا لم تستخدم شيئًا - فلن يحتاجه أحد؟

greendimka لم أكن أحاول إثارة أي عداء: درع :. أحاول ببساطة أن أفهم السيناريوهات أو إذا كانت هناك سيناريوهات لست على دراية بها ، والتي هي بصراحة ممكنة تمامًا!

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

أحد المستأجرين الرئيسيين الذين تمسك بهم فريق TypeScript هو محاولة الحفاظ على TypeScript في حالة تزامن مع اتجاه ECMAScript ، وتجنب إنشاء أي ميزات محددة قد تتسبب في تباعدهم عن الاتجاه العام الذي تتطور إليه JavaScript.

لا يعني ذلك أنني لن أستخدمه (ربما كنت سأفعله إذا كان موجودًا). المشكلة هي كما هي في هذه المسألة أن الفصول الجزئية قد تحذيرات لذلك يبدو من المشكوك فيه أنه سيتم تنفيذها في أي وقت قريب. من المحتمل أن يظل على هذا النحو لفترة من الوقت حتى أ) يصبح ميزة لا غنى عنها لأصحاب المصلحة ذوي القيمة العالية أو ب) ينتقل الاقتراح إلى المراحل اللاحقة من TC39.

لا أرى "زيادة الوحدة النمطية" كحل. يسمح لك بزيادة نظام الكتابة ، ويسمح للعديد من سيناريوهات إنشاء الكود التي تم تفصيلها في هذا الموضوع. هذا هو خطوة نحو ميزات اللغة الأخرى.

• هل هو قبيح؟ بالتأكيد ، قبيح مثل كل الجحيم. ومع ذلك ، إذا كنت تقوم بإنشاء الكود ، فما الفرق؟ فقط أداة الجيل الخاص بك هي التي تحتاج إلى القلق بشأن كيفية زيادة الفصل. بمجرد تشغيل أداة إنشاء الشفرة الخاصة بك ، وتضمين الوحدات النمطية الخاصة بك ، ستحصل على أخطاء تحسس وتجميع كاملة ، إلخ.

• هل هي مثالية؟ بعيد عنه! أرى سيناريو أكثر شيوعًا مع mixins بحاجة إلى الدعم على مستوى اللغة. وأعتقد أن شيئًا ما يتماشى مع المصممين كما هو مقترح هنا أمر منطقي ، على الرغم من عدم وجود أي اقتراح محدد مرة أخرى.

@ ديفيد دريسكول ، آسف لكونك وقح للغاية. أنا أميل حقًا إلى الوقوف بجانب التقدم الإيجابي.

أود هذا حتى أتمكن من وضع تطبيقات ثابتة في فصل دراسي جزئي.

نظرًا لأنه لا يبدو أن هذا سيؤتي ثماره قريبًا ، أود أن أقترح حلاً بديلًا وجدناه. توجد بعض التعليقات من هذا القبيل ، لكنني لم أرَ تعليقًا بهذه التفاصيل يقرأ.

نود استخدام Partials في سيناريو إنشاء رمز حيث نريد أن نكون قادرين على توسيع كود TypeScript الذي تم إنشاؤه. ومع ذلك ، فإننا ننتج نماذج لها اعتمادات متبادلة ، لذا فإن الميراث من فصولنا لا يعمل بشكل جيد بالمعنى التقليدي. لا ينتهي الأمر بالفئات المُنشأة التي تشير إلى فئات أخرى بالنوع الصحيح من الكائن الذي تتم الإشارة إليه وسننتهي بنمط مصنع معقد للحصول على أنواع المثيلات الصحيحة التي تم إنشاؤها.

انتهى بنا الأمر بتغيير الفئات التي تم إنشاؤها إلى فئات أساسية ، ولكن فقط في إعلان الفصل. ثم أنشأنا فئات stub التي ورثناها من فئاتنا الأساسية الجديدة. يمكننا بعد ذلك توسيع هذه الفئات الجديدة وسوف يرثون كل محتواها من الطبقة الأساسية.

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

ملف 1: الفئة الأساسية

module ViewModels {
    export class PersonBase {
        // Generated members
        public anotherPerson: Person;
        constructor(){
            // Generated constructor code
        }
    }
}

ملف 2: الفصل الفعلي

module ViewModels {
    export class Person extends PersonBase {
        // Custom methods
        public NewVariable: string = "NewVar";
        constructor() {
            super();
            // Custom constructor code
        }
    }
}

لقد أدى هذا إلى حل مشكلة الفصل الجزئي مع الكود الذي تم إنشاؤه. مجد لأندرو سكوت لتوصله إلى الفكرة.

أود حقًا هذا أيضًا ، نظرًا لأنني أقوم بإنشاء بعض التعليمات البرمجية باستخدام منشئ رمز ، وأحتاج إلى إضافة بعض التغييرات إليه. ستسمح الفئات الجزئية بإعادة إنشاء الكود دون الحاجة إلى إضافة التغييرات مرة أخرى لاحقًا (والتي قد تكون كبيرة أو معقدة)

هناك سبب مهم لوجود فئات جزئية لا أعتقد أنه تم ذكرها حتى الآن: الانتقال تدريجيًا من JS إلى TS. في جافا سكريبت ، خاصة ما قبل ES6 ، يمكن أن تبدو الفصول الدراسية كمجموعة من:

Foo.prototype.someFunction = function() {/*....*/}

ويمكن توزيعها على ملفات متعددة دون أي معالجة خاصة. يتطلب تحويل قاعدة كود مثل هذا إلى TypeScript حديثًا حاليًا وظائف متحركة بحيث يكون جميع أعضاء الفصل في نفس الملف ، وهو ما يمكن أن يكون تغييرًا جائرًا للغاية. باستخدام الفئات الجزئية ، يمكن إجراء الترحيل باستخدام عمليات التحرير المحلية فقط.

RyanCavanaugh لقد ذكرت أن كل شيء

أعتقد أن اقتراح mixin به الكثير من الأسئلة المفتوحة. اقتراح الفصل الجزئي هنا هو مجرد تدوين للأشياء المسموح بها بالفعل في TypeScript ، فقط مع بعض السكر النحوي (يمكن فعل هذه الميزة حرفيًا كإعادة تخطيط نحوي للأشياء التي لدينا بالفعل).

فكيف يمكن للمرء القيام بذلك في TypeScript ؟:
File1.ts:

// Imagine this file is code generated and could be regenerated during development
export partial class Contact
{
    firstName: string;
    lastName: string;
    partial OnInit( args: any ) : void;
    constuctor( args: any )
    {
        this.OnInit( args );
    }
}
export class Address
{
    addr: string;
    city: string;
    state: string;
    zip: string;
}

File2.ts

// See where I'm going with this? This file would be hand edited and allows me to specify associations and children.
partial class Contact
{
    Addresses: string[] = [];
    partial OnInit( args: any ) void
    {
        this.firstName = args.firstName;
        this.lastName = args.lastName;
        this.Addresses.push( new Address() );
    }
}

سيؤدي تحويل ما سبق إلى إصدار فئة JS واحدة لجهة الاتصال ، شيء من هذا القبيل:

var Contact = (function () {
    function Contact() {
         this.Addresses = [];
   }
   Contact.prototype.constuctor = function (args) {
       this.OnInit( args );
   };
   Contact.prototype.OnInit = function (args) {
       this.firstName = args.firstName;
       this.lastName = args.lastName;
       this.Addresses.push(new Address());
   };
   return Contact;
})();

var Address = (function () {
    function Address() {
    }
    return Address;
})();

لاحظ أنه في النهاية أريد فصلًا واحدًا باسم Contact ولا أريد أن أضطر إلى تصنيف صنفين منفصلين في فئة فرعية إلى فئة ثالثة.

تضمين التغريدة

هنا مثال على شيء سوف يعمل. إنه لا يرتفع من الناحية التركيبية مثل partial ومع ذلك فهو يعمل وهو حل وظيفي للغاية.

// address.ts
export class Address
{
    addr: string;
    city: string;
    state: string;
    zip: string;
}

// contact.impl.ts
import { Address } from './address';

// Class implementation, do the things here that are not code generated
export class Contact {
    firstName: string;
    lastName: string;
    addresses: Address[];
    constructor(args: any) {
        this.onInit(args);
    }
}
// extending the interface here
// define methods you know will need in the constructor only
// This only applies to the constructor however
export interface Contact {
    onInit(args: any): void;
}

// contact.partial.ts
import { Contact } from './contact.impl';

// Implement the extended contract here
Contact.prototype.onInit = function(this: Contact, args: any) {
    this.addresses = args.addresses.concat();
    // do stuff;
};

// Adding another method (not part of the extended interface)
Contact.prototype.somethingAwesome = function(this: Contact) {
    // do awesome stuff here
};

// Tell TypeScript "I added this here!!!!"
declare module './contact.impl' {
    interface Contact {
        somethingAwesome();
    }
}

// contact.ts
import { Contact } from './contact.impl';
import './contact.partial';

// Bring it all together (perhaps there are more than one partial class?)
export { Contact };

// main.ts
import { Contact } from './contact';

// use the contact!
const contact = new Contact(['my', 'args']);
const {firstName, lastName} = contact;
contact.somethingAwesome();

بدلاً من ذلك ، يمكنك أيضًا إنشاء رمز للواجهة واستخدام امتداد الواجهة لتنفيذ ذلك.

قد تكون هناك أيضًا طرق لاستخدام وظيفة Mixin الجديدة ، لكنني لم أغوص في ذلك بعد بما يكفي لإعطاء إجابة مؤهلة.

@ ديفيد دريسكول نجاح باهر. انفجر رأسي للتو.

أتساءل عما إذا كان المجتمع سينتهي به الأمر مع مفترق ، والذي يدعم ببساطة الطبقات الجزئية دون التخلص من المشكلة.
حتى الآن لم أسمع أي حجج حقيقية ضد الطبقات الجزئية. فقط أسباب قليلة لتبرير الكسل.

تضمين التغريدة

أتساءل عما إذا كان المجتمع سينتهي به الأمر مع مفترق ، والذي يدعم ببساطة الطبقات الجزئية دون التخلص من المشكلة.
حتى الآن لم أسمع أي حجج حقيقية ضد الطبقات الجزئية. فقط أسباب قليلة لتبرير الكسل.

لست متأكدًا مما تحاول قوله هنا. ولكن إذا كان الشعور العام داخل المجتمع هو أنه يمكننا تحقيق نفس النتائج باستخدام ميزات اللغة الحالية ، فأنا فقط بحاجة إلى بعض الأمثلة عن كيفية القيام بذلك. ما نشره @ david-driscoll أعلاه هو أبعد من فهمي. ولا يبدو أنه يحل المشكلة تمامًا. في الواقع ، مما يمكنني قوله ، أساء تفسير نواياي.
شاغلي الأساسي هو إنشاء التعليمات البرمجية للخصائص العددية للفئة ، مثل فئة البوجو أو فئة النموذج. لكنني بحاجة إلى أن أكون قادرًا ، في ملف منفصل ، أو حتى في نفس الملف ، ولكن ليس ضمن تعريف الفئة الأساسي ، على إضافة خصائص الارتباط (حتى أتمكن من لصق تعريف أولي تم إنشاؤه حديثًا على الأصل).
على سبيل المثال ، ستحصل فئة جهات الاتصال الخاصة بي من أعلى على رمز تم إنشاؤه باستخدام الاسم الأول والاسم الأخير. ولكن ، في تعريفي المنفصل هو المكان الذي سأضيف فيه تعريف مجموعة كائنات العنوان وتهيئتها.
لا يعرف مُنشئ الكود الخاص بي سوى سمات الفصل ، وليس الارتباطات ، لذا لا يمكنه كتابة مجموعة العناوين - مثلما حدث في مثال ديفيد.

cosmoKenney لم يكن واضحًا تمامًا مكان وجود العنوان. سامحني على فهم السياق بشكل خاطئ. أنا فقط أحاول المساعدة في إعطاء البدائل. هناك الكثير من الوظائف التي تسمح بسلوك مماثل دون وضع شيء ما في المترجم مثل الفئات الجزئية ، والتي لديها الكثير من الاعتبارات الإضافية والمشاكل المحتملة لتنفيذ كلا نظامي الوحدة (داخلي / خارجي).

في حالتك ، فإن إنشاء فئة أساسية مجردة ، أو إنشاء واجهة سيعمل ، ثم ترث الفئة الأخرى من ذلك. ثم لا تزال حقيقة إنشاء فصلك الدراسي مخفية.

بمعنى آخر:

// address.partial.ts
export interface IAddress
{
    addr: string;
    city: string;
    state: string;
    zip: string;
}

// address.ts
import { IAddress } from './address.partial';

export class Address
{
    constructor(args: any) {

    }
}
export interface Address extends IAddress{}

// contact.partial.ts
import { IAddress } from './address.partial';

export interface IContact {
    firstName: string;
    lastName: string;
    addresses: IAddress[];
}

// contact.ts
import { Address } from './address';
import { IContact } from './contact.partial';

// Class implementation, do the things here that are not code generated
export class Contact {
    addresses: Address[] = [];

    constructor(args: any) {
        this.firstName = args.firstName;
        this.lastName = args.lastName;
        this.addresses.push( new Address("address?") );
    }

    public somethingAwesome() {
        //
    }
}
export interface Contact extends IContact {}

// main.ts
import { Contact } from './contact';

const contact = new Contact(['my', 'args']);
const {firstName, lastName} = contact;
contact.somethingAwesome();

cosmoKenney : يقدم @ david-driscoll حلاً مثيرًا للاهتمام ، لكنه لا يزال يفتقر إلى سهولة الفصول الجزئية الحقيقية. كما أوضحت تجاربي الشخصية - لا يستخدم المطورون ببساطة "الأجزاء" التي يتم تصنيعها بهذه الطريقة. على الرغم من أنه حل بديل جيد ، إلا أن سهولة وراحة الجزئيات ليست موجودة.

في الوقت الحالي لا أعرف كيف يعمل مترجم TypeScript داخليًا. يمكنني فقط أن أفترض أنه يقرأ جميع ملفات المصدر ، ويتابعها ، ويخرج ملفات JS. إذا كان الأمر كذلك - لا أرى أي مشاكل في قراءة فئة واحدة من عدة ملفات مصدر. إذا قدم ملفان مصدر أو أكثر من فئة واحدة رمزًا متضاربًا (تم تحديد خاصية fe نفسها مرتين) ، فسيقوم المترجم ببساطة بطرح استثناء. تمامًا كما يحدث إذا كتبت رمزًا غير صالح من الناحية النحوية.

greendimka ، @ david-driscoll
حاولت تجميع مثال ديفيد من الأعلى ، لكن لا يعجبني ذلك:

C:\TestProjects\TypeScriptFakePartialClassTest>tsc -m amd address.partial.ts address.ts contact.partial.ts contact.ts main.ts
address.ts(4,14): error TS2300: Duplicate identifier 'Address'.
address.ts(10,18): error TS2300: Duplicate identifier 'Address'.
contact.ts(7,14): error TS2300: Duplicate identifier 'Contact'.
contact.ts(11,14): error TS2339: Property 'firstName' does not exist on type 'Contact'.
contact.ts(12,14): error TS2339: Property 'lastName' does not exist on type 'Contact'.
contact.ts(20,18): error TS2300: Duplicate identifier 'Contact'.
main.ts(5,8): error TS2459: Type 'Contact' has no property 'firstName' and no string index signature.
main.ts(5,19): error TS2459: Type 'Contact' has no property 'lastName' and no string index signature.

بالإضافة إلى أنني أتفق مع greendimka على أن هذا الأمر معقد للغاية بحيث لا يمكن استخدامه مئات المرات في تطبيق كبير.

greendimka لا أعرف كيف يعمل المترجم أيضًا ، لكن لا تقلل من أهمية المهمة. JavaScript ليس .NET ولا تتوفر الوحدات النمطية بشكل عام (يجب عليك استيرادها حرفيًا)

أود أن أرى هذا وقد تم تنفيذه ، لكن هذه المهمة تثير العديد من الأشياء التي يجب التفكير فيها بعناية ، مثل:

• إذا قمت بتحديد جزء من الفصل في ملف A ، جزء من الملف B ، أي جزء يجب أن يحتوي على الفصل الدراسي الكامل بعد التحويل؟ يجب إنشاء واحدة جديدة؟
• هل يجب أن تقوم جميع الملفات التي تحتوي على عناصر جزئية بتصدير نفس الفئة؟
• كيف أتجنب التبعيات الدورية إذا طلبت الملف الرئيسي لتلك الإضافات؟
• ماذا لو قمت بتصدير المزيد من الأشياء في الوحدة النمطية أكثر من مجرد الفئة نفسها؟
• التحقق من تعارض الأسماء؟

وما إلى ذلك وهلم جرا...

greendimka انظر (تحرير: تم استهداف هذا في WoLfulus ، آسفgreendimka):

إذا قمت بتحديد جزء من الفصل في ملف A ، جزء من الملف B ، أي جزء يجب أن يحتوي على الفصل الدراسي الكامل بعد التحويل؟ يجب إنشاء واحدة جديدة؟

سأكون سعيدًا تمامًا لأن يكون للملف A.js التعريف الكامل ، ويتم إيقاف الملف B. ربما مع تعليق جاهز. يقوم معظمنا بتجميع ملفات.

هل يجب أن تقوم جميع الملفات التي تحتوي على عناصر جزئية بتصدير نفس الفئة؟

تمت الإجابة على هذا إلى حد كبير من خلال إجابتي على السؤال الأول.

كيف أتجنب التبعيات الدورية إذا طلبت الملف الرئيسي لتلك الإضافات؟

انا لا اعرف. أليست مهمة محمّل الوحدة التعرف على هذا السيناريو؟

ماذا لو قمت بتصدير المزيد من الأشياء في الوحدة النمطية أكثر من مجرد الفئة نفسها؟

لا أرى مشكلة في هذا. بعبارة أخرى ، إذا كان لدى B.ts تعريفًا جزئيًا وبعض الفئات الأخرى غير الجزئية ، فيجب أن تحتوي B.js على التعليق الجاهز كما هو مذكور أعلاه ، وتعريفات الفئات غير الجزئية. بسيط ، على ما أعتقد.

التحقق من تعارض الأسماء؟

كيف ينتهي بك الأمر مع تعارض في الاسم؟ إذا كنت تقصد في الفصل ، فإن الكلمة الأساسية "الجزئية" ستحل ذلك. ولكن إذا كان هناك ملفان آخران كلاهما يعرف كلاهما بنفس الاسم ، ولكن بدون الكلمة الأساسية "الجزئية" ، يجب أن يرسل المترجم خطأ حول الأنواع المكررة - كما هو الحال الآن. ولكن إذا كنت تتحدث عن تعريفين جزئيين لنفس الفئة يحددان خاصية أو طريقة بنفس الاسم ، فيجب أن يرسل المترجم خطأ حول الأعضاء المكررة - كما يحدث الآن.

WoLfulus ، أجاب cosmoKenney بشكل جيد. فقط لجعله أفضل مع سؤالك الأول (حول ملفات A و B): كمصمم لغة ، يتمتع المرء بامتياز تحديد القواعد. أعني بذلك أن الملف A قد يحتوي على مثل هذا الرمز "فئة جزئية X" وقد يكون للملف B مثل هذا الرمز "الجزئي (fileX) الفئة X" ، والذي سينتج fileX.js.

تضمين التغريدة

كيف أتجنب التبعيات الدورية إذا طلبت الملف الرئيسي لتلك الإضافات؟
انا لا اعرف. أليست مهمة محمّل الوحدة التعرف على هذا السيناريو؟

لا يحتوي TypeScript على محمل وحدة.

تضمين التغريدة

أتساءل عما إذا كان المجتمع سينتهي به الأمر مع مفترق ، والذي يدعم ببساطة الطبقات الجزئية دون التخلص من المشكلة.
حتى الآن لم أسمع أي حجج حقيقية ضد الطبقات الجزئية. فقط أسباب قليلة لتبرير الكسل.

هذه ليست فكرة جيدة. على سبيل المثال ، هل فكرت في كيفية الحفاظ على الشوكة عند إضافة عمليات الاستيراد الديناميكية؟
أيضًا ، تم تقديم الكثير من الحجج ضد الطبقات الجزئية. يتعارض فصل المصدر إلى المصدر عن المراسلات بين ملفات TypeScript و JavaScript مع مبدأ أساسي للغة. أتخيل أن الميزة ستحتاج إلى تمكين سيناريو أكثر قيمة من الفئات الجزئية حتى يتم أخذها في الاعتبار. من المحتمل أن يتم رفضه.

WoLfulus ، أجاب cosmoKenney بشكل جيد. فقط لجعله أفضل مع سؤالك الأول (حول ملفات A و B): كمصمم لغة ، يتمتع المرء بامتياز تحديد القواعد. أعني بذلك أن الملف A قد يحتوي على مثل هذا الرمز "فئة جزئية X" وقد يكون للملف B مثل هذا الرمز "الجزئي (fileX) الفئة X" ، والذي سينتج fileX.js.

لا أعتقد أنك توصل رسالتك. هذا يجعل الأمر يبدو كما لو كنت تشعر أن أي قيود تواجهها في التعبير عن نفسك بأي لغة موجودة لأسباب تعسفية تمامًا.
وأيضًا لم تتم الإجابة على أسئلة WoLfulus ، على الأقل لم يرضي.

بدلة دونس

TL ؛ DR: هذا لا يحدث. إذا كنت هنا في الأسفل عند رقم التعليق 189 وترغب في تسجيل عدم موافقتك بذلك ، فالرجاء قراءة الموضوع بأكمله أولاً ، لأن الأسباب الجيدة جدًا لعدم إضافة هذا تمت تغطيتها على نطاق واسع أعلاه.

تفسيرنا لهذا الموقف كالتالي:

• يحتوي TypeScript بالفعل على عدد كبير جدًا من ميزات فئة TS (إعلانات خصائص المُنشئ ، ومُهيئ الأعضاء ، ومُصممي الديكور غير المكتمل ، ومعدِّلات الوصول ، و implements ، وما إلى ذلك) لشيء كان يُقصد به حقًا أن يكون "ES6 + أنواع" . جزء من هذا هو خطأنا (اتجاهنا التصميم الأصلي كان عموما جدا OOP) وجزء من ذلك هو خطأ ES6 في (الاقتراح الطبقة انتقلت حول الكثير قبل خمس سنوات، ولقد انتهى الأمر بعد الميزات التي لم يتمكنوا من ذلك). تعد إضافة ميزة أخرى خاصة بفئة TS بمثابة قشة أخرى على ظهر البعير والتي يجب أن نتجنبها إذا استطعنا.
• بشكل لا لبس فيه ، فإن مستقبل JavaScript هو وحدات. الفصول الجزئية لها معنى وتعمل بشكل جيد في نموذج "الحساء العالمي". يُعد السماح بالفصول الجزئية التي تمتد على وحدات متعددة وصفة لكارثة لأن أمر التحميل لا يمكن التنبؤ به. لا تعد إضافة ميزة تعمل بشكل جيد في عالم عالمي فقط استخدامًا جيدًا للوقت.
• C # لديه ولكننا لسنا هنا لإعادة اختراع C #. عنجد!
• سيناريو "الكود الذي تم إنشاؤه" ليس مقنعًا من حيث الأسس الموضوعية. أي إصدار معقول للفئات الجزئية من شأنه أن يقيد مُهيئ الخاصية ورمز المُنشئ إلى إعلان واحد بالضبط ، وسيكون هذا بمثابة كسر صفقة بالنسبة للإعدادات .Designer.cs -style حيث من المحتمل أن يحتاج كل من كود المستخدم والكود المُنشأ إلى مُبدِّلات أو منطق المُنشئ .
• هناك العديد والعديد من الآليات التركيبية الأخرى المتاحة في JS - mixins ، Object.assign ، إلخ. السيناريو الذي أدى إلى هذه الميزة في C # كان مدفوعًا بقيود غير موجودة ببساطة في JS.
• الحل البديل الحالي ل interface + prototype.method = ... لا يمكن سيناريو الشفرة التي تم إنشاؤها فقط، فضلا عن partial class شأنه. من الغريب كتابة هذا الرمز يدويًا ولكن لا توجد مشكلة في إنشاء الكود بشكل مختلف ، لذلك إذا كنت تعتقد حقًا أن إعداد الكود الذي تم إنشاؤه بواسطة ملف مقسم هو الطريقة الوحيدة لحل مشكلتك (أنا متشكك) ، فإن هذه الطريقة متاحة لك .
• نحن نعتبر أن ES6 هو الحكم على "يجب أن يكون" للفئات. لا يوجد شيء مميز حول TypeScript (بخلاف جاذبيتها لمبرمجي C #) تجعلها تحتاج إلى فئات جزئية أكثر مما تحتاجه JavaScript غير المكتوبة. لذا إذا كان هناك بعض السيناريوهات التي تمنعه ​​بالفعل من إضافة فئات جزئية ، فيجب أن يكون هذا السيناريو قادرًا على تبرير نفسه من خلال عملية TC39. إذا اكتسب ذلك قوة جذب ، فسيسعدنا أن نثقله بالمدخلات عليه ، لكن لا يبدو أن هذا الأمر يقع على رادار أي شخص.

RyanCavanaugh عن هذا:

الحل الحالي للواجهة + prototype.method = ... يقوم بتمكين سيناريو الكود الذي تم إنشاؤه تمامًا مثل الفصل الجزئي.

كما ذكرت أكثر من مرة ، أنا بخير لوجود طريقة غير جزئية وغير c # لإنجاز ما أحتاجه ، واطلب فقط مثالًا عمليًا. كان david-driscoll مفيدًا جدًا ، لكنه نشر رمزًا لا يتم تجميعه. لذا ، إذا كنت تعتقد أن بإمكاني إنشاء صنف بخصائص عددية فقط ، على سبيل المثال ، الاسم الأخير الأول - كما هو مذكور أعلاه - فلا بأس بذلك. أنا فقط بحاجة إلى طريقة لإضافة مجموعة من الأنواع الأخرى كخاصية في الفصل عن طريق الترميز اليدوي لذلك. لكني أحتاج أيضًا إلى طريقة للتعامل مع تهيئة هذه المجموعة.

cosmoKenney هل أنت موقع قمت بنسخ الكود الصحيح؟ المثال الثاني يحتوي على واجهات بدلاً من نفس اسم الفئة. يمكنني إرفاق الرمز البريدي إذا أردت. لقد كنت مترددًا فقط لأن الملفات العشوائية على الإنترنت يمكن أن تكون سيئة ولا أريدك أن تعتقد أنني أنشر شيئًا ضارًا 🙂

آسف لسماع هذا ، لكنني أحترم قرارات التصميم المتخذة هنا. لدي سؤالان إذا كان هذا مناسبًا:

يحتوي TypeScript بالفعل على عدد كبير جدًا من ميزات الفئة الخاصة بـ TS (إعلانات خصائص المُنشئ ، ومُهيئ الأعضاء ، ومُصممي الديكور غير المكتمل ، ومعدِّلات الوصول ، والأدوات ، وما إلى ذلك) لشيء كان يُقصد به حقًا أن يكون "أنواع + ES6". جزء من هذا هو خطأنا (كان اتجاه التصميم الأصلي بشكل عام OOP للغاية) وجزء من ذلك هو خطأ ES6 (تم نقل اقتراح الفصل منذ حوالي خمس سنوات وانتهى بنا الأمر بالحصول على ميزات لم تصنعه). تعد إضافة ميزة أخرى خاصة بفئة TS بمثابة قشة أخرى على ظهر البعير والتي يجب أن نتجنبها إذا استطعنا.

بالنظر إلى ذلك ، هل يمكن أن تكون إحدى الطرق الممكنة للمضي قدمًا هي التمييز بوضوح ، تنظيميًا ورمزًا ، بين الكتابة الخالصة لـ JS ، وتركيبات اللغة الأخرى التي تقدمها TS؟ أنا للحب واحد كل من الكتابة وميزات اللغة إضافية. بصفتي مستهلكًا / مطورًا ، لا أهتم كثيرًا بحقيقة أن TS تضيف أشياء غير موجودة في JS. فقط أعطني أشياء رائعة ، إذا كان TC39 لا يريدها ، فلا يهمني.

إذا كانت TS ستغلف هذه الأشياء من بعضها البعض ، فربما يكون من الأسهل إعادة استخدامها والتشعب والبناء عليها من خلال مشاريع مثل SoundScript ، بدلاً من استبدالها؟

ومن ثم يمكن لمشروع آخر أن يبني على هذه الكتابة لتقديم تراكيب لغوية أفضل / أخرى مما تقدمه JS.

بشكل لا لبس فيه ، فإن مستقبل JavaScript هو وحدات. الفصول الجزئية لها معنى وتعمل بشكل جيد في نموذج "الحساء العالمي". يُعد السماح بالفصول الجزئية التي تمتد على وحدات متعددة وصفة لكارثة لأن أمر التحميل لا يمكن التنبؤ به. لا تعد إضافة ميزة تعمل بشكل جيد في عالم عالمي فقط استخدامًا جيدًا للوقت.

هل هو حقا؟ تأكد من أن الوحدات ستكون جزءًا طبيعيًا من JavaScript ، ولكن ماذا عن الجسم الأصلي الرئيسي للشفرة؟ أنا أحب مساحات الأسماء ولا يوجد حساء فيها إذا تم بشكل صحيح. أقوم بتجميعها جميعًا في ملف واحد ، ولست بحاجة إلى وحدات تحميل ، وفي جميع الحالات تقريبًا لا حاجة إلى تحميل وحدة غير متزامنة. بعض العناصر المقترحة مثل https://github.com/Microsoft/TypeScript/issues/420 ستكون ممكنة وذات صلة بمساحات الأسماء فقط. هل تقول أن مثل هذه الأشياء لن تحدث لأننا يجب أن نستخدم الوحدات فقط؟ هل مساحات الأسماء على الطريق مهجورة؟

@ david-driscoll شكرًا لك ، لقد كنت بالفعل مفيدًا بدرجة كافية. نظرًا لأن RyanCavanaugh هو الشخص الذي يستمر في إغلاق المشكلة وذكر أن هناك

أرى أيضًا الكثير من المفاهيم الخاطئة حول ماهية الفصول الجزئية. إنها حقًا بنية بسيطة ، والجميع يبالغ في ذلك:
https://msdn.microsoft.com/en-us/library/wa80x488.aspx

بالنظر إلى ذلك ، هل يمكن أن تكون إحدى الطرق الممكنة للمضي قدمًا هي التمييز بوضوح ، تنظيميًا ورمزًا ، بين الكتابة الخالصة لـ JS ، وتركيبات اللغة الأخرى التي تقدمها TS؟ أنا شخصياً أحب ميزات الكتابة واللغة الإضافية. بصفتي مستهلكًا / مطورًا ، لا أهتم كثيرًا بحقيقة أن TS تضيف أشياء غير موجودة في JS. فقط أعطني أشياء رائعة ، إذا كان TC39 لا يريدها ، فلا يهمني.

سيكون ذلك إعادة كتابة للغة وكسر كود الجميع.

كما أن عبارة "أعطني أشياء رائعة فقط" تختلف اختلافًا جوهريًا عن أهداف تصميم TypeScript . إذا كنت تريد أشياء رائعة فقط ولا تهتم بالمحاذاة مع JavaScript ، فيجب عليك اختيار لغة مختلفة ، مثل CoffeeScript أو Dart أو Haxe . بالطبع ، ربما تكون هناك أسباب وراء عدم أداء هؤلاء بشكل جيد مثل TypeScript في التبني ...

الشخص الذي يستمر في إغلاق المشكلة وذكر أن هناك حلولاً بديلة ، ربما يجب عليه تقديم مثال للتغلب على هذه المشكلة

هناك الكثير من حالات الاستخدام لما يحله partial . تحتوي أي بنية لغة تقريبًا على الكثير من حالات الاستخدام التي تكون صالحة لها ، ولكن لأسباب وجيهة ، يجب عليك الاختيار والاختيار.

أنت تسأل باستمرار عن ميزة لغة معينة ، كما في "أحب سيارة خضراء" ولكنك لا تصل إلى جوهر المشكلة ، فلماذا تحتاج السيارة إلى أن تكون خضراء؟ إذا أوضحت سبب احتياج سيارتك لأن تكون خضراء ، أو كنت منفتحًا على حقيقة أنك لا تهتم حقًا بلون سيارتك ، طالما أنها توفر احتياجاتك الحقيقية.

لا أفهم سبب شعورك بأنه من واجب رايان إخبارك بكيفية إعادة طلاء سيارتك ، فقط لأنه لأسباب وجيهة قررت شركة السيارات عدم إنتاج سيارات صديقة للبيئة.

(تعد فئات Oh و mixin المضافة في TypeScript 2.2 طريقة جيدة لتحقيق ما أظن أنه حاجتك الحقيقية)

interface Base {}

interface Constructor<T> {
    new (...args: any[]): T;
    prototype: T;
}

interface PartialClass {
    foo(): void;
}

function PartialClass<B extends Constructor<Base>>(base: B): B & Constructor<PartialClass> {
    return class extends base {
        foo() {
            console.log('foo');
        }
    };
}

class MyBase {
    bar() {
        console.log('bar');
    }
}

const MyPartialBase = PartialClass(MyBase);

const instance = new MyPartialBase();

instance.bar();
instance.foo();

@ kitsonk mixins

• Mixins هي وحدات قائمة بذاتها يمكن إضافتها إلى الفئات الموجودة.
• يمكن للفصول الجزئية الوصول إلى الأعضاء من أي جزء آخر ، كما لو كانوا جزءًا من نفس الفصل.

كتمرين ، حاول تنفيذ تقسيم الكود التالي باستخدام mixins:

partial class Point {
  readonly x: number;
  readonly y: number;
}

partial class Point {
  translate(dx: number, dy: number): Point {
    return new Point(this.x + dx, this.y + dy);
  }
}

كتمرين ، حاول تنفيذ تقسيم الكود التالي باستخدام mixins

لذا بالعودة إلى النقطة ... لذا بدلاً من الإشارة إلى ميزة اللغة ، ما المشكلة التي تحاول معالجتها بمثالك؟ لأن الحل البديل في TypeScript سهل:

class Point {
  readonly x: number;
  readonly y: number;
  translate(dx: number, dy: number): Point {
    return new Point(this.x + dx, this.y + dy);
  }
}

(وإذا أردنا completist، ولكن مرة أخرى، فإنه لا يحل الاستخدام، ليست كل حالات الاستخدام)

interface PointBase {
    x: number;
    y: number;
}

interface Constructor<T> {
    new (...args: any[]): T;
    prototype: T;
}

interface TranslatePointPartial {
    translate(dx: number, dy: number): TranslatePointPartial;
}

function TranslatePointPartial<B extends Constructor<PointBase>>(base: B): B & Constructor<TranslatePointPartial> {
    return class TranslatePointPartial extends base {
        translate(dx: number, dy: number): TranslatePointPartial & PointBase {
            return new TranslatePointPartial(this.x + dx, this.y + dy);
        }
    };
}

class Point {
    readonly x: number;
    readonly y: number;
}

const MyPoint = TranslatePointPartial(Point);

const instance = new MyPoint();

instance.x;
instance.y;
instance.translate(1, 2);

@ الفيل السفينة

بالنظر إلى ذلك ، هل يمكن أن تكون إحدى الطرق الممكنة للمضي قدمًا هي التمييز بوضوح ، تنظيميًا ورمزًا ، بين الكتابة الخالصة لـ JS ، وتركيبات اللغة الأخرى التي تقدمها TS؟

لا أرى طريقة لفصل الاثنين في هذه المرحلة. يمكن للمرء ، من الناحية النظرية ، كتابة بعض اللغات على كوفي سكريبت التي تحولت نحويًا إلى TypeScript واستخدام تلك اللغة ذات المستوى الأعلى لإضافة ميزات نحوية جديدة مع الاستمرار في استخدام نظام كتابة TS ، ولكن هذا لن يساعدك إلا على ذلك. يبدو أن مجرد اختيار واحدة من العديد من لغات التجميع إلى JS الأخرى خيار أفضل إذا كان هذا هو الهدف.

هل تقول أن مثل هذه الأشياء لن تحدث لأننا يجب أن نستخدم الوحدات فقط؟ هل مساحات الأسماء على الطريق مهجورة؟

مساحات الأسماء لا تسير في أي مكان ، بالتأكيد. إنها مجرد تسمية لنمط منتشر بالفعل على نطاق واسع ولا يزال لها معنى كبير في عالم وحدات ES6. الوحدات النمطية هي الطريقة التي ينظم بها الأشخاص أكوادهم بشكل متزايد ولديهم الكثير من الفوائد الجانبية الرائعة. أنا أقول فقط أن الفصول الجزئية لا معنى لها تقريبًا في هذا العالم ، وسيكون من الغريب إضافة نمط تنظيمي جديد بشكل أساسي لا يتوافق معه. إذا كان العالم يتحرك في الاتجاه المعاكس وكان الجميع مثل "البرامج النصية العالمية ذات الآثار الجانبية عند التحميل رائعة ، الجميع يحتفلون على بعضهم البعض prototype s" ، فربما نشعر بشكل مختلف.

تضمين التغريدة

ربما ... ربما لا يكون لهم نفس القدر من المعنى ... ولكن كما قلت مرات عديدة ، أعتقد أنه حتى في هذا الموضوع ، فإن الفصول الجزئية تدور حول تسهيل إنشاء الكود ... هذه هي الفائدة الرئيسية التي أراها منهم يستحق الميزة في TS ... أنا ، ويجب أن أفترض العديد من الآخرين ولكن هذا مجرد تخمين ، أقوم حاليًا بإنشاء طن من كود TS من كود C # الخاص بي ... ولكن بعد ذلك يصبح السؤال هو كيفية توسيع النطاق الذي تم إنشاؤه بأمان رمز TS ؟؟؟ هذا سؤال أسهل بكثير للإجابة عليه بفصول جزئية ... نلجأ حاليًا إلى الاختراقات من أجل الاحتفاظ بالشفرة المخصصة في ملفات أكواد TS التي تم إنشاؤها ...

شكرا

نفس الشيء هنا ، نقوم بإنشاء "وكيل" مطبوع لواجهات برمجة تطبيقات C # الخاصة بنا ، ونود أن نكون قادرين على توسيع هذه الكائنات في الطباعة بسهولة.

أنا لست متخصصًا في JS ، لذا يجب أن أفتقد شيئًا ما ، لأنني لا أرى سبب إمكانية تقسيم إعلان الفئات في ملفات TS متعددة (مع إعلان فئة واحد فقط في ملف JS واحد فقط بعد التجميع) مشكلة لعالم JS. بقدر ما أراه ، فهو شفاف لـ JS ، كما لو كان قد كتب في ملف واحد من البداية. أعني ، إذا كنت تستخدم فئات جزئية أم لا ، فسيكون ناتج JS هو نفسه تمامًا ، ولكنه سيمنع تكلفة قابلية امتداد كائن JS للمطورين لدينا.

تضمين التغريدة

هناك شيء آخر أردت أن أذكره أنني شخصياً لا أطلب من مترجم TS أن يحل بطريقة ما معضلة التغليف التي قد تنشأ عند إنشاء وحدة ES6 باستخدام فئات جزئية في ملفات TS مختلفة ... تجميع ملفات TS متعددة في ملف js واحد لوحدة ES6 ... مرة أخرى ، تساعد الفئات الجزئية في إنشاء الكود بشكل كبير ... إنها تسمح للأدوات بإنشاء أجزاء كبيرة من النموذج الخاص بك مع قابلية توسع موثوقة ...

تضمين التغريدة

أنت تسأل باستمرار عن ميزة لغة معينة ، كما في "أحب سيارة خضراء" ولكنك لا تصل إلى جوهر المشكلة ، فلماذا تحتاج السيارة إلى أن تكون خضراء؟ إذا أوضحت سبب احتياج سيارتك لأن تكون خضراء ، أو كنت منفتحًا على حقيقة أنك لا تهتم حقًا بلون سيارتك ، طالما أنها توفر احتياجاتك الحقيقية.

لا ، لم أعد أطلب ميزة جديدة. لقد قيل مرارًا وتكرارًا أن اللغة يمكن أن تحقق ما أريد. لقد قدمت أمثلة على ما أريد (في C #) ، لكنني لم أر بعد في الأمثلة المفيدة طريقة للوصول إلى المكان الذي أحتاج أن أكون فيه.

لا أفهم سبب شعورك بأنه من واجب رايان إخبارك بكيفية إعادة طلاء سيارتك ، فقط لأنه لأسباب وجيهة قررت شركة السيارات عدم إنتاج سيارات صديقة للبيئة.

يبدو أن رايان هو الوسيط هنا ويغلق القضية. لهذا السبب. إذا كان مرجعًا لغويًا ، فربما لا ينبغي عليه إغلاق المشكلة قبل بذل جهد لفهم حاجتي ورفض هذا الطلب دون تقديم مثال على كيفية القيام بذلك باستخدام ميزات اللغة الأم. لقد ذكرت أنني أرغب في حل وقت التجميع. وأنا مطور جيد جدًا وكنت موجودًا منذ فترة في البرمجة بالعديد من اللغات المختلفة والغامضة ، وما زلت أعاني من صعوبة في بناء جملة mixin. لا أفهم كيف دخل شيء بهذا التعقيد ويصعب فهمه إلى اللغة ، ومع ذلك يرفض الجميع أناقة بناء الجملة الجزئي ، ببساطة ، على ما يبدو ، لأنه مستعار من C #.

يبدو أن رايان هو الوسيط هنا ويغلق القضية. لهذا السبب. إذا كان مرجعًا لغويًا ، فربما لا ينبغي عليه إغلاق المشكلة قبل بذل جهد لفهم حاجتي

🤔

RyanCavanaugh ، أعلم أنك بذلت جهدًا للمساعدة. وفي هذه المرحلة ، أنتقل إلى تجربة الخلطات. أو مجرد إرث ، أو ربما أنا في عجلة من أمري لإنجاز هذا المشروع لدرجة أنني أتجاهل طريقة للقيام بذلك باستخدام الأدوية الجنيسة. همم...
بالميراث والتسمية ، يمكنني أن أفعل:

class AddressBase // this is a code generated class
{
    public address: string;
    public city: string;
    public state: string;
    public zip: string;

    constructor( jsonFromService: any )
    {
        this.OnInit( jsonFromService );
    }

    OnInit( jsonFromService: any )
    {
        // could use Object.assign here
        this.address = jsonFromService.address;
        this.city = jsonFromService.city;
        this.state = jsonFromService.state;
        this.zip = jsonFromService.zip;
    }
}

class ContactBase // this is also a code generated class
{
    public firstName: string;
    public lastName: string;

    constructor( jsonFromService: any )
    {
        this.OnInit( jsonFromService );
    }

    OnInit( jsonFromService: any )
    {
        // could use Object.assign here
        this.firstName = jsonFromService.firstName;
        this.lastName = jsonFromService.lastName;
    }
}

// classes that extend the functionality of the code generated classes:
class Address extends AddressBase // subclass simply because I don't want to have to use AddressBase all over my codebase, and then refactor if I ever extend the class
{
}

class Contact extends ContactBase
{
    public Addresses: Address[] = []; // THIS is the customization/extension that cannot be code generated.

    OnInit( jsonFromService: any )
    {
        // note that jsonFromService receives a dto with a array of address info
        super.OnInit( jsonFromService );

        for ( let addr of jsonFromService.Addresses )
        {
            this.Addresses.push( new Address( addr ) );
        }
    }
}

وهذا يعمل بشكل جيد بالنسبة لي. إنه ليس جميلًا ويفرض على الفئات التي تم إنشاؤها في الكود أن يكون لها أسماء لا أريد استخدامها في الكود. لكن ، مرة أخرى ، إنه يعمل.

في الوقت الحالي ، أشعر أن الرجال ، الذين يعارضون الطبقات الجزئية بشدة ، يسيئون فهم مفهوم الطبقات الجزئية ، ويعتقدون أن الفصول الجزئية شيء ليس الطبقات الجزئية.

لتوضيح الأمر: الصنف الجزئي عبارة عن بناء نحوي يسمح لك بتقسيم تعريف نفس الفئة الفردية إلى عدة ملفات مادية. الكلمات الرئيسية هنا هي "متشابهة" و "مفردة".

تعطي وثائق TypeScript تعريفًا سيئًا للفئات الجزئية (الفقرة الأولى هنا: https://www.typescriptlang.org/docs/handbook/mixins.html ).

مثال على مفهوم الفصول الجزئية الحقيقية :

ملف "Point.generated.ts":

partial class Point {
   readonly x: number;
   readonly y: number;
}

ملف "Point.codeByHand.ts":

partial class Point {
  constructor(x: number, y: number) {
      this.x = x;
      this.y = y;
  }

  translate(dx: number, dy: number): Point 
  {
      return new Point(this.x + dx, this.y + dy);
  }
}

يتم تجميعها في "Point.js" - ويأتي الاسم من اسم فئة ، وليس من أسماء الملفات:

var Point = (function () {
    function Point(x, y) {
        this.x = x;
        this.y = y;
    }
    Point.prototype.translate = function (dx, dy) {
        return new Point(this.x + dx, this.y + dy);
    };
    return Point;
}());

Mixins ، عند استخدامها كـ "فئات جزئية" (وأعتقد بشدة أن هذا المصطلح في التوثيق يساء استخدامه ) يمثل في الواقع وراثة متعددة ( https://en.wikipedia.org/wiki/Multiple_inheritance ).

لذلك ، كما نرى ، نناقش أداتين مختلفتين: فئات جزئية حقيقية ووراثة متعددة. هاتان أداتان مختلفتان. وكأي أداة - لديهم مجال التطبيق الخاص بهم. بمعنى آخر: قد يستخدم النجار المطرقة بدلاً من المطرقة ، عندما لا تكون المطرقة متاحة ، لكن المطرقة ليست هي الأداة الصحيحة.

IMHO ، هذا النقاش ليس له مستقبل ويجب أن نوقفه. بينما ما زلت لا أرى أي مشاكل تكنولوجية للفئات الجزئية الحقيقية ، فإن الفريق لا يرغب حقًا في تنفيذها ، على الأقل في الوقت الحالي.

لا يرغب فريق TS في تنفيذ ميزات خاصة بـ TS إن أمكن. إذا كنت تريد مناقشة المزيد ، فإليك مكانًا أفضل: https://esdiscuss.org/topic/class-syntax-enhancements

آمل أن يكون هناك مستودع GitHub على

تضمين التغريدة

في الوقت الحالي ، أشعر أن الرجال ، الذين يعارضون الطبقات الجزئية بشدة ، يسيئون فهم مفهوم الطبقات الجزئية ، ويعتقدون أن الفصول الجزئية شيء ليس الطبقات الجزئية.

لتوضيح الأمر: الصنف الجزئي عبارة عن بناء نحوي يسمح لك بتقسيم تعريف نفس الفئة الفردية إلى عدة ملفات مادية. الكلمات الرئيسية هنا هي "متشابهة" و "مفردة".

لا أعتقد أن أي شخص هنا يسيء فهم تعريف الفئات الجزئية ، أعتقد أنك ربما تسيء فهم تعريف الفئات في JavaScript.

إذا كان لديك انطباع بأن فئات JavaScript تشبه على الإطلاق الفئات الموجودة في أي لغة أخرى مستخدمة على نطاق واسع ، فقد يبدو لك أن الآخرين يسيئون فهمهم.

ومع ذلك ، كما قيل عدة مرات في هذه المناقشة ، أعلم أنني قلت ذلك صراحة مرة واحدة على الأقل ، فصول JavaScript ليست تركيبات تعريفية فهي ضرورية.

لا توجد حتى يتم تنفيذ العبارات.

تحديدها يعتمد على الطفرة.

هذا يجعلها بالفعل هشة وتعتمد على النظام عندما يتعلق الأمر بالميراث.

هذا يمكن أن يستمر ...

تضمين التغريدة

لا أفهم كيف دخل شيء بهذا التعقيد ويصعب فهمه إلى اللغة ، ومع ذلك يرفض الجميع أناقة بناء الجملة الجزئي ، ببساطة ، على ما يبدو ، لأنه مستعار من C #.

أنا حقا لا أعتقد أن هذا صحيح. الجميع يحب C # ، حتى مبرمجي Java 😛 ، ولا يختلف TypeScript من أجل الاختلاف.

تضمين التغريدة

أعتقد أنك ربما تسيء فهم تعريف الفئات في JavaScript ...

للاستشهاد به وأدناه: أنا أتحدث عن TypeScript.
كما قلت: لا أرى أي مشكلة فنية في تنفيذ فئات جزئية حقيقية في TypeScript ، والتي سيتم تجميعها في تركيبات JavaScript.

تضمين التغريدة

للاستشهاد به وأدناه: أنا أتحدث عن TypeScript.
كما قلت: لا أرى أي مشكلة فنية في تنفيذ فئات جزئية حقيقية في TypeScript ، والتي سيتم تجميعها في تركيبات JavaScript.

المشكلة في هذا satatement لا يوجد شيء مثل فئة TypeScript.

يا ولد! سيستخدم بعض الناس أي شيء كسبب.
حسنًا ، لا توجد فئات في TypeScript. أو فئات TypeScript. أو أيا كان. ايا كان.

أعني أنها فئات JavaScript. بينما أكون مذنبًا في بعض الأحيان لكوني متحذلقًا ، فأنا أقوم بهذا التمييز على وجه التحديد لأننا نحتاج إلى الاتفاق على تعريف مصطلح فئة قبل أن نتمكن من مناقشة الميزات التي يمكن إضافتها إليها.

أعتقد أننا لا نعني نفس الشيء عندما نتحدث عن الطبقات وهذا يسبب تنافرًا معرفيًا ويعيق التفاهم المتبادل.

أعتقد أننا لا نعني نفس الشيء عندما نتحدث عن الطبقات وهذا يسبب تنافرًا معرفيًا ويعيق التفاهم المتبادل ..
موافق تماما!

في الواقع ، فإن المشاركة الأولى في هذا الموضوع تصف تمامًا ما تم طلبه ، وبالتالي فإن هذه المناقشة ليس لها مستقبل :)

greendimka نعم ، ليس لها مستقبل حيث يبدو أن TypeScript لن تحتوي على فئات جزئية أبدًا. من وجهة نظري ، هذا شيء جيد.

ومع ذلك ، فإن سوء الفهم وسوء الاتصال ليست أشياء جيدة ولهذا السبب ما زلت أتحدث معك.

لسوء الحظ ، لا يبدو أنك مهتم بأي منهما

ج: شرح ما هي فئات JavaScript هو أنه يمكن للمرء أن يغير رأيه ويتفق معك على أنه يمكن جعلها قابلة للتجزئة بشكل تافه.

ب. التعلم من الآخرين حول ماهية فئات JavaScript بحيث يجب أن تفهم وجهة النظر المعارضة.

أعتقد أن هذا عار ، لكنني لن أناقش الأمر أكثر إذا كنت ترغب في ذلك.

أنا لست ضد أي مناقشات. ولكن قيل عدة مرات هنا أنه لن يتم تنفيذ الفصول الجزئية (على الأقل ليس الآن). لذلك أعتقد أنه من الأفضل التركيز على أشياء أخرى. ربما يمكن تغيير TypeScript في المستقبل ، من يدري.
بالنسبة إلى A و B. أنا أكره JavaScript. لكنني أعرف ذلك جيدًا ، وبالطبع أعرف كيف "يتم تمثيل" الفصول فيه. لكن الهدف من هذه المناقشة بأكملها لم يكن تعديل JavaScript ، ولكن لتحسين قدرات TypeScript ، كلغة أعلى ، والتي تنتج كود JavaScript "منخفض المستوى".
تخيل أننا سنستبدل TypeScript بـ C ++ و JavaScript برمز الجهاز. تفتقر شفرة الآلة إلى معظم المفاهيم الموجودة في C ++. ولكن هل يجب أن تتوقف لغة ++ C عن التطور بسبب ذلك؟ بالطبع لا. هل يجب أن يتوقف عن التطور لأن بعض المترجمين القدامى لن يكونوا قادرين على التجميع؟ بالطبع لا - أنت تعطي ميزة جديدة للمطورين وتخبرهم: إنها تعمل مع المجمعين الجدد - أنت (المطورين) تقرر ما إذا كنت تريد استخدامها.

تضمين التغريدة
يا رجل يا رجل. من يهتم بجزء جافا سكريبت من المعادلة؟ TypeScript هي طبقة أعلاه ، أو على أي حال تريد صياغتها. هل تتذكر مناقشات 4GL مقابل 3GL القديمة؟ TypeScript بالنسبة إلى Javascript حيث أن 4GL هو 3GL ، نوع من. كما أن الحجة القائلة بأن TypeScript هو ES6 مع أنواع قوية ، وبالتالي فإن Partial Classes خارج نطاق خارطة طريق TypeScript هي LAME. لدينا Mixins ، Generics ، Modules ، Name Spaces و Type Casting. فلماذا لا تبذل جهدًا إضافيًا مع الفصول الجزئية؟

كل ما نريده من الفئات الجزئية هو السكر النحوي الذي يمكننا من دمج جميع التعريفات المختلفة لفئة TypeScript واحدة في تعريف نهائي واحد - مستوى منخفض - 3GL - فئة Javascript. يجب ألا يكون هناك أي تأثير على تعريف فئة JavaScript النهائي ، أليس كذلك؟ لماذا يعتبر المنتج النهائي للترجمة إلى جافا سكريبت جزءًا من هذه المناقشة؟ عنجد.

cosmoKenney "نصها الوحيد مع الأنواع" هو نقطة بيع كبيرة تحول مطوري JavaScript. إذا كنت تريد شيئًا أكثر ، فأنت تنظر إلى اللغة الخطأ. ربما جرب Scala.js بدلاً من ذلك؟

تحرير: لقد أدركت للتو أنه يمكن تنفيذ الفصول الجزئية في ES.next باستخدام أداة تحميل وحدة مخصصة. كما ترى

import {MyClass} from './myclass.*'

يمكن للمُحمل دمج جميع تعريفات MyClass المُصدَّرة من أي ملفات تطابق حرف البدل في فئة واحدة ، ثم توفير ذلك.

spion أحب الطريقة التي تشير إليها بشكل صحيح تمامًا باسم ES.next class class. ستدعم أداة تحميل الوحدة النمطية ES ، مثل المستعرض ، أو محمل polyfill ، مثل SystemJS ، الفئات الجزئية.
تتمثل إحدى المشكلات الأساسية في إضافة هذه الميزة على مستوى TypeScript في أنها تكسر الأدوات الموجودة مثل اللوادر والرازم. من ناحية أخرى ، إذا حددتها ECMAScript ، فستقوم كل هذه الأدوات بتنفيذ الميزة وسيظل TypeScript متوافقًا مع كل هذه الأدوات.

أنا بالتأكيد أتفق معك بخصوص Scala.js

تضمين التغريدة

لدينا Mixins ، Generics ، Modules ، Name Spaces و Type Casting. فلماذا لا تبذل جهدًا إضافيًا مع الفصول الجزئية؟

Mixins كما هو موضح في TypeScript هي نمط تصميم ECMAScript من TypeScript _types_.

علم الوراثة هي ميزة نظام نوع لذا فهي لا تنطبق.

الوحدات النمطية هي ميزة ECMAScript.

مساحات الأسماء هي عبارة عن سكر نحوي لإضفاء الطابع الرسمي على نمط تصميم ECMAScript.

نوع Casting غير موجود في TypeScript.

aluanhaddad لماذا تستمر في جعل هذا الأمر وقت التشغيل؟ اللوادر النمطية وكل ما لا علاقة له بالترشيح.

+1

تضمين التغريدة

aluanhaddad لماذا تستمر في جعل هذا الأمر وقت التشغيل؟ اللوادر النمطية وكل ما لا علاقة له بالترشيح.

هذا ليس صحيحا.

انظر إلى الأنظمة البيئية SystemJS و Webpack وسترى خلاف ذلك.

حتى أن تدفقات عمل gulp التقليدية والصخرية تعتمد على المراسلات بين ملفات الإدخال والإخراج.

+1

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