Typescript: من أجل .. مع التكرارات

هذا مسموح به بالفعل إذا كان هدفك هو ES6:

interface MyMap<T> {
    values(): Iterable<T>;
}
var myMap: MyMap<string>;

for (let value of myMap.values()) {
    var s: string = value;
}

سبب عدم السماح بذلك في ES5 / ES3 هو:

• تتمثل إحدى بديهيات TypeScript في عدم القيام بإصدار موجه بالكتابة. أي أن الكود المنبعث لا يعتمد على ما يفكر فيه نظام النوع بشأن الكود الخاص بك ، بل على أنه تحويل نحوي لمصدر الإدخال الخاص بك.
• سيعني إجراء محاكاة المكرر الكاملة أنه يتعين علينا الاعتماد على pollyfill للرمز ، ومرة ​​أخرى جودة أخرى نود الاحتفاظ بها
• منطق التكرار الكامل الذي تم إنشاؤه ليس رقيقًا ، فأنت بحاجة إلى استدعاء التالي () والتحقق من ذلك ، إذا فشل في العودة إذا لم تستخدم القيمة. هذا إرسال إضافي ، بحثان عن الخصائص ، وتخصيص كائن على كل تكرار للحلقة. لقد حاولنا إبقاء الكود المنبعث بسيطًا ومرتبطًا بالمصدر خاصة في خصائص الأداء
• أخيرًا للقيام بكل ذلك على كائنات مخصصة قابلة للتكرار ، ما زلنا بحاجة إلى القيام بذلك على المصفوفات ، نظرًا لأن المصفوفات لا تتمتع بهذا الدعم في ES5 / ES3 ، ولا نريد إجراء إصدار موجه بنوع ، نحتاج إلى تحويل مصفوفة إلى تكرار ، وهو أبطأ بشكل كبير من حلقة for العادية. والمسألة الرئيسية هي أنه ليس من الواضح من النظر إلى حلقة على مصفوفة أنها ستتكبد هذه التكلفة.

نتيجة لهذه العوامل ، في ES3 / ES5 يُسمح فقط بالمصفوفات for.. of loops (باعتبارها أكثر الكائنات القابلة للتكرار شيوعًا المتوفرة في لغة JS اليوم) ؛ بالنسبة لاستهداف ES6 (أي مع دعم محرك وقت التشغيل للصفائف القابلة للتكرار والمصفوفات القابلة للتكرار) يُسمح بالمتكررات المخصصة بالإضافة إلى المصفوفة والسلسلة والخريطة والمجموعة .. إلخ.

فهمت ...
mhegazy شكرا جزيلا على ردكم المفصل !!!

أجد هذا مخيبا للآمال حقا. يمكنني استخدام for-of مع أي تكراري واستهداف ES5 مع Traceur و Babel اليوم. أنا مهتم باقتراح قيام فريقنا بالتبديل من Traceur إلى TypeScript ، لكن هذا القيد في TypeScript سيوقف ذلك من الحدوث. عندما تقول TypeScript إنها تهدف إلى أن تكون مجموعة شاملة من ES6 ، أعتقد أن ذلك يجب أن يشمل القدرة على استهداف متصفحات ES5 لجميع ميزات ES6 التي يدعمها.

أعتقد أنه يمكنني استخدام TypeScript لاستهداف ES6 ثم تشغيل هذا الإخراج من خلال Traceur أو Babel. أنا حقا لا أريد أن أفعل ذلك رغم ذلك.

كتحديث لهذه المشكلة ، يتم دعم بروتوكول المكرر الآن للهدف ES3 / ES5 باستخدام --downlevelIteration . راجع # 12346 لمزيد من المعلومات.

يبدو أنه من المفترض أن يتم إصلاح هذا في TS 2.3 ، لكني أقوم بتشغيل TS 2.3.3 و

      for (let [ i, observationPoint ] of observationPointsList.entries())
        observationPoints[ observationPoint.spot || (i + 1) ] = observationPoint;

حيث observationPointsList هو ObservationPointModel[] ، ينتج عنه:

[11:30:56]  typescript: src/models/observation-set.ts, line: 44 
            Type 'IterableIterator<[number, ObservationPointModel]>' is not an array type or a string type. 

هل فاتني شيء؟

lhunath يجب تحديد الخيار --downlevelIteration .

آه ، حقًا. لا أستطيع أن أرى في هذه الوثائق أو # 12346 - لماذا هذا مخفي خلف خيار مقابل السلوك القياسي؟ هل سيبقى هذا دائمًا اختياريًا؟

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