ما رأي فريق TypeScript في بناء الجملة واستخدام بادئة رمز / حرف؟

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

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

للإضافة إلى ذلك ، هناك محادثات حول إمكانية تبديل رموز # و @ حولها (على سبيل المثال استخدام # للمصممين) ، والذي سيكون له تأثير واضح على TypeScript أيضًا .

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

تحتاج الاستخدامات إلى تحديد الرؤية ، لأسباب لا أفهمها تمامًا

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

تتمثل إحدى ميزات الصيغة المقترحة في أنه يمكنك حذف this واستخدام #field مباشرةً. علاوة على ذلك ، قد يتم تبديل sigil بالمصممون (https://github.com/tc39/proposal-private-fields/issues/32) وبدلاً من ذلك سيتم استخدام @ ، لذلك ستستخدم @field ، تمامًا مثل روبي. هل تجد هذا النحو قبيح لا يزال؟

لا أعتقد أن الناس سيكونون سعداء بحل غير "خاص" يعتمد على الكلمات الرئيسية.

لا أرى طريقة جيدة للقيام بذلك أثناء دعم eval كما تفعل JavaScript - يسمح الرمز المميز ببعض التمايز ويجعل من الممكن دعم الحالة الخاصة التي لا تعتمد على نظام نوع ثابت كما في TypeScript . لقد ناقشنا عددًا من بدائل بناء الجملة على https://github.com/tc39/proposal-private-fields/issues/14 ، ولا أرى البنية الحالية لـ TypeScript كشيء يمكن أن يعمل بشكل صحيح طوال الوقت في بيئة JS العامة بالكامل.

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

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

هل تجد هذا النحو قبيح لا يزال؟

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

| اللغة | بناء الجملة | ملاحظات |
| --- | --- | --- |
| سي # | int الخاصة x؛ | |
| C ++ | نشر:
كثافة العمليات س ؛ | |
| جافا | int الخاصة x؛ | |
| PHP | x دولار خاص ؛ | |
| بايثون | __x | "لا تعليق" |
| روبي | نشر
طريقة مواطنه
# ...
نهاية | إنها طريقة ، لكن الحقول خاصة
بشكل افتراضي أعتقد. |
| تيبسكريبت | خاص x ؛ | |
| فيجوال بيسك | خاص x كعدد صحيح | |

كل اللغات المذكورة أعلاه ما عدا _ واحدة_ تستخدم الكلمة الرئيسية private ، ويبدو أن Python ليس لديها حالة خاصة "مناسبة" على أي حال.

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

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

لا أرى طريقة جيدة للقيام بذلك أثناء دعم التقييم العام كما يفعل JavaScript

هل سيكون من الممكن شرح هذه المسألة من منظور الشخص العادي؟ (ربما في https://github.com/tc39/proposal-private-fields/issues/14)

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

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

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

1. انظر على سبيل المثال للممتلكات الخاصة.
2. إذا لم يكن هناك ملكية خاصة ، فابحث عن النموذج الأولي للممتلكات الخاصة.
3. سلسلة النموذج الأولي التصاعدي حتى لا يتم العثور على خاصية.
4. إذا تم العثور على صفقة مع واصف الخاصية (قابل للكتابة ، احصل ، ضبط ، قابل للتكوين)
5. إذا لم يتم العثور عليها وقراءتها ، فقم بإرجاع undefined أو اكتب القيمة كخاصية خاصة إذا لم يتم إغلاقها أو تجميدها.

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

التحدي الأكبر هو أن فئات JavaScript لا تزال تسمية خاطئة إلى حد ما. هم في الأساس سكر نحوي لوظائف مُنشئ الوراثة النموذجية. هناك فكرة واحدة خطرت لي والتي سأحاول إضافتها إلى tc39 / اقتراح-خاص-الحقول # 14.

هل سيكون من الممكن شرح هذه المسألة من منظور الشخص العادي؟

إذا تطلب الأمر إعادة كتابة موقع الاتصال ، فلن تتمكن أبدًا من دعم أشياء مثل:

class Foo {
    private foobar: string;
    baz() {
        const p = 'foo' + 'bar';
        console.log(this[p]);
    }
}

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

لن يكون لديك ممتلكات خاصة ، سيكون لديك شيء مثل الممتلكات الخاصة

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

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

AFAIK ، لن يتم دعم ذلك على أي حال ( المرجع ).

ما زلت لا أتابع حالة EVAL حقًا. اعتقدت أن عمليات التحقق من الممتلكات ستتم في وقت التشغيل ، بعد حساب أسماء الممتلكات.

لكن الناس ما زالوا "لكني أحب الخصوصية"

أحاول ألا أكون واحداً من هؤلاء الأشخاص ، وأن أفهم القضايا ، لكن الصيغة المقترحة تجعلني غير مرتاح. =)

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

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

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

(ربما أفتقد شيئًا واضحًا)

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

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

@ glen-84 تشير كلتا التدوينتين اللتين ذكرتهما إلى وجود مشاكل في حالة عدم وجود sigil'd الخاصة. هل لديك أفكار لإيجاد حلول لتلك المشاكل؟ أعتقد أن تعقيد سلسلة البحث سيكون محفوفًا بالمخاطر من حيث التوافق ، مما يجعل تنفيذ JavaScript أكثر صعوبة مع الأداء الجيد (ربما يجعل البرامج الحالية أبطأ) ، ومن المستحيل أساسًا التوافق مع البروكسيات ، وبشكل عام ، يعقد النموذج العقلي للغة بشكل كبير (والذي يحتوي بالفعل على نظام كائن معقد نسبيًا).

في المقارنة بين اللغات ، ذكرت روبي. أعتقد أن روبي هي مثال جيد للدولة الخاصة _ مع علامة سيجيل- @ . يمكنك استدعاء أساليب getter و setter بدون سيجيل.

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

قصدت الانتقال إذا لم يكن العقار في الفصل الحالي ، للبحث عن ملكية عامة أو محمية.

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

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

You'd have to somehow encode a "private key" into each lexical environment.

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

You'd have to change the semantics of each and every property access (because any property access might result in a private field). Engines are highly optimized around the current property lookup semantics.

هل هو مُحسَّن للغاية لدرجة أن مفتاحًا واحدًا للرؤية سيؤثر بشكل كبير على الأداء؟

Would for-in enumerate over these properties?

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

Can someone shadow a private property with a normal property lower on the prototype chain? What about the reverse?

ربما نعم (تمت زيادة الرؤية) للسؤال الأول ، ولا للسؤال الثاني. مرة أخرى ، لقد تم كل هذا من قبل ، أليس كذلك؟

How do you prevent leaking the names of private fields to clients that shouldn't know that information? This is probably a fatal information leak.

الرؤية هي مجرد أداة لتغليف وتحديد واجهة عامة. 99٪ من المطورين ربما لا يهتمون بـ "تسرب المعلومات". ومع ذلك ، فقد اقترحت هنا ميزتين منفصلتين. ربما يمكن تسمية هذا الاقتراح بشيء مختلف ، مثل "الدولة المخفية" أو "الدولة الآمنة" ، والسماح بتنفيذ شيء مثل الدولة الخاصة / المحمية بشكل مختلف.

All of this runtime stuff is going to be terrible for performance

استخدم "الحالة المخفية / الآمنة" إذا كنت تريد الأداء. : د بكل جدية ما هو نوع الخسارة في الأداء الذي نتحدث عنه؟ ربما يمكن لشخص ما إنشاء نموذج أولي. =)

Also, we couldn't use such a solution to self-host the built-ins

ألن تكون عناصر الاستضافة الذاتية المضمنة (إذا فهمت حتى ما يعنيه ذلك) سيئة للأداء؟ إذا لم يكن كذلك ... استخدم "الحالة المخفية / الآمنة" وليس الرؤية الخاصة / المحمية ذات المستوى الأعلى.

أعتقد أن تعقيد سلسلة البحث سيكون محفوفًا بالمخاطر من حيث التوافق

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

أعتقد أن روبي هي مثال جيد للدولة الخاصة باستخدام علامة سيجيل - @

روبي ليست حتى لغة عائلة C ، ولا توجد مجالات عامة على ما يبدو ، ولكن فقط حاصلون ومُحددون (accessors). يحتوي مقترح الدولة الخاص الحالي على العديد من الإعلانات جنبًا إلى جنب ، مع نفس الغرض العام (إعلان الخصائص) ، ولكن هناك تراكيب مختلفة وغير متسقة بشكل واضح.

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

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

ما رأي فريق TypeScript في بناء الجملة واستخدام بادئة رمز / حرف؟

أنا شخصياً أعتقد أنه يبدو فظيعًا ...

ملاحظة لقد قدمت اقتراحًا للتخلص من البنية الفظيعة # .

@ shelby3 لسوء الحظ ، لا أرى ذلك كخيار واقعي. tl ؛ دكتور ، علينا أن نقلق بشأن كيفية تفاعل كل شيء مع eval ؛ عدم تضمين سيجيل يجعل كل شيء "ديناميكيًا جدًا" للعمل بشكل صحيح.

littledan لقد تابعت هناك الآن وقدمت أقوى حجة لدي ضد استخدام sigil ، لزيادة التوافق مع TypeScript . أنا أفهم الآن على الرغم من لماذا يجب أن نعلن خصوصية الحجج غير المصنفة للطرق.

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

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

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

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

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

تساهم إمكانية الوصول إلى الخصائص الخاصة في وقت التشغيل إلى حد كبير في قابلية الاختبار لأنني قادر على حقن الحالة الخاصة في فئة قيد الاختبار بمجرد تعيين الحقول الخاصة (في TypeScript ، أوصي باستخدام تدوين القوس بدلاً من any casts بسبب الأفضل دعم إعادة البناء) ، على سبيل المثال:

let instance: ClassUnderTest = new ClassUnderTest();
instance["_privateField"] = "My injected state";

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

@ about-code راجع https://github.com/tc39/proposal-private-fields/issues/33

لا أعتقد أن مجتمع TypeScript سيسعد بتغيير كل خطوطهم private variable إلى private #variable .

من منظور TypeScript ، يسعد معظمنا بأوهامنا الجميلة والرائعة للغة جيدة (التحسس ، أخطاء وقت البناء ، الأنواع ، السكريات المختلفة). تمنحنا هذه الأوهام تجربة تطوير أفضل ، فنحن نكتب كود أفضل بشكل أسرع. هذا هو السبب الرئيسي وراء استخدامنا TS إلى جانب ESNext transpilation - ولكن بالنسبة للأخير ، يوجد Babel وهذا أفضل (أو على الأقل كان أفضل عندما تحققت مؤخرًا).

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

لكن بالنسبة للبقية منا: لا نحتاج حقًا إلى JS private. نحتاج إلى المتغيرات البسيطة والسهلة private convenient تمامًا كما استخدمناها في C ++ و Java و C # وما إلى ذلك.

يرجى التصويت على حل لن يكون مؤلمًا بالنسبة لنا. ربما لينة خاصة؟ لأنني أشك في أننا نريد sigil الخاص #variable . أو ربما يكون TS private و ES الخاص مفاهيم مختلفة؟ قبيح.

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

لا أعتقد أن مجتمع TypeScript سيسعد بتغيير كل خطوطهم private variable إلى private #variable

في الواقع ، مع هذا الاقتراح ، سيكون private غير ضروري. بدلاً من ذلك ، فإن # sigil يستبدلها بالكامل بدون تعارض.

لكن بالنسبة للبقية منا: لا نحتاج حقًا إلى JS private. نحتاج إلى المتغيرات البسيطة والسهلة الخاصة والمريحة تمامًا كما استخدمناها في C ++ و Java و C # وما إلى ذلك.

يتميز TypeScript الخاص بخصوصية ناعمة ، مثل معظم لغات OO. حتى المتغيرات الخاصة في Java لا تزال خاصة من الناحية الفنية ، لأنها لا تزال متاحة من خلال فتحة الهروب. JS private يعادل استخدام الإغلاق ، باستثناء أنه لا يزال بإمكانك الوصول إلى الحالة الخاصة لمثيلات غير this .

يرجى التصويت على حل لن يكون مؤلمًا بالنسبة لنا. ربما لينة خاصة؟ لأنني أشك في أننا نريد sigil الخاص # متغير. أو ربما يكون TS الخاص و ES الخاص مفاهيم مختلفة؟ قبيح.

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

بالإضافة إلى ذلك ، بمجرد أن تقوم ES بتوحيد الدولة الخاصة ، ستتبناها TS ومن المحتمل أن تتخلى عن آليتها الخاصة الناعمة ، ليتم إزالتها في الإصدار الرئيسي التالي. لقد كانت دائمًا مجموعة شاملة صارمة من ES ، وقد أضافت (وظائف غير متزامنة) و / أو تم تغييرها (فئات) و / أو تم إهمالها ( /// <amd-dependency /> ) ميزات حسب الضرورة مع تطور ES نفسها ، للحفاظ على نفسها باعتبارها صارمة مجموعة شاملة وليست مكررة للمواصفات الحالية.

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

😭

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

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

تضمين التغريدة أنا أقف بشكل صحيح. (لقد كان تخمينًا متعلمًا ، راجع للشغل).

اقتراح حقول الفصل في المرحلة 2 الآن ، لذلك أنا سعيد بفكر فريق TypeScript في هذا الأمر وجاهز لاتباع معايير EcmaScript 💯

إذا وعندما يصل اقتراح الدولة الخاصة إلى الحالة الصحيحة ، فسيقوم TS بتنفيذه.

mhegazy هل المرحلة الثالثة هي الوقت المناسب للتنفيذ؟

تحرير: ربما وجدت إجابتي 😄

styfle راجع المناقشة من ملاحظات اجتماع التصميم (# 16415) التي تناقش الاعتبارات الحالية حول التنفيذ.

هل المرحلة الثالثة هي الوقت المناسب للتنفيذ؟

نعم فعلا. لقد بدأنا في التحقيق في التصميمات المختلفة الممكنة لهذه الميزة.

اقتراح حقول الفصل الآن في المرحلة الثالثة. (اعتبارًا من شهر مضى)

اقتراح حقول الفصل الآن في المرحلة الثالثة. (اعتبارًا من شهر مضى)

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

أي تحديث حول موقف / تقدم فريق TS في اعتماد بناء الجملة #[field] الآن بعد أن كان في المرحلة 3 لفترة من الوقت؟ أنا شخصياً لا أحبها حقًا ، وأفضل كثيرًا الكلمات الرئيسية الحالية لـ TS private ، لكن في نفس الوقت أريد أن أكون قريبًا من المعايير قدر الإمكان.

أنا شخصياً لا أحبها حقًا ، وأفضل كثيرًا الكلمات الرئيسية الخاصة الموجودة في TS

أنا أيضًا ، إنه قبيح جدًا

لكن mhegazy أود (محاولة) القيام بذلك ، هل يمكنني ذلك؟

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

يكفي القول ، هناك الكثير هنا.

weswigham طيب ، أنا أستسلم 😂

في ما يلي تنبيه سأقوم (مع

تحديث: عملنا قيد التقدم هنا .

نعم فعلا. لقد بدأنا في التحقيق في التصميمات المختلفة الممكنة لهذه الميزة.

لا أحب بناء جملة # أيضًا ، لكنني أفهم الأسباب الفنية وراء هذا التركيب. mhegazy ما أود حقًا فعله بواسطة فريق TypeScript بعد تنفيذ اقتراح جديد للتفكير في ما ستفعله TypeScript بالتطبيقات القديمة مثل namespace ، private والتي يمكن استخدامها ولكن يجب استخدامها بشكل عام ليس نظرًا لوجود طريقة أفضل للمعايير es لفعل الشيء نفسه أو تقريبًا.

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

pleerock ،

هذا ما أتوقع رؤيته من TypeScript:

class Example {
    private a = 1;
    #b = 2;
}

انبعاث (استهداف ESNext):

class Example {
    a = 1;
    #b = 2;
}

Emit (استهداف ESNext ، مع خيار مترجم جديد لإرسال الحقول المميزة كحقول خاصة على أنها حقول ES):

class Example {
    #a = 1;
    #b = 2;
}

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

@ glen-84 بالطبع سيكون الأمر كذلك ، كنت أتحدث عن خطة طويلة المدى بشأن الكلمات الرئيسية والنحو القديمة

ليس لدينا أي خطط لإهمال أي بناء جملة أو كلمات رئيسية.

لا أعتقد أيضًا أنه سيكون لدينا خيار من أي نوع لتحويل private إلى # - لديهم سلوك متوقع مختلف ؛ # هو خصوصية وقت التشغيل الصعب ، بينما private هو مجرد خصوصية وقت التصميم.

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

يكتشف الناس هذا بشكل عام بناءً على قراءة الوثائق ، والتي نقوم بالطبع بتحديثها. module foo { موجودًا في اللغة ولكنه لم يعد موجودًا في الحياة البرية بعد الآن باستثناء قواعد الرموز القديمة جدًا التي تسبق namespace foo { .

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

لا أعتقد أيضًا أنه سيكون لدينا خيار من أي نوع لتحويل الخاص إلى # - لديهم سلوك متوقع مختلف ؛ # هي خصوصية وقت التشغيل الصعب ، بينما الخصوصية هي فقط خصوصية وقت التصميم.

D'oh. كنت آمل أن نتمكن من استخدام private اختياريًا للخصوصية الشديدة أيضًا ، لتجنب ... بناء الجملة المؤسف.

على أي حال ، ربما تكون ميزة soft-private كافية لحالات الاستخدام (الحالية) الخاصة بي.

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

التحرير: لقد نسيت أن الإصدار 3 قد تم إصداره بالفعل.

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

• https://github.com/tc39/proposal-class-fields/issues/100
• https://github.com/tc39/proposal-class-fields/issues/106

أنا لست TC39 ، ولكن اقتراحي الشخصي للجميع هو الانتظار أولاً حتى يتم ترسيخ بناء الجملة مرة أخرى (ربما انتظار المرحلة 4) ، ثم تنفيذها.

FWIW لن أفسر المناقشة في tc39 / المقترحة-class-field # 100 على أنها تشير إلى أي شيء على وجه الخصوص. # ليس جميلًا في البداية ، ولكن لم يتم اقتراح أي شكل نحوي مفضل والصيغة الوحيدة التي يبدو أن الناس يريدونها غير قابلة للتطبيق بشكل واضح. يجب أن تكون هناك بادئة sigil من نوع ما وجميع المحاولات للسماح لـ this.someProp أن تكون خاصة محكوم عليها بالفشل.

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

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

أوافق على أنه ربما لا تكون المشكلة المثالية ذكرها ، ولكن الأخرى ،
من المحتمل أن تكون tc39 / offer-class-Field # 106 أكثر إرشادية - هناك
مناقشة جادة حول استخدام الخرائط الضعيفة بدلاً من ذلك ، من بين أمور أخرى ، لأن
الوكيل المتداخل تمتص بوضوح.

إيشيا ميدوز
[email protected]
www.isiahmeadows.com

في يوم الإثنين 30 يوليو 2018 الساعة 3:38 مساءً ، أرسل Ryan Cavanaugh [email protected]
كتب:

FWIW لن أفسر المناقشة في
tc39 / اقتراح-فئة الحقول # 100
https://github.com/tc39/proposal-class-fields/issues/100 ليكون
دلالة على أي شيء على وجه الخصوص. # ليست جميلة في البداية ، ولكن
لم يتم اقتراح أي شكل نحوي مفضل والصيغة الوحيدة لذلك
يبدو أن الناس يريدون غير عملي بشكل واضح. يجب أن يكون هناك بادئة
sigil من نوع ما وجميع المحاولات للسماح لـ this.someProp بأن تكون خاصة
محكوم عليها بالفشل.

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

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/9950#issuecomment-408984395 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AERrBGCphyQUu5lJQW7lgsqALLL3e0_Wks5uL2DLgaJpZM4JVDwV
.

هناك بعض المناقشات حول استخدام WeakMaps ، لكنني لا أرى كيف سيحسن ذلك التفاعل مع Proxy. أود دعوة أي عضو في TC39 لديه فكرة أخرى حول كيفية عمل ميزات الفصل الدراسي الخاص لتقديمها إلى اللجنة للحصول على تعليقات ؛ حاليًا ، هذا الاقتراح في المرحلة 3 ويمثل نظريًا الموقف الإجماعي للجنة. قدم العديد من الأشخاص تنازلات للوصول إلى هدف مشترك يتمثل في تمكين هذه الميزة ، حتى مع وجود تصميمات أخرى ممكنة.

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

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

FWIW لن أفسر المناقشة في tc39 / المقترحة-class-field # 100 على أنها مؤشر على أي شيء على وجه الخصوص. # ليس جميلًا في البداية ، ولكن لم يتم اقتراح أي شكل نحوي مفضل والصيغة الوحيدة التي يبدو أن الناس يريدونها غير قابلة للتطبيق بشكل واضح. يجب أن تكون هناك بادئة sigil من نوع ما وجميع المحاولات للسماح لـ this.someProp أن تكون خاصة محكوم عليها بالفشل.

في وقت متأخر من ذلك ، ولكن هناك بالفعل اقتراح يقترح بناء جملة this->var .

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

أعتقد أنه سيكون من الجيد أن يكون لديك خيار مترجم لجعل private تحويل إلى نوع من _soft_ خاص سيتم فرضه في وقت التشغيل. لا أعتقد أن حالة الاستخدام الخاصة بالحاجة إلى خصوصية حقيقية أمر شائع بشكل خاص ، لذلك حتى بغض النظر عن أي كراهية لبناء جملة # ، أعتقد أن معظم الناس يميلون إلى التمسك بـ private . لكن وقت الترجمة الخاص فقط _too_ soft IMO. أيضًا ، سيساعد هذا الخيار في تقليل عدد المتغيرات المحتملة للخاص ... إذا تُرك المطورون لتنفيذ ذلك بمفردهم ، فيمكنك الحصول على كل هذه:

class Demo {
  private a

  #b

  <strong i="9">@reflect</strong>
  #c
}

لذا أقترح أنه مع تمكين الخيار الجديد ، فإن private a سينتقل إلى <strong i="13">@reflect</strong> #a ، حيث @reflect هو مصمم يتيح الانعكاس على الممتلكات عبر واجهة برمجة تطبيقات يدعمها المجتمع. كان هناك بعض الحديث عن مكتبة ديكور قياسية ، لذا فإن مصمم الديكور @reflect (أو أي شيء نريد تسميته) يمكن توحيده في المستقبل ؛ أعتقد أنه سيكون مرشحًا جيدًا لذلك.

أفترض أن الجانب السلبي الرئيسي لاقتراحي سيكون تأثير الأداء. يمكننا أن نأمل أن يكون لدى JS يومًا ما بعض الديكورات القياسية التي يتم تنفيذها محليًا لتحسينها ، ولكن الحقيقة في المستقبل المنظور هي أن <strong i="19">@reflect</strong> #x سيكون أبطأ من #x . لكنني أقترح هذا كخيار فقط ، والذي ربما يجب تعطيله افتراضيًا (لأسباب تتعلق بالتوافق مع الإصدارات السابقة أيضًا).

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

في وقت متأخر من هذا ، ولكن هناك في الواقع اقتراح يقترح هذا-> var syntax.

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

قدمت اللجنة الكثير من الأسباب المدروسة جيدًا لتأييد الاقتراح الحالي بدلاً من اقتراح الفئات 1.1 ، على سبيل المثال https://github.com/tc39/proposal-class-fields/issues/100#issuecomment -429460917

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

ربما فاتني ذلك. كانت صفحة مشكلات الصفوف 1.1 غير نشطة لمدة نصف عام ، وحتى المثال الذي ربطته تمت كتابته بعد شهر من تعليقي.

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

تحرير: تعليقي لا يقترح أن يقوم TypeScript بأي شيء مختلف. أعتقد أنه من المفيد تصحيح المعلومات الخاطئة حول القضايا المشار إليها في الاقتراح.

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

مرحبًا يا رفاق ، في حال كان ذلك مفيدًا ، أود مشاركة التنفيذ الخاص بي لأعضاء محميين / خاصين في وقت التشغيل:

انظر lowclass .

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

ملحوظات:

• يستخدم WeakMaps لتخزين الدولة المحمية / الخاصة.
• على عكس التطبيقات الأخرى التي رأيتها ، فهو يعمل مع رمز غير متزامن مع عمليات الاسترجاعات / الوعود / الانتظار لأنه لا يعتمد على تتبع مكدس المكالمات المتزامن.
• إنه يعمل مع الحاصلين / الضباط (بما في ذلك المكالمات الفائقة) (انظر الاختبارات).
• يعمل مع super الأصلي ، أو باستخدام مساعد Super لـ ES5 (انظر الاختبارات).
• يدعم طريقة constructor (انظر الاختبارات).
• القدرة على تمديد الفصول المضمنة (باستثناء التاريخ ، لكنني أردت النظر في ذلك على الرغم من أن الناس يقولون إنه غير ممكن ولكني أريد تأكيد ذلك. انظر الاختبارات ، والعمل مع العناصر المخصصة الأصلية).
• القدرة على تمديد العادية الأصلية class es (انظر الاختبارات).
• التفاف أصلي class es ، مما يمنحهم قدرات محمية وخاصة (انظر الاختبارات).
• اكتب فئات ES5 على غرار function بدلاً من أصلي class es (انظر الاختبارات).
• مساحة كبيرة لتحسين الأداء (مثل التخزين المؤقت لمكالمات المساعد الفائقة / المحمية / الخاصة وتحسين البحث في algos)

لإجراء الاختبارات:

npm install
npm test

راجع أيضًا https://github.com/babel/proposals/issues/12 و https://github.com/babel/babel/issues/8421 للحصول على التفاصيل والمشكلات المتعلقة بتنفيذ Babel.

مرحبا بكم جميعا

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

يرجى قراءة هذا الموضوع .

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

fe هنا موضوع آخر (مع أفكار بناء جملة أفضل من # IMHO الحالي).

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

لذلك ، يتم شحن حقول الفصول الخاصة في V8 v7.2 و Chrome 72. هل هناك أي خطط لبدء تنفيذ اقتراح الحقول الخاصة؟

@ ChrisBrownie55 الحقول العامة هي الشحن. خاصة ليست كذلك.

jhpratt هذا أمر سيئ بالنسبة لي ، ولكن يبدو أن فريق Chrome يخطط للشحن الخاص في المستقبل القريب

كمرجع: https://v8.dev/blog/v8-release-72#public -class-field

يوثق أنهم يشحنون الحقول العامة اعتبارًا من V8 7.2 ، ولكن هناك هذا فيما يتعلق بالمجالات الخاصة (التركيز الخاص بي):

تم التخطيط لدعم حقول الفئة

isiahmeadows كنت أشير في الواقع إلى

استنتاج

يتم شحن الحقول العامة في V8 v7.2 و Chrome 72. نحن نخطط لشحن حقول الدرجة الخاصة قريبًا.

رابط لمقال على مدونة مطوري جوجل

تمت كتابة هذه المقالات بواسطة mathiasbynens و Andreas Haas ، ويمكنك طلب توضيح إذا لزم الأمر (على الرغم من أنني أعتقد أن كل من هذه ccgsathya و joyeecheung اللذان يعملان على اللمسات الأخيرة من التنفيذ في V8.

على أي حال ، توج اجتماع TC39 في يناير 2019 لمدة عام ونصف من إعادة التفكير في البدائل لمقترحات المجالات والأساليب الخاصة مع إعادة تأكيد أخرى للإجماع على المقترحات. أعتقد أنه يمكننا اعتبار الإصدار الحالي مستقرًا وجاهزًا لاستخدام TypeScript.

أطلق Chrome للتو حقول دروس خاصة 🎉
إنها متوفرة فقط في Chrome 74 الذي تم إصداره حاليًا في بناء _canary_.

لقد شحنت للتو حقول دروس خاصة في Chrome 74! جربه في Chrome canary اليوم!
- ساتيا جوناسيكاران عبر توتيتر

هل يعرف أي شخص أين نحن هنا بشأن اختيار تطبيق معين (أو بناء واحد) لمجالات الفصل الخاص؟ رأيت أن trusktr أوصى بـ lowclass لكنني لا أعرف ما إذا كان "_Private Inheritance_" جزءًا من المواصفات.

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

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

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

أي تحديثات على تقدم التنفيذ؟ ربما العلاقات العامة التي يمكننا بناءها لاختبارها وتقديم الملاحظات؟

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

نأمل في توجيه هذا العمل. يمكننا نشر التغييرات على هذا الريبو (Microsoft / TypeScript) بمجرد دمج هذا الشرط الأساسي: https://github.com/Microsoft/TypeScript/pull/30467.

التعليقات موضع ترحيب كبير.

لا أعرف ما إذا كان "الميراث الخاص" جزءًا من المواصفات.

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

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

تعني "الميراث الخاص" (كما هو موضح في الإصدار الحالي من الفئة الدنيا) أنه يمكن للفئة الفرعية استخدام أساليب خاصة موروثة من فئة فائقة ، ولكن الطريقة تطبق التغييرات _ فقط _ على الخصائص الخاصة للمثيل _ داخل نطاق تلك الفئة الفرعية_ ، كما لو تحتوي الفئة الفرعية على تلك الطرق التي تم تعريفها على أنها طرق خاصة في تعريفها الخاص ، ولكن لا يمكن للفئة الفرعية تعديل الخصائص الخاصة للمثيل في نطاق فئة super أو sibling.

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

بعبارة أخرى ، في مفهوم "الميراث الخاص" لكل فئة نطاق خاص ، وأي طرق خاصة موروثة تعمل فقط في نطاق الفئة المحلية ، على عكس المحمية حيث تعمل الطرق المحمية على نطاق واحد للتسلسل الهرمي للفئة بأكملها.

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

لا يوجد "ميراث خاص" في حقول فئة الاقتراح ، لذلك لن يعمل ما يلي (وأنا أوافق على أن هذا مرغوب فيه ، للحفاظ على الخصوصية الحقيقية):

class Foo {
    test() {
        this.#privateMethod()
    }

    #foo = 'foo'

    #privateMethod() {
        console.log(this.#foo)
    }
}

class Bar extends Foo {
    test() {
        // This does not work, no private inheritance:
        this.#privateMethod()
    }

    // #foo is private only inside Bar code, it is NOT the same #foo as in Foo
    // scope.
    #foo = 'bar'
}

في الطبقة الدنيا ، سيكون "الميراث الخاص" مساويًا لكتابة الكود غير الجاف التالي لمحاكاة نفس الشيء ، باستخدام بعض النسخ / اللصق في المحرر الخاص بك:

class Foo {
    test() {
        this.#privateMethod()
    }

    #foo = 'foo'

    #privateMethod() {
        console.log(this.#foo)
    }
}

class Bar extends Foo {
    test() {
        // This does not work, no private inheritance:
        this.#privateMethod()
    }

    // #foo is private only inside Bar code, it is NOT the same #foo as in Foo
    // scope.
    #foo = 'bar'

    // copy the method over by hand (because there's no private inheritance):
    #privateMethod() {
        console.log(this.#foo)
    }
}

في كلا المثالين ، المتغير #foo هو متغير محدد لكل فئة. هناك متغيرين #foo ، وليس واحدًا ؛ كل واحد يمكن قراءته وكتابته فقط عن طريق الكود في نفس تعريف الفئة.

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

في الطبقة الدنيا ، إذا تم استخدام #someMethod في الفئة الممتازة ، فإنه يعمل على #foo للطبقة الفائقة. إذا تم استخدام #someMethod في نطاق الفئة الفرعية ، فإنه يعمل على #foo للفئة الفرعية ، وليس #foo للفئة الممتازة!

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

إنه في قناة Chrome الثابتة الآن ، لذا يمكن للمطورين استخدامه محليًا. أنا مهتم في الغالب بهذه المشكلة بسبب VSCode - عند كتابة vanilla .js javascript ، يضع VSCode علامة عليها كخطأ. هل هناك طريقة لإضافة دعم لحقول الفصل الخاص في Vanilla JS في VSCode منفصلة عن المناقشة حول ما إذا كان يجب إضافتها إلى Typescript؟

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

تحديث: إنه مدعوم أيضًا في Node 12 Stable. أيضًا ، يحتوي Babel على مكون إضافي لتحويل بناء الجملة هذا. غالبًا ما يستخدم المطورون الميزات قبل أن تصبح مقترحات المرحلة 4. أود أن أرى دعمًا مضافًا لبناء الجملة هذا في Vanilla JS (غير ts) أو طريقة لتمكينه من خلال jsconfig.json حتى لا يظهر VSCode خطأ عند استخدامه. يقول VSCode repo أن دعم JS الخاص به مدعوم بواسطة TypeScript ويشير إلى هذه المشكلة.

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

أود أن أقترح أن تقدم TypeScript حقولًا خاصة تحت علامة تشير إلى أن هذه الميزة تجريبية وقابلة للتغيير بين المرحلة 3 والمرحلة 4.

ربما يمكننا تنفيذ دعم بناء الجملة أولاً بدون الدلالات؟

ربما يمكننا تنفيذ دعم بناء الجملة أولاً بدون الدلالات؟

بالنسبة لفحص النوع / التحسس ، أعتقد أنه يجب أن يكون هناك نوع من الدلالات ، ولكن لا يمكن أن يكون هناك دعم تحويل من المستوى الأدنى مثل BigInt (يمكن استخدامه فقط مع esnext ).

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

@ ChrisBrownie55 أود أن أقول إنه ليس من المنطقي أن هذه الميزة لم يتم تنفيذها بعد

يبدو أن هذا قيد التقدم:
https://github.com/microsoft/TypeScript/pull/30829
(والذي يبدو أنه ينتظر على https://github.com/microsoft/TypeScript/pull/30467)

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

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

كانت هناك أيضًا نوبات متقطعة في المناقشة ، لذلك ما زلت لا أعتبرها جاهزة لوقت الذروة

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

• https://github.com/tc39/proposal-class-fields/issues/100
• https://github.com/tc39/proposal-class-fields/issues/150

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

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

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

وقد تم شحنها أيضًا في Node

فقط كأثر جانبي لإصدار Chrome ، والذي يحافظ على محرك Node's JS.

قد تكون ميزة مثيرة للجدل ، ولكن ما إذا كان المطورون يستخدمونها يجب أن يكون قرارًا متروكًا للمطور ، وليس الأدوات

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

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

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

الشيء الجيد هو أنه نظرًا لأن الحقول الخاصة الجديدة تستخدم بناء الجملة # ، فلا يزال هناك مجال لإصلاحه باستخدام الكلمة الرئيسية private كبديل.

هل يتعين على TS حقًا اتباع معيار 100٪؟ نحن نعلم بالفعل أن اللجنة تتعارض مع المجتمع بـ thisGlobal أو #privateLol ، لذا ربما حان الوقت للقول إن Google ليس لديها احتكار لـ JavaScript قبل فوات الأوان؟

TeoTN الحقول الخاصة ليست شيئًا من Google. لقد تم المضي قدمًا من خلال TC39 ، كما فعلت كل المعايير الحديثة الأخرى.

بعض النقاط للمساعدة في توفير الوضوح:

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

RyanCavanaugh شكرًا للتوضيح وأيضًا على كل العمل الرائع! اقتراح صغير: ES تتطور باستمرار وهناك العديد من الميزات التي يتم العمل عليها ، أعتقد أنه من الجيد أن يكون لديك قاعدة في أي مرحلة - المرحلة 4؟ المرحلة 3؟ أو في مكان ما بينهما؟ - ميزات ES مؤهلة للتضمين. خلاف ذلك ، يمكن أن يتكرر هذا النوع من المناقشة مرارًا وتكرارًا في المستقبل لميزات أخرى.

يمكن القول بشكل معقول أن الحقول الخاصة مخبوزة بالكامل.

kkimdev المرحلة 4 بقدر ما تذهب ؛ هذا يعني أن تصبح جزءًا من المعيار.

ميزات ES التي لم يتم خبزها بالكامل

فضولي ، ما هي ميزات ES المخبوزة بالكامل؟ ما معنى "مخبوز بالكامل" في هذا المثال؟

تنفيذ الميزات المعتمدة والشحن ES ليس اختياريًا

هذا معقول تمامًا بالنظر إلى أن هدف TypeScript هو أن يكون ببساطة نوعًا ما على Vanilla JS (لذا فإن أشياء مثل namespace كانت اختيارًا سيئًا فيما يتعلق بالأهداف الحالية ، و enum قابلة للنقاش أيضًا).

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

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

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

أعتقد أن أفضل مكان لمناقشة قرارات تصميم اللغة هذه سيكون في مستودعات المقترحات ، وفي اجتماعات TC39 ، وفي سياقات أخرى مخصصة لهذا العمل. لقد ناقشنا مقترحات المجالات والأساليب الخاصة على نطاق واسع مع trusktr هناك ؛ المناقشة هنا تبدو خارج الموضوع.

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

نظرًا لأن TypeScript Intellisense تعمل على إبراز بناء جملة JavaScript في VS Code ومشكلتي تمييز بناء الجملة اللتين وجدتهما (Microsoft / vscode # 72867 و Microsoft / vscode # 39703) في إعادة توجيه مستودع VS Code هنا - حيث تتم مناقشة تنفيذ هذا في TypeScript - اسمحوا لي أن أساهم بالقول إنه سيكون من الرائع ألا يكون هناك خطأ في ملفات JavaScript.

يتم تمييز JavaScript الصالحة تمامًا على أنها خاطئة في VS Code لأن مترجمًا للغة مختلفة بصدد تحديد ما إذا كان سيتم دعم بناء الجملة أم لا. :-)

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

على الرغم من أنني لست عضوًا في فريق TypeScript ، إلا أنهم يعملون بنشاط على تنفيذ ذلك ولا أعتقد أن هناك الكثير من الشك في هذه المرحلة في أن الحقول الخاصة سيتم دعمها. راجع https://github.com/microsoft/TypeScript/pull/30829.

يمكنني أن أؤكد أنه يجري العمل عليها - نحن نتعاون مع فريق TS ونقوم حاليًا بإتمام عملية تغيير العنوان. متحمس للحقول ذات الأسماء الخاصة في TS (وامتدادًا ، خادم اللغة).

شكراً جزيلاً لمتعاونينا في Bloomberg لتنفيذ ذلك في https://github.com/microsoft/TypeScript/pull/30829!

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

على سبيل المثال ، سيتم إنشاء الإعلانات التالية:

// index.d.ts
declare class Foo {
    #private;
    // ...
}

... بالنظر إلى المدخلات:

// index.ts
class Foo {
    #name: string;
}

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

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

إن وجود خاص يجعل الفصل اسميًا في تحليلنا ، لذا من المهم الحفاظ على ذلك في ملف الإعلان. ربما يمكنك استخدام أداة تحويل إعلان ما بعد الإرسال مثل dts-downlevel لتقليل مستوى الإعلان الخاص لـ TSes الأقدم بطريقة ما؟ (لا أعرف ما إذا كان يحتوي على مستوى أدنى لـ #privates حتى الآن)

للإضافة إلى ما قاله Wesley: downlevel-dts يحول #private إلى معدّل private للتوافق مع الإصدارات القديمة من TypeScript.

وجود خاص يجعل الفصل اسميًا في تحليلنا ، لذا من المهم الحفاظ على ذلك في ملف الإعلان

هل يمكنك توضيح كيفية جعل الفصل اسميًا؟ 🙂 نظرًا لخصائص خاصة متعددة ، #foo و #bar ، ستتم إضافة إعلان خاص واحد فقط #private إلى الإعلانات. لا توجد طريقة للتحليل من الإقرارات لا أسماء الخصائص الخاصة ولا كم كانت هناك ، لأنه تم استبدالها جميعًا بإعلان ملكية واحد #private . سأفهم بشكل أفضل إذا احتفظت بالأسماء #foo و #bar . إنه أمر غريب بعض الشيء ، لا سيما بالنظر إلى أن LanguageService تشكو من عدم استخدام الخاصية #private أبدًا. يبدو لي وكأنه حشرة. لكن في جميع الأحوال ، الحقول الخاصة ليست جزءًا من الملكيات العامة من النوع ولا يمكن الوصول إليها من خارج الفصل ، لذلك من الناحية النظرية لا أفهم لماذا يجب أن تكون جزءًا من الإعلانات؟ ألا يجب أن تنطبق نفس المبادئ على الحقول والأساليب التي تم التعليق عليها بمعدلات وصول أخرى بخلاف public حيث لا تكون من النوع KeyOf وليست جزءًا من الإعلانات المحيطة؟

للإضافة إلى ما قاله Wesley: downlevel-dts يحول #private إلى معدّل private للتوافق مع الإصدارات الأقدم من TypeScript.

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

wessberg لقد أبلغت عن الخطأ الذي لاحظته بخصوص تحذيرات خدمة اللغة غير المرغوب فيها ويمكن على الأرجح تنفيذ حل.

إعادة سؤالك الآخر:

هل يمكنك توضيح كيفية جعل الفصل اسميًا؟

فتح شخص ما مشكلة حول ذلك من قبل .

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

سبب آخر هو أن الكود مثل أدناه يجب أن يفشل في فحص النوع ، لأنه لا توجد طريقة لـ "القيام بالشيء الصحيح" في وقت التشغيل:

class A {
    #foo = getFoo();
    bar = "bar";
    equals(other: A) {
        return this.#foo === other.#foo && this.bar === other.bar;
    }
}

new A().equals({ bar: "bar" }); // error: missing property '#foo'

يا رفاق ، أنا متحمس جدًا لدينا بناء جملة #private ! إنه رائع!

لكن يجب أن أعترف أنني أشعر بالضيق حقًا لأنه ليس لدينا صيغة مختصرة (انظر الاقتراح) ، مثل هذا:

class Counter {
  #count = 0
  increment() {
    return #count++
  }
}

كنت أتساءل - هل يمكننا تطوير مكون إضافي مطبوع أو خيار tsconfig لتمكين بناء الجملة المختصرة كميزة تجريبية؟

أنا فقط أموت من أجل التحسين المريح البسيط ، لتجنب الكثير من التكرار غير الضروري this. - عيوب بناء الجملة المختصرة ، كما هو مذكور في الاقتراح ، لا يبدو أنها مخاوف كبيرة بالنسبة لي للقلق ، لذلك سأكون سعيدًا بالتأكيد لتعيين "experimentalPrivateShorthand": true أو شيء من هذا القبيل في مشاريعي الخاصة

هل يمكن هذا؟ ربما هناك سبب وجيه لعدم إمكانية ذلك؟ ماذا سيكون العمل المتضمن؟ في صحتك!

: موجة: مطاردة

@ chase-moskal لا يقوم TypeScript بتنفيذ أي شيء بخلاف الأنواع التي تتجاوز معيار ECMAScript. والسبب في ذلك هو تغيير الدلالات ، كما يتضح من الحقول الخاصة ومصممي الديكور.

@ chase-moskal الطريقة الأكثر عملية لتجنب كتابة this طوال الوقت هي بصراحة تعيين اختصار لها في IDE الخاص بك (مثل F3 على سبيل المثال). يمكن إجراء العديد من الأشياء عن طريق إرسال محلل TS أو محلل Babel وكتابة المكونات الإضافية ، لكنها كلها تتطلب الكثير من العمل وستجعلك غير متزامن مع الأدوات الرسمية. أدرك أن سؤالك كان عن الدعم الرسمي بالطبع ، فقط اعتقدت أنني سأشارك أفكاري.

jhpratt - تستخدم الكتابة المطبوعة لمساعدتي على البقاء في حالة جيدة. لقد أعطتني وظائف الزينة والسهم في العصور القديمة! اعتادت أن تكون قادرة على المنافسة مع بابل ، على الأقل أكثر من الآن

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

mbrowne - ليس "قابلية الكتابة" للكود حقًا هو ما يهم كثيرًا مثل قابلية القراءة ، لذلك لا داعي للقلق بشأن حساب ضغطات المفاتيح. وجهة نظري هي أن التكرار في جافا سكريبت this غالبًا ما يكون فوضى غير ضرورية

فكر الآن في هذا لسهولة القراءة: عندما نحصل على بناء جملة #private ، في كل مرة ترى فيها this ، ستعرف على الفور أنه كان من أجل الوصول إلى عضو عام - وهو فوز كبير لـ مقروئية!

على أي حال ، اكتشفت للتو أن الكتابة المطبوعة لا تدعم الأساليب الخاصة حتى الآن

لذلك كل هذا يحتاج فقط إلى مزيد من العمل والوقت ، على ما يبدو من أهل بلومبيرج

بدون أساليب خاصة لمطابقة الحقول ، نحتاج فقط إلى الانتظار (لأن لا أحد يخلط المطبوعين الخاصين مع الهاشتاج الخاصين في نفس الفئة دون أن يصابوا بالجنون!)

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

: موجة: مطاردة

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

لا تقوم TypeScript حاليًا بتنفيذ أي مقترحات ECMAScript قبل الوصول إلى المرحلة 3. وهذا هو المكان الذي ستحتاج فيه للحصول على الاختصار قبل أن يهتم TS.

نعم ، لقد قدم لك TypeScript مصممي الديكور منذ سنوات. خمين ما؟ تغيرت الدلالات ، وقت كبير.

نحن نعيش في عالم غير مثالي ، وهناك حاجة إلى بعض الميزات في الوقت الحالي. على سبيل المثال ، اقتراح مصممي الديكور لا يزال في المرحلة الثانية ، لكن بعض المشاريع الكبيرة (Angular) تستخدمهم بنشاط لفترة طويلة. مثال آخر: ECMAScript لا يحدد معدّلات protected لأعضاء الفصل ، وهو أمر مفيد لحل المشاكل الحقيقية.

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

تقدم اللغات الأخرى ميزات تجريبية تحت أعلام المترجم أيضًا.

لا أقول أنه يجب على TypeScript تنفيذ كل اقتراح ضمن المرحلة 1 أو 2 ، ولكن العديد من المقترحات المثيرة للاهتمام لـ TS عالقة ، لأنه لا توجد مكافئات في ECMAScript ، على سبيل المثال https://github.com/microsoft/TypeScript/issues/2000

ikokostya كنت

كان TypeScript حازمًا على عدم تنفيذ أي شيء قبل المرحلة 3 ، حتى تحت العلم. وقد نوقش هذا باستفاضة في قضايا أخرى مختلفة سابقا.

لا أرى أي شيء سوى الدخول في دوائر ، لذا لن أرد أكثر ما لم يظهر شيء بارز.

jhpratt وجهة نظري ليست حول الاختزال. من فضلك اقرأ تعليقي من خلال.

اقتراح شوكة غير ذي صلة على الإطلاق.

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

لكن يجب أن أعترف أنني متخوف حقًا ليس لدينا صيغة مختصرة (انظر الاقتراح)

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

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

... خصوصًا عندما لا يكون جزء كبير من حالة الاستخدام للحقول الخاصة موجودًا في this على الإطلاق (على سبيل المثال ، static isMe(obj) { try { obj.#x; return true; } catch { return false; } } ، لتسمية مثال واحد).

phaux - هذه معلومات جيدة حقًا حول الاختزال مقابل خط الأنابيب ، شكرًا!

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

كان TypeScript حازمًا على عدم تنفيذ أي شيء قبل المرحلة 3 ، حتى تحت العلم.

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

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

يبدو لي أن الكتابة المطبوعة كانت أكثر قدرة على المنافسة مع babel والمتصفحات لميزات ecmascript ، وهي الآن متحفظة للغاية - نحن في موقف حيث قام كل من Babel و chrome بشحن الحقول الخاصة (غير معلمة) لمدة عام من قبل جاء بلومبيرج لإنقاذنا

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

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

أكثر وأكثر ، يبدو أنه يمكنني اختيار ميزات رائعة ، أو أنواع ثابتة - لكن لا يمكنني الآن الحصول على أفضل ما في العالمين ، لذلك هناك تنافر إدراكي متزايد بداخلي

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

لتنفيذ ميزات المرحلة 3 ، هل هو أكثر من أن الكتابة المطبوعة تفتقر إلى عرض النطاق الترددي أو الأولوية؟

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

: موجة: مطاردة

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

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

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

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

@ 0kku - إذن أنت تقول إنها مجرد مشكلة في النطاق الترددي / السعة ، وليست فلسفية - فإن تراكم الأخطاء أصبح الآن أولوية أعلى من تنفيذ ميزات المرحلة 3 ، ولكن بالعودة إلى التاريخ

ljharb - هذا مثير للاهتمام الآن - هل من الممكن بالفعل تشغيل الكتابة المطبوعة و babel معًا بهذه الطريقة؟ لتحقيق أفضل ما في العالمين؟

لكني لا أستطيع أن أرى كيف يمكن لخدمة لغة vscode ts أن تعمل دون أن تنهار على بناء الجملة غير المألوف (مثل الطرق الخاصة على سبيل المثال)؟ تفتقر إلى اللدغات التحسسية ، وهي جزء كبير جدًا من عرض القيمة المطبوع عليها - إذا كان لابد من تعطيل intellisense تمامًا ، فإن الإستراتيجية ليست بداية

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

: موجة: مطاردة

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

أنت أيضًا قادر تمامًا على استخدام babel ، حصريًا ، لترجمة نصك المطبوع

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

@ chase-moskal على الرغم من أن ما قاله @ 0kku صحيح بشكل عام ، إلا أنني لم أر أي سبب لعدم تنفيذ الأساليب الخاصة في TS في هذه المرحلة. أعتقد أن هذا الاقتراح وصل إلى المرحلة الثالثة بعد حقول الفصل ، وما زال المنفذون يعملون عليه.

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

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

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

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

لقد توقفنا أيضًا عن التبني المبكر للتسلسل الاختياري على الرغم من رد المجتمع الهائل - إذا كان لديّ نيكل في كل مرة قال فيها أحدهم "حسنًا ، فقط ضعها خلف العلم" ، كنت سأكتب هذا من قارب. ولكن كان هذا هو الشيء الصحيح الذي يجب القيام به ، لأنه كان علينا تخمين ما أنتج (null)?.prop ، وكنا بالتأكيد نخمن null (وليس undefined ) ، ونحن ' د أن تعيش مع عبء تعقيد مستمر آخر لمعرفة ذلك. هناك جانب إيجابي قوي معادٍ للوقائع هنا لحقيقة أنه لا أحد عالق جالسًا على قاعدة بيانات مكونة من 3 ملايين سطر مليء باستخدام ?. حيث يعتمدون على ذلك الإنتاج null بعض الأحيان ، دون أي وسيلة لذلك حتى تعرف على كيفية الانتقال إلى السلوك المختلف undefined .

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

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

ليس ذلك فحسب ، بل إنه ليس مؤكدًا بنسبة 100٪ أن اقتراح حقول الفصل الحالي وجميع تفاصيله ستجعله يصل إلى المرحلة 4 في شكله الحالي (خاصة الآن بعد أن هناك شركة عضو في TC39 تحرض على إلغاء الاقتراح بالكامل واستبداله بأخرى مختلفة). أعتقد أن 95٪ يقين ، ولكن بشكل عام ، حتى تنفيذ اقتراح المرحلة 3 لا يخلو من المخاطر تمامًا. ومع ذلك ، فإن احتمالية إجراء المزيد من التغييرات بعد المرحلة 3 منخفضة للغاية ، لذلك أعتقد أن سياسة TS الحالية هي سياسة جيدة.

الآن بعد أن أصبحت هناك شركة عضو في TC39 تسعى لإلغاء اقتراح [حقول الفصل] تمامًا واستبداله بآخر آخر

مثيرة للاهتمام ، العقل نقطة الارتباط إلى ذلك؟

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

آخر مرة راجعت فيها ، ttypescript هي الطريقة الوحيدة لتكوين محولات TypeScript غير برمجيًا في tsconfig.json ، وهي لا تتداخل مع أي IDEs ، وبالتالي فإن قدرة الأطراف الثالثة على إنشاء ميزات مفيدة تتكامل جيدًا مع الأدوات الموجودة مثل VS Code ليست موجودة حتى الآن. لا نريد التخلي عن تجربة VS Code الرائعة الخاصة بنا عن طريق التبديل إلى ttypescript والحاجة إلى الاعتماد على مخرجات المحطة بينما يتعذر على VS Code فهم بناء الجملة ورمي الأخطاء.

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

مثيرة للاهتمام ، العقل نقطة الارتباط إلى ذلك؟

https://github.com/microsoft/TypeScript/pull/30829#issuecomment -541338266

هناك مجموعة محدودة جدًا من الأشياء النحوية التي يمكنك القيام بها باستخدام مكون Babel الإضافي ؛ يجب أن يدعم المحلل اللغوي ذلك بالفعل. على سبيل المثال ، لا يزال تعبير "البرنامج المساعد" do يتطلب منطقًا في جوهر Babel نفسه: https://github.com/babel/babel/blob/master/packages/babel-parser/src/parser /expression.js#L991 إنه لا يختلف حقًا عن تبديل سطر الأوامر.

هل هناك مشكلة يمكن اتباعها بالنسبة لطرق الفصل الدراسي الخاص والمُلحقين؟

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

بالنسبة لكل من هاتين الميزتين ، سنظل عالقين في الحفاظ على اثنين من مسارات الشفرات المختلفة بمهارة هنا لبقية حياتنا

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

يؤسفني أن هبطت هنا: /

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

هناك مجموعة محدودة جدًا من الأشياء النحوية التي يمكنك القيام بها باستخدام مكون Babel الإضافي ؛ يجب أن يدعم المحلل اللغوي ذلك بالفعل.

حقيقي. ولكن من أجل المقارنة مع TypeScript ، في Babel ، يمكنك تفرع المحلل اللغوي فقط وإعداد babel.config.js لاستخدام المحلل اللغوي المخصص وأي ملحقات بناء جملة مخصصة تقوم بإنشائها. نعم ، هناك الكثير من العمل (خاصة تعلم كيفية إضافة بناء جملة جديد لأول مرة) ، لكنني لست على دراية بأي خيار مكافئ لـ TS ، وبالطبع في Babel ، من الأسهل بكثير كتابة مكونات تحويل إضافية بناءً على بناء الجملة الحالي. لست متأكدًا من الحالة الحالية لخيارات التخصيص في TypeScript ، ولكن عندما نظرت إليها آخر مرة قبل عامين ، بدا أنه لا يوجد خيار لتمديدها بخلاف تفرغ الشيء بأكمله.

جرب هذا: https://github.com/dsherret/ts-morph

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

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

ljharb نعم ، يجب عليهم ذلك. ومع ذلك ، عندما تصبح طريقة إعلان الخاص هو إلقاء رموز التجزئة أمام المتغيرات ، فإن الطريقة "الصحيحة" لإنشاء فصل دراسي في JS تعني تعليم الأشخاص وضع علامات التجزئة أمام متغيرات الأعضاء. ليس فقط عند التصريح عنها ، ولكن أيضًا عند الرجوع إليها. إنه أمر محير بشكل خاص إذا كنت قادمًا من لغات أخرى. أول ما فكرت به عند رؤية شيء مثل this.#x = this.#something(); والإعلان في فئة ما هو أن التجزئة كانت منفصلة عن المتغير نفسه. لم أكن لأخمن أبدًا أنه كان معدلًا. الشرطة السفلية للجمهور تبدو معكوسة أيضًا. هذا ليس وثيق الصلة بـ TS ، ولكن مجرد خرافة مزعجة على ما أعتقد.

نعم ، تعلم أشياء جديدة عندما يتم ترسيخ المرء في الألفة قد يكون تعديلًا. لدي إيمان بأن مجتمع JS سيستمر في التعلم!

(التجزئة هي جزء من المتغير نفسه، اسم this.#x ليس "س، ولكن القطاع الخاص"، ولكن في الواقع، #x ، قيمة فريدة في هذا النطاق المعجمي)

نعم ، تعلم أشياء جديدة عندما يتم ترسيخ المرء في الألفة قد يكون تعديلًا. لدي إيمان بأن مجتمع JS سيستمر في التعلم!

بالطريقة التي تضعها بها ، تبدو كما لو كان ذلك يتعلم شيئًا ما يضيف إلى حكمة البرمجة لدينا ، في حين أن هذا مجرد غرابة أخرى في JS يجب على المرء أن يحفظها: D