Sistem jenis Windows Runtime (WinRT)

  • Artikel

Catatan umum

Semua jenis—kecuali untuk jenis dasar—harus dimuat dalam namespace. Ini tidak valid untuk jenis berada di namespace layanan global.

Jenis yang disediakan oleh Windows semuanya terkandung dalam namespace Windows.* . Jenis WinRT yang tidak disediakan oleh Windows (termasuk jenis WinRT yang disediakan oleh bagian lain Microsoft) harus berada di namespace selain Windows.*.

Dengan pengecualian antarmuka, semua jenis WinRT harus memiliki visibilitas publik. Antarmuka WinRT mungkin secara opsional memiliki visibilitas privat. Semua jenis WinRT lain yang ditentukan pengguna (struktur, kelas, enum, delegasi, atribut) harus memiliki visibilitas publik.

WinRT tidak mendukung jenis berlapis. Tidak ada jenis WinRT yang dapat mengapit jenis lain; tidak ada jenis WinRT yang dapat ditumpuk di dalam jenis lain.

Tidak semua aspek sistem jenis WinRT tersedia untuk Anda, sebagai pengembang pihak ketiga.

  • WinRT mendukung parameterisasi antarmuka dan delegasi. Namun, dalam rilis ini WinRT tidak mendukung definisi jenis parameter oleh pihak ke-3. Hanya jenis parameter yang disertakan dalam sistem di namespace Windows.* yang didukung.

  • WinRT mendukung komposisi kelas sebagai mekanisme pewarisan runtime. Namun, dalam rilis ini WinRT tidak mendukung definisi kelas root composable. Hanya kelas root composable yang disertakan dalam sistem di namespace Windows.* yang didukung.

Namespace WinRT dan nama jenis mempertahankan huruf besar/kecil, tetapi tidak sensitif, mirip dengan Sistem File Windows dan Registri Windows. Ini berarti Anda tidak dapat memiliki namespace layanan atau nama jenis yang hanya bervariasi menurut kasus. Misalnya, Anda tidak dapat memiliki Foo.SomeType dan foo. AnotherType, Anda juga tidak dapat memiliki Foo.SomeType dan Foo.someType.

Pengidentifikasi WinRT harus sesuai dengan tata bahasa berikut. Perhatikan bahwa hanya karakter yang ditentukan dalam Unicode 3.0 dan yang lebih lama yang didukung.

    identifier-or-keyword: 
        identifier-start-character   identifier-continuation-characters* 
    identifier-start-character: 
        letter-character
        underscore (U+005F) 
    identifier-continuation-characters: 
        identifier-continuation-character
        identifier-continuation-characters   identifier-continuation-character 
    identifier-continuation-character: 
        identifier-start-character 
        decimal-digit-character
        connecting-character
        combining-character
        formatting-character 
    letter-character: 
        A Unicode 3.0 character of classes Lu, Ll, Lt, Lm, Lo, or Nl 
    combining-character: 
        A Unicode 3.0 character of classes Mn or Mc 
    decimal-digit-character: 
        A Unicode 3.0 character of the class Nd 
    connecting-character: 
        A Unicode 3.0 character of the class Pc 
    formatting-character: 
        Zero Width Non-Joiner (U+200C)
        Zero Width Joiner (U+200D)

Jenis berparameter

WinRT mendukung parameterisasi jenis antarmuka dan delegasi. Jenis parameter memungkinkan keluarga antarmuka ditentukan yang dapat diproses secara polimorfis dalam bahasa pemrograman yang mendukung polimorfisme parametris.

Instansiasi jenis parameter terjadi ketika jenis parameter ditentukan dengan daftar argumen jenis dalam konteks jenis, seperti posisi parameter metode. Misalnya, HRESULT foo(X<Y> x) membuat instans jenis parameter bernama X dengan jenis Y sebagai argumen jenis pertama dan satu-satunya.

Antarmuka atau delegasi WinRT yang tidak diparameter diberi GUID untuk mengidentifikasi antarmuka yang mendasar secara unik sebagai berbeda dari antarmuka lain pada objek yang sama. Antarmuka berparameter (misalnya, IVector<T>) atau delegasi (misalnya, EventHandler<T>) malah diberi ID antarmuka berparameter (PIID), yang merupakan GUID yang secara unik mengidentifikasi jenis parameter ini. Ini bukan IID. GUID ini digunakan dalam menghasilkan IID untuk instans jenis parameter (misalnya, IVector<int>).

Daftar argumen jenis berparameter

Jenis WinRT ini diizinkan untuk muncul dalam daftar argumen untuk jenis berparameter.

  • Jenis dasar WinRT (misalnya, Boolean, Int32, String, Guid, dll.)
  • Enum WinRT
  • Struktur WinRT
  • Antarmuka WinRT
  • Delegasi WinRT
  • Kelas runtime WinRT
  • Instansiasi jenis parameter lainnya (misalnya, IVector<IVector<int>>) Jenis lain dilarang muncul dalam daftar argumen jenis parameter. Misalnya, array.

Instans jenis berparameter

Instans jenis berparameter dapat muncul dalam konteks apa pun yang dapat muncul dari jenis non-parameter. Instans antarmuka berparameter dapat digunakan di mana saja antarmuka dapat digunakan, seperti dalam daftar antarmuka yang diterapkan oleh kelas runtime. Instans delegasi berparameter dapat digunakan di mana saja delegasi dapat digunakan, seperti dalam definisi peristiwa.

Parameter jenis parameter dapat muncul: dalam antarmuka parameter atau definisi delegasi; atau, di mana pun jenis normal dapat muncul. Jika parameter muncul di mana hanya antarmuka yang dapat muncul, parameter tersebut dibatasi untuk menjadi antarmuka. Jika parameter muncul dalam konteks di mana jenis apa pun dapat muncul, parameter tersebut tidak dibatasi; dan sebagainya. Argumen untuk instans jenis parameter harus memenuhi semua batasan tersebut.

Pembuatan guid untuk jenis berparameter

Algoritma pembuatan guid harus memenuhi persyaratan ini.

  • Ketika jenis parameter diinstansiasi dua kali dengan argumen yang sama, kedua instansiasi harus ditetapkan antarmuka atau isi delegasi yang sama, dan IID yang sama.
  • Jika dua jenis parameter yang berbeda dibuat, bahkan dengan argumen yang sama, secara statistik tidak mungkin bahwa mereka diberi IID yang sama.
  • Jika jenis parameter diinstansiasi dua kali, tetapi dengan argumen yang berbeda, secara statistik tidak mungkin kedua instansiasi diberi IID yang sama.

Catatan

Ini tidak diizinkan untuk jenis berparameter yang akan diinstansiasi dengan instansiasi yang sama dengan argumen, atau sebagai argumen ke jenis parameter lain yang muncul dalam daftar argumen (yaitu, instansiasi melingkar). Misalnya, jika X = Foo<Y>, dan Y = Foo<X>, non-sirkularitas telah dilanggar. Namun, jika X = Foo<Y> dan Y = Foo<int>, maka non-sirkularitas telah dipertahankan.

Algoritma instansiasi adalah sebagai berikut.

  1. Setiap jenis parameter diberi ID antarmuka parameter oleh pembuatnya—disingkat PIID. Perhatikan bahwa PIID bukan IID, juga tidak diteruskan sebagai argumen ke QueryInterface. Penulis harus memastikan bahwa PIID unik untuk jenis parameter.
  2. Tanda tangan jenis untuk jenis dasar adalah string oktet ASCII (lihat tabel di bawah). Misalnya, Int32 adalah "i4".
  3. Tanda tangan jenis untuk antarmuka yang bukan merupakan instans antarmuka parameter adalah IID-nya yang dikodekan dalam ASCII dalam bentuk putus-putus, dan dibatasi oleh kurung kurawal. Misalnya, "{00000000-0000-0000-0000-000000000000}".
  4. Tanda tangan jenis untuk delegasi yang bukan instans delegasi berparameter adalah string "delegasi", lalu IID seperti halnya antarmuka. Tata bahasa terperinci muncul berikutnya.
  5. Panduan untuk jenis berparameter dihitung sesuai dengan tata bahasa ini.
    • menurut UUID rfc 4122, komputasi hash signature_octets yang dihasilkan ver 5 sha-1—ini menggunakan guid pinterface/pintergroup winrt tunggal sebagai namespace seperti yang dijelaskan dalam rfc 4122/4.3, dan tanda tangan pinterface/pintergroup dan args yang diinisiasi dengan sebagai string nama.
    • instansiasi pinterface diberi guid ini, dan tanda tangan dari 4.
    signature_octets => guid_to_octets(wrt_pinterface_namespace) string_to_utf8_octets(ptype_instance_signature)

        wrt_pinterface_namespace => "11f47ad5-7b73-42c0-abae-878b1e16adee"

        ptype_instance_signature => pinterface_instance_signature | pdelegate_instance_ signature

        pinterface_instance _signature => "pinterface(" piid_guid  ";" args ")"

        pdelegate_instance _signature => "pinterface(" piid_guid ";" args ")"

        piid_guid => guid

        args => arg | arg ";" args

        arg => type_signature

        type_signature => base_type_identifer | com_interface_signature | interface _signature | delegate_signature  | interface_group_signature | runtime_class_signature | struct_signature | enum_signature | pinterface_instance_signature | pdelegate_instance_signature
        com_interface_signature => "cinterface(IInspectable)"

        base_type_identifier is defined below

        interface_signature => guid

        interface_group_signature => "ig(" interface_group_name ";" default_interface ")"

        runtime_class_signature => "rc(" runtime_class_name ";" default_interface ")"

        default_interface => type_signature

        struct_signature => "struct(" struct_name ";" args ")"

        enum_signature => "enum(" enum_name ";" enum_underlying_type ")"

        enum_underlying_type => type_signature

        delegate_signature => "delegate(" guid ")"

        guid => "{" dashed_hex "}"

        dashed_hex is the format that uuidgen writes in when passed no arguments.

            dashed_hex => hex{8} "-" hex{4} "-" hex{4} "-" hex{4} "-" hex{12}

            hex => [0-9a-f]
  1. Ketika instansiasi jenis p diteruskan sebagai argumen ke pinterface lainnya, tanda tangan yang dihitung oleh langkah 3 digunakan sebagai tanda tangan jenis dalam elemen tata bahasa 'pinterface_instance_signature' atau 'pdelegate_instance_signature', sebagaimana merujuknya.

Nama-nama ini digunakan untuk jenis dasar saat muncul.

  • UInt8 memetakan ke "u1"
  • Int32 memetakan ke "i4"
  • UInt32 memetakan ke "u4"
  • Int64 memetakan ke "i8"
  • UInt64 memetakan ke "u8"
  • Peta tunggal ke "f4"
  • Peta ganda ke "f8"
  • Boolean memetakan ke "b1"
    • Perhatikan bahwa, untuk mendapatkan dukungan parameter jenis Boolean , Anda perlu menambahkan /Yc:wchar_t untuk mengaktifkan wchar_t sebagai jenis bawaan.
  • Peta Char16 ke "c2"
  • Peta string ke "string"
  • Peta guid ke "g16"

Nama di atas peka huruf besar/kecil. Dengan pengecualian String, nama jenis menggunakan satu karakter untuk menyarankan jenis data, diikuti dengan ukurannya dalam byte. Nama-nama ini dipilih: menjadi ringkas (untuk menghindari ukuran besar dalam tanda tangan jenis struct); agar tidak tampak membingungkan mirip dengan nama WinRT, nama RIDL, atau nama proyeksi bahasa untuk jenis apa pun; dan masih untuk tetap kira-kira dapat dibaca manusia.

Untuk enum_type_signature, satu-satunya nilai 'underlying_type' yang valid adalah Int32 atau UInt32.

Untuk struct_type_signature, args adalah daftar type_signatures berurutan untuk bidang struktur. Ini mungkin jenis dasar, atau jenis struktur lainnya.

Struct_name dan enum_name memenuhi syarat namespace, menggunakan titik "." sebagai pemisah. Misalnya, "namespace X { struct A{ int; }; }" menjadi "struct(X.A;i4)".

Default_interface harus antarmuka, instans antarmuka p, delegasi, atau instans delegasi p yang ditentukan sebagai default di kelas runtime atau isi grup antarmuka, menggunakan atribut IDL '[default]'.

Perhatikan bahwa atribut kustom diabaikan; diasumsikan tidak berpengaruh pada marshaling.

Versi

Semua jenis WinRT kecuali jenis dasar harus memiliki atribut Version. Proyeksi bahasa menggunakan info atribut Versi untuk mengaktifkan kompatibilitas mundur, dan untuk skenario pencahayaan. Jenis pihak ketiga harus menyertakan atribut Versi, tetapi harus diabaikan oleh proyeksi bahasa. Komponen WinRT pihak ketiga dipaketkan secara eksklusif dalam aplikasi, sehingga mereka tidak pernah dapat mengubah versi secara independen dari aplikasi itu sendiri.

Atribut Versi dapat secara opsional diterapkan ke anggota antarmuka (metode, properti, dan peristiwa). Ini ditujukan untuk penulisan kelas tingkat tinggi di C#/VB dan C++/CX. Atribut versi pada anggota antarmuka, bahkan anggota antarmuka sistem Windows, harus diabaikan saat runtime berdasarkan proyeksi bahasa.

Atribut Versi menyertakan parameter konstruktor bilangan bulat 32-bit yang tidak ditandatangani. Untuk jenis Windows WinRT, nilai ini adalah nilai NTDDI untuk versi Windows konstruksi jenis terkait pertama kali didefinisikan. Untuk jenis pihak ketiga, arti dari nilai ini terserah penulis jenis.

Struktur, delegasi, dan antarmuka sistem Windows tidak dapat diubah setelah ditentukan. Mereka mungkin tidak pernah dimodifikasi dalam rilis Windows berikutnya.

Enum sistem Windows dan kelas runtime secara aditif dapat diversifikasi. Enum dapat menambahkan nilai enum baru dalam rilis Windows berikutnya. Kelas dapat menambahkan antarmuka baru yang diimplementasikan (termasuk pabrik statis, aktivasi, pabrik komposisi, antarmuka yang dapat diambil alih, dan dilindungi) dalam rilis Windows berikutnya. Detail lebih lanjut tentang penerapan versi aditif disertakan dalam bagian untuk enum dan kelas runtime.

Namaspace

Namespace adalah cakupan penamaan yang digunakan untuk mengatur kode, dan untuk menghindari penamaan tabrakan. Semua jenis bernama dalam sistem jenis WinRT (enum, struct, delegasi, antarmuka, dan kelas runtime) tinggal di namespace layanan. Namespace dapat berisi namespace lain.

Jenis-jenis dasar

Sistem Jenis WinRT mencakup serangkaian inti jenis primitif bawaan.

Jenis WinRT Deskripsi jenis
Int16 bilangan bulat bertanda tangan 16-bit
Int32 bilangan bulat bertanda tangan 32-bit
Int64 bilangan bulat bertanda tangan 64-bit
UInt8 bilangan bulat tidak bertanda 8-bit
UInt16 bilangan bulat tidak bertanda 16-bit
UInt32 bilangan bulat tidak bertanda 32-bit
UInt64 bilangan bulat tidak bertanda 64-bit
Tunggal angka titik floating IEEE 754 32-bit
Ganda angka titik float IEEE 754 64-bit
Char16 nilai non-numerik 16-bit yang mewakili unit kode UTF-16
Boolean nilai Boolean 8-bit
String urutan Char16 yang tidak dapat diubah yang digunakan untuk mewakili teks
Guid Guid standar 128-bit

Enum

Jenis enum adalah jenis nilai yang berbeda dengan sekumpulan konstanta bernama.

Setiap jenis enum memiliki jenis integral yang sesuai yang disebut jenis enum yang mendasar. Satu-satunya jenis enum hukum yang mendasar di WinRT adalah Int32 dan UInt32.

Enum dengan jenis UInt32 yang mendasar harus membawa FlagsAttribute. Enum dengan jenis Int32 yang mendasar tidak boleh membawa FlagsAttribute.

Enum harus memiliki visibilitas publik.

Penerapan versi enum

Enum dapat diversi secara aditif. Versi berikutnya dari enum tertentu dapat menambahkan nilai (juga dikenal sebagai konstanta bernama). Nilai yang sudah ada sebelumnya mungkin tidak dihapus atau diubah. Nilai Enum secara opsional membawa VersionAttribute untuk membedakan kapan nilai tertentu ditambahkan ke jenis enum. Nilai enum tanpa VersionAttribute dianggap memiliki nilai versi yang sama dengan jenis enum penutup.

Struct

Struct adalah tipe catatan dengan satu atau beberapa bidang. Struktur selalu diteruskan dan dikembalikan oleh nilai. Bidang struct hanya boleh primitif, enum, struct, string, dan IReference<T> (yang terakhir adalah satu-satunya dua jenis bidang yang dialokasikan tumpukan).

Struktur harus memiliki visibilitas publik.

Secara umum, struct harus memiliki setidaknya satu bidang (ada pengecualian langka, seperti jenis yang mewakili kontrak dan atribut metadata). Semua bidang struct harus publik.

Struct tidak boleh generik atau parameter.

Antarmuka

Antarmuka adalah kontrak yang terdiri dari sekelompok anggota jenis terkait yang penggunaannya ditentukan, tetapi implementasinya tidak. Definisi antarmuka menentukan anggota antarmuka—metode, properti, dan peristiwa. Tidak ada implementasi yang terkait dengan antarmuka.

Antarmuka non-parameter harus memiliki ID antarmuka unik (alias IID) yang ditentukan melalui GuidAttribute. Antarmuka parameter harus memiliki ID antarmuka parameter unik (juga dikenal sebagai PIID) yang ditentukan melalui GuidAttribute. PIID digunakan untuk menghasilkan IID untuk instans antarmuka parameter tertentu melalui algoritma yang ditentukan di atas.

Antarmuka mungkin memiliki visibilitas publik atau privat. Ini mencerminkan fakta bahwa beberapa antarmuka mewakili kontrak bersama yang diterapkan oleh beberapa kelas WinRT, sementara antarmuka lain mewakili anggota yang diterapkan oleh satu kelas WinRT. Antarmuka visibilitas privat harus menentukan kelas WinRT yang eksklusif untuknya melalui ExclusiveToAttribute. Antarmuka privat hanya dapat diimplementasikan oleh kelas WinRT yang ditentukan dalam ExclusiveToAttribute.

IInspectable dan IUnknown

Dalam hal antarmuka, WinRT tidak memiliki gagasan tentang warisan. Sebaliknya ada gagasan bahwa antarmuka dapat memerlukan antarmuka lain. Untuk informasi selengkapnya, khususnya tentang kata kunci MIDL 3.0 requires , lihat antarmuka MIDL 3.0.

Semua antarmuka WinRT secara implisit memerlukan IInspectable; dan pada gilirannya IInspectable membutuhkan IUnknown. IUnknown mendefinisikan tiga metode: QueryInterface, AddRef, dan Release sesuai penggunaan COM tradisional. IInspectable mendefinisikan tiga metode selain metode IUnknown: GetIids, GetRuntimeClassName, dan GetTrustLevel. Ketiga metode ini memungkinkan klien objek untuk mengambil informasi tentang objek . Secara khusus, IInspectable.GetRuntimeClassName memungkinkan klien objek untuk mengambil nama jenis WinRT yang dapat diselesaikan dalam metadata untuk mengaktifkan proyeksi bahasa.

Antarmuka memerlukan

Seperti disebutkan di atas, antarmuka dapat menentukan bahwa antarmuka memerlukan satu atau beberapa antarmuka lain yang harus diimplementasikan pada objek apa pun yang mengimplementasikan antarmuka yang dimaksud. Misalnya, jika IButton memerlukan IControl, maka kelas apa pun yang menerapkan IButton juga perlu menerapkan IControl.

Tetapi sistem jenis WinRT maupun ABI tidak memiliki konsep pewarisan antarmuka. Jadi ide untuk menambahkan fungsionalitas baru dengan menerapkan antarmuka baru yang mewarisi dari antarmuka yang ada (misalnya, IFoo2 mewarisi dari IFoo) tidak memiliki arti. Memang benar bahwa proyeksi bahasa WinRT dapat menggunakan hubungan warisan untuk kemudahan konsumsi dalam bahasa tertentu, dan kelas runtime dapat menggunakan pewarisan, tetapi pewarisan antarmuka tidak ada dalam konteks penulisan MIDL 3.0 (lihat antarmuka MIDL 3.0).

Antarmuka berparameter

Antarmuka mendukung parameterisasi jenis. Definisi antarmuka berparameter menentukan daftar parameter jenis selain daftar anggota antarmuka dan antarmuka yang diperlukan. Antarmuka yang diperlukan dari antarmuka berparameter dapat berbagi daftar argumen jenis yang sama, sehingga argumen jenis tunggal digunakan untuk menentukan instans parameter antarmuka dan antarmuka yang diperlukannya (misalnya, IVector<T> requires IIterable<T>). Tanda tangan anggota mana pun (yaitu, metode, properti, atau peristiwa) dari antarmuka berparameter dapat mereferensikan jenis dari daftar argumen jenis antarmuka parameter (misalnya, IVector<T>.SetAt([in] UInt32 index, [in] T value)).

Pihak ketiga tidak dapat menentukan antarmuka parameter baru. Hanya antarmuka berparameter yang ditentukan oleh sistem yang didukung.

Delegasikan

Delegasi adalah jenis WinRT yang bertindak sebagai penunjuk fungsi jenis aman. Delegasi pada dasarnya adalah objek WinRT sederhana yang mengekspos satu antarmuka yang mewarisi dari IUnknown, dan mendefinisikan satu metode bernama Invoke. Memanggil delegasi secara bergantian memanggil metode yang direferensikannya. Delegasi sering (tetapi tidak secara eksklusif) digunakan untuk mendefinisikan peristiwa WinRT.

Delegasi WinRT adalah jenis bernama, dan menentukan tanda tangan metode. Mendelegasikan tanda tangan metode mengikuti aturan yang sama untuk parameter seperti metode antarmuka. Nama tanda tangan dan parameter metode Invoke harus cocok dengan definisi delegasi.

Seperti antarmuka, delegasi non-parameter harus memiliki ID antarmuka unik (alias IID) yang ditentukan melalui GuidAttribute. IID delegasi digunakan sebagai IID antarmuka metode tunggal yang digunakan untuk mengimplementasikan delegasi. Delegasi berparameter harus memiliki ID antarmuka parameter unik (juga dikenal sebagai PIID) yang ditentukan melalui GuidAttribute. PIID digunakan untuk menghasilkan IID untuk instans delegasi parameter tertentu melalui algoritma yang ditentukan di atas.

Delegasi harus memiliki visibilitas publik.

IUnknown

Perhatikan bahwa, tidak seperti antarmuka WinRT, delegasi mengimplementasikan IUnknown, tetapi tidak IInspectable. Ini berarti bahwa mereka tidak dapat diperiksa untuk informasi jenis saat runtime.

Delegasi berparameter

Delegasi mendukung parameterisasi jenis. Definisi delegasi berparameter menentukan daftar parameter jenis selain tanda tangan metode tradisional seperti yang ditentukan di atas. Dalam tanda tangan metode, parameter apa pun dapat ditentukan sebagai salah satu jenis dari daftar argumen jenis delegasi yang diparameterkan.

Pihak ketiga tidak dapat menentukan delegasi parameter baru. Hanya delegasi berparameter yang ditentukan oleh sistem yang didukung.

Anggota antarmuka

Antarmuka WinRT mendukung tiga jenis anggota: metode, properti, dan peristiwa. Antarmuka mungkin tidak memiliki bidang data.

Metode

Antarmuka WinRT mendukung metode yang mengambil parameter nol atau lebih, dan yang mengembalikan HRESULT yang menunjukkan keberhasilan atau kegagalan panggilan metode. Metode dapat secara opsional menunjukkan parameter tunggal yang akan diproyeksikan sebagai nilai pengembalian dalam bahasa berbasis pengecualian. Parameter nilai yang dikembalikan ini, jika ditentukan, harus menjadi parameter terakhir dalam tanda tangan metode.

Metode harus memiliki visibilitas publik.

Metode mungkin tidak menggunakan jumlah variabel argumen. Metode mungkin tidak memiliki parameter opsional, atau parameter dengan nilai default.

Metode mungkin tidak diparameterkan. Delegasi parameter dan metode antarmuka berparameter dapat menggunakan parameter jenis dari jenis yang berisi dalam tanda tangan metode.

Parameter

Semua parameter metode kecuali parameter panjang array (dijelaskan di bawah) harus memiliki nama dan jenis. Perhatikan bahwa nilai yang dikembalikan harus menentukan nama seperti yang dilakukan parameter. Nama parameter metode, termasuk nama jenis pengembalian, harus unik dalam cakupan metode .

Hanya parameter untuk delegasi berparameter dan anggota antarmuka berparameter yang dapat menentukan jenis parameter untuk jenis parameter. Metode mungkin tidak diparameterkan secara individual. Parameter dapat selalu menentukan instans jenis parameter (misalnya, IVector<int>) sebagai jenis parameter.

Semua parameter metode harus secara eksklusif masuk atau keluar parameter. Parameter masuk/keluar tidak didukung.

Meskipun metode pada antarmuka WinRT harus mengembalikan HRESULT, metode dapat secara opsional menunjukkan bahwa parameter keluar terakhirnya dimaksudkan untuk digunakan sebagai nilai pengembalian ketika metode diproyeksikan ke dalam bahasa berbasis pengecualian. Parameter tersebut dikenal sebagai parameter [out, retval] setelah sintaks MIDL yang digunakan untuk mendeklarasikannya. Ketika parameter [out, retval] ditentukan, parameter tersebut harus menjadi parameter terakhir dalam tanda tangan metode.

Selain [out, retval] perlu muncul di akhir daftar parameter, tidak ada persyaratan pemesanan lain untuk parameter keluar.

Parameter array

Metode WinRT mendukung parameter array yang sesuai. Array tidak pernah dapat digunakan kecuali sebagai parameter. Mereka tidak dapat berdiri sendiri bernama jenis, dan mereka tidak dapat digunakan sebagai jenis bidang struct. Parameter array dapat digunakan sebagai inparameter , out, dan retval .

WinRT mendukung parameter array dari sebagian besar jenis WinRT termasuk jenis dasar (termasuk string dan guid), struktur, enum, delegasi, antarmuka, dan kelas runtime. Array array lain tidak diperbolehkan.

Karena sesuai, parameter array harus selalu didahului dalam daftar parameter dengan parameter untuk ukuran array. Parameter ukuran array harus UInt32. Parameter ukuran array tidak memiliki nama.

WinRT mendukung tiga gaya larik yang berbeda.

  • PassArray. Gaya ini digunakan ketika pemanggil menyediakan array ke metode . Dalam gaya ini, parameter ukuran array dan parameter array adalah kedua in parameter.
  • FillArray. Gaya ini digunakan ketika pemanggil menyediakan array untuk diisi metode, hingga ukuran array maksimum. Dalam gaya ini, parameter ukuran array adalah in parameter, sedangkan parameter array adalah out parameter . Saat menggunakan gaya FillArray, parameter array dapat secara opsional menentukan salah satu parameter lain sebagai parameter panjang array. Rincian di bawah ini.
  • ReceiveArray. Gaya ini digunakan ketika penelepon menerima array yang dialokasikan oleh metode . Dalam gaya ini, parameter ukuran array dan parameter array adalah kedua out parameter. Selain itu, parameter array diteruskan oleh referensi (yaitu, ArrayType**, bukan ArrayType*).

Catatan

Kombinasi out parameter ukuran array, tetapi in parameter array, tidak valid di WinRT.

Saat parameter array digunakan sebagai parameter [out, retval], parameter panjang array harus berupa out parameter—yaitu, hanya gaya ReceiveArray yang legal untuk retval array.

Parameter panjang array

Parameter array gaya FillArray dapat secara opsional menentukan parameter lain sebagai parameter panjang array. Jika parameter ukuran array yang diperlukan menentukan jumlah maksimum elemen dalam array yang disediakan oleh pemanggil, parameter panjang array menentukan jumlah elemen yang benar-benar diisi oleh penerima panggilan.

Parameter panjang array ditentukan dengan atribut LengthIs pada parameter array.

Metode kelebihan beban

Dalam cakupan antarmuka tunggal, lebih dari satu metode mungkin memiliki nama yang sama. Metode dengan nama yang sama pada antarmuka harus memiliki tanda tangan yang unik. Properti dan peristiwa tidak dapat kelebihan beban.

WinRT mendukung kelebihan beban pada jenis parameter, tetapi mendukung kelebihan beban pada jumlah parameter input—juga dikenal sebagai aritas metode. Ini dilakukan untuk mendukung bahasa dinamis yang ditik dengan lemah (seperti JavaScript).

Ketika antarmuka memiliki beberapa metode dengan nama dan jumlah parameter input yang sama, tepat salah satu metode tersebut harus ditandai sebagai default. Dari semua metode yang kelebihan beban dengan nama dan jumlah parameter input yang sama, hanya metode yang ditandai sebagai default yang akan diproyeksikan oleh bahasa yang dinamis dan ditik dengan lemah. Jika hanya ada satu metode kelebihan beban dari nama tertentu dan jumlah parameter input, menandainya sebagai default valid, tetapi tidak diperlukan.

Untuk tujuan menentukan aritas metode, parameter array dan parameter panjang yang diperlukan adalah pertimbangkan satu parameter. Gaya PassArray dan FillArray dianggap sebagai parameter input tunggal, sementara gaya ReceiveArray dianggap sebagai parameter output tunggal.

Ketika beberapa metode pada antarmuka memiliki nama yang sama, nama unik untuk setiap metode bertabrakan harus disimpan dalam OverloadAttribute yang dilampirkan ke metode . Metode kelebihan beban default membawa DefaultOverloadAttribute.

Kelebihan beban operator

WinRT tidak mendukung kelebihan beban operator. Metode tidak boleh diberi nama menggunakan nama operator khusus seperti op_Addition yang ditentukan dalam spesifikasi CLI ECMA 335, partisi I, bagian 10.3.

Properti

Properti adalah sepasang metode get/set dengan nama dan jenis yang cocok yang muncul dalam beberapa proyeksi bahasa sebagai bidang daripada metode.

Properti dan metode get/set-nya harus memiliki visibilitas publik.

Properti harus memiliki get metode . Metode getter properti tidak memiliki parameter, dan mengembalikan nilai jenis properti. Properti dengan hanya get metode disebut properti baca-saja.

Properti mungkin secara opsional memiliki set metode . Metode setter properti memiliki parameter tunggal dari jenis properti, dan mengembalikan kekosongan. Properti dengan get metode dan set disebut properti baca/tulis.

Properti mungkin tidak diparameterkan. Properti dari antarmuka berparameter dapat menggunakan parameter jenis dari jenis yang berisi sebagai jenis properti.

Acara

Peristiwa adalah sepasang metode tambahkan/hapus pendengar dengan nama yang cocok dan jenis delegasi. Peristiwa adalah mekanisme bagi antarmuka untuk memberi tahu pihak-pihak yang tertarik ketika sesuatu yang signifikan terjadi.

Peristiwa dan metode pendengar add/remove-nya harus memiliki visibilitas publik.

Metode pendengar peristiwa add memiliki parameter tunggal dari jenis delegasi peristiwa, dan mengembalikan Windows.Foundation.EventRegistrationToken. Metode pendengar peristiwa remove memiliki parameter tunggal jenis Windows.Foundation.EventRegistrationToken , dan mengembalikan kekosongan.

Peristiwa mungkin tidak diparameterkan. Peristiwa dari antarmuka berparameter dapat menggunakan parameter jenis dari jenis yang berisi sebagai jenis delegasi peristiwa.

Kelas runtime

WinRT memungkinkan Anda menentukan kelas. Kelas harus mengimplementasikan satu atau beberapa antarmuka. Kelas tidak dapat mengimplementasikan anggota jenis secara langsung (yaitu, tidak dapat menentukan metode, properti, atau peristiwanya sendiri). Kelas harus menyediakan implementasi semua anggota dari semua antarmuka yang diterapkannya.

Ada beberapa jenis antarmuka yang berbeda, yang dijelaskan secara rinci di bawah ini.

  • Antarmuka anggota (termasuk antarmuka yang dilindungi dan dapat diganti)
  • Antarmuka statis
  • Antarmuka pabrik aktivasi
  • Antarmuka pabrik komposisi

Kelas runtime tidak dapat diparameterkan. Kelas runtime dapat mengimplementasikan instans antarmuka berparameter (yaitu, antarmuka berparameter dengan semua parameter jenisnya yang ditentukan) di mana saja biasanya akan menerima antarmuka non-parameter.

Kelas runtime harus memiliki visibilitas publik.

Kelas runtime hanya dapat mengimplementasikan antarmuka yang tidak eksklusif (yaitu, jangan membawa atribut exclusiveTo) atau yang eksklusif untuk kelas runtime yang dimaksud. Kelas runtime mungkin tidak mengimplementasikan antarmuka yang eksklusif untuk kelas runtime yang berbeda. Ada satu pengecualian untuk aturan ini—kelas yang dapat disusun dapat mengimplementasikan antarmuka yang eksklusif untuk kelas dalam rantai derivasinya yang ditandai sebagai dapat diambil alih. Detail tentang antarmuka yang dapat diganti untuk diikuti.

Antarmuka anggota

Kelas runtime dapat menerapkan nol atau lebih antarmuka anggota. Antarmuka anggota memungkinkan kelas untuk mengekspos fungsionalitas yang terkait dengan instans kelas. Kelas runtime menentukan daftar antarmuka anggota yang diterapkannya. Entri dalam daftar antarmuka anggota yang diterapkan oleh kelas runtime dapat secara opsional membawa informasi versi. Detail tentang penerapan versi kelas runtime untuk diikuti.

Antarmuka anggota diimplementasikan langsung pada instans kelas runtime.

Kelas runtime yang mengimplementasikan satu atau beberapa antarmuka anggota harus menentukan salah satu antarmuka anggota untuk menjadi antarmuka default. Kelas runtime yang mengimplementasikan antarmuka anggota nol tidak menentukan antarmuka default.

Antarmuka statis

Kelas WinRT dapat menentukan nol atau lebih antarmuka statis. Antarmuka statis memungkinkan kelas untuk mengekspos fungsionalitas yang terkait dengan kelas itu sendiri, daripada dengan instans kelas tertentu.

Kelas harus menentukan setidaknya satu anggota atau antarmuka statis. Kelas tanpa anggota dan tidak ada antarmuka statis yang tidak valid.

Antarmuka statis ditentukan melalui StaticAttribute yang terkait dengan kelas runtime. StaticAttribute membawa referensi referensi antarmuka statis serta informasi versi. Detail tentang penerapan versi kelas runtime untuk diikuti.

Meskipun antarmuka statis dinyatakan sebagai bagian dari kelas runtime, antarmuka statis sebenarnya tidak diimplementasikan pada instans kelas itu sendiri. Sebaliknya, mereka diimplementasikan di pabrik aktivasi kelas. Detail tentang pabrik aktivasi yang harus diikuti.

Aktivasi

Kelas runtime secara opsional mendukung aktivasi—kemampuan sistem untuk menghasilkan instans kelas tertentu. Kelas harus menerapkan setidaknya satu antarmuka anggota untuk mendukung aktivasi.

WinRT mendefinisikan tiga mekanisme aktivasi: aktivasi langsung (tanpa parameter konstruktor), aktivasi pabrik (dengan satu atau beberapa parameter konstruktor), dan aktivasi komposisi. Kelas yang tidak dapat dikomposiskan dapat mendukung aktivasi langsung dan/atau pabrik. Kelas yang dapat dikomposiskan hanya mendukung aktivasi yang dapat disusupi. Detail tentang komposisi dan aktivasi yang dapat dikomposisi untuk diikuti.

Kelas yang mendukung aktivasi langsung diaktifkan dengan memanggil metode IActivationFactory.ActivateInstance pada pabrik aktivasi kelas. Metode ini tidak mengambil parameter, dan mengembalikan instans yang baru diaktifkan dari kelas runtime. Detail tentang pabrik aktivasi yang harus diikuti.

Kelas yang mendukung aktivasi pabrik menentukan satu atau beberapa antarmuka pabrik, yang masing-masing pada gilirannya menentukan satu atau beberapa metode pabrik. Antarmuka pabrik ini diimplementasikan pada pabrik aktivasi kelas.

Metode pabrik mengambil satu atau beberapa in parameter, dan harus mengembalikan instans yang baru diaktifkan dari kelas runtime. Parameter lain out di luar instans kelas yang baru diaktifkan tidak diizinkan. Metode pabrik harus mengambil satu atau beberapa parameter—aktivasi pabrik tanpa parameter tidak diizinkan. Aktivasi langsung harus digunakan untuk aktivasi tanpa parameter.

Kelas yang mendukung aktivasi langsung atau pabrik ditandai dengan ActivatableAttribute. ActivatableAttribute membawa informasi versi (detail tentang penerapan versi kelas runtime untuk diikuti) serta referensi opsional ke antarmuka pabrik. Kelas dapat ditandai dengan beberapa ActivatableAttributes—paling banyak satu untuk aktivasi default, ditambah satu untuk setiap antarmuka pabrik yang diimplementasikan oleh pabrik aktivasi kelas. Kelas yang ditandai dengan ActivatableAttribute mungkin juga tidak ditandai dengan ComposableAttribute. Detail tentang komposisi untuk diikuti.

Komposisi

Kelas runtime secara opsional mendukung komposisi—kemampuan untuk beberapa instans kelas untuk digabungkan menjadi objek tunggal dari luar. WinRT menggunakan komposisi sebagai bentuk pewarisan kelas runtime.

Kelas WinRT dapat secara opsional menyusun satu kelas dasar yang dapat disusun, yang pada gilirannya dapat menyusun satu kelas dasar yang dapat disusun, dll. Kelas tidak perlu dapat dikomposiskan untuk menyusun kelas dasar yang dapat disusupi. Kelas hanya dapat menyusun dengan kelas yang dapat disusupi sebagai kelas dasar. Kelas yang dapat disusun tidak diperlukan untuk menyusun kelas lain yang dapat disusun (yaitu, mungkin akar hierarki). Grafik komposisi melingkar (seperti A menyusun B, yang menyusun A) tidak diizinkan.

Pada runtime, kelas pembuatan adalah agregasi objek WinRT—satu untuk setiap objek dalam rantai komposisi. Objek agregat ini mendelegasikan identitas dan masa pakai ke objek yang awalnya diaktifkan dalam rantai komposisi (disebut objek pengontrol). Setiap objek dalam rantai memegang penunjuk yang tidak dapat didelegasikan IInspectable ke kelas yang disusunnya untuk memanggil metode pada antarmuka kelas dasar yang disusun, termasuk metode pada antarmuka yang dilindungi. Setiap objek dalam rantai memiliki penunjuk ke kelas pengontrol untuk mendelegasikan masa pakai dan identitas serta untuk memanggil metode pada antarmuka yang dapat diganti. Detail tentang antarmuka yang dilindungi dan dapat diganti untuk diikuti.

Mari kita ambil contoh bahwa Tombol menyusun Kontrol, yang pada gilirannya menyusun UIElement. Dalam contoh tersebut, instans Tombol menggabungkan instans Kontrol , yang pada gilirannya menggabungkan instans UIElement . Ketiga objek memiliki referensi ke objek Tombol untuk mengontrol masa pakai dan identitas serta untuk mengkueri antarmuka yang dapat diganti. Setiap objek memiliki penunjuk IInspectable ke objek yang disusunnya (Tombol menahan penunjuk ke Kontrol; Kontrol menyimpan pointer ke UIElement) agar dapat memanggil metode pada antarmuka yang diterapkan pada kelas yang disusun, termasuk antarmuka yang dilindungi.

Kelas tidak boleh mengimplementasikan antarmuka apa pun yang ditentukan pada kelas yang dibuatnya, atau kelas apa pun dalam rantai komposisi, kecuali antarmuka ditandai sebagai dapat diganti di kelas yang dapat disusupi. Detail tentang antarmuka yang dapat diganti untuk diikuti.

Kelas yang dapat disusupi harus ditandai dengan satu atau beberapa ComposableAttributes. ComposableAttribute membawa referensi ke antarmuka pabrik komposisi—apakah metode pabrik pada antarmuka pabrik komposisi dapat digunakan untuk mengontrol aktivasi objek atau tidak—serta informasi versi. Detail tentang antarmuka pabrik komposisi dan penerapan versi yang harus diikuti. Kelas dapat ditandai dengan beberapa ComposableAttributes—satu untuk setiap antarmuka pabrik komposisi yang diterapkan oleh pabrik aktivasi kelas.

Proyeksi bahasa JavaScript tidak mendukung komposisi kelas. Dengan demikian, kelas yang dapat disusupi, dan kelas yang menyusun kelas yang dapat dibuat, harus ditandai dengan WebHostHiddenAttribute yang menunjukkan bahwa JavaScript tidak boleh mencoba memproyeksikan jenis ini.

Pihak ketiga hanya dapat menentukan kelas yang menyusun kelas lain yang dapat disusupi. Anda mungkin tidak mendefinisikan kelas root Anda sendiri yang dapat dikomposisikan.

Aktivasi yang dapat disusupi

Kelas yang dapat dikomposisi harus menentukan satu atau beberapa antarmuka pabrik komposisi, yang pada gilirannya mengimplementasikan satu atau beberapa metode pabrik komposisi. Antarmuka pabrik komposisi diimplementasikan pada pabrik aktivasi kelas. Detail tentang pabrik aktivasi yang harus diikuti.

Antarmuka pabrik komposisi digunakan untuk membuat instans kelas yang dapat dikomposisi. Antarmuka pabrik yang dapat dikomposisikan mendeklarasikan nol atau lebih metode pabrik yang dapat digunakan untuk mengaktifkan instans kelas untuk tujuan komposisi. Perhatikan bahwa legal untuk memiliki antarmuka pabrik yang dapat dikomposisikan dengan metode pabrik nol. Ini menyiratkan bahwa kelas dapat digunakan untuk komposisi, tetapi pihak ketiga mungkin tidak secara langsung menyusun kelas —metode untuk membuat instans hanya internal.

Kelas yang dapat disusun menyatakan apakah metode pabrik pada antarmuka pabrik komposisi tertentu dapat digunakan untuk mengaktifkan kelas secara langsung sebagai objek pengontrol atau tidak. Antarmuka pabrik yang dapat dikomposisikan yang ditandai sebagai publik dapat digunakan untuk langsung mengaktifkan kelas sebagai objek pengontrol, serta secara tidak langsung untuk mengaktifkan kelas sebagai objek yang dibuat. Antarmuka pabrik yang dapat dikomposisi yang ditandai dilindungi hanya dapat digunakan untuk mengaktifkan kelas secara tidak langsung sebagai objek yang dikomposisikan. Kelas yang dapat dikomposisi selalu dapat diaktifkan sebagai objek yang terdiri.

Antarmuka pabrik komposisi harus merupakan exclusiveto kelas runtime yang diimplementasikan olehnya.

Seperti metode pabrik aktivasi, metode pabrik komposisi harus mengembalikan instans kelas yang dapat dikomposisikan. Selain itu, metode pabrik komposisi memiliki dua parameter tambahan: parameter controlling IInspectable* [in], dan parameter IInspectable** [out] yang tidak mendelegasikan. Metode pabrik komposisi dapat secara opsional memiliki parameter tambahan in . Jika ditentukan, tambahan dalam parameter harus terjadi di awal tanda tangan metode, sebelum parameter yang diamanatkan tercantum sebelumnya. Metode pabrik komposisi mungkin tidak memiliki parameter tambahan out di luar IInspectable yang tidak dapat didelegasikan** dan parameter nilai yang dikembalikan.

Ketika kelas yang dapat dikomposisi diaktifkan untuk komposisi (misalnya, Kontrol atau UIElement saat instans Tombol diaktifkan), penunjuk ke objek yang mengontrol identitas dan masa pakai diteruskan melalui parameter IInspectable* [in] yang mengontrol. Metode pabrik yang dapat dikomposisi mengembalikan instans yang baru diaktifkan sebagai nilai pengembalian. Instans ini mendelegasikan semua fungsi manajemen identitas dan seumur hidup ke IInspectable pengontrol* yang disediakan. Selain itu, metode pabrik yang dapat dikomposisi mengembalikan penunjuk ke IInspectable yang tidak dapat didelegasikan* yang dapat digunakan kelas pembuatan untuk memanggil metode pada kelas yang disusun.

Ketika kelas komposable diaktifkan sebagai kelas pengontrol (misalnya, Tombol dalam contoh sebelumnya), metode pabrik komposable yang sama digunakan sebagai untuk aktivasi untuk komposisi. Saat mengaktifkan kelas komposable secara langsung, null diteruskan untuk parameter pengontrol *IInspectable* . Ini adalah indikator untuk kelas komposable yang sedang diaktifkan sebagai kelas pengontrol. Ketika kelas pengontrol membuat instans kelas yang dibuatnya, kelas tersebut meneruskan referensi ke dirinya sendiri sebagai parameter IInspectable* yang mengontrol. Metode pabrik yang dapat dikomposisi mengembalikan instans kelas pengontrol sebagai nilai yang dikembalikan. Parameter non-delegasi IInspectable** [out] diabaikan oleh kode klien saat mengaktifkan kelas yang dapat dikontrol yang dapat dikomposisikan.

Dibangun pada contoh Button ->Control ->UIElement sebelumnya, kelas tombol akan diaktifkan dengan memanggil salah satu metode pabrik komposisinya dan meneruskan null untuk parameter luar. Tombol pada gilirannya akan mengaktifkan instans Kontrol , meneruskan referensi ke dirinya sendiri sebagai parameter luar. Kontrol pada gilirannya akan mengaktifkan instans UIElement , meneruskan referensi luar yang diterimanya sebagai parameter luar. Metode pabrik UIElement akan kembali ke MengontrolUIElement yang baru dibuat dalam parameter instans, serta referensi ke IInspectable yang tidak mendelegasikan UIElement dalam parameter dalam. Metode pabrik Kontrol akan kembali ke TombolKontrol yang baru dibuat dalam parameter instans serta referensi ke Kontrol yang tidak mendelegasikan IInspectable dalam parameter dalam. Pabrik komposisi Tombol akan kembali ke kode panggilan Tombol yang baru dibuat dalam parameter instans, dan null untuk parameter dalam.

Dimungkinkan bagi kelas untuk kadang-kadang diaktifkan untuk komposisi, dan lain kali diaktifkan sebagai kelas pengontrol. Misalnya, jika RadioButton menyusun Tombol, maka Tombol akan diaktifkan untuk komposisi ketika RadioButton diaktifkan; tetapi diaktifkan sebagai kelas pengontrol ketika Tombol diaktifkan secara langsung. Dalam kedua kasus, kelas Kontrol yang dikomposisi Tombol akan diaktifkan untuk komposisi.

Antarmuka yang dilindungi

Kelas yang dapat disusun dapat menyatakan nol atau lebih antarmuka anggotanya untuk dilindungi. Kelas yang tidak dapat dikomposisi mungkin tidak menyatakan antarmuka anggota untuk dilindungi. Hanya kode di kelas yang menyusun kelas yang dapat disusun (secara langsung atau tidak langsung) yang dapat meminta dan menggunakan antarmuka yang dinyatakan sebagai kelas yang dapat dinyatakan sebagai dilindungi. Kode dari luar rantai komposisi mungkin tidak meminta, atau menggunakan, antarmuka yang dapat dinyatakan sebagai terlindungi.

Misalnya, jika UIElement mendeklarasikan antarmuka yang dilindungi IUIElementProtected, maka hanya kelas yang menyusun UIElement—termasuk komposisi langsung (Kontrol) dan tidak langsung (Tombol) —yang dapat meminta dan menggunakan antarmuka IUIElementProtected .

Antarmuka yang dapat diganti

Kelas yang dapat disusun dapat menyatakan nol atau lebih antarmuka anggotanya dapat diganti. Antarmuka yang dapat diganti hanya dapat dikueri, dan digunakan di dalam, rantai komposisi—mirip dengan aturan tentang mengakses antarmuka yang dilindungi yang dirinci sebelumnya. Namun, di mana antarmuka yang dilindungi hanya dapat diimplementasikan oleh kelas yang awalnya mendeklarasikannya, antarmuka yang dapat diganti dapat diimplementasikan kembali oleh kelas yang menyusun kelas yang mengimplementasikan antarmuka yang dapat diganti.

Pada runtime, kode kelas yang dapat dikomposisi yang memanfaatkan antarmuka yang dapat diganti harus QueryInterface untuk antarmuka melalui penunjuk IInspectable* pengontrol yang digunakan untuk delegasi identitas dan seumur hidup. Pointer ini mengembalikan implementasi antarmuka yang dapat diganti paling awal dalam rantai komposisi (yaitu, paling dekat dengan instans kelas pengontrol). Kelas yang ingin mengakses antarmuka yang dapat diambil alih dari kelas yang dibuatnya dapat melakukannya melalui referensi yang tidak mendelegasikan yang disimpan kelas kompostik ke kelas yang disusungnya.

Mari kita ambil contoh bahwa UIElement mendeklarasikan antarmuka yang dapat diganti IUIElementOverridable. Dalam hal ini, kelas yang berasal dari UIElement, termasuk turunan langsung (Kontrol) dan tidak langsung (Tombol), akan diizinkan untuk mengimplementasikannya. Jika kode dalam UIElement diperlukan untuk mengakses fungsionalitas di IUIElementOverridable, maka UIElement akan meminta IInspectable pengontrol untuk mendapatkan implementasi paling awal dalam rantai komposisi. Jika Kontrol dan Tombol keduanya mengimplementasikan IUIElementOverridable, maka implementasi Tombol akan dikembalikan ketika pengontrol IInspectable dikueri. Jika Button ingin mengakses fungsionalitas kelas yang dibuat, Tombol dapat menggunakan IInspectable yang tidak mendelegasikan yang dikembalikan dari metode pabrik komposisi untuk mengkueri kelas dasar untuk antarmuka tersebut.

Pabrik aktivasi

Kelas runtime secara opsional memiliki pabrik aktivasi. Kelas runtime harus memiliki pabrik aktivasi jika kelas dapat diaktifkan, dapat dikomposisikan, atau memiliki antarmuka statis. Pabrik aktivasi untuk kelas dapat diambil dari sistem saat runtime melalui fungsi RoGetActivationFactory Win32.

Pabrik Aktivasi harus mengimplementasikan antarmuka IActivationFactory . Namun, hanya kelas yang mendukung aktivasi langsung yang menyediakan implementasi metode tunggal IActivationFactoryActivateInstance. Kelas yang tidak mendukung aktivasi langsung harus mengembalikan E_NOTIMPL dari IActivationFactory.ActivateInstance.

Pabrik aktivasi harus mengimplementasikan semua antarmuka pabrik aktivasi, antarmuka pabrik komposisi, dan antarmuka statis yang ditentukan pada kelas runtime.

Tidak ada jaminan bahwa proyeksi bahasa mempertahankan satu instans pabrik aktivasi selama masa pakai pabrik. Penulis kelas WinRT yang perlu menyimpan informasi berumur panjang untuk akses anggota statis perlu menyimpannya di suatu tempat di luar pabrik aktivasi.

Proyeksi berbasis kelas

Meskipun WinRT terutama merupakan model pemrograman berbasis antarmuka di bawah tenda, kelas runtime menyediakan model pemrograman berbasis kelas yang lebih selaras dengan bahasa pemrograman modern, mainstream, berorientasi objek (OO). Proyeksi bahasa diharapkan untuk memproyeksikan kelas runtime sebagai entitas tunggal, daripada sebagai kantong antarmuka yang harus ditangani pengembang secara terpisah.

Untuk mencapai model berbasis kelas ini, proyeksi bahasa diharapkan untuk memproyeksikan anggota jenis dari antarmuka anggota kelas sebagai anggota kelas langsung. Proyeksi bahasa diharapkan untuk memproyeksikan anggota jenis dari antarmuka statis kelas sebagai anggota kelas statis. Akhirnya, proyeksi bahasa diharapkan untuk memproyeksikan metode aktivasi (aktivasi langsung serta antarmuka dari pabrik dan antarmuka pabrik yang dapat disusun) sebagai konstruktor kelas.

Untuk membantu dalam proyeksi berbasis kelas ini, metadata untuk kelas runtime menentukan anggota kelas untuk semua metode, properti, dan peristiwa dari setiap antarmuka yang mereka terapkan. Setiap anggota kelas secara eksplisit diikat kembali ke anggota antarmuka tempat awalnya ditentukan. Ini memungkinkan proyeksi bahasa untuk mengekspos kelas sebagai entitas tunggal, menangani semua kueri antarmuka dan penghitungan referensi di bawah sampul atas nama pengembang.

Secara default, setiap anggota antarmuka yang diimplementasikan diproyeksikan sebagai anggota kelas. Namun, karena kelas runtime dapat mengimplementasikan beberapa antarmuka dan versi independen dari waktu ke waktu (detail penerapan versi untuk diikuti), dimungkinkan untuk ada tabrakan nama untuk anggota yang ditentukan pada antarmuka yang berbeda yang diterapkan oleh satu kelas runtime.

Ketika tabrakan terjadi, proyeksi anggota kelas default tidak mungkin. Jika tabrakan terjadi di seluruh antarmuka yang ditambahkan dalam versi terpisah, anggota yang bertabrakan dari versi paling awal diproyeksikan sebagai anggota kelas. Saat tabrakan terjadi di seluruh antarmuka yang ditambahkan dalam versi yang sama, tidak ada anggota yang bertabrakan yang diproyeksikan sebagai anggota kelas. Perhatikan, metode dengan nama bertabrakan diizinkan selama semua versi memiliki aritas yang berbeda seperti yang dijelaskan dalam Metode kelebihan beban.

Anggota antarmuka yang tidak diproyeksikan sebagai anggota kelas harus tersedia untuk pengembang. Biasanya, ini dilakukan oleh operator casting atau pencarian dinamis, memungkinkan pengembang untuk menentukan antarmuka dan metode tertentu yang ingin mereka panggil.

Untuk mengatasi tabrakan nama metode, kelas runtime dapat menentukan nama alternatif untuk metode pada anggota dan antarmuka statis yang mereka terapkan. Nama alternatif ini digunakan oleh proyeksi bahasa untuk menyediakan akses yang tidak ambigu ke nama metode yang bertabrakan dari instans kelas. Meskipun kelas runtime dapat memberikan nama metode alternatif, tanda tangan metode, parameter, dan atribut apa pun yang dilampirkan ke metode atau atributnya masih harus sama persis dengan definisi antarmuka asli.

Karena aktivasi langsung, metode pabrik, dan metode pabrik komposisi diproyeksikan sebagai konstruktor kelas, semuanya diproyeksikan pada kelas runtime seolah-olah mereka memiliki nama yang sama. Semua metode di semua antarmuka pabrik harus memiliki tanda tangan unik, harus mendukung kelebihan beban berbasis aritas atas kelebihan beban berbasis jenis, dan harus menggunakan DefaultOverloadAttribute untuk membedakan metode pabrik dari aritas yang sama.

Penerapan versi kelas

Kelas runtime secara aditif dapat diversi. Versi berikutnya dari kelas runtime tertentu dapat menentukan antarmuka tambahan dari semua jenis, dengan detail lebih lanjut tentang jenis antarmuka individual di bawah ini. Antarmuka yang sudah ada sebelumnya yang ditentukan oleh kelas mungkin tidak pernah dihapus atau diubah tanpa melanggar kompatibilitas mundur.

Penerapan versi antarmuka anggota

Antarmuka anggota pada kelas runtime secara aditif dapat diberi versi. Versi berikutnya dari kelas runtime tertentu dapat mengimplementasikan antarmuka anggota tambahan, bahkan jika kelas belum pernah menerapkan antarmuka anggota sebelumnya. Versi berikutnya dari kelas runtime yang dapat dikomposisikan tertentu dapat mengimplementasikan antarmuka tambahan yang dilindungi dan dapat diganti.

Antarmuka yang diimplementasikan oleh kelas runtime secara opsional membawa VersionAttribute untuk membedakan kapan antarmuka tertentu ditambahkan ke jenis kelas runtime. Nilai implementasi antarmuka tanpa VersionAttribute dianggap memiliki nilai versi yang sama dengan jenis kelas runtime penutup.

Penerapan versi antarmuka statis

Antarmuka statis pada kelas runtime secara aditif dapat diversikan. Versi berikutnya dari kelas runtime tertentu dapat mengimplementasikan antarmuka statis tambahan, bahkan jika kelas belum pernah menerapkan antarmuka statis sebelumnya.

StaticAttribute menyertakan parameter UInt32 untuk nomor versi, yang menentukan versi Windows yang menambahkan dukungan aktivasi tersebut.

Penerapan versi aktivasi

Dukungan aktivasi untuk kelas runtime secara aditif dapat versi. Versi berikutnya dari kelas runtime tertentu dapat menerapkan mekanisme aktivasi tambahan, bahkan jika kelas tidak pernah menerapkan mekanisme aktivasi. Perhatikan, kelas yang dapat dikomposiskan tidak dapat diaktifkan, dan dengan demikian mungkin tidak menambahkan dukungan aktivasi.

Perhatikan bahwa kelas yang mendukung aktivasi langsung hanya dapat menambahkan antarmuka aktivasi pabrik baru. Kelas yang sebelumnya hanya mendukung aktivasi pabrik dapat menambahkan dukungan aktivasi langsung serta antarmuka aktivasi pabrik baru.

ActivatableAttribute menyertakan parameter UInt32 untuk nomor versi. Nomor versi untuk ActivatableAttribute menentukan versi Windows yang menambahkan dukungan aktivasi tersebut.

Penerapan versi komposisi

Dukungan komposisi untuk kelas runtime secara aditif dapat diversi. Versi berikutnya dari kelas runtime yang dapat dikomposisikan tertentu dapat menerapkan mekanisme komposisi tambahan, asalkan kelas didefinisikan sebagai dapat dikomposisikan ketika dibuat. Kelas yang dapat disusupi mungkin tidak menambahkan dukungan aktivasi.

ComposableAttribute menyertakan parameter UInt32 untuk nomor versi. Nomor versi untuk ComposableAttribute menentukan versi Windows yang menambahkan dukungan komposisi tersebut.

Mengelola atribut kustom

WinRT mendukung definisi atribut metadata kustom. Semua konstruksi dalam sistem jenis WinRT dapat membawa atribut metadata kustom. Ini termasuk semua jenis bernama (enum, struktur, delegasi, antarmuka, kelas, dll.) serta elemen individual yang terkandung dalam konstruksi jenis (seperti metode, parameter, dll.).

Atribut kustom diberi nama seperti jenis WinRT lainnya. Namun, mereka tidak dapat diaktifkan. Mereka murni konstruksi data.

Atribut kustom menentukan skema data dari parameter posisi atau bidang bernama. Atribut kustom tidak boleh menggunakan parameter posisi dan bidang bernama—atribut harus memilih satu atau yang lain. Jenis parameter dan bidang atribut kustom terbatas pada jenis dasar WinRT, enum, dan referensi ke jenis WinRT lainnya. Tidak ada parameter atau jenis bidang lain yang diizinkan.

Atribut kustom yang menggunakan parameter posisi harus menentukan satu atau beberapa set parameter posisi yang valid. Setiap set harus menentukan parameter posisi nol atau lebih. Instans atribut kustom harus menentukan satu set parameter posisi serta data untuk setiap parameter posisi dalam set yang dipilih.

Atribut kustom yang menggunakan bidang bernama menentukan bidang nol dengan nama dan jenis. Instans atribut kustom harus menentukan pasangan nama/nilai untuk bidang yang ingin ditentukannya. Instans dapat menentukan nilai untuk semua, beberapa, atau tidak ada pasangan nama/nilai.

Atribut valid untuk tidak memiliki parameter posisi atau bidang bernama.

Atribut kustom harus memiliki visibilitas publik.

Atribut dapat menentukan jenis konstruksi jenis WinRT yang mungkin dikaitkan dengannya melalui AttributeUsageAttribute.

Pihak ketiga tidak dapat menentukan atribut kustom. Hanya atribut kustom yang ditentukan oleh sistem yang didukung.