Apa pendapat tim TypeScript tentang sintaks dan penggunaan awalan simbol/karakter?

Saya pribadi berpikir itu terlihat mengerikan , tetapi ternyata ada batasan teknis (penggunaan perlu mengidentifikasi visibilitas, untuk alasan yang tidak sepenuhnya saya pahami).

Akan menyedihkan melihat TypeScript kehilangan sintaks pribadi/dilindungi saat ini, yang jauh lebih bersih dan konsisten dengan sejumlah bahasa lain. Apakah ini mungkin terjadi? Apakah ada alternatif?

Untuk menambah ini, ada pembicaraan tentang kemungkinan mengganti simbol # dan @ (yaitu menggunakan # untuk dekorator), yang jelas akan mempengaruhi TypeScript juga .

Saya pikir itu "mengerikan" juga. Saya pikir seperti operator bind :: , yang sebenarnya tidak terlalu jauh, ada baiknya menunda bahkan mencoba mengimplementasikannya sampai sedikit lebih jauh di jalan dengan T39. Saya sangat curiga ini akan menjadi perjalanan yang sulit. Juga, down-emit untuk mendukungnya akan agak sulit saya duga, karena kebutuhan untuk menulis ulang setiap situs akses.

penggunaannya perlu mengidentifikasi visibilitas, untuk alasan yang tidak sepenuhnya saya pahami

Terutama karena Anda perlu mengidentifikasi di situs penggunaan cara mencari properti, karena memerlukan algoritme pencarian yang berbeda sehingga kelas turunan dapat menggunakan kembali nama pribadi yang sama tanpa perlu "tahu" tentang properti pribadi leluhur.

Salah satu keuntungan dari sintaks yang diusulkan adalah Anda dapat menghilangkan this dan cukup menggunakan #field secara langsung. Selanjutnya, sigil dapat ditukar dengan dekorator (https://github.com/tc39/proposal-private-fields/issues/32) dan sebagai gantinya @ akan digunakan, jadi Anda akan menggunakan @field , seperti Ruby. Apakah menurut Anda sintaks ini masih jelek?

Saya tidak berpikir orang akan senang dengan solusi berbasis kata kunci non "pribadi".

Saya tidak melihat cara yang baik untuk melakukan itu sambil mendukung eval seperti yang dilakukan JavaScript - token konkret memungkinkan beberapa diferensiasi dan memungkinkan untuk mendukung status pribadi yang tidak didasarkan pada sistem tipe statis seperti pada TypeScript . Kami telah membahas sejumlah alternatif sintaks di https://github.com/tc39/proposal-private-fields/issues/14 , dan saya tidak melihat sintaks TypeScript saat ini sebagai sesuatu yang dapat bekerja dengan baik sepanjang waktu dalam lingkungan JS sepenuhnya umum.

Terutama karena Anda perlu mengidentifikasi di situs penggunaan cara mencari properti, karena memerlukan algoritme pencarian yang berbeda sehingga kelas turunan dapat menggunakan kembali nama pribadi yang sama tanpa perlu "tahu" tentang properti pribadi leluhur.

Saya berharap saya tahu lebih banyak tentang cara kerja JavaScript secara internal. Saya pikir itu akan berfungsi seperti yang dijelaskan di sini dan di sini , tetapi ternyata tidak. Saya masih merasa sulit untuk percaya bahwa itu akan berdampak signifikan pada kinerja, tetapi tidak ada angka untuk perbandingan.

Apakah menurut Anda sintaks ini masih jelek?

Pada dasarnya, ya. Lebih dari itu, saya merasa keduanya tidak konsisten dengan sintaks JavaScript lainnya, serta tidak konsisten dengan banyak bahasa lain:

| Bahasa | Sintaks | Catatan |
| --- | --- | --- |
| C# | int pribadi x; | |
| C++ | pribadi:
intx; | |
| Jawa | int pribadi x; | |
| PHP | pribadi $x; | |
| Python | __x | "tidak ada komentar" |
| Ruby | pribadi
metode def
# ...
akhir | Ini adalah metode, tetapi bidang bersifat pribadi
secara default saya pikir. |
| TypeScript | pribadi x; | |
| Visual Basic | Pribadi x Sebagai Bilangan Bulat | |

Semua kecuali _satu_ bahasa di atas menggunakan kata kunci private , dan tampaknya Python tidak benar-benar memiliki status pribadi yang "benar".

Dengan pengecualian Python (sekali lagi), tidak ada bahasa yang memformat deklarasi bidang atau akses bidang secara berbeda tergantung pada visibilitas, dan semuanya memungkinkan pengubah visibilitas baru jika diperlukan.

Saya juga merasa bahwa # dan @ bekerja lebih baik untuk hal-hal seperti dekorator, yaitu ( dalam kata Kevin ) "secara sintaksis 'di luar' dari aliran imperatif".

Saya tidak melihat cara yang baik untuk melakukan itu sambil mendukung evaluasi umum seperti yang dilakukan JavaScript

Apakah mungkin untuk menjelaskan masalah ini dalam istilah awam? (mungkin di https://github.com/tc39/proposal-private-fields/issues/14)

Akan menyenangkan untuk memiliki daftar masalah ini dengan contoh di satu tempat, sehingga ada sesuatu untuk dirujuk.

Saya masih merasa sulit untuk percaya bahwa itu akan berdampak signifikan pada kinerja, tetapi tidak ada angka untuk perbandingan.

Itu akan, jika Anda ingin itu benar-benar pribadi versus hanya konvensi seperti di TypeScript. Setiap kali Anda mencari properti di JavaScript, prosesnya pada dasarnya seperti ini:

1. Lihat contoh untuk properti sendiri.
2. Jika tidak ada properti sendiri, lihat prototipe untuk properti sendiri.
3. Naik rantai prototipe sampai tidak ada properti yang ditemukan.
4. Jika ditemukan kesepakatan dengan deskriptor properti (dapat ditulis, dapatkan, atur, dapat dikonfigurasi)
5. Jika tidak ditemukan dan dibaca, kembalikan undefined atau tulis, tetapkan nilai sebagai milik sendiri jika tidak disegel atau dibekukan.

Sekarang dengan privates tanpa pola dalam namanya, Anda tidak akan memiliki properti sendiri, Anda akan memiliki sesuatu seperti properti pribadi yang tidak akan naik ke rantai prototipe. Anda kemudian harus mencarinya di sana juga untuk setiap operasi yang mungkin dapat mengakses properti pribadi, karena Anda tidak dapat memastikan mana yang dirujuk. Mencarinya dengan cara biasa dan kemudian hanya jika tidak ditemukan mencari secara pribadi bisa sangat berbahaya, karena bagaimana jika Anda menemukan sesuatu di rantai prototipe, tetapi ada juga versi pribadi?

Tantangan terbesar adalah bahwa kelas JavaScript masih sedikit keliru. Mereka pada dasarnya adalah gula sintaksis untuk fungsi konstruktor pewarisan prototipe. Ada satu pemikiran yang muncul di benak saya yang akan saya coba tambahkan ke tc39/proposal-private-fields#14.

Apakah mungkin untuk menjelaskan masalah ini dalam istilah awam?

Jika perlu menulis ulang situs panggilan, maka Anda tidak akan pernah dapat mendukung hal-hal seperti:

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

Atau penggunaan struktur seperti eval . Anda dapat memilih untuk tidak mendukung hal-hal seperti akses indeks untuk pribadi atau tidak ada dukungan evaluasi, tetapi kemudian "mengapa repot". Hampir semua ini telah ditunjukkan dengan satu atau lain cara dalam proposal di sana tetapi orang-orang masih "tapi saya suka pribadi" 😁.

Anda tidak akan memiliki properti sendiri, Anda akan memiliki sesuatu seperti properti pribadi sendiri

Jika Anda memiliki satu set properti dengan item visibility di deskriptor, saya kira masalahnya adalah, jika properti tidak ada pada objek saat ini, Anda tidak akan tahu apakah akan naik atau tidak rantai prototipe.

Jika perlu menulis ulang situs panggilan, maka Anda tidak akan pernah dapat mendukung hal-hal seperti ...

AFAIK, itu tidak akan didukung ( ref ).

Saya masih tidak terlalu mengikuti kasus eval. Saya pikir pemeriksaan properti akan terjadi saat runtime, setelah nama properti dihitung.

tapi orang masih "tapi aku suka private"

Saya mencoba untuk tidak menjadi salah satu dari orang-orang itu, dan untuk memahami masalahnya, tetapi sintaks yang diusulkan hanya membuat saya tidak nyaman. =)

Oke, saya pikir saya mengerti kasus eval/rewrite sekarang. Situs penggunaan di dalam kelas akan ditulis ulang untuk menunjukkan visibilitas berdasarkan properti yang dideklarasikan, dan itu tidak akan mungkin kecuali jika mereka adalah pencarian sederhana.

Jika Anda memiliki satu set properti dengan item visibilitas di deskriptor, saya kira masalahnya adalah, jika properti tidak ada pada objek saat ini, Anda tidak akan tahu apakah akan naik atau tidak ke rantai prototipe.

Hmm. Tetapi jika itu tidak ada di kelas saat ini, bukankah itu menurut definisi non-pribadi? Jika demikian, itu harus naik ke rantai prototipe (seperti dengan pencarian properti publik biasa). Tidak akan ada pekerjaan tambahan untuk akses private .

(Saya mungkin melewatkan sesuatu yang jelas)

Tetapi jika itu tidak ada di kelas saat ini, bukankah itu menurut definisi non-pribadi? Jika demikian, itu harus naik ke rantai prototipe (seperti dengan pencarian properti publik biasa).

Tidak, Anda tidak ingin naik. Label pribadi tidak diwariskan dan subkelas dapat menggunakan kembali pribadi tanpa khawatir tentang penyamaran/tabrakan nama.

@glen-84 Kedua posting yang Anda sebutkan menunjukkan masalah dengan status pribadi yang tidak ditandai. Apakah Anda memiliki ide untuk solusi untuk masalah tersebut? Saya pikir memperumit rantai pencarian akan berisiko dari segi kompatibilitas, membuat JavaScript lebih sulit untuk diterapkan dengan kinerja yang baik (mungkin membuat program yang ada lebih lambat), pada dasarnya tidak mungkin untuk menyesuaikan dengan Proksi, dan umumnya, secara signifikan memperumit model mental bahasa (yang sudah memiliki sistem objek yang relatif kompleks).

Dalam perbandingan lintas bahasa, Anda menyebutkan Ruby. Saya pikir Ruby adalah contoh yang baik dari private state _with_ a sigil-- @ . Anda dapat memanggil metode pengambil dan penyetel tanpa sigil.

Tidak, Anda tidak ingin naik. Label pribadi tidak diwariskan dan subkelas dapat menggunakan kembali pribadi tanpa khawatir tentang penyamaran/tabrakan nama.

Maksud saya naik jika properti itu tidak ada di kelas saat ini, untuk mencari properti publik atau yang dilindungi.

Kedua posting yang Anda sebutkan menunjukkan masalah dengan status pribadi yang tidak ditandai. Apakah Anda memiliki ide untuk solusi untuk masalah tersebut?

Sangat sulit bagi saya untuk melakukan itu, sebagai seseorang tanpa pemahaman tentang cara kerja internal JavaScript.

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

Saya tidak tahu apa artinya ini. Untuk apa? Apakah tidak mungkin dilakukan?

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.

Sangat dioptimalkan sehingga satu sakelar pada visibilitas akan memengaruhi kinerja secara signifikan?

Would for-in enumerate over these properties?

Saya kira itu akan tergantung pada konteksnya. Dalam kelas yang sama, ya. Namun, ini bukan alasan untuk tidak menggunakan private , ini adalah detail implementasi, dan bahasa lain mungkin telah menjawab pertanyaan seperti itu.

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

Mungkin ya (visibilitas meningkat) untuk pertanyaan pertama, dan tidak untuk pertanyaan kedua. Sekali lagi, ini semua telah dilakukan sebelumnya, bukan?

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.

Visibilitas hanyalah alat untuk enkapsulasi dan mendefinisikan antarmuka publik. 99% pengembang mungkin tidak peduli dengan "kebocoran informasi". Yang mengatakan, saya memang menyarankan dua fitur terpisah di sini . Mungkin proposal ini bisa disebut sesuatu yang berbeda, seperti "status tersembunyi" atau "status aman", dan memungkinkan sesuatu seperti status privat/dilindungi diimplementasikan secara berbeda.

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

Gunakan "status tersembunyi/aman" jika Anda ingin perf. :D Dalam semua keseriusan, jenis kehilangan kinerja apa yang sedang kita bicarakan? Mungkin seseorang dapat membuat prototipe. =)

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

Bukankah self-hosting built-in (jika saya bahkan mengerti apa artinya) akan sangat buruk untuk kinerja? Jika tidak ... gunakan "status tersembunyi/aman" dan bukan visibilitas pribadi/terlindungi tingkat yang lebih tinggi.

Saya pikir memperumit rantai pencarian akan berisiko dari segi kompatibilitas

Saya bukan orang pertama/satu-satunya yang berpikir bahwa ini bisa/bisa berhasil. Anda mengakses properti, terlihat ke deskriptor untuk visibilitas, dan merespons sesuai. Tampaknya tidak rumit jika Anda tidak tahu bagaimana hal-hal benar-benar bekerja di JS. Saya benar-benar perlu membaca kursus kilat tentang JS internal/algoritma pencarian properti. =P

Saya pikir Ruby adalah contoh yang baik dari keadaan pribadi dengan sigil--@

Ruby bahkan bukan bahasa C-family, dan sepertinya tidak ada bidang publik, tetapi hanya getter dan setter (aksesor). Proposal private state saat ini memiliki beberapa deklarasi yang duduk berdampingan, dengan tujuan umum yang sama (mendeklarasikan properti), tetapi sintaks yang terlihat berbeda dan tidak konsisten.

Dengan semua yang dikatakan, saya jauh dari kedalaman saya di sini, dan kemungkinan besar saya menambahkan lebih banyak kebisingan daripada nilai, jadi saya akan mencoba untuk tetap diam dan membiarkan para ahli mencapai konsensus.

Saya akan mendiskusikan keinginan ini dengan TC39 dan kita akan melihat apakah kita dapat menemukan ide lain tentang cara menghindari awalan. Saya tidak punya, secara pribadi. Perhatikan bahwa, jika TypeScript memutuskan untuk mengimplementasikan bidang pribadi, bidang tersebut masih berada di Tahap 1 di TC39 dan oleh karena itu dapat berubah.

Apa pendapat tim TypeScript tentang sintaks dan penggunaan awalan simbol/karakter?

Saya pribadi berpikir bahwa itu terlihat mengerikan ...

Catatan Saya telah membuat saran untuk menyingkirkan sintaks # mengagumkan.

@ shelby3 Sayangnya, saya tidak melihatnya sebagai opsi yang realistis. tl;dr, kita harus khawatir tentang bagaimana semuanya akan berinteraksi dengan eval ; tidak termasuk sigil hanya membuat semuanya "terlalu dinamis" untuk bekerja dengan baik.

@littledan Saya telah menindaklanjuti di sana sekarang dan membuat argumen terkuat saya untuk tidak menggunakan sigil , dan argumen saya untuk memaksimalkan kompatibilitas dengan TypeScript . Saya mengerti sekarang mengapa kita harus mendeklarasikan privasi untuk argumen metode yang tidak diketik.

@isiahmeadows

Ini sebagian besar akan menggantikan implementasi pseudo-pribadi saat ini [...] Juga, bagian terpenting dari proposal adalah bahwa properti pribadi hanya tersedia di dalam kelas itu sendiri.

Saya harap ini tidak akan menggantikan implementasi pseudo-private. Saya pikir ketersediaan hanya di dalam kelas sebenarnya bukan hal yang baik (mengingat bahwa ketersediaan yang Anda maksud adalah aksesibilitas ). Saya akui mungkin ada situasi khusus di mana masuk akal untuk memiliki properti yang sangat pribadi dan tidak dapat diakses, misalnya untuk tujuan keamanan. Saya juga mengakui, bahwa jelas membingungkan orang yang akrab dengan bahasa lain, bahwa private sebenarnya tidak terlalu pribadi dalam JavaScript. Tetapi terlepas dari alasan keamanan, menurut pendapat saya, sebagian besar pengembang harus menggunakan private sebagian besar waktu hanya untuk menentukan kontrak tetapi tidak untuk mengontrol aksesibilitas.

Misalnya dari perspektif arsitek, saya pikir hal yang sangat baik tentang TS private -keyword dan sifatnya pseudo-private adalah

• yang memungkinkan untuk mengekspresikan kontrak antarmuka tipe dan bagaimana itu dimaksudkan untuk digunakan oleh klien
• bahwa kontrak diperiksa pada waktu kompilasi oleh kompiler TS
• bahwa saya masih dapat secara sadar "melanggar" kontrak saat runtime, terutama untuk pengujian unit kotak putih.

Aksesibilitas properti pribadi saat runtime sangat berkontribusi pada testabilitas karena saya dapat menyuntikkan status pribadi ke dalam kelas yang sedang diuji hanya dengan mengatur bidang pribadinya (dalam TypeScript saya sarankan menggunakan notasi braket alih-alih gips any karena lebih baik dukungan refactoring), misalnya:

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

Tidak perlu kode pengujian yang rumit hanya untuk menyiapkan kelas dengan status (pribadi) tertentu.
Keuntungan lain dari properti pseudo-private adalah bahwa mereka penting untuk patching monyet .

@about-code Lihat https://github.com/tc39/proposal-private-fields/issues/33

Saya tidak berpikir bahwa komunitas TypeScript akan dengan senang hati mengubah semua baris private variable menjadi private #variable .

Dari perspektif TypeScript, sebagian besar dari kita senang dengan ilusi indah dan manis dari bahasa yang baik (intellisense, kesalahan waktu pembuatan, jenis, berbagai gula). Ilusi ini memberi kami pengalaman pengembangan yang lebih baik, kami menulis kode yang lebih baik lebih cepat. Ini adalah alasan utama mengapa kami menggunakan TS selain transpilasi ESNext -- tetapi untuk yang terakhir ada Babel dan itu lebih baik (atau setidaknya lebih baik ketika saya terakhir memeriksanya).

Saya tidak berbicara tentang beberapa orang yang benar-benar menginginkan sesuatu yang lebih dari variabel pribadi daripada gula sintaksis dalam file sumber mereka. Saya pikir orang-orang itu membutuhkan sesuatu yang lebih kuat, mungkin lebih dekat dengan kode asli.

Tetapi untuk kami yang lain: kami tidak benar-benar membutuhkan JS private. Kita membutuhkan variabel private convenient yang sederhana dan mudah seperti yang kita gunakan di C++, Java, C#, dll.

Silakan pilih solusi yang tidak akan menyusahkan kami. Mungkin pribadi yang lembut? Karena saya ragu kita menginginkan sigil private #variable . Atau mungkin TS private dan ES private akan menjadi konsep yang berbeda? Buruk rupa.

@igabesz

Saya tidak berpikir bahwa komunitas TypeScript akan dengan senang hati mengubah semua baris private variable menjadi private #variable

Sebenarnya, dengan proposal itu, private tidak diperlukan. Sebaliknya, sigil # menggantikannya sepenuhnya tanpa konflik.

Tetapi untuk kami yang lain: kami tidak benar-benar membutuhkan JS private. Kami membutuhkan variabel nyaman pribadi yang sederhana dan mudah seperti yang kami gunakan di C++, Java, C#, dll.

Pribadi TypeScript bersifat pribadi lunak, seperti kebanyakan bahasa OO. Bahkan variabel private Java secara teknis masih soft-private, karena masih dapat diakses dengan escape hatch. JS private setara dengan menggunakan penutupan, kecuali bahwa Anda masih dapat mengakses keadaan pribadi dari instance non- this .

Silakan pilih solusi yang tidak akan menyusahkan kami. Mungkin pribadi yang lembut? Karena saya ragu kita menginginkan #variabel sigil private. Atau mungkin TS private dan ES private akan menjadi konsep yang berbeda? Buruk rupa.

Mereka akan menjadi konsep yang berbeda, tetapi secara umum, palka pelarian jarang berguna dalam praktiknya. Pengecualian utama adalah dengan pemeriksaan objek (misalnya alat pengembang, Node.js util.inspect ), tetapi sebagian besar ditentukan oleh host dan sekarang sudah menggunakan API asli yang diistimewakan, jadi tidak perlu mendesak untuk menambahkannya ke spesifikasi.

Selain itu, setelah ES memiliki status privat standar, TS akan mengadopsinya dan kemungkinan akan menghentikan mekanisme soft-privatenya sendiri, untuk dihapus di versi utama berikutnya. Itu selalu menjadi superset ketat dari ES, dan telah menambahkan (fungsi async), mengubah (kelas), dan/atau tidak digunakan lagi ( /// <amd-dependency /> ) fitur yang diperlukan saat ES itu sendiri berkembang, untuk mempertahankan dirinya sebagai yang ketat superset dan tidak menduplikasi spesifikasi saat ini.

Selain itu, setelah ES memiliki status privat standar, TS akan mengadopsinya dan kemungkinan akan menghentikan mekanisme soft-privatenya sendiri, untuk dihapus di versi utama berikutnya.

😭

Selain itu, setelah ES memiliki status privat standar, TS akan mengadopsinya dan kemungkinan akan menghentikan mekanisme soft-privatenya sendiri, untuk dihapus di versi utama berikutnya.

Ini bukan posisi tim TS. kami tidak memiliki rencana untuk menghentikan hal apa pun dalam waktu dekat.
Jika dan ketika proposal private state mencapai state yang benar, TS akan mengimplementasikannya. Saya tidak berpikir ini memiliki implikasi pada prajurit karena TS menerapkannya hari ini.

@mhegazy Oke. Saya berdiri dikoreksi. (Itu adalah tebakan yang berpendidikan, BTW.)

Proposal Bidang Kelas ada di Tahap 2 sekarang jadi saya senang tim TypeScript memikirkan ini dan siap mengikuti standar EcmaScript

Jika dan ketika proposal private state mencapai state yang benar, TS akan mengimplementasikannya.

@mhegazy Apakah Tahap 3 waktu yang tepat untuk diterapkan?

EDIT: Saya mungkin telah menemukan jawaban saya

@styfle lihat diskusi dari catatan pertemuan desain (#16415) yang membahas pertimbangan saat ini seputar implementasi.

Apakah Tahap 3 waktu yang tepat untuk diterapkan?

Ya. Kami mulai menyelidiki kemungkinan desain yang berbeda untuk fitur ini.

Proposal Bidang Kelas sekarang berada di Tahap 3. (Mulai sebulan yang lalu)

Proposal Bidang Kelas sekarang berada di Tahap 3. (Mulai sebulan yang lalu)

Sementara bidang kelas mencapai Tahap 3, Metode dan Pengakses Pribadi mengikuti dari itu, dan berada di Tahap 2 hingga kemarin ketika dipindahkan ke Tahap 3. Sekarang semua yang diperlukan untuk menangani anggota pribadi kelas ada di Tahap 3.

Adakah pembaruan tentang posisi/kemajuan tim TS dalam mengadopsi sintaks #[field] sekarang setelah berada di tahap 3 untuk sementara waktu? Secara pribadi saya sangat tidak menyukainya, dan lebih memilih kata kunci private TS yang ada, tetapi pada saat yang sama ingin sedekat mungkin dengan standar.

Secara pribadi saya sangat tidak menyukainya, dan lebih memilih kata kunci pribadi TS yang ada

saya juga, itu sangat jelek

tapi @mhegazy saya ingin (mencoba) melakukan ini, bisakah saya?

Parse seharusnya tidak buruk (hampir merupakan pengubah baru yang hanya token, hampir), tetapi typecheck akan merepotkan (karena kita akan memiliki dua jenis pribadi yang berbeda yang perlu dibandingkan entah bagaimana), dan emisi downlevel mengerikan (karena downleveling privasi runtime nyata adalah transformasi besar - @rbuckton memiliki ide tentang itu, dan mungkin implementasi (saya tidak tahu pasti; dia punya banyak dari itu di garpunya)). Kami secara teknis tidak dapat menghentikan Anda untuk mencoba, tetapi saya tidak akan merekomendasikannya, jika Anda dapat menemukan sesuatu yang lain yang lebih Anda sukai, dan saya tidak dapat menjamin bahwa kami akan siap menerimanya setelah Anda selesai. Plus, sementara bidang dan metode pribadi telah maju, itu masih sedikit tidak lengkap sampai statika pribadi (dan mungkin dekorator ) maju juga (mengingat bagaimana mereka semua berinteraksi, mungkin lebih baik untuk menambahkan semuanya sekaligus).

Cukuplah untuk mengatakan, ada banyak hal di sini.

@weswigham Oke, aku menyerah 😂

Berikut adalah pendahuluan yang saya (dengan

Pembaruan: Pekerjaan kami sedang berlangsung di sini .

Ya. Kami mulai menyelidiki kemungkinan desain yang berbeda untuk fitur ini.

Saya juga tidak suka sintaks # , tapi saya mengerti alasan teknis di balik sintaks ini. @mhegazy Apa yang benar-benar ingin saya lakukan oleh tim TypeScript setelah menerapkan proposal baru untuk memikirkan apa yang akan dilakukan TypeScript dengan implementasi usang seperti namespace , private yang dapat digunakan tetapi umumnya harus tidak karena ada cara standar es yang lebih baik untuk melakukan hal yang sama atau hampir sama.

Saya juga ingin menambahkan beberapa sen saya tentang protected . Jika (sekarang mudah-mudahan) kita akan menghapus/menghentikan kata kunci private suatu hari nanti, saya pikir tidak apa-apa untuk melakukan hal yang sama dengan kata kunci protected . Saya tahu sebagian besar orang dapat tidak setuju, tetapi ya cakupan visibilitas tambahan terkadang berguna, tetapi nilai keseluruhannya tidak terlalu tinggi.

@pleerock ,

Inilah yang saya harapkan dari TypeScript:

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

Emit (menargetkan ESNext):

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

Emit (menargetkan ESNext, dengan opsi kompiler baru untuk memancarkan bidang yang ditandai sebagai pribadi sebagai bidang pribadi ES):

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

Itu harus kompatibel ke belakang, sementara juga memungkinkan Anda untuk menggunakan bidang pribadi ES dengan sintaks yang bersih.

@ Glen-84 tentu saja, saya sedang berbicara tentang rencana jangka panjang pada kata kunci dan sintaks yang usang

Kami tidak memiliki rencana untuk menghentikan sintaks atau kata kunci apa pun.

Saya juga tidak berpikir kita akan memiliki opsi apa pun untuk mengubah private menjadi # - mereka memiliki perilaku yang diharapkan berbeda; # adalah privasi hard runtime, sedangkan private hanyalah privasi waktu desain.

@weswigham saya juga berpikir begitu. @RyanCavanaugh ya itu jawaban yang diharapkan. Tapi tetap saja saya akan menerapkan setidaknya beberapa strategi untuk pengguna baru untuk menghindari penggunaan namespace/kata kunci pribadi karena mereka sudah usang dengan proposal ecmascript terbaru

Orang umumnya mengetahui hal ini berdasarkan membaca dokumentasi, yang tentu saja kami perbarui. module foo { masih dalam bahasa tetapi pada dasarnya tidak pernah terlihat di alam liar lagi kecuali dalam basis kode yang sangat lama yang ada sebelum namespace foo { .

@RyanCavanaugh senang mendengarnya. Tapi tetap saja saya percaya bahwa orang baru yang berasal dari c# katakanlah pasti akan mencoba menggunakan ruang nama (tidak semua, tetapi beberapa di antaranya). Saya kira hal yang sama mungkin terjadi dengan pengguna yang berasal dari bahasa lain - mereka akan mulai menggunakan pribadi alih-alih # dan ini cenderung lebih masif daripada contoh dengan ruang nama

Saya juga tidak berpikir kita akan memiliki opsi apa pun untuk mengubah pribadi menjadi # - mereka memiliki perilaku yang diharapkan berbeda; # adalah privasi waktu proses yang sulit, sedangkan pribadi hanya privasi waktu desain.

D'oh. Saya berharap bahwa kami juga dapat menggunakan private untuk privasi yang sulit, untuk menghindari ... sintaks yang tidak menguntungkan.

Bagaimanapun, soft-private mungkin cukup untuk kasus penggunaan saya (saat ini).

Saya pikir akan sangat bagus untuk menyertakan dukungan sintaks ini dalam TypeScript versi 3 yang akan datang karena fitur ini sangat besar dan versi 3 terlihat sebagai kesempatan yang baik untuk membuat orang mulai menggunakan sintaks # .

EDIT: sangat lupa bahwa versi 3 sudah dirilis.

Sekadar informasi, ada beberapa churn baru-baru ini tentang bidang/slot pribadi/apa pun di repo proposal TC39, jadi bahkan tidak yakin proposal dalam bentuknya saat ini akan berhasil. Berikut beberapa masalah yang relevan di sana:

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

Saya bukan TC39, tetapi saran pribadi saya untuk semua orang adalah pertama-tama menunggu sintaks untuk memantapkan lagi (mungkin menunggu tahap 4), dan kemudian mengimplementasikannya.

FWIW Saya tidak akan menafsirkan diskusi di tc39/proposal-class-fields#100 sebagai indikasi dari sesuatu yang khusus. # tidak cantik pada awalnya, tetapi tidak ada bentuk sintaksis yang disarankan dan satu-satunya sintaks yang tampaknya diinginkan orang secara nyata tidak bisa diterapkan. Harus ada semacam awalan sigil dan semua upaya untuk mengizinkan this.someProp menjadi pribadi pasti akan gagal.

Saya menyadari bahwa kedengarannya agak meremehkan, tetapi sejujurnya itulah maksud saya - tidak ada pengeluh di utas tersebut yang secara bermakna terlibat dengan masalah teknis inti yang dibahas di utas yang masih ada atau FAQ. Sangat menyedihkan untuk membaca utas pada repo itu dan melihat penjelasan panjang yang benar tentang mengapa sigil diperlukan diturunkan ke tanah.

Jika akhirnya adalah tidak ada yang menggunakan bidang pribadi kecuali mereka benar -

Saya setuju itu mungkin bukan masalah yang ideal untuk disebutkan, tetapi yang lain,
tc39/proposal-class-fields#106, mungkin jauh lebih indikatif - ada
diskusi serius tentang penggunaan peta yang lemah antara lain, karena
interop proxy jelas menyebalkan.

Isiah Padang Rumput
[email protected]
www.isiahmeadows.com

Pada hari Senin, 30 Juli 2018 jam 15.38, Ryan Cavanaugh [email protected]
menulis:

FWIW Saya tidak akan menafsirkan diskusi di
tc39/proposal-class-fields#100
https://github.com/tc39/proposal-class-fields/issues/100 menjadi
menunjukkan sesuatu yang khusus. # tidak cantik pada awalnya, tapi
tidak ada bentuk sintaksis yang disarankan dan satu-satunya sintaks yang
orang tampaknya ingin jelas tidak bisa diterapkan. Harus ada awalan
sigil dari beberapa jenis dan semua upaya untuk mengizinkan this.someProp menjadi pribadi
ditakdirkan untuk gagal.

Saya menyadari bahwa kedengarannya agak meremehkan, tapi sejujurnya itulah maksud saya -
tidak ada pengeluh di utas itu yang terlibat secara bermakna dengan
masalah teknis inti yang dibahas dalam utas yang masih ada atau FAQ. Dia
menyedihkan sekali untuk membaca utas di repo itu dan melihat lama
penjelasan yang benar tentang mengapa sigil diperlukan diturunkan ke dalam
tanah.

Jika permainan akhirnya adalah tidak ada yang menggunakan bidang pribadi kecuali mereka benar -
membutuhkan privasi runtime yang sulit, itu mungkin hasil yang baik untuk web di
hal kinerja dan debuggability.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/TypeScript/issues/9950#issuecomment-408984395 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AERrBGCphyQUu5lJQW7lgsqALLL3e0_Wks5uL2DLgaJpZM4JVDwV
.

Ada beberapa diskusi tentang penggunaan WeakMaps, tetapi saya tidak melihat bagaimana hal itu akan meningkatkan interaksi dengan Proxy. Saya akan mengundang setiap anggota TC39 yang memiliki gagasan lain tentang bagaimana fitur kelas privat harus bekerja untuk mempresentasikannya kepada komite untuk mendapatkan umpan balik; saat ini, proposal ini berada di Tahap 3 dan secara teoritis mewakili posisi konsensus panitia. Banyak orang membuat kompromi untuk mencapai tujuan bersama untuk mengaktifkan fitur ini, meskipun desain lain memungkinkan.

Saya bekerja untuk mengatur diskusi di antara kerangka kerja tentang cara menggunakan Proxy untuk mengamati mutasi objek, dan bagaimana itu harus berinteraksi dengan bidang pribadi. Beri tahu saya jika Anda ingin bergabung dalam percakapan.

@RyanCavanaugh

FWIW Saya tidak akan menafsirkan diskusi di tc39/proposal-class-fields#100 sebagai indikasi dari sesuatu yang khusus. # tidak cantik pada awalnya, tetapi tidak ada bentuk sintaksis yang disarankan dan satu-satunya sintaks yang tampaknya diinginkan orang secara nyata tidak bisa diterapkan. Harus ada semacam awalan sigil dan semua upaya untuk mengizinkan this.someProp menjadi pribadi pasti akan gagal.

Terlambat dalam hal ini, tetapi sebenarnya ada proposal yang menyarankan this->var syntax .

Memang, proposal ini kemungkinan besar sudah mati ("panitia tidak antusias" adalah satu-satunya alasan yang dapat saya temukan). Tetapi sintaks alternatif memang telah diusulkan, dan saya harap semua pihak yang berkepentingan mengetahui dan mengetahui hal ini.

Saya pikir akan lebih baik untuk memiliki opsi kompiler untuk membuat private transpile ke semacam _soft_ private yang akan diberlakukan saat run-time. Saya tidak berpikir kasus penggunaan untuk membutuhkan hard private yang sebenarnya sangat umum, jadi meskipun tidak menyukai sintaks # , saya pikir kebanyakan orang akan cenderung bertahan dengan private . Tetapi waktu kompilasi hanya pribadi yang _too_ soft IMO. Juga, opsi seperti itu akan membantu mengurangi jumlah kemungkinan varian private...jika pengembang dibiarkan mengimplementasikannya sendiri maka Anda dapat memiliki semua ini:

class Demo {
  private a

  #b

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

Jadi saya mengusulkan bahwa dengan opsi baru diaktifkan, private a akan berubah menjadi <strong i="13">@reflect</strong> #a , di mana @reflect adalah dekorator yang memungkinkan refleksi pada properti melalui API yang didukung komunitas. Ada beberapa pembicaraan tentang perpustakaan dekorator standar, sehingga dekorator @reflect (atau apa pun yang kita ingin menyebutnya) dapat distandarisasi di masa depan; Saya pikir itu akan menjadi kandidat yang baik untuk itu.

Saya kira kelemahan utama proposal saya adalah dampak kinerja. Kita dapat berharap bahwa suatu hari JS mungkin memiliki beberapa dekorator standar yang diimplementasikan secara asli untuk mengoptimalkannya, tetapi kenyataan di masa mendatang adalah <strong i="19">@reflect</strong> #x akan lebih lambat daripada hanya #x . Tapi saya hanya mengusulkan ini sebagai opsi, yang mungkin harus dinonaktifkan secara default (untuk alasan kompatibilitas mundur juga).

@MichaelTheriot

Terlambat dalam hal ini, tetapi sebenarnya ada proposal yang menyarankan sintaks this->var.

Memang, proposal ini kemungkinan besar sudah mati ("panitia tidak antusias" adalah satu-satunya alasan yang dapat saya temukan)

Panitia telah memberikan banyak alasan yang dipertimbangkan dengan baik untuk mendukung proposal saat ini alih-alih proposal kelas 1.1, misalnya https://github.com/tc39/proposal-class-fields/issues/100#issuecomment -429460917

@mrowne

Saya mungkin telah melewatkannya. Halaman masalah kelas 1.1 telah tidak aktif selama setengah tahun, dan bahkan contoh yang Anda tautkan ditulis sebulan setelah komentar saya.

FYI, saya menyebutkan ini di utas yang Anda tautkan beberapa bulan yang lalu. Komentar saya di sini hanya untuk mengatasi kesalahpahaman bahwa tidak ada sintaks alternatif yang diusulkan, karena saya percaya semua pihak yang terlibat harus menyadari bahwa itu tidak terjadi.

Sunting: Komentar saya tidak menyarankan TypeScript melakukan sesuatu yang berbeda. Saya yakin akan berguna untuk mengoreksi kesalahan informasi tentang isu-isu yang dirujuk dalam proposal.

@MichaelTheriot pihak yang perlu diberi tahu tentang proposal alternatif bukanlah pihak yang terlibat dalam percakapan ini. TypeScript akan mengikuti proposal yang ada di jalur untuk diratifikasi. Fakta bahwa sintaks alternatif telah diusulkan dan tidak diadopsi tidak terlalu berguna untuk percakapan ini menurut saya.

Hai teman-teman, jika ini membantu, saya ingin membagikan implementasi saya sendiri dari runtime protected/anggota pribadi:

Lihat lowclass .

Lihat file pengujian ekstensif yang menunjukkan semua jenis penggunaan runtime anggota publik/dilindungi/pribadi. Implementasinya tidak lama, dan beberapa fitur dapat dihilangkan agar hanya memiliki fungsi terproteksi/pribadi minimal.

Catatan:

• Ini menggunakan WeakMaps untuk menyimpan status terproteksi/pribadi.
• Tidak seperti implementasi lain yang pernah saya lihat, ini bekerja dengan kode async dengan panggilan balik/janji/menunggu karena tidak bergantung pada pelacakan tumpukan panggilan sinkron.
• Ini bekerja dengan getter/setter (termasuk panggilan super) (lihat tes).
• Bekerja dengan super , atau menggunakan Super helper untuk ES5 (lihat tes).
• Mendukung metode constructor (lihat tes).
• Kemampuan untuk memperluas kelas bawaan (kecuali untuk Date, tapi saya ingin melihatnya meskipun orang mengatakan itu tidak mungkin tetapi saya ingin mengonfirmasinya. Lihat tes, fe bekerja dengan Elemen Kustom asli).
• Kemampuan untuk memperluas class es asli biasa (lihat tes).
• bungkus asli class es, memberi mereka kemampuan yang dilindungi dan pribadi (lihat tes).
• Tulis kelas function gaya ES5 alih-alih asli class es (lihat tes).
• banyak ruang untuk pengoptimalan kinerja (melakukan caching panggilan pembantu super/terlindungi/pribadi dan mengoptimalkan algo pencarian)

Untuk menjalankan tes:

npm install
npm test

Lihat juga https://github.com/babel/proposals/issues/12 dan https://github.com/babel/babel/issues/8421 untuk detail dan masalah dengan implementasi Babel.

Halo kalian semua,

tolong jangan implementasikan spesifikasi bidang kelas pribadi yang belum selesai. Ini memiliki masalah.

Silakan baca utas ini .

Saya akan mendorong siapa saja yang membaca ini untuk melihat beberapa ide sintaks lainnya (hanya membaca dengan teliti, masih ada lagi), dan menyuarakan pendapat Anda.

fe inilah utas lain (dengan ide sintaksis yang lebih baik daripada # IMHO saat ini).

Jika ada komunitas JavaScript yang sudah menggunakan public/private/protected secara luas, komunitas TypeScriptlah yang memiliki peluang besar untuk membantu membentuk masa depan JS private/protected.

Jadi, bidang kelas pribadi sedang dikirimkan di V8 v7.2 dan Chrome 72. Apakah ada rencana untuk mulai menerapkan proposal bidang pribadi?

@ChrisBrownie55 Bidang publik dikirimkan. Swasta tidak.

@jhpratt itu salah saya, tetapi tampaknya tim Chrome berencana mengirim secara pribadi dalam waktu dekat

Untuk referensi: https://v8.dev/blog/v8-release-72#public -class-fields

Ini mendokumentasikan bahwa mereka mengirimkan bidang kelas publik pada V8 7.2, tetapi ada ini tentang bidang pribadi (penekanan milik saya):

Dukungan untuk bidang kelas privat direncanakan untuk rilis V8 di masa mendatang .

@isiahmeadows Saya sebenarnya merujuk ke posting berbeda di blog pengembang Google.

Kesimpulan

Bidang kelas publik dikirimkan dalam V8 v7.2 dan Chrome 72. Kami berencana untuk mengirimkan bidang kelas pribadi segera.

Tautan ke artikel di blog pengembang Google

Artikel-artikel ini ditulis oleh @mathiasbynens dan Andreas Haas, yang dapat Anda minta klarifikasi jika diperlukan (walaupun menurut saya masing-masing postingan tersebut cukup jelas). cc @gsathya dan @joyeecheung yang sedang mengerjakan sentuhan akhir implementasi di V8.

Bagaimanapun, pertemuan TC39 Januari 2019 mengakhiri satu setengah tahun memikirkan kembali alternatif untuk bidang pribadi dan proposal metode dengan penegasan kembali konsensus pada proposal. Saya pikir kita dapat menganggap versi saat ini stabil dan siap untuk menggunakan TypeScript.

Chrome baru saja merilis bidang kelas pribadi
Mereka hanya ada di Chrome 74 yang saat ini dirilis di _canary_ build.

Saya baru saja mengirimkan bidang kelas pribadi di Chrome 74! Cobalah di Chrome canary hari ini!
— Sathya Gunasekaran via Twtiter

Adakah yang tahu di mana kita berada di sini dalam memilih implementasi tertentu (atau membangunnya) untuk bidang kelas pribadi? Saya melihat bahwa @trusktr merekomendasikan lowclass tetapi saya tidak tahu apakah "_Private Inheritance_" adalah bagian dari spesifikasi.

Jelas tidak; bidang pribadi tidak berjalan di rantai prototipe (karena objek lain akan dapat melihatnya, dan dengan demikian mereka tidak akan menjadi pribadi)

Saya akan berasumsi bahwa bidang pribadi akan berubah menjadi WeakMaps (satu WeakMap per bidang, cara yang sama dilakukan Babel). Juga harus ada opsi untuk menyimpan sintaks # di hasil akhir, bagi mereka yang secara eksklusif menargetkan browser yang mendukungnya (tentu saja ini akan menjadi lebih relevan seiring waktu).

Untuk alasan kinerja, mungkin juga layak untuk mempertimbangkan opsi yang memungkinkan pengembang menggunakan sintaks # untuk kompatibilitas di masa mendatang (ketika lebih banyak browser mendukungnya), tetapi sebenarnya transpile ke properti publik dengan beberapa awalan khusus, misalnya __ts# . WeakMaps harus dibandingkan untuk melihat apakah ini benar-benar diperlukan, tetapi saya menduga bahwa perbedaan kinerja antara properti publik dan WeakMaps bisa menjadi signifikan. Jika opsi seperti itu ditambahkan, tentu saja itu harus dimatikan secara default, karena pengembang yang menggunakan sintaks # biasanya mengharapkannya menjadi waktu kompilasi dan waktu proses pribadi. Tetapi bagi mereka yang ingin memaksimalkan kinerja run-time dan puas dengan waktu kompilasi pribadi sementara, itu bisa menjadi cara yang bagus untuk mulai menggunakan sintaks baru tanpa berpotensi menyebabkan penurunan kinerja.

Adakah pembaruan tentang kemajuan implementasi? Mungkin PR yang bisa kita buat untuk menguji dan memberikan umpan balik?

@jhpratt yakin! Jika Anda memeriksa cabang di PR ini , Anda akan dapat menguji bidang instance bernama pribadi. Metode dan pengakses sedang berlangsung.

Kami berharap untuk hulu pekerjaan ini. Kami dapat melakukan PR perubahan terhadap repo ini (Microsoft/TypeScript) segera setelah PR prasyarat ini digabungkan: https://github.com/Microsoft/TypeScript/pull/30467.

Umpan balik sangat diterima.

Saya tidak tahu apakah "Warisan Pribadi" adalah bagian dari spesifikasi.

Sidenote, saya berencana untuk menjatuhkan fitur itu di kelas rendah, untuk mengaktifkan 100% privasi sejati. Saya tidak benar-benar membutuhkannya dalam praktik, itu lebih merupakan eksperimen.

Ngomong-ngomong, saya ingin memposting di sini, seandainya ada teori tentang "warisan pribadi" yang mungkin berguna (mungkin hanya menarik, atau mungkin membantu memicu ide lain):

"Warisan pribadi" (seperti yang terlihat pada versi kelas rendah saat ini) berarti bahwa subkelas dapat menggunakan metode pribadi yang diwarisi dari superkelas, tetapi metode tersebut menerapkan perubahan _ hanya _ ke properti pribadi dari instance _dalam cakupan subkelas itu_, seolah-olah subkelas memiliki metode yang didefinisikan sebagai metode pribadi dalam definisinya sendiri, tetapi subkelas tidak dapat mengubah properti pribadi dari instance dalam lingkup kelas super atau saudara kandung.

Sebagai perbandingan, dalam "warisan yang dilindungi", sebuah subkelas _can_ memodifikasi properti dari turunannya sendiri atau turunan superkelasnya, tetapi masih tidak dapat mengubah properti dari kelas saudara. Dalam pewarisan terproteksi, subkelas memodifikasi properti yang dapat dilihat oleh semua kelas super (kelas super semuanya membaca/menulis ke properti yang sama).

Dengan kata lain, dalam konsep "warisan pribadi" setiap kelas memiliki ruang lingkup pribadi, dan metode pribadi apa pun yang diwariskan hanya beroperasi pada ruang lingkup kelas lokal, berbeda dengan yang dilindungi di mana metode yang dilindungi beroperasi pada satu ruang lingkup untuk seluruh hierarki kelas.

Tidak yakin apakah itu masuk akal, jadi inilah contoh kode sederhana untuk menjelaskan seperti apa "warisan pribadi" itu, jika kami menulisnya menggunakan fitur bidang pribadi bidang proposal-kelas-bidang ecma saat ini:

Tidak ada "warisan pribadi" di bidang kelas-proposal, jadi yang berikut ini tidak akan berfungsi (dan saya setuju ini diinginkan, untuk menjaga privasi sejati):

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'
}

Di kelas rendah, "warisan pribadi" akan setara dengan menulis kode non-KERING berikut untuk meniru hal yang sama, menggunakan beberapa salin/tempel di editor Anda:

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)
    }
}

Dalam kedua contoh, variabel #foo adalah variabel khusus untuk setiap kelas. Ada dua variabel #foo , bukan satu; masing-masing dapat dibaca dan ditulis hanya dengan kode dalam definisi kelas yang sama.

Di kelas rendah, pewarisan pribadi memungkinkan kita untuk menggunakan kembali metode superkelas pribadi, _but_ metode tersebut beroperasi dalam lingkup di mana metode tersebut digunakan. Jadi pada akhirnya seolah-olah kita menyalin dan menempelkan metode superclass ke dalam subclass, seperti pada contoh di atas, tetapi masih ada dua variabel #foo untuk setiap kelas.

Di kelas rendah, jika #someMethod digunakan di kelas super, ia beroperasi pada #foo dari superkelas. Jika #someMethod digunakan dalam lingkup subclass, ia beroperasi pada #foo dari subclass, bukan #foo dari superclass!

Saya harap itu menjelaskan konsepnya, dan bahkan jika itu tidak akan digunakan, saya harap ini menarik atau berguna dalam memicu ide apa pun.

Ini ada di saluran stabil Chrome sekarang, sehingga pengembang dapat menggunakannya secara asli. Saya sebagian besar tertarik dengan masalah ini karena VSCode - saat menulis javascript vanilla .js , VSCode menandainya sebagai kesalahan. Apakah ada cara untuk menambahkan dukungan untuk bidang kelas pribadi di Vanilla JS di VSCode terpisah dari perdebatan tentang apakah akan menambahkannya ke TypeScript?

Secara pribadi, saya tidak merasa TS harus menambahkan dukungan untuk mereka sebelum mencapai tahap 4. TS sudah memiliki waktu kompilasi pribadi yang berfungsi cukup baik untuk saat ini. Setelah mencapai tahap 4, maka saya setuju itu masuk akal. (Terkadang ada juga fluks dalam diskusi, jadi saya masih belum menganggapnya siap untuk prime time.)

Pembaruan: Ini juga didukung di Node 12 stabil. Juga, Babel memiliki plugin untuk mengubah sintaks ini. Pengembang sering menggunakan fitur sebelum menjadi proposal tahap 4. Saya ingin melihat dukungan ditambahkan untuk sintaks ini di Vanilla JS (non-ts) atau cara untuk mengaktifkannya melalui jsconfig.json sehingga VSCode tidak menunjukkan kesalahan saat menggunakannya. Repo VSCode mengatakan bahwa dukungan JS mereka didukung oleh TypeScript dan merujuk ke masalah ini.

Saya harus mengatakan bahwa tidak masuk akal bagi TypeScript untuk tidak mendukung fitur sama sekali karena sudah ada dalam produksi di browser utama dan Node.js. Ini bukan untuk mengatakan bahwa TypeScript harus sepenuhnya memantapkan semuanya sekarang dan melepaskannya sebagai fitur bawaan.

Saya menyarankan agar TypeScript memperkenalkan bidang pribadi di bawah bendera yang menunjukkan bahwa fitur ini bersifat eksperimental dan dapat berubah antara tahap 3 dan tahap 4.

Mungkin kita bisa mengimplementasikan dukungan sintaks terlebih dahulu tanpa semantik?

Mungkin kita bisa mengimplementasikan dukungan sintaks terlebih dahulu tanpa semantik?

Untuk pemeriksaan tipe/intellisense, saya pikir harus ada semacam semantik, tetapi tidak dapat memiliki dukungan transformasi tingkat bawah seperti BigInt (hanya dapat digunakan dengan esnext ).

fwiw, itu hanya dapat berubah pada tahap 3 karena umpan balik implementasi. Mengingat bahwa chrome mengirimkannya, perubahan apa pun sangat tidak mungkin.

@ChrisBrownie55 menurut saya tidak masuk akal bahwa fitur ini belum diimplementasikan

Sepertinya ini sedang berlangsung:
https://github.com/microsoft/TypeScript/pull/30829
(yang tampaknya menunggu di https://github.com/microsoft/TypeScript/pull/30467)

Benar, #30829 hampir siap untuk digabungkan setelah rebase, modulo beberapa fitur-gating yang mungkin ingin kita lakukan sehingga meledak pada metode bernama pribadi.

Kawan, hanya karena browser utama menerapkan fitur tersebut (untuk melihat bagaimana rasanya, memainkannya, dll) tidak berarti semua orang harus melakukannya.

Ada juga gejolak sesekali dalam diskusi, jadi saya masih tidak akan menganggapnya siap untuk prime time

Seperti yang disebutkan @isiahmeadows , proposal bidang kelas penuh dengan kontroversi dan banyak orang tidak menyukainya. Berikut adalah beberapa masalah yang menunjukkan ketidaksukaan komunitas terhadap bidang pribadi saat ini:

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

Jika saya adalah seorang pelaksana bahasa, saya akan khawatir tentang hal ini, dan saya tidak ingin bertanggung jawab atas fitur yang sangat tidak disukai yang dirilis (ditetapkan dalam batu) karena saya memutuskan untuk mengizinkan ribuan (tidak mengetahui) pengembang mulai menggunakan yang bermasalah fitur dalam kode produksi.

Bidang pribadi mungkin yang paling kontroversial dari semua fitur yang diperkenalkan sejak ES6. Saya pikir akan bijaksana bagi pelaksana bahasa untuk mempertimbangkan ketidaksukaan sebelum membantu mengatur fitur tersebut.

@trusktr Ini mungkin fitur yang kontroversial, tetapi apakah pengembang menggunakannya harus menjadi keputusan yang diserahkan kepada pengembang, bukan alat. Peramban utama telah mengirimkannya bukan untuk "bermain dengannya" tetapi untuk mengirimkannya untuk digunakan dalam produksi. Itu juga dikirimkan dalam Node, runtime JS sisi server paling populer. Sekali lagi, saya kurang peduli apakah sintaks membuatnya menjadi TypeScript atau tidak, tetapi lebih peduli pada apakah sintaks tersebut didukung oleh server bahasa JavaScript di VSCode (yang didukung oleh TypeScript).

Itu juga telah dikirim di Node

Hanya sebagai efek samping dari rilis Chrome, yang memelihara mesin JS Node.

Ini mungkin fitur yang kontroversial, tetapi apakah pengembang menggunakannya harus menjadi keputusan yang diserahkan kepada pengembang, bukan alatnya

Itu mungkin terjadi untuk pengembang seperti Anda (mungkin Anda hanya perlu merilis produk, dan Anda akan bekerja dengan alat apa pun yang Anda miliki, yang sebenarnya adalah apa yang harus Anda lakukan dalam hal itu, dan apa yang dilakukan oleh banyak pengembang yang dipekerjakan).

Ada juga banyak pengembang yang mungkin tidak tahu tentang senjata kaki yang terkait dengan bidang kelas, sementara hanya mencoba menggunakan alat yang diberikan kepada mereka.

Dan ada juga pengembang yang peduli dengan bahasa itu sendiri, dan masa depan kode yang dapat dipelihara, dan ingin melihatnya berkembang dengan benar, sebelum kesalahan tertentu terlambat untuk diperbaiki.

Hal baiknya adalah, karena bidang pribadi baru menggunakan sintaks # , masih ada ruang untuk memperbaikinya menggunakan kata kunci private sebagai alternatif.

Apakah TS benar-benar harus mengikuti standar 100%? Kita sudah tahu bahwa komite akan melawan komunitas dengan thisGlobal atau #privateLol , jadi mungkin sudah waktunya untuk mengatakan bahwa Google tidak memiliki monopoli atas JavaScript sebelum terlambat?

@TeoTN Bidang pribadi bukan milik Google. Ini telah berjalan melalui TC39, seperti halnya setiap standar terbaru lainnya.

Beberapa poin untuk membantu memberikan kejelasan:

• Kami tidak terburu-buru untuk mengirimkan fitur ES yang belum sepenuhnya matang (lihat juga: rantai opsional, penggabungan nol, ekspresi lempar, operator saluran pipa, nama, dll)
• Sebaliknya, menerapkan fitur ES yang telah diratifikasi dan dikirimkan bukanlah opsional
• Banyak orang yang tidak menyukai hal-hal tertentu juga bukan faktor
• Bidang pribadi akan berada di TS ketika kami yakin aman untuk kami implementasikan tanpa perubahan desain (atau pencabutan) nanti yang menyebabkan rasa sakit pengguna yang serius

@RyanCavanaugh Terima kasih atas klarifikasinya dan juga untuk semua pekerjaan yang luar biasa! Saran kecil: ES terus berkembang dan ada banyak fitur yang sedang dikerjakan, saya pikir ada baiknya memiliki aturan bahwa pada tahap apa - Tahap 4? Tahap 3? atau di suatu tempat di antaranya? - Fitur ES memenuhi syarat untuk dimasukkan. Jika tidak, diskusi semacam ini dapat berulang lagi dan lagi di masa mendatang untuk fitur-fitur lainnya.

Bidang pribadi dapat dikatakan sepenuhnya matang.

@kkimdev Tahap 4 sejauh ini; itu berarti telah menjadi bagian dari standar.

Fitur ES yang belum sepenuhnya matang

Penasaran, apa saja fitur ES yang sepenuhnya dipanggang? Apa yang dimaksud dengan "dipanggang penuh" dalam contoh ini?

menerapkan fitur ES yang telah diratifikasi dan dikirimkan bukanlah opsional

Itu benar-benar masuk akal mengingat tujuan TypeScript untuk hanya mengetik di atas vanilla JS (jadi hal-hal seperti namespace adalah pilihan yang buruk sehubungan dengan tujuan saat ini, dan enum juga bisa diperdebatkan).

TypeScript memiliki beberapa kekuatan untuk membantu (atau tidak membantu) komunitas dalam mempengaruhi spesifikasi bahasa, dengan menunggu (atau tidak menunggu) untuk mengirimkan fitur sampai semua mesin utama dengan suara bulat mengirimkan fitur yang diberikan.

Tampaknya tidak efisien, karena anggota tim TS duduk di TC39, jadi mereka telah menjadi bagian dari konsensus untuk fitur yang menjadi tahap 3 sebelum ada yang mengirimkannya - termasuk yang ini.

Saya sangat menghargai keputusan desain TypeScript untuk menjadi konservatif dalam apa yang mereka kirimkan; dalam banyak kasus, masuk akal untuk menunggu sedikit lebih lama untuk memberikan stabilitas yang terjamin kepada pengembang. Saya sangat senang dengan keputusan kebijakan sehubungan dengan bidang pribadi, dan sering berhubungan dengan @DanielRosenwasser tentang mereka. Tim TypeScript telah memberikan banyak masukan yang berguna untuk TC39 selama bertahun-tahun, yang membantu membentuk desain banyak fitur.

Saya pikir tempat terbaik untuk mendiskusikan keputusan desain bahasa ini adalah di repositori proposal, dalam pertemuan TC39, dan dalam konteks lain yang didedikasikan untuk pekerjaan ini. Kami telah membahas bidang pribadi dan proposal metode secara ekstensif dengan @trusktr di sana; diskusi di sini tampaknya di luar topik.

Pada akhirnya, saya pikir TC39 adalah tempat di mana kita harus terus melakukan desain bahasa, dan repositori TypeScript bisa menjadi tempat untuk mendiskusikan aspek lain, seperti prioritas dan detail implementasi untuk suatu fitur, dan penilaian kapan suatu fitur cukup stabil untuk dikirim.

Karena TypeScript Intellisense mendukung penyorotan sintaks JavaScript dalam VS Code dan dua masalah penyorotan sintaks yang saya temukan (Microsoft/vscode#72867 dan Microsoft/vscode#39703) di repositori VS Code redirect di sini - di mana implementasi ini ke dalam TypeScript dibahas - izinkan saya berkontribusi dengan mengatakan bahwa akan lebih baik jika ini tidak menjadi kesalahan dalam file JavaScript.

JavaScript yang benar-benar valid ditandai sebagai salah dalam Kode VS karena kompiler untuk bahasa yang berbeda sedang dalam proses memutuskan apakah sintaks akan didukung atau tidak. :-)

Saya tidak punya masalah dengan TypeScript yang meluangkan waktu sebelum membuat keputusan tentang ini (sebenarnya saya mendukungnya!), Tetapi ini memengaruhi penyorotan sintaksis JavaScript dengan cara yang tidak dapat dengan mudah diperbaiki atau pekerja di sekitar bahkan secara lokal (sejauh Saya tahu) dengan menambal file tata bahasa penyorot sintaks, karena tidak ada yang ditambal (AFAIK).

Meskipun saya tidak berada di tim TypeScript, mereka secara aktif bekerja untuk menerapkan ini dan saya tidak berpikir ada banyak keraguan pada saat ini bahwa bidang pribadi akan didukung. Lihat https://github.com/microsoft/TypeScript/pull/30829.

Saya dapat mengonfirmasi bahwa ini sedang dikerjakan- kami berkolaborasi dengan tim TS dan saat ini sedang menyelesaikan rebase. Bersemangat untuk bidang bernama pribadi di TS (dan, dengan ekstensi, Server Bahasa).

Terima kasih banyak kepada kolaborator kami di Bloomberg untuk menerapkan ini di https://github.com/microsoft/TypeScript/pull/30829!

Hei di sana. Jika Anda ingin saya membuat masalah terpisah untuk ini, katakan saja. Saya tertarik untuk mempelajari apa alasannya untuk memancarkan #private PropertyDeclaration yang menyebabkan masalah ini .

Misalnya, deklarasi berikut akan dibuat:

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

...Mengingat masukan:

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

Saya mencoba memahami terlebih dahulu mengapa itu perlu ada, tetapi juga jika itu dapat ditinggalkan, mengingat saya sedang membangun alat di sekitar pembuatan deklarasi.

Saya mencoba memahami terlebih dahulu mengapa itu perlu ada, tetapi juga jika itu dapat ditinggalkan, mengingat saya sedang membangun alat di sekitar pembuatan deklarasi.

Kehadiran private membuat kelas menjadi nominal dalam analisis kami, jadi menjaganya dalam file deklarasi adalah penting. Anda mungkin dapat menggunakan alat transformator deklarasi pasca-emisi seperti dts-downlevel untuk menurunkan tingkat deklarasi pribadi untuk TS yang lebih lama dengan cara tertentu? (Saya tidak tahu apakah itu memiliki downlevel untuk #privas belum)

Untuk menambah apa yang dikatakan Wesley: downlevel-dts mengkonversi #private ke private pengubah, untuk kompatibilitas dengan versi TypeScript yang lebih lama.

Kehadiran pribadi membuat kelas menjadi nominal dalam analisis kami, jadi menjaganya dalam file deklarasi itu penting

Bisakah Anda menguraikan bagaimana membuat nominal kelas? Mengingat beberapa properti pribadi, #foo dan #bar , masih hanya satu deklarasi ambient #private akan ditambahkan ke deklarasi. Tidak ada cara untuk menganalisis dari deklarasi baik nama properti pribadi maupun berapa jumlahnya, karena semuanya diganti dengan satu deklarasi properti #private . Saya akan lebih memahaminya jika itu mempertahankan nama #foo dan #bar . Agak aneh, terutama mengingat bahwa LanguageService mengeluh bahwa properti #private tidak pernah digunakan. Ini terlihat seperti bug bagi saya. Tetapi dalam semua keadaan, bidang pribadi bukan bagian dari jenis properti publik dan tidak dapat diakses dari luar kelas, jadi secara teoritis saya tidak mengerti mengapa mereka harus menjadi bagian dari deklarasi? Bukankah prinsip yang sama berlaku untuk bidang dan metode yang dijelaskan dengan Pengubah akses lain selain public di mana mereka bukan tipe KeyOf dan bukan bagian dari deklarasi ambient?

Untuk menambah apa yang dikatakan Wesley: downlevel-dts mengkonversi #private ke private pengubah, untuk kompatibilitas dengan versi TypeScript yang lebih lama.

Kedengarannya seperti solusi yang bagus. Namun, dengan melakukan itu, properti apa pun yang Anda berikan kepada pengubah private tidak akan menjadi bagian dari file .d.ts karena itu bukan bagian dari properti publik dari tipe tersebut. Saya secara khusus tertarik pada deklarasi, yang bahkan dengan contoh paling sederhana menghasilkan diagnostik untuk properti yang tidak digunakan yang disebut #private .

@wessberg Saya melaporkan bug yang Anda perhatikan pada peringatan layanan bahasa yang tidak diinginkan dan mungkin dapat menerapkan solusi.

Kembali pertanyaan Anda yang lain:

Bisakah Anda menguraikan bagaimana membuat nominal kelas?

Seseorang membuka masalah tentang itu sebelumnya .

Salah satu alasan untuk membuat sesuatu yang nominal dalam kasus ini adalah agar pelaksana kelas dapat mempertahankan beberapa invarian tersembunyi di antara bidang pribadi: membuat tipe struktural akan merusak tujuan ini setidaknya tanpa tipe yang benar-benar mewah yang dapat mengekspresikan hal-hal seperti "daftarnya adalah selalu diurutkan" atau "diameternya adalah 2 * jari-jari".

Alasan lain adalah bahwa kode seperti di bawah ini seharusnya gagal untuk diketik, karena tidak ada cara untuk "melakukan hal yang benar" saat runtime:

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'

hey kawan, saya sangat bersemangat kami memiliki sintaks #private ! itu mengagumkan!

tetapi saya harus mengakui bahwa saya benar-benar kecewa kami tidak memiliki sintaks steno (lihat proposal) , seperti ini:

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

saya bertanya-tanya — bisakah kami mengembangkan plugin TypeScript atau opsi tsconfig untuk mengaktifkan sintaks steno sebagai fitur eksperimental?

saya hanya ingin peningkatan ergonomis yang apik, untuk menghindari terlalu banyak pengulangan this. - kerugian pada sintaks steno, seperti yang dicatat oleh proposal, sepertinya tidak terlalu mengkhawatirkan bagi saya, jadi saya pasti akan senang untuk mengatur "experimentalPrivateShorthand": true atau sesuatu seperti ini di proyek saya sendiri

ini bisa dilakukan? mungkin ada alasan bagus itu tidak mungkin? apa yang akan menjadi pekerjaan yang terlibat? Bersulang!

:gelombang: mengejar

@chase-moskal TypeScript tidak mengimplementasikan apa pun selain dari Jenis di luar standar ECMAScript. Alasan untuk ini adalah mengubah semantik, seperti yang ditunjukkan oleh bidang dan dekorator pribadi.

@chase-moskal Cara paling praktis untuk menghindari pengetikan this sepanjang waktu adalah jujur ​​hanya dengan menetapkan pintasan untuk itu di IDE Anda (seperti F3 misalnya). Banyak hal yang mungkin dilakukan dengan melakukan forking TS parser atau Babel parser dan menulis plugin, tetapi semuanya banyak pekerjaan dan akan membuat Anda tidak sinkron dengan perkakas resmi. Saya menyadari bahwa pertanyaan Anda adalah tentang dukungan resmi tentu saja, hanya berpikir saya akan membagikan pemikiran saya.

@jhpratt —

sejujurnya, saya benar-benar lapar sehingga saya tidak bisa menulis kelas minimalis yang cantik seperti rekan-rekan saya yang menggunakan babel lebih dari setahun yang lalu, dan babel bahkan memiliki semua lonceng dan peluit yang saya dambakan!

@mbrowne — sebenarnya bukan "kemampuan menulis" kode yang lebih penting daripada keterbacaan , jadi jangan khawatir tentang menghitung penekanan tombol. maksud saya hanya bahwa pengulangan javascript this terlalu sering menjadi kekacauan yang tidak berguna

sekarang pikirkan ini untuk keterbacaan: ketika kita mendapatkan sintaks #private steno, setiap kali Anda melihat this , Anda akan langsung tahu itu untuk mengakses anggota publik — kemenangan besar bagi keterbacaan!

lagi pula, saya baru tahu bahwa TypeScript belum mendukung metode pribadi

jadi ini semua hanya membutuhkan lebih banyak pekerjaan dan waktu, tampaknya dari orang-orang bloomberg

tanpa metode pribadi untuk mencocokkan bidang, kita hanya perlu menunggu (karena tidak ada yang akan mencampurkan TypeScript-private dengan hashtag-private di kelas yang sama tanpa menjadi gila!)

jadi, ini adalah tim Bloomberg yang memodernisasi TypeScript di sini, dan mereka juga terlibat dalam fitur privasi yang sama untuk babel setahun yang lalu juga? mereka melakukan pekerjaan tuhan, dan saya ingin tahu mengapa! lanjutkan Kerja baikmu! Bersulang!

:gelombang: mengejar

Ya, TypeScript memberi Anda dekorator bertahun-tahun yang lalu. Tebak apa? Semantik berubah, waktu besar. Sekarang TypeScript macet mendukung API lama untuk waktu dekat, dan itu akan menyebabkan kerusakan besar setiap kali diputuskan untuk menghapusnya. Fungsi panah adalah bagian dari spesifikasi ECMAScript, jadi membicarakannya sama sekali tidak relevan.

TypeScript saat ini tidak mengimplementasikan proposal ECMAScript sebelum mencapai tahap 3. Di situlah Anda perlu mendapatkan steno sebelum TS tertarik.

Ya, TypeScript memberi Anda dekorator bertahun-tahun yang lalu. Tebak apa? Semantik berubah, waktu besar.

Kita hidup di dunia yang tidak ideal, dan beberapa fitur diperlukan saat ini. Misalnya, proposal dekorator masih dalam tahap 2, tetapi beberapa proyek besar (Angular) aktif menggunakannya untuk waktu yang lama. Contoh lain: ECMAScript tidak menentukan pengubah protected untuk anggota kelas, yang berguna untuk memecahkan masalah nyata.

Sekarang TypeScript macet mendukung API lama untuk waktu dekat, dan itu akan menyebabkan kerusakan besar setiap kali diputuskan untuk menghapusnya.

Bahasa lain juga memperkenalkan fitur eksperimental di bawah flag compiler.

Saya tidak mengatakan bahwa TypeScript harus mengimplementasikan setiap proposal di bawah Tahap 1 atau 2, tetapi banyak proposal menarik untuk TS hanya macet, karena tidak ada padanan dalam ECMAScript, misalnya https://github.com/microsoft/TypeScript/issues/2000

@ikokostya Saya menggunakan dekorator sebagai contoh sesuatu di mana semantik telah berubah setelah TypeScript mengimplementasikannya. Apakah Anda benar-benar mengatakan bahwa singkatan ini "dibutuhkan sekarang"? Percayalah, kita bisa mengatur lima karakter tambahan. Jika itu penting bagi Anda, Anda bebas membayar kompiler.

TypeScript telah tegas untuk tidak mengimplementasikan apa pun sebelum tahap 3, bahkan di bawah bendera. Hal ini telah dibahas secara menyeluruh dalam berbagai masalah lain sebelumnya.

Saya tidak melihat apa-apa selain berputar-putar, jadi saya tidak akan menanggapi lebih jauh kecuali sesuatu yang penting muncul.

@jhpratt Maksud saya bukan tentang singkatan. Silakan baca komentar saya sampai habis.

Saran tentang garpu sama sekali tidak relevan.

Tidak semua orang setuju—dan lebih tepatnya, tidak semua orang di komite TC39 setuju—bahwa steno akan membuat kode lebih mudah dibaca atau intuitif. Ada banyak diskusi tentang ini, dan sintaks steno dipindahkan ke proposal terpisah karena kekhawatiran itu. (Saya belum cukup memikirkannya untuk membentuk opini saya sendiri, hanya memberikan rekap.) Jika Anda ingin mendorong proposal ini ke depan, cara untuk melanjutkan adalah memberikan umpan balik ke TC39. Saya yakin sudah ada banyak pekerjaan yang terlibat dalam mempertahankan TS dan menerapkan semua proposal yang telah mencapai tahap 3, jadi sulit untuk membayangkan ini dipertimbangkan untuk TS kecuali jika maju lebih jauh di TC39.

tapi saya harus mengakui saya benar-benar kecewa kami tidak memiliki sintaks steno (lihat proposal)

Singkatan itu akan tidak sesuai dengan proposal pipa yang juga mungkin menggunakan # dan sudah dibahas menjadi proposal tahap-2. Benar-benar tidak masuk akal untuk mengimplementasikan proposal sedini ini dan kemudian membuat perubahan besar. Pada tahap awal seperti itu Anda bahkan tidak tahu proposal mana yang akan menang.

Bahkan jika ternyata kompatibel, saya dapat memikirkan setidaknya beberapa kasus penggunaan lagi untuk operator awalan # yang lebih berguna daripada menjadi singkatan untuk mengetik 5 karakter tambahan.

… terutama ketika sebagian besar kasus penggunaan untuk bidang pribadi tidak ada di this sama sekali (misalnya, static isMe(obj) { try { obj.#x; return true; } catch { return false; } } , untuk menyebutkan satu contoh).

@phaux — itu informasi yang sangat bagus tentang steno vs pipa, terima kasih!

@jhpratt

TypeScript telah tegas untuk tidak mengimplementasikan apa pun sebelum tahap 3, bahkan di bawah bendera.

cukup adil, tetapi kemudian harus ditunjukkan, bahwa metode pribadi sebenarnya adalah tahap 3 , tetapi belum ada dukungan TypeScript — dan lihat, saya sangat menyukai proposal singkatan, tetapi itu hanya estetika — saya sebenarnya sekarang jauh lebih kecewa tentang kurangnya metode dan pengakses pribadi sekarang

saya berasumsi (berdoa) bahwa tim bloomberg melanjutkan pekerjaan tuhan di sini pada TypeScript, seperti yang mereka lakukan untuk babel setahun yang lalu? jika demikian, maka kita benar-benar hanya perlu bersabar dan duduk tenang :)

bagi saya sepertinya TypeScript dulu jauh lebih kompetitif dengan babel dan browser untuk fitur ecmascript, dan sekarang ini sebenarnya terlalu konservatif — kami berada dalam situasi di mana babel dan chrome telah mengirimkan bidang pribadi (tidak ditandai) selama setahun sebelumnya bloomberg datang untuk menyelamatkan kita

saya tidak nyaman dengan perbedaan merayap antara TypeScript dan fitur babel — teman-teman babel saya telah menulis kode yang apik selama setahun terakhir, sedangkan saya masih di sini membayar penalti TypeScript — mereka menertawakan saya!

saya suka TypeScript yang digunakan untuk menawarkan flag eksperimental yang memungkinkan saya untuk memutuskan apa yang saya bersedia ambil risiko refactoring di masa depan untuk membelikan saya beberapa fitur hebat — apakah sekarang posisi TypeScript, terlalu berbahaya untuk membiarkan pengembang memutuskan risiko itu, dan TypeScript itu sekarang menjadi pengasuhku?

semakin banyak, sepertinya saya dapat memilih fitur luar biasa, atau tipe statis — tetapi sekarang saya tidak dapat memiliki yang terbaik dari kedua dunia, jadi ada disonansi kognitif yang berkembang dalam diri saya

saya sangat ingin tahu tentang dinamika di sini — jika bloomberg tidak masuk seperti seorang ksatria berbaju zirah, berapa lama sebelum TypeScript menerima tantangan itu sendiri? atau ini eksperimen TypeScript: "jika kita menghindari fitur baru ini.. berapa lama lagi komunitas akan.. melakukannya untuk kita?", hah, itu cukup sinis bahkan bagi saya untuk bertanya-tanya! atau mungkin ini adalah kolaborasi baik hati yang sangat keren yang mengeksplorasi jalan baru untuk pendanaan dan dukungan untuk open source, dan ini sedikit lebih lambat dari yang diharapkan? atau mungkin filosofi TypeScript jauh lebih konservatif daripada dulu? di mana kita pada spektrum ini?

untuk implementasi fitur tahap 3, apakah lebih karena TypeScript kurang bandwidth, atau prioritas?

maaf mengomel, dan hei, saya benar-benar tidak mencoba untuk bersikap kasar atau menuduh serius di sini, hanya melemparkan pikiran dari sudut pandang orang luar saya. saya hanya pengguna dan saya benar-benar ingin tahu tentang bagaimana orang-orang di sini yang lebih tahu mungkin bereaksi terhadap gambar-gambar yang saya lukis ini — diskusi yang menarik, saya menghargai Anda semua!

:gelombang: mengejar

saya suka TypeScript yang digunakan untuk menawarkan flag eksperimental yang memungkinkan saya untuk memutuskan apa yang saya bersedia ambil risiko refactoring di masa depan untuk membelikan saya beberapa fitur hebat — apakah sekarang posisi TypeScript, terlalu berbahaya untuk membiarkan pengembang memutuskan risiko itu, dan TypeScript itu sekarang menjadi pengasuhku?

Ini bukan tentang mengasuhmu. Ini tentang tidak ingin menghabiskan waktu mengimplementasikan fitur yang pasti akan menjadi beban pemeliharaan ketika semantik berubah dalam proposal. Mereka benar-benar tidak ingin menghabiskan waktu mencari cara untuk mendamaikan semantik yang berubah ketika mereka bertentangan dengan implementasi TS. Mereka memiliki hal-hal yang lebih baik untuk dilakukan. Masih ada segunung masalah terkait tipe yang harus dipecahkan, jadi masuk akal untuk menghabiskan sumber daya mereka yang terbatas untuk itu, dan tidak mencoba melakukan pekerjaan TC39 selain menyelesaikan masalah sistem tipe.

Adapun metode dan pengakses pribadi: Itu juga tidak diterapkan di V8. Metode kelas dan bidang instance berbeda, dan mereka tidak bisa begitu saja... membalik tombol untuk mendukungnya juga. Dibutuhkan waktu aktual untuk mengimplementasikannya dan mereka memiliki tangan penuh dengan pekerjaan apa adanya dan mereka adalah tim kecil. Lebih jauh, aturannya tidak hanya proposal harus berada pada tahap 3: mereka juga secara eksplisit mengatakan bahwa mereka ingin memiliki keyakinan tinggi pada semantik proposal untuk menjadi final. Meskipun jarang, semantik _can_ berubah pada Tahap 3. Fitur ini tidak diimplementasikan di V8 tanpa alasan yang jelas. Jangan salah paham; Saya juga ingin melihat proposal itu diimplementasikan, dan tidak sabar untuk menggunakannya. Namun, mengimplementasikan proposal dari tahap awal adalah buang-buang waktu dan waktu tim TS lebih baik dihabiskan di tempat lain. Ada banyak sekali proposal Tahap 2, 1 dan 0 yang ingin saya _suka_ gunakan _hari ini_, tetapi saya mengerti mengapa saya belum dapat memilikinya. Sabar temanku.

Anda juga cukup dapat menggunakan babel, secara eksklusif, untuk mengubah naskah Anda, jika Anda lebih suka opsi yang disediakan babel untuk Anda.

@0kku — jadi Anda mengatakan itu hanya masalah bandwidth/kapasitas, bukan masalah filosofis — tumpukan bug sekarang menjadi prioritas yang lebih tinggi daripada implementasi fitur tahap 3, namun kembali ke sejarah TypeScript sebelumnya, mungkin bug lebih sedikit , sehingga lebih mudah mengalokasikan kapasitas untuk implementasi eksperimental? saya dapat membeli teori ini, dan tanggapan kami harus menunggu, atau berkontribusi

@ljharb — oh sekarang sangat menarik — apakah mungkin menjalankan TypeScript dan babel bersama sedemikian rupa? untuk mencapai yang terbaik dari kedua dunia?

tetapi saya tidak dapat melihat bagaimana layanan bahasa vscode ts masih dapat bekerja tanpa meledak pada sintaks yang tidak dikenal (seperti metode pribadi misalnya)? kekurangan intellisense menggigit terlalu banyak bagian dari proposisi nilai TypeScript — jika intellisense harus dinonaktifkan sepenuhnya, strateginya adalah non-starter

bagaimana ini bisa diperbaiki dalam jangka panjang? saya kira jika kami membedakan kesalahan TypeScript tertentu untuk setiap sintaks fitur eksperimental, dan juga, jika proyek TypeScript dapat menonaktifkan kesalahan spesifik tersebut di tingkat tsconfig — maka kami akan mencoba membuka pintu untuk memanfaatkan fitur babel dan fitur TypeScript pada saat yang sama — pria yang akan sangat keren, dan melumpuhkan seluruh kelas keluhan.. bersorak!

:gelombang: mengejar

@ljharb

Anda juga cukup dapat menggunakan babel, secara eksklusif, untuk mengubah naskah Anda

Saya kira Anda dapat mengatur proses pengecekan tipe di mana Anda hanya mengubah metode pribadi menggunakan Babel (tetapi biarkan tipe pada yang lainnya) dan lakukan pengecekan tipe pada kode itu dengan tsc . (Skrip pembangunan, untuk setelah pemeriksaan pengetikan, hanya akan menggunakan Babel saja.) Tetapi Anda harus mengabaikan banyak kesalahan sintaks dalam IDE Anda - saya pikir itu akan menjadi pemecah kesepakatan bagi kebanyakan orang.

@chase-moskal Meskipun apa yang dikatakan @0kku benar secara umum, saya belum melihat alasan untuk tidak menerapkan metode pribadi di TS saat ini. Saya pikir proposal itu lebih lambat mencapai tahap 3 daripada bidang kelas, dan para pelaksana masih mengerjakannya.

Jika Anda penasaran mengapa kami tidak tertarik untuk menggunakan fitur eksperimental, silakan lihat clusterfoxtrot yang --useDefineForClassFields . Kami menerapkan penginisialisasi properti kelas sangat, sangat awal dengan asumsi bahwa tidak ada proposal TC39 yang mungkin dengan semantik yang berbeda bahkan mungkin ada, dan kami sangat salah.

Dekorator cenderung berada di kapal yang sama, dan Anda akan terkejut jika Anda berpikir kami dapat menghentikan dukungan sepenuhnya untuk semantik lama. Beberapa perusahaan besar telah membangun kerangka kerja besar yang diadopsi dengan baik di sekitarnya; sama sekali tidak realistis bahwa kita dapat mengatakan "Nama bendera dimulai dengan experimental jadi Anda seharusnya tahu bahwa fitur yang didukung selama 5 tahun terakhir ini mungkin akan muncul dan menghilang suatu hari nanti".

Untuk kedua fitur tersebut, kita akan terjebak mempertahankan dua jalur kode yang agak berbeda di sini selama sisa hidup kita, dan itu menyebalkan, tapi itulah trade-offnya -- kami sangat berkomitmen untuk menjaga TypeScript build-to-build pembaruan dimungkinkan tanpa merusak perilaku runtime kode Anda; tradeoff ini tidak terlihat ketika itu menguntungkan Anda (misalnya program Anda terus bekerja ) tetapi Anda dapat melihat sisi negatifnya dalam hal adopsi fitur yang bersemangat dengan lebih mudah.

Dari sudut pandang kami, Anda tidak dapat melepaskan kompatibilitas runtime versi-ke-versi, dengan cara yang sama Anda tidak dapat melepaskan tanggung jawab atas kelalaian.

Kami juga menunda adopsi awal rantai opsional meskipun ada desakan komunitas MASSIVE - jika saya memiliki uang receh untuk setiap kali seseorang berkata, "Ya, taruh saja di belakang bendera", saya akan mengetik ini dari perahu. Tapi itu adalah hal yang benar untuk dilakukan, karena kami harus menebak apa yang dihasilkan (null)?.prop , dan kami benar-benar akan menebak null (bukan undefined ), dan kami' d hidup dengan beban kompleksitas lain yang berkelanjutan untuk mencari tahu yang satu itu. Ada kontrafaktual terbalik yang kuat di sini untuk fakta bahwa tidak ada yang terjebak duduk di basis kode dari 3 juta baris yang diisi dengan ?. penggunaan di mana mereka bergantung pada yang menghasilkan null kadang-kadang, tanpa cara untuk bahkan mencari cara untuk beralih ke perilaku undefined berbeda.

Bloomberg menerapkan bidang pribadi karena mereka sangat senang memiliki fitur tersebut dan ingin sekali berkontribusi pada TypeScript. Jika mereka tidak berada dalam situasi ini, kami akan mengimplementasikan fitur itu sendiri, sama seperti yang lainnya.

Secara umum saya akan mengatakan bahwa garis waktu JavaScript sangat, sangat panjang, dan secara realistis Anda dapat menulis JavaScript yang baik dan ergonomis pada tahun 2020 tanpa menggunakan sintaks 2024, sama seperti Anda dapat menulis JS yang baik dan ergonomis pada tahun 2016 tanpa menggunakan sintaks 2020. Tidak ada yang diblokir oleh ketidakmampuan untuk menggunakan sintaks yang bahkan belum memutuskan semantik; itu hanya pemrograman imajiner pada saat itu.

Tidak hanya itu, bahkan tidak 100% yakin bahwa proposal bidang kelas saat ini dan semua detailnya akan mencapai tahap 4 dalam bentuknya yang sekarang (terutama sekarang karena ada perusahaan anggota TC39 yang berusaha untuk menghapus proposal sepenuhnya dan menggantinya dengan yang berbeda). Saya kira 95% kepastian, tetapi secara umum bahkan menerapkan proposal tahap 3 tidak sepenuhnya tanpa risiko. Namun, kemungkinan perubahan lebih lanjut setelah tahap 3 sangat rendah, jadi saya pikir kebijakan TS saat ini adalah kebijakan yang baik.

sekarang ada perusahaan anggota TC39 yang ingin menghapus proposal [bidang kelas] sepenuhnya dan menggantinya dengan yang lain

Menarik, pikiran arahkan link ke itu?

Berikut idenya: mungkin tim TS dapat meluangkan waktu untuk meningkatkan sistem plugin, untuk memberi pembuat plugin API yang jelas yang terhubung ke waktu kompilasi dan waktu-server-protokol intellisense-time. Ini akan memungkinkan pihak ketiga untuk mengimplementasikan fitur eksperimental apa pun yang mereka inginkan termasuk sintaks baru, dan masih memiliki intellisense yang berfungsi di dalam IDE dan editor teks.

Terakhir saya periksa, ttypescript adalah satu-satunya cara untuk mengonfigurasi transformator TypeScript secara non-program di tsconfig.json , dan itu tidak menghubungkan ke intellisense dari IDE apa pun, sehingga kemampuan pihak ke-3 untuk membuat fitur bermakna yang terintegrasi dengan baik dengan alat yang ada seperti VS Code belum ada. Kami tidak ingin melepaskan pengalaman Kode VS kami yang bagus dengan beralih ke ttypescript dan perlu mengandalkan keluaran terminal sementara Kode VS tidak dapat memahami sintaks dan melempar kesalahan.

Kemudian TypeScript dapat fokus pada fitur stabil, dan membiarkan pihak ketiga membuat atau menggunakan fitur eksperimental yang berisiko (semudah itu di ekosistem Babel).

Menarik, pikiran arahkan link ke itu?

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

Ada serangkaian hal sintaksis yang sangat terbatas yang dapat Anda lakukan dengan plugin Babel; pada dasarnya parser harus sudah mendukungnya. Ekspresi do "plugin", misalnya, masih membutuhkan logika di inti Babel itu sendiri: https://github.com/babel/babel/blob/master/packages/babel-parser/src/parser /expression.js#L991 Ini benar-benar tidak berbeda dari switch

Apakah ada masalah yang dapat diikuti untuk metode dan pengakses kelas privat?

@RyanCavanaugh

Untuk kedua fitur itu, kita akan terjebak mempertahankan dua jalur kode yang agak berbeda di sini selama sisa hidup kita

Saya tidak berpikir bahwa itu harus berjalan seperti ini dan saya dapat membayangkan bahwa itu menyakiti seluruh komunitas. Jika dekorator mencapai tahap 3, saya pikir masuk akal untuk menyediakan waktu untuk meningkatkan ke dekorator versi baru. Mungkin mendukung keduanya untuk sementara waktu, mungkin membuat hard switch dan melepaskan dekorator lama di TypeScript 4+. Saya tidak tahu perbedaan antara dekorator lama dan baru, karena saya tidak menggunakannya (yah, fitur eksperimental). Tapi saya pikir proyek yang terkena dampak harus mengerjakan proposal, jika proposal tidak memenuhi kebutuhan mereka. Itu lebih baik untuk semua orang. TypeScript adalah tempat yang salah untuk mengobarkan perang tentang fitur warisan dan eksperimental.

Saya menyesal telah mendarat di sini :/

@RyanCavanaugh

Ada serangkaian hal sintaksis yang sangat terbatas yang dapat Anda lakukan dengan plugin Babel; pada dasarnya parser harus sudah mendukungnya.

Benar. Tetapi untuk membandingkan dengan TypeScript, di Babel Anda dapat memotong parser saja dan mengatur babel.config.js untuk menggunakan parser khusus dan plugin sintaks khusus apa pun yang Anda buat. Ya itu banyak pekerjaan (terutama mempelajari cara menambahkan sintaks baru untuk pertama kalinya), tetapi saya tidak mengetahui opsi yang setara untuk TS, dan tentu saja di Babel jauh lebih mudah untuk menulis plugin transformasi berdasarkan sintaks yang ada. Saya tidak yakin apa status opsi penyesuaian saat ini di TypeScript, tetapi ketika saya terakhir melihatnya beberapa tahun yang lalu sepertinya tidak ada opsi untuk memperpanjangnya selain memotong semuanya.

Coba ini: https://github.com/dsherret/ts-morph

Hash untuk privates IMO jelek dan membingungkan. Ini sulit ditegakkan karena tidak ada cara untuk menerapkannya sebaliknya. Tidak ada langkah membangun seperti di TS. Efeknya adalah itu hanya menyumbat kode dengan simbol untuk keuntungan yang sangat kecil dari "pribadi yang sulit" dengan orang-orang berpikir itu adalah cara yang 'benar' untuk menulis JS karena banyak orang diajari bahwa hal-hal seharusnya bersifat pribadi secara default.
Seharusnya ada lebih banyak proposal sebelum mendorongnya ke dalam standar, terutama ketika ada ketidaksepakatan yang jelas tentang masalah ini.

@ robot56 hal - hal diajari bahwa semua hal harus dapat diakses melalui refleksi, yang sebenarnya bukan hal yang baik untuk siapa pun.

@ljharb Ya, mereka harus. Namun ketika cara mendeklarasikan private menjadi melempar simbol hash di depan variabel, cara "benar" untuk membuat kelas di JS berarti mengajari orang untuk hanya meletakkan hash di depan variabel anggota. Tidak hanya saat mendeklarasikannya, tetapi juga saat mereferensikannya. Ini sangat membingungkan jika Anda berasal dari bahasa lain. Pikiran pertama saya ketika melihat sesuatu seperti this.#x = this.#something(); dan deklarasi di kelas adalah bahwa hash terpisah dari variabel itu sendiri. Saya tidak akan pernah menduga itu adalah modifikator. Garis bawah untuk publik, yang tampaknya mundur juga. Ini tidak benar-benar relevan dengan TS, tapi saya kira hanya kata-kata kasar yang mengganggu.

Ya, mempelajari hal-hal baru ketika seseorang sudah terbiasa mungkin menjadi penyesuaian. Saya memiliki keyakinan bahwa komunitas JS akan terus belajar!

(hash adalah bagian dari variabel itu sendiri, nama this.#x bukan "x, tetapi pribadi", tetapi sebenarnya, #x , nilai unik dalam lingkup leksikal itu)

Ya, mempelajari hal-hal baru ketika seseorang sudah terbiasa mungkin menjadi penyesuaian. Saya memiliki keyakinan bahwa komunitas JS akan terus belajar!

Cara Anda mengatakannya, terdengar seperti mempelajari sesuatu yang menambah kebijaksanaan pemrograman kami, sedangkan ini hanyalah kekhasan JS yang harus dihafal :D