# 394 का संभावित डुप्लिकेट

Https://github.com/Microsoft/TypeScript/issues/1003#issuecomment -61171048 भी देखें

@NoelAbrahams मैं वास्तव में यह नहीं सोचता कि यह # 394 का डुप्लिकेट है, इसके विपरीत दोनों विशेषताएं बहुत पूरक हैं जैसे:

 class Model<T> {
    get(prop: memberof T): T[prop];
    set(prop:  memberof T, value: T[prop]): void;
  }

आदर्श होगा

@fdecampredon

contact.set(Math.random() >= 0.5 ? 'age' : 'name', 13)

इस मामले में क्या करना है?

यह मेरे मामले के अंतिम पैराग्राफ से कमोबेश एक ही मामला है। जैसे मैंने कहा कि हमारे पास कई विकल्प हैं, हम एक त्रुटि की रिपोर्ट कर सकते हैं, या any T[prop] लिए रिपोर्ट कर सकते हैं, मुझे लगता है कि दूसरा समाधान अधिक तार्किक है

शानदार प्रस्ताव। सहमत, यह उपयोगी सुविधा होगी।

@fdecampredon , मेरा मानना ​​है कि यह एक डुप्लिकेट है। दान से टिप्पणी और संबंधित प्रतिक्रिया देखें जिसमें membertypeof लिए सुझाव है।

IMO यह सब एक संकीर्ण उपयोग के मामले के लिए एक नया वाक्यविन्यास है।

@NoelAbrahams यह समान नहीं है।

• memberof T रिटर्न प्रकार जो केवल T उदाहरण की वैध संपत्ति के नाम के साथ एक स्ट्रिंग हो सकता है।
• T[prop] T की संपत्ति का प्रकार स्ट्रिंग के साथ नामित किया गया है जिसे prop तर्क / चर द्वारा दर्शाया गया है।

एक brifge लिए नहीं है memberof के प्रकार prop होना चाहिए पैरामीटर memberof T ।

वास्तव में, मैं टाइप मेटाडेटा के आधार पर प्रकार के अनुमान के लिए अधिक समृद्ध प्रणाली रखना चाहूंगा। लेकिन ऐसा ऑपरेटर एक अच्छी शुरुआत के साथ-साथ memberof ।

यह दिलचस्प और वांछनीय है। टाइपस्क्रिप्ट अभी तक स्ट्रिंग-हैवी फ्रेमवर्क के साथ अच्छा नहीं करते हैं और यह स्पष्ट रूप से बहुत मदद करेगा।

टाइपस्क्रिप्ट स्ट्रिंग-हैवी फ्रेमवर्क के साथ अच्छा नहीं करता है

सच। फिर भी यह तथ्य नहीं बदलता है कि यह एक डुप्लिकेट सुझाव है।

अभी तक और यह स्पष्ट रूप से बहुत कुछ मदद करेगा [टाइपिंग-हैवी फ्रेमवर्क टाइप करने के लिए]

उस पर यकीन नहीं है। उपर्युक्त उल्लिखित छद्म-वस्तु पैटर्न के बजाय टुकड़ा-टुकड़ा और कुछ हद तक विशिष्ट लगता है। मैं # 1003 की तर्ज पर मैजिक स्ट्रिंग समस्या के लिए एक अधिक समग्र दृष्टिकोण पसंद करूंगा।

1003 सुझाव देता है कि any एक गेट्टर के रिटर्न प्रकार के रूप में। यह प्रस्ताव शीर्ष पर जोड़ता है कि मूल्य प्रकार को भी देखने का एक तरीका जोड़कर - मिश्रण इस तरह से होगा:

declare module ImmutableJS {
  class Map<T> {
    get(prop: memberof T): T[prop];
    set(prop: memberof T, value: T[prop]): Map<T>;
  }
}

@spion , क्या आपका मतलब # 394 है? यदि आप आगे पढ़ने के लिए थे तो आप निम्नलिखित देखेंगे:

मैंने वापसी के प्रकार के बारे में सोचा लेकिन इसे छोड़ दिया और समग्र सुझाव को बहुत बड़ा नहीं बनाया।

यह मेरा प्रारंभिक विचार था लेकिन इसमें समस्याएं हैं। यदि memberof T कई तर्क हैं, तो कौन सा membertypeof T संदर्भित करता है?

get(property: memberof T): membertypeof T;
set(property: memberof T, value: membertypeof T);

यह हल करता है "मैं किस तर्क का उल्लेख कर रहा हूं" समस्या, लेकिन membertypeof नाम गलत लगता है और ऑपरेटर के किसी प्रशंसक को संपत्ति के नाम को लक्षित नहीं करता है।

get(property: memberof T): membertypeof property;
set(property: memberof T, value: membertypeof property);

मुझे लगता है कि यह बेहतर काम करता है।

get(property: memberof T is A): A;
set(property: memberof T is A, value: A)

दुर्भाग्य से यकीन नहीं है कि मेरे पास एक महान समाधान है, हालांकि मेरा मानना ​​है कि अंतिम सुझाव में सभ्य क्षमता है।

OK @NoelAbrahams # 394 में एक टिप्पणी थी जो कमोबेश उसी चीज़ का वर्णन करने की कोशिश कर रही थी जो यह थी।
अब मुझे लगता है कि T[prop] शायद इस टिप्पणी के विभिन्न प्रस्तावों की तुलना में थोड़ा अधिक सुरुचिपूर्ण है, और इस मुद्दे में प्रस्ताव प्रतिबिंब में शायद थोड़ा आगे जाता है।
इस कारण से मुझे नहीं लगता कि इसे डुप्लिकेट के रूप में बंद किया जाना चाहिए।
लेकिन मुझे लगता है कि मैं पक्षपाती हूं क्योंकि मैं इस मुद्दे को लिखने वाला हूं;)।

@fdecampredon , अधिक

@ नोएल एब्राहाम्स उफ़, मुझे वह हिस्सा याद आ गया। यकीन है, वे बहुत अधिक समतुल्य हैं (यह एक और सामान्य पैरामीटर को पेश नहीं करता है, जो समस्या हो सकती है या नहीं भी हो सकती है)

फ्लो पर एक नज़र डालने के बाद, मुझे लगता है कि यह थोड़ा मजबूत प्रकार की प्रणाली और विशेष प्रकार के साथ एक तदर्थ प्रकार संकीर्णता के साथ अधिक सुरुचिपूर्ण होगा।

उदाहरण के लिए हम get(prop: string): Contact[prop] साथ क्या मतलब है, संभव ओवरलोडिंग की एक श्रृंखला है:

interface Map {
  get(prop : string) : Contact[prop];
}

// is morally equivalent to 

interface Map {
  get(prop : "name") : string;
  get(prop : "age") : number;
}

& प्रकार ऑपरेटर (चौराहे प्रकार) के अस्तित्व को मानते हुए, यह इसके बराबर है

interface Map {
   get : (prop : "name") => string & (prop : "age") => number;
}

अब जब हमने अपने गैर-सामान्य मामले को केवल विशेष प्रकार के उपचार (कोई [prop] ) के साथ केवल अभिव्यक्ति में अनुवाद किया है, तो हम मापदंडों के प्रश्न को संबोधित कर सकते हैं।

यह विचार कुछ हद तक एक प्रकार के पैरामीटर से उत्पन्न होता है। हम कुछ विशेष डमी जेनेरिक प्रकारों को $MapProperties , $Name और $Value परिभाषित कर सकते हैं, जबकि केवल टाइप परीक्षक को इंगित करते हुए केवल टाइप एक्सप्रेशन (कोई विशेष सिंटैक्स) की अवधि में हमारे उत्पन्न प्रकार को व्यक्त करने के लिए नहीं। कि कुछ किया जाना चाहिए।

class Map<T> {
   get : $MapProperties<T, (prop : $Name) => $Value>
   set : $MapProperties<T, (prop : $Name, val : $Value) => void>
}

यह जटिल लग सकता है और टेम्प्लेटिंग या गरीब आदमी के आश्रित प्रकार के पास हो सकता है, लेकिन जब कोई व्यक्ति मूल्यों पर निर्भर होना चाहता है, तो इसे टाला नहीं जा सकता है।

एक अन्य क्षेत्र जहां यह उपयोगी होगा, टाइप की गई वस्तु के गुणों पर निर्भर करता है:

interface Env {
 // pretend this is an actually interesting type
};

var actions = {
  action1: function (env: Env, x: number) : void {},
  action2: function (env: Env, y: string) : void {}
};

// actions has type { action1: (Env, number) => void; action2: (Env, string) => void; }
var env : Env = {};
var boundActions = {};
for (var action in actions) {
  boundActions[action] = actions[action].bind(null, env);
}

// boundActions should have type { action1: (number) => void; action2: (string) => void; }

इन प्रकारों को अनुमान लगाने के लिए कम से कम सैद्धांतिक रूप से संभव होना चाहिए ( for लूप के परिणाम का अनुमान लगाने के लिए पर्याप्त प्रकार की जानकारी है), लेकिन यह भी संभवतः काफी खिंचाव है।

ध्यान दें कि प्रतिक्रिया के अगले संस्करण से उस दृष्टिकोण का बहुत फायदा होगा, https://github.com/facebook/react/issues/3398 देखें

जैसे https://github.com/Microsoft/TypeScript/issues/1295#issuecomment -64944856, जब स्ट्रिंग को एक स्ट्रिंग शाब्दिक के अलावा अन्य अभिव्यक्ति द्वारा आपूर्ति की जाती है, तो यह सुविधा हॉल्टिंग समस्या के कारण जल्दी से टूट जाती है। हालांकि, क्या ईएस 6 प्रतीक समस्या (# 2012) से सीखने का उपयोग करके इसका एक मूल संस्करण अभी भी लागू किया जा सकता है?

मंजूर की।

हम सिंटैक्स के लिए एक अनुभव प्राप्त करने के लिए प्रायोगिक शाखा में इसे आज़माना चाहेंगे।

बस यह सोचकर कि प्रस्ताव का कौन सा संस्करण लागू होने जा रहा है? Ie कॉल स्थल पर T[prop] मूल्यांकन किया जा रहा है और उत्सुकता से एक ठोस प्रकार के साथ बदल दिया गया है या क्या यह प्रकार का नया रूप बनने जा रहा है?

मुझे लगता है कि हमें # 3779 में परिभाषित एक अधिक सामान्य और कम क्रिया वाक्यविन्यास पर भरोसा करना चाहिए।

interface Map<T> {
  get<A>(prop: $Member<T,A>): A;
  set<A>(prop: $Member<T,A>, value: A): Map<T>;
}

या यह A के प्रकार का अनुमान लगाने के लिए नहीं है?

केवल यह कहना चाहता हूं कि मैंने इम्यूटेबलजेएस के साथ टीएस एकीकरण को आसान बनाने के लिए थोड़ा कोडेन टूल बनाया, जबकि हम सामान्य समाधान की प्रतीक्षा कर रहे हैं: https://www.npmjs.com/package/tsimmutable। यह काफी सरल है, लेकिन मुझे लगता है कि यह ज्यादातर उपयोग के मामलों के लिए काम करेगा। शायद यह किसी की मदद करेगा।

इसके अलावा, मैं यह नोट करना चाहता हूं, कि सदस्य प्रकार के साथ समाधान ImmutableJS के साथ काम नहीं कर सकता है:

interface Profile {
  firstName: string 
}

interface User {
  profile: Profile  
}

let a: Map<User> = fromJS(/* ... */);
a.get('profile') // Type will be Profile, but the real type is Map<Profile>!

@ s-panferov कुछ इस तरह से काम कर सकता है:

interface ImmutableMap<T> {
    get<A extends boolean | number | string>(key : string) : A;
    get<A extends {}>(key : string) : ImmutableMap<A>;
    get<E, A extends Array<any>>(key : string) : ImmutableList<E>;
}

interface Profile {

}

interface User {
    name : string;
    profile : Profile;
}

var map : ImmutableMap<User>;

var name = map.get<string>('name'); // string
var profile = map.get<Profile>('profile'); // ImmutableMap<Profile>

यह DOM नोड्स या दिनांक ऑब्जेक्ट्स को बाहर नहीं करेगा, लेकिन इसे उन्हें अपरिवर्तनीय संरचनाओं में उपयोग करने की अनुमति नहीं दी जानी चाहिए। https://github.com/facebook/immutable-js/wiki/Converting-from-JS-objects

धीरे-धीरे सबसे अच्छे तरीके से काम करना

मुझे लगता है कि सबसे पहले वर्तमान में उपलब्ध वर्कअराउंड के साथ शुरुआत करना उपयोगी है, और फिर धीरे-धीरे इसे वहां से काम करना है।

मान लें कि हमें एक ऐसे फ़ंक्शन की आवश्यकता है जो किसी भी गैर-आदिम ऑब्जेक्ट के लिए एक संपत्ति का मूल्य लौटाता है:

function getProperty<T extends object>(container: T; propertyName: string) {
    return container[propertyName];
}

अब हम चाहते हैं कि टारगेट प्रॉपर्टी के प्रकार का रिटर्न वैल्यू हो, इसलिए इसके प्रकार के लिए एक और जेनेरिक टाइप पैरामीटर जोड़ा जा सकता है:

function getProperty<T extends object, P>(container: T; propertyName: string) {
    return <P> container[propertyName];
}

तो एक वर्ग के साथ एक उपयोग मामला ऐसा दिखेगा:

class C {
    member: number;
    static member: string;
}

let instance = new C();
let result = getProperty<C, typeof instance.member>(instance, "member");

और result सही प्रकार से number प्राप्त करेंगे।

हालाँकि, कॉल में 'सदस्य' का डुप्लिकेट संदर्भ प्रतीत होता है: एक प्रकार के पैरामीटर में है, और दूसरा एक _literal_ स्ट्रिंग है जो हमेशा लक्ष्य संपत्ति के नाम का स्ट्रिंग प्रतिनिधित्व प्राप्त करेगा। इस प्रस्ताव का विचार यह है कि इन दोनों को एकल प्रकार के पैरामीटर के लिए एकीकृत किया जा सकता है जो केवल स्ट्रिंग प्रतिनिधित्व प्राप्त करेगा।

इसलिए यहां यह देखने की जरूरत है कि स्ट्रिंग एक _generic पैरामीटर_ के रूप में भी कार्य करेगी, और इसे काम करने के लिए शाब्दिक के रूप में पारित किया जाएगा (अन्य मामले चुपचाप इसके मूल्य की अनदेखी कर सकते हैं जब तक कि रनटाइम प्रतिबिंब का कोई रूप उपलब्ध न हो)। तो शब्दार्थ को स्पष्ट करने के लिए, सामान्य पैरामीटर और स्ट्रिंग के बीच संबंध को दर्शाने के लिए कुछ तरीका होना चाहिए:

function getProperty<T extends object, PName: string = propertyName>(container: T; propertyName: string) {
    return <T[PName]> container[propertyName];
}

और अब कॉल की तरह दिखेगा:

let instance = new C();
let result = getProperty<C>(instance, "member");

जो आंतरिक रूप से हल करेगा:

let result = getProperty<C, "member">(instance, "member");

हालाँकि, C में member नामक एक उदाहरण और स्थिर संपत्ति होती है, उच्च-प्रकार की सामान्य अभिव्यक्ति T[PName] अस्पष्ट है। चूँकि यहाँ इरादा अधिकतर उदाहरणों के गुणों पर लागू करने का है, typeon प्रस्तावित T[PName] रूप में शब्दार्थ में सुधार कर सकता है, जिसका प्रतिनिधित्व कुछ लोग करते हैं। _value reference_, जरूरी नहीं कि एक प्रकार:

function getProperty<T extends object, PName: string = propertyName>(container: T; propertyName: string) {
    return <typeon T[PName]> container[propertyName];
}

(यह तब भी काम करेगा जब T एक संगत इंटरफ़ेस प्रकार हो, जैसा कि typeon समर्थन करता है)

स्थैतिक संपत्ति प्राप्त करने के लिए, फ़ंक्शन को स्वयं निर्माणकर्ता के साथ बुलाया जाएगा और निर्माणकर्ता को typeof C रूप में पारित किया जाना चाहिए:

let result = getProperty<typeof C>(C, "member"); // Note it is called with the constructor object

(आंतरिक रूप से typeon (typeof C) typeof C हल होता है इसलिए यह काम करेगा)
result अब सही प्रकार से string ।

अतिरिक्त प्रकार के संपत्ति पहचानकर्ताओं का समर्थन करने के लिए, इसे इस प्रकार लिखा जा सकता है:

type PropertyIdentifier = string|number|Symbol;

function getProperty<T extends object, PName: PropertyIdentifier = propertyName>(container: T; propertyName: PropertyIdentifier) {
    return <typeon T[PName]> container[propertyName];
}

तो कई अलग-अलग विशेषताएं हैं जिन्हें इसका समर्थन करने की आवश्यकता है:

• शाब्दिक मूल्यों को सामान्य मापदंडों के रूप में पारित करने की अनुमति दें।
• उन शाब्दिकों को फ़ंक्शन तर्कों का मान प्राप्त करने दें।
• उच्च प्रकार की जेनरिक के एक फार्म की अनुमति दें।
• _Generic_ प्रकार पर शाब्दिक जेनेरिक पैरामीटर के माध्यम से एक संपत्ति प्रकार को संदर्भित करने की अनुमति दें।

समस्या पर पुनर्विचार करना

अब हम मूल समाधान पर वापस आते हैं:

function getProperty<T extends object, P>(container: T; propertyName: string) {
    return <P> container[propertyName];
}

इस वर्कअराउंड के बारे में एक फायदा यह है कि इसे अधिक जटिल पथ नामों का समर्थन करने के लिए आसानी से बढ़ाया जा सकता है, न केवल प्रत्यक्ष गुण, बल्कि नेस्टेड वस्तुओं के गुण:

function getPath<T extends object, P>(container: T; path: string) {
    ... more complex code here ...

    return <P> resultValue;
}

और अब:

class C {
    a: {
        b: {
            c: string[];
        }
    }
}
let instance = new C();
let result = getPath<C, typeof instance.a.b.c>(instance, "a.b.c");

result सही ढंग से string[] यहाँ मिलेगा।

सवाल यह है कि क्या नेस्टेड रास्तों का भी समर्थन किया जाना चाहिए? क्या वास्तव में यह सुविधा उपयोगी होगी यदि उन्हें टाइप करते समय कोई ऑटो-पूर्ति उपलब्ध न हो?

इससे पता चलता है कि एक अलग समाधान संभव हो सकता है, जो दूसरी दिशा में काम करेगा। मूल वर्कअराउंड पर वापस:

function getProperty<T extends object, P>(container: T; propertyName: string) {
    return <P> container[propertyName];
}

दूसरी दिशा से इसे देखते हुए, प्रकार के संदर्भ को स्वयं लेना और इसे एक स्ट्रिंग में बदलना संभव है:

function getProperty<T extends object, P>(container: T; propertyName: string = @typeReferencePathOf(P)) {
    return <P> container[propertyName];
}

@typeReferencePathOf अवधारणा में nameOf लेकिन सामान्य मापदंडों पर लागू होता है। यह प्राप्त प्रकार के संदर्भ typeof instance.member (या वैकल्पिक रूप से typeon C.member ) ले जाएगा, संपत्ति पथ member निकालें, और इसे संकलित स्ट्रिंग "member" संकलन में परिवर्तित करें समय। एक कम विशेष पूरक @typeReferenceOf पूरी स्ट्रिंग "typeof instance.member" समाधान करेगा।

तो अब:

getProperty<C, typeof instance.subObject>(instance);

इसका समाधान करेंगे:

getProperty<C, typeof instance.subObject>(instance, "subObject");

और getPath लिए समान कार्यान्वयन:

getPath<C, typeof instance.a.b.c>(instance);

इसका समाधान करेंगे:

getPath<C, typeof instance.a.b.c>(instance, "a.b.c");

चूँकि @typeReferencePathOf(P) केवल एक डिफ़ॉल्ट मान के रूप में सेट किया गया है। यदि आवश्यक हो तो तर्क को मैन्युअल रूप से कहा जा सकता है:

getPath<C, SomeTypeWhichIsNotAPath>(instance, "member.someSubMember.AnotherSubmember.data");

यदि दूसरे प्रकार के पैरामीटर को @typeReferencePathOf() प्रदान नहीं किया जाएगा undefined या वैकल्पिक रूप से खाली स्ट्रिंग "" को हल कर सकता है। यदि एक प्रकार प्रदान किया गया था, लेकिन आंतरिक मार्ग नहीं था, तो यह "" समाधान करेगा।

इस दृष्टिकोण के लाभ:

• उच्च-प्रकार की जेनरिक की आवश्यकता नहीं है।
• सामान्य पैरामीटर के रूप में शाब्दिक अनुमति देने की आवश्यकता नहीं है।
• किसी भी तरह से जेनेरिक का विस्तार करने की आवश्यकता नहीं है।
• typeof अभिव्यक्ति टाइप करते समय स्वतः पूर्णता की अनुमति देता है और संकलन-समय पर एक स्ट्रिंग प्रतिनिधित्व से इसे बदलने की आवश्यकता के बजाय इसे सत्यापित करने के लिए मौजूदा जाँच प्रकार का उपयोग करता है।
• जेनेरिक कक्षाओं में भी इस्तेमाल किया जा सकता है।
• typeon आवश्यकता नहीं है (लेकिन यह समर्थन कर सकता है)।
• अन्य परिदृश्यों में लागू किया जा सकता है।

+1

अच्छा लगा! मैंने पहले से ही एक ही समस्या को दूर करने के लिए एक बड़ा प्रस्ताव लिखना शुरू कर दिया है, लेकिन इस चर्चा को पाया, तो आइए यहां चर्चा करते हैं।

यहाँ मेरे गैर प्रस्तुत मुद्दे से एक उद्धरण है:

प्रश्न : .d.ts में निम्नलिखित फ़ंक्शन को कैसे घोषित किया जाना चाहिए, जहां इसका उपयोग किया जाना है?

function mapValues(obj, fn) {
      return Object.keys(obj)
          .map(key => ({key, value: fn(obj[key], key)}))
          .reduce((res, {key, value}) => (res[key] = value, res), {})
}

यह फ़ंक्शन (थोड़े बदलाव के साथ) लगभग हर सामान्य "बर्तनों" पुस्तकालय में पाया जा सकता है।

जंगली में mapValues दो अलग-अलग उपयोग के मामले हैं:

ए। _Object-as-a -_ -_ _ _ जहां संपत्ति के नाम गतिशील हैं, मूल्यों में एक ही प्रकार है, और फ़ंक्शन सामान्य स्थिति में है मोनोमोर्फिक (इस प्रकार के बारे में पता)

var obj = {'a': 1, 'b': 2, 'c': 3};
var res = mapValues(x, val => val * 5); // {a: 5, b: 10, c: 15}
console.log(res['a']) // 5

बी _Object-as-a-_ -Record _ जहां प्रत्येक संपत्ति का अपना प्रकार है, जबकि फ़ंक्शन पैरामीट्रिक पॉलीमॉर्फिक है (कार्यान्वयन द्वारा)

var obj = {a: 123, b: "Hello", c: true};
var res = mapValues(p, val => [val]); // {a: [123], b: ["Hello"], c: [true]}
console.log(res.a[0].toFixed(2)) // "123.00"

वर्तमान टाइपस्क्रिप्ट के साथ mapValues लिए सबसे अच्छा उपलब्ध इंस्ट्रूमेंटेशन है:

declare function mapValues<T1, T2>(
    obj: {[key: string]: T1},
    fn: (arg: T1, key: string) => T2
): {[key: string]: T2};

यह देखना मुश्किल नहीं है कि यह हस्ताक्षर पूरी तरह से _Object-as-a -_ -_ _ _ _ इंस्पेक्शन का कुछ आश्चर्यजनक ¹ परिणाम उत्पन्न होता है, जहां _Object-as-a-_ _Record _ इरादा था।

प्रकार {p1: T1, p2: T2, ...pn: Tn} {[key: string]: T1 | T2 | ... | Tn } सभी प्रकारों को स्वीकार करते हुए और रिकॉर्ड की संरचना के बारे में सभी जानकारी को प्रभावी ढंग से खारिज कर दिया जाएगा:

• सही और अपेक्षित ² ठीक होने के लिए console.log(res.a[0].toFixed(2)) संकलक द्वारा अस्वीकार कर दिया जाएगा;
• स्वीकृत console.log((<number>res['a'][0]).toFixed(2)) में दो अनियंत्रित और त्रुटि-प्रवण स्थान हैं: टाइप-कास्ट और मनमाना संपत्ति नाम।

^{1, 2} - प्रोग्रामर के लिए जो ES से TS के लिए माइग्रेट करता है

इस समस्या को हल करने के लिए संभावित कदम (और दूसरों को भी हल करें)

1. स्ट्रिंग शाब्दिक प्रकारों की मदद से वैरिकाड रिकॉर्ड का परिचय

type Numbers<p extends string> =  { ...p: number };
type NumbersOpt<p extends string> = {...p?: number };
type ABC = "a" | "b" | "c";
type abc = Numbers<ABC> // abc =  {a: number, b: number, c: number} 
type abcOpt = NumbersOpt<ABC> // abcOpt =  {a?: number, b?:number, c?: number}

function toFixedAll<p extends string>(obj: {...p: number}, precision):{...p: string}  {
      var result: {...p: string} = {} as any;
      Object.keys(obj).forEach((p:p) => {
           result[p] = obj[p].toFixed(precision);
      });
      return result;
}

var test = toFixedAll({x:5, y:7}, 3); // { x: "5.00", y: "6.00" },  p inferred as "x"|"y"
console.log(test.y.length) // 4   test.y: string

2. औपचारिक प्रकारों को 'स्ट्रिंग' का विस्तार करने के लिए विवश अन्य औपचारिक प्रकारों के साथ सब्सक्राइब करने की अनुमति दें

उदाहरण:

declare function mapValues<p extends string, T1[p], T2[p]>(
     obj:{...p: T1[p]}, fn:(arg: T1[p]) => T2[p]
): {...p: T2[p]};

3. औपचारिक प्रकारों के विनाश की अनुमति दें

उदाहरण:

class C<Array<T>> {
     x: T;
}   

var v1: C<string[]>;   // v1.x: string

सभी तीन चरणों के साथ हम लिख सकते हैं

declare module Backbone {

  class Model<{...p: T[p]}> {
    get(prop: p): T[p];
    set(prop: p, value: T[p]): void;
  }
}

declare module ImmutableJS {
  class Map<{...p: T[p]}> {
    get(prop: p): T[p];
    set(prop: p, value: T[p]): this;
  }
}

declare function pluck<p extends string, T[p]>(
    arr: Array<{...p:T[p]}>, prop: p
): Array<T[p]> 

मुझे पता है कि सिंटैक्स @fdecampredon द्वारा प्रस्तावित एक से अधिक क्रिया है
लेकिन मैं कल्पना नहीं कर सकता कि मूल प्रस्ताव के साथ mapValues या combineReducers के प्रकार को कैसे व्यक्त किया जाए।

function combineReducers(reducers) {
  return (state, action) => mapValues(reducers, (reducer, key) => reducer(state[key], action))
}

मेरे प्रस्ताव के साथ इसकी घोषणा इस तरह दिखाई देगी:

declare function combineReducers<p extends string, S[p]>(
    reducers: { ...p: (state: S[p], action: Action) => S[p] }
): (state: { ...p: S[p] }, action: Action) => { ...p: S[p] };

क्या यह मूल प्रस्ताव के साथ स्पष्ट है?

@spion , @fdecampredon ?

@Artazor निश्चित रूप से एक सुधार है। अब इस सुविधा के मेरे बेंचमार्क उपयोग के मामले को व्यक्त करना काफी अच्छा प्रतीत होता है:

user.id और user.name मानकर user.id number और string अनुसार डेटाबेस स्तंभ प्रकार हैं यानी Column<number> और Column<string>

एक फ़ंक्शन का प्रकार लिखें select जो लेता है:

select({id: user.id, name: user.name})

और Query<{id: number; name: string}>

select<T>({...p: Column<T[p]>}):Query<T>

यकीन नहीं है कि कैसे जा रहे हैं कि जाँच की और हालांकि अनुमान लगाया जा रहा है। लगता है जैसे कोई समस्या हो सकती है, क्योंकि टाइप T मौजूद नहीं है। क्या वापसी प्रकार को विनाशकारी रूप में व्यक्त करने की आवश्यकता होगी? अर्थात

select<T>({...p: Column<T[p]>}):Query<{...p:T[p]}>

@Artazor पूछना भूल गया, क्या p extends string पैरामीटर वास्तव में आवश्यक है?

क्या ऐसा कुछ करना पर्याप्त नहीं होगा?

select<T[p]>({...p: Column<T[p]>}):Query<{...p:T[p]}>

यानी सभी प्रकारों के लिए T [p] {...p:Column<T[p]>}

संपादित करें: एक और सवाल, यह कैसे सही होने के लिए जाँच की जा रही है?

@spion मुझे आपकी बात समझ में आ गई है - आपने T[p] मुझे गलत समझा है (लेकिन यह मेरी गलती है), मेरा मतलब पूरी तरह से अलग चीज से है, और आप उस p extends string को देखेंगे।

चलो डेटा संरचनाओं के लिए चार उपयोग मामलों पर विचार करें: List , Tuple , Dictionary और Record । हम उन्हें _conceptual data structure_ के रूप में संदर्भित करेंगे और निम्नलिखित गुणों के साथ उनका वर्णन करेंगे:

जावास्क्रिप्ट में, इन चार मामलों को दो भंडारण रूपों द्वारा समर्थित किया जाता है: a Array - a1 और a2 के लिए , और Object - b1 और b2 के लिए ।

_Note 1 _। ईमानदार होने के लिए, यह कहना सही नहीं है कि Tuple Array द्वारा समर्थित है, क्योंकि केवल "सत्य" टपल प्रकार arguments ऑब्जेक्ट का प्रकार है जो Array । फिर भी, वे अधिक या कम विनिमेय हैं, खासकर विनाशकारी और Function.prototype.apply के संदर्भ में जो मेटा-प्रोग्रामिंग के लिए दरवाजा खोलता है। टाइपस्क्रिप्ट भी Tuples मॉडलिंग के लिए Arrays का लाभ उठाती है।

_Note 2 _। जबकि ईएस 6 Map रूप में मनमाने ढंग से कुंजियों के साथ शब्दकोश की पूर्ण अवधारणा को बाद में पेश किया गया था, ब्रेंडन ईच का प्रारंभिक Record और एक सीमित Dictionary (साथ देने का प्रारंभिक निर्णय) स्ट्रिंग कुंजी केवल) Object (जहां obj.prop obj["prop"] बराबर है) के एक ही हुड के तहत पूरी भाषा का सबसे विवादास्पद तत्व बन गया (मेरी राय में)।
यह शाप और जावास्क्रिप्ट शब्दार्थ दोनों का आशीर्वाद है। यह प्रतिबिंब को तुच्छ बनाता है और प्रोग्रामरों को स्वतंत्र रूप से _programming_ और _meta-programming_ के स्तर के बीच लगभग शून्य मानसिक लागत (यहां तक ​​कि बिना सूचना के!) के बीच स्विच करने के लिए प्रोत्साहित करता है। मेरा मानना ​​है कि यह स्क्रिप्टिंग भाषा के रूप में जावास्क्रिप्ट सफलता का अनिवार्य हिस्सा है।

अब यह टाइपस्क्रिप्ट के लिए इस अजीब शब्दार्थ के लिए प्रकार व्यक्त करने का तरीका प्रदान करने का समय है। जब हम सोचते हैं कि _programming_ स्तर पर सब ठीक है:

हालाँकि, जब हम _meta-programming_ स्तर पर जाते हैं, तो _programming_ स्तर पर तय की गई चीजें अचानक परिवर्तनशील हो जाती हैं! और यहाँ हम अचानक ट्यूपल्स और फंक्शन सिग्नेचर के बीच संबंधों को पहचानते हैं और # 5453 (वैरिएडिक किंड्स) जैसी चीजों का प्रस्ताव करते हैं, जो वास्तव में मेट्रोपोग्रामिंग जरूरतों के केवल छोटे (लेकिन काफी महत्वपूर्ण) हिस्से को कवर करते हैं - एक औपचारिक को नष्ट करने की क्षमता देकर हस्ताक्षरों का संयोजन। बाकी के प्रकारों में पैरामीटर:

     function f<T>(a: number, ...args:T) { ... }

    f<[string,boolean]>(1, "A", true);

मामले में, यदि # 6018 भी लागू किया जाएगा, तो फंक्शन क्लास जैसा दिख सकता है

declare class Function<This, TArgs, TRes> {
        This::(...args: TArgs): TRes;
        call(self: This, ...args: TArgs): TRes;
        apply(self: This, args: TArgs): TRes;
        // bind needs also formal pattern matching:
        bind<[...TPartial, ...TCurried] = TArgs>(
           self: This, ...args: TPartial): Function<{}, TCurried, TRes> 
}

यह महान है लेकिन वैसे भी अधूरा है।

उदाहरण के लिए, कल्पना करें कि हम निम्नलिखित फ़ंक्शन को एक सही प्रकार असाइन करना चाहते हैं:

function extractAndWrapAll(...args) {
     return args.map(x => [x]);
}

// wrapAll(1,"A",true) === [[1],["A"],[true]]

प्रस्तावित प्रकार के साथ हम हस्ताक्षर के प्रकारों को परिवर्तित नहीं कर सकते हैं। यहां हमें कुछ अधिक शक्तिशाली की जरूरत है। वास्तव में, संकलन-समय के कार्यों को करना वांछनीय है जो कि प्रकार (फेसबुक के प्रवाह में) के रूप में काम कर सकते हैं। हालाँकि, मुझे यकीन है कि यह तब ही संभव होगा, जब (और अगर) टाइपस्क्रिप्ट की प्रणाली को अगले प्रोग्रामर के सामने एक छोटे से उपयोगकर्ता अद्यतन को तोड़ने के लिए महत्वपूर्ण जोखिम के बिना इसे समाप्त करने के लिए पर्याप्त स्थिर होगा। इस प्रकार, हमें पूर्ण मेटा-प्रोग्रामिंग समर्थन की तुलना में कुछ कम कट्टरपंथी चाहिए लेकिन फिर भी प्रदर्शन की समस्याओं से निपटने में सक्षम है।

इस समस्या को दूर करने के लिए, मैं _object के हस्ताक्षर_ की धारणा प्रस्तुत करना चाहता हूँ। मोटे तौर पर यह या तो है

1. ऑब्जेक्ट के संपत्ति नामों का सेट, या
2. शब्दकोश की कुंजी का सेट, या
3. किसी सरणी के संख्यात्मक सूचकांक का सेट
4. टपल के संख्यात्मक पदों का सेट।

आदर्श रूप से, पूर्णांक प्रकार के साथ-साथ स्ट्रिंग या ट्यूपल जैसे हस्ताक्षरों को दर्शाने के लिए स्ट्रिंग शाब्दिक प्रकार होना अच्छा होगा।

type ZeroToFive = 0 | 1 | 2 | 3 | 4 | 5;
// or
type ZeroToFive = 0 .. 5;   // ZeroToFive extends number (!)

पूर्णांक शाब्दिकों के नियम स्ट्रिंग शाब्दिकों के अनुरूप हैं;

तब हम सिग्नेचर एब्स्ट्रक्शन सिंटैक्स पेश कर सकते हैं, जो कि ऑब्जेक्ट रेस्ट / स्प्रेड सिंटैक्स से बिल्कुल मेल खाता है:

{...Props: T }

एक महत्वपूर्ण अपवाद के साथ: यहां Props पहचानकर्ता है जो सार्वभौमिक क्वांटिफायर के तहत बाध्य है:

<Props extends string> {...Props: T }  // every property has type T

<Index extends number> {...Index: T }  // every item has type T  
// the same as T[]

इस प्रकार, इसे टाइप लेक्सिकल स्कोप में पेश किया जाता है और इस स्कोप के नाम के रूप में कहीं भी इस्तेमाल किया जा सकता है। हालाँकि, इसका उपयोग दोहरा है: जब आराम / प्रसार संपत्ति के नाम के स्थान पर उपयोग किया जाता है तो यह ऑब्जेक्ट सिग्नेचर पर अमूर्तता का प्रतिनिधित्व करता है जब इसे एक स्टैंडअलोन प्रकार का उपयोग किया जाता है तो यह स्ट्रिंग (या संख्या का एक उपप्रकार) का प्रतिनिधित्व करता है।

declare class Object {
      static keys<p extends string, q extends p>(object{...q: {}}): p[];
}

और यहाँ सबसे अधिक परिष्कृत भाग है: _Key आश्रित प्रकार_

हम विशेष प्रकार के निर्माण का परिचय देते हैं: T for Prop (मैं इस वाक्यविन्यास का उपयोग T [Prop] के बजाय करना चाहता हूं जो आपको भ्रमित करता है) जहां Prop उस प्रकार चर का नाम है जो ऑब्जेक्ट के हस्ताक्षर को अमूर्त रखता है। उदाहरण के लिए <Prop extends string, T for Prop> प्रस्तुत किया जाने प्रकार शाब्दिक दायरे में दो औपचारिक प्रकार, Prop और T जहां यह ज्ञात है कि प्रत्येक विशेष मूल्य के लिए p के Prop वहाँ यह T खुद का प्रकार होगा।

हम यह नहीं कहते हैं कि कहीं न कहीं एक ऐसी वस्तु है जिसकी संपत्ति Props और उनके प्रकार T ! हम केवल दो प्रकारों के बीच एक कार्यात्मक निर्भरता का परिचय देते हैं। टाइप टी को Props के सदस्यों के साथ सहसंबद्ध किया जाता है, और यह सब!

यह हमें इस तरह की चीजें लिखने की संभावना देता है

function unwrap<P extends string, T for P>(obj:{...P: Maybe<T>}): Maybe<{...P: T}> {
  ...
}

unwrap({a:{value:1}, b:{value:"A"}, c:{value: true}}) === { a: 1, b: "A", c: true }
// here actual parameters will be inferred as 
unwrap<"a"|"b"|"c", {a: number, b: string, c: boolean}>

हालाँकि दूसरे पैरामीटर को एक वस्तु के रूप में नहीं, बल्कि पहचानकर्ता के अमूर्त मानचित्र के प्रकार के रूप में माना जाता है। इस परिप्रेक्ष्य में T for P का उपयोग tuples के लिए प्रकारों के अमूर्त दृश्यों को दर्शाने के लिए किया जा सकता है जब P संख्या ( @JsonFreeman ?) का उप-प्रकार होता है?

जब T का उपयोग कहीं न कहीं {...P: .... T .... } अंदर किया जाता है तो यह उस मानचित्र के बिल्कुल एक प्रकार का प्रतिनिधित्व करता है।

यह मेरा मुख्य विचार है।
किसी भी प्रश्न, विचार, आलोचना का बेसब्री से इंतजार -)

ठीक है, इसलिए extends string को एक मामले में सरणियों (और वैराडिक तर्क) को ध्यान में रखना है, और दूसरे में स्ट्रिंग स्थिरांक (प्रकार के रूप में) है। मिठाई!

हम यह नहीं कहते हैं कि कहीं न कहीं एक ऐसी वस्तु है जिसमें गुण होते हैं और उनके प्रकार T हैं! हम केवल दो प्रकारों के बीच एक कार्यात्मक निर्भरता का परिचय देते हैं। टाइप टी को Props के सदस्यों के साथ सहसंबद्ध किया जाता है, और यह सब!

मेरा यह मतलब नहीं था, मेरा मतलब यह था कि उनके प्रकार टी [पी] हैं, पी द्वारा अनुक्रमित प्रकारों का एक शब्दकोश। अगर एक अच्छा अंतर्ज्ञान है, तो मैं यही रखूंगा।

कुल मिलाकर, सिंटैक्स को थोड़ा और काम करने की आवश्यकता हो सकती है, लेकिन सामान्य विचार बहुत बढ़िया लगता है।

क्या वैरिएबल तर्कों के लिए unwrap लिखना संभव है?

संपादित करें: कोई बात नहीं, मुझे सिर्फ यह एहसास हुआ कि वैराडिक प्रकार के आपके प्रस्तावित विस्तार से यह पता चलता है।

सभी को नमस्कार,
मैं हैरान हूँ कि मैं अपनी समस्या को कैसे हल करूं और इस चर्चा को पाया।
समस्या यह है:
मेरे पास RpcManager.call(command:Command):Promise<T> विधि है, और उपयोग ऐसा होगा:

RpcManager.call(new GetBalance(123)).then((result) => {
 // here I want that result would have a type.
});

मुझे लगता है कि समाधान की तरह हो सकता है:

interface Command<T> {
    responseType:T;
}

class GetBalance implements Command<number> {
    responseType: number; // somehow this should be avoided. maybe Command should be abstract class.
    constructor(userId:number) {}
}

class RpcManager {
    static call(command:Command):Promise<typeof command.responseType> {
    }
}

or:

class RpcManager {
    static call<T>(command:Command<T>):Promise<T> {
    }
}

इस पर कोई विचार?

@ antanas-arvasevicius उस उदाहरण में अंतिम कोड ब्लॉक करना चाहिए जो आपको चाहिए।

ऐसा लगता है कि आपके पास एक विशिष्ट कार्य को पूरा करने का एक और प्रश्न है; स्टैक ओवरफ्लो का उपयोग करें या यदि आपको लगता है कि आपको एक कंपाइलर बग मिल गया है तो एक समस्या दर्ज करें।

हाय, रयान, आपकी प्रतिक्रिया के लिए धन्यवाद।
मैंने कोशिश की है कि कोड के अंतिम ब्लॉक लेकिन यह काम नहीं करता है।

त्वरित डेमो:

interface Command<T> { }
class MyCommand implements Command<{status:string}> { }
class RPC { static call<T>(command:Command<T>):T { return; } }

let response = RPC.call(new MyCommand());
console.log(response.status);

//output: error TS2339: Property 'status' does not exist on type '{}'.
//tested with: Version 1.9.0-dev.20160222

खेद है कि मैंने स्टैक ओवरफ्लो का उपयोग नहीं किया, लेकिन मुझे लगा कि यह इस मुद्दे से संबंधित है :)
क्या मुझे इस विषय के बारे में एक नया मुद्दा खोलना चाहिए?

एक गैर-सामान्य जेनेरिक प्रकार पैरामीटर काम करने से रोकता है; सामान्य तौर पर आपको _never_ में प्रकार के घोषणाओं में अप्रयुक्त प्रकार के पैरामीटर होने चाहिए क्योंकि वे अर्थहीन हैं। यदि आप T उपभोग करते हैं, तो सब कुछ बस काम करता है:

interface Command<T> { foo: T }
class MyCommand implements Command<{status:string}> { foo: { status: string; } }
class RPC { static call<T>(command:Command<T>):T { return; } }

let response = RPC.call(new MyCommand());
console.log(response.status);

यह सिर्फ आश्चर्यजनक है! धन्यवाद!
मैंने नहीं सोचा है कि टाइप पैरामीटर को सामान्य प्रकार के अंदर रखा जा सकता है और
टीएस उसे निकालेगा।
फरवरी 22, 2016 11:56 अपराह्न, "रयान कैवानुघ" सूचनाएँ @ithub.com ने लिखा:

एक गैर-सामान्य जेनेरिक प्रकार पैरामीटर काम करने से रोकता है; में
सामान्य तौर पर आपको _never_ के प्रकार में अप्रयुक्त प्रकार के पैरामीटर होने चाहिए
घोषणाएं निरर्थक हैं। यदि आप टी का उपभोग करते हैं, तो बस सब कुछ
काम करता है:

इंटरफ़ेस कमांड{foo: T} वर्ग MyCommand लागू करता है कमांड <{status: string}> {foo: {status: string; }} वर्ग RPC {स्थिर कॉल(कमांड: कमांड): टी {वापसी; }}
प्रतिक्रिया दें = RPC.call (नया MyCommand ());
कंसोल.लॉग (प्रतिक्रिया.स्टैटस);

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/1295#issuecomment -187404245
।

यदि आप RPC शैली API बना रहे हैं तो आप कुछ उपयोगी पा सकते हैं @ antanas-arvasevicius: https://github.com/alm-tools/alm/blob/master/docs/contributing.nYNC.md : गुलाब

ऊपर दिए गए दृष्टिकोण प्रतीत होते हैं:

• काफी जटिल;
• कोड में तार के उपयोग से निपटने नहीं है। string "सभी संदर्भों को ढूंढें" -able नहीं हैं, और न ही रीपेक्टेबल (जैसे नाम)।
• कुछ केवल "प्रथम स्तर" गुणों का समर्थन करते हैं और अधिक जटिल अभिव्यक्तियों का नहीं (जो कुछ रूपरेखाओं द्वारा समर्थित हैं)।

यहाँ एक और विचार है, जो सी # अभिव्यक्ति के पेड़ों से प्रेरित है। यह सिर्फ एक मोटा विचार है, पूरी तरह से सोचा-समझा कुछ भी नहीं है! सिंटेक्स भयानक है। मैं सिर्फ यह देखना चाहता हूं कि क्या यह किसी को प्रेरित करता है।

मान लें कि हमारे पास अभिव्यक्तियों को दर्शाने के लिए एक विशेष प्रकार के तार हैं।
चलो इसे type Expr<T, U> = string ।
जहाँ T प्रारंभिक वस्तु प्रकार है और U परिणाम प्रकार है।

मान लें कि हम का एक उदाहरण बना सकते हैं Expr<T,U> एक लैम्ब्डा उस प्रकार के एक पैरामीटर लेता है का उपयोग करके T और प्रदर्शन उस पर एक सदस्य का उपयोग कर सकते।
उदाहरण के लिए: person => person.address.city ।
जब ऐसा होता है, तो पूरे लैम्ब्डा को एक स्ट्रिंग से संकलित किया जाता है जिसमें पैरामीटर पर जो भी पहुंच होती है, इस मामले में: "address.city" ।

आप इसके बजाय एक सादे तार का उपयोग कर सकते हैं, जिसे Expr<any, any> रूप में देखा जाएगा।

यह विशेष Expr भाषा में

function pluck<T, U>(array: T[], prop: Expr<T, U>): U[];

let numbers = pluck([{x: 1}, {x: 2}], p => p.x);  // number[]
// compiles to:
// let numbers = pluck([..], "x");

यह मूल रूप से C # के लिए एक्सप्रेशन का उपयोग करने का एक सीमित रूप है।
क्या आपको लगता है कि यह परिष्कृत और कहीं दिलचस्प हो सकता है?

@fdecampredon @RyanCavanaugh

_ ( @ jods4 - मुझे खेद है कि मैं यहां आपके सुझाव का जवाब नहीं दे रहा हूं। मुझे उम्मीद है कि यह टिप्पणियों के माध्यम से 'दफन' नहीं होगा। _

मुझे लगता है कि इस फीचर ('टाइप प्रॉपर्टी टाइप') का नामकरण बहुत भ्रामक है और इसे समझना बहुत मुश्किल है। यह पता लगाना कठिन था कि यहाँ वर्णित अवधारणा क्या है और पहली जगह में इसका क्या अर्थ है!

सबसे पहले, सभी प्रकार के गुण नहीं हैं! undefined और null (हालांकि ये टाइप सिस्टम के केवल हालिया जोड़ नहीं हैं)। आदिम number , string , boolean शायद ही कभी एक संपत्ति (जैसे 2 ["प्रोप") द्वारा अनुक्रमित होते हैं? हालांकि यह काम करने लगता है, यह लगभग हमेशा एक गलती है)

मैं इस मुद्दे को नाम देना चाहूंगा इंटरफेस संपत्ति प्रकार संदर्भ स्ट्रिंग शाब्दिक मूल्यों के माध्यम से । यहां विषय एक नए 'प्रकार' को शुरू करने के बारे में नहीं है, बल्कि एक स्ट्रिंग वेरिएबल या फ़ंक्शन पैरामीटर का उपयोग करके किसी मौजूदा को संदर्भित करने का एक बहुत ही खास तरीका है जिसका मूल्य _must संकलन समय_ पर जाना जाता है।

यह अत्यधिक लाभकारी होता यदि इसे विशेष उपयोग के मामले के संदर्भ के बाहर वर्णित और सरल रूप में वर्णित किया जाता:

interface MyInterface {
  prop1: number;
  prop2: string;
}

let prop1Name = "prop1";
type Prop1Type = MyInterface[prop1Name]; // Prop1Type is now 'number'

let prop2Name = "prop2";
type Prop2Type = MyInterface[prop2Name]; // Prop2Type is now 'string'

let prop3Name = "prop3";
type NonExistingPropType = MyInterface[prop3Name]; // Compilation error: property 'prop3' does not exist on 'MyInterface'.

let randomString = createRandomString();
type NotAvailablePropType = MyInterface[randomString]; // Compilation error: value of 'randomString' is not known at compile time.

_Edit: ऐसा लगता है कि इसे सही ढंग से लागू करने के लिए कंपाइलर को यह पता

_Edit 2: शायद यह केवल const साथ काम करेगा जब एक चर के साथ प्रयोग किया जाएगा? _

मुझे यकीन नहीं है कि मूल उद्देश्य केवल एक स्ट्रिंग या शाब्दिक के बहुत ही विशेष मामले में संपत्ति के संदर्भ को एक फ़ंक्शन या विधि पैरामीटर को पारित करने की अनुमति है? जैसे

function func(someString: string): MyInterface[someString] {
  ..
}

let x = func("prop"); // x gets the type of MyInterface.prop

क्या मैंने इसे मूल रूप से इस उद्देश्य से परे सामान्यीकृत किया है?

यह एक ऐसे मामले को कैसे संभालेगा जहां फ़ंक्शन तर्क एक स्ट्रिंग शाब्दिक नहीं है, अर्थात संकलन समय पर ज्ञात नहीं है? जैसे

let x = func(getRandomString()); // What type if inferred for 'x' here?

क्या यह त्रुटि होगी, या डिफ़ॉल्ट रूप से any शायद होगा?

(पुनश्च: यदि यह वास्तव में इरादा था, तो मैं इस मुद्दे का नाम बदलने के लिए सुझाव दूंगा इंटरफ़ेस प्रकार प्रकार संदर्भ स्ट्रिंग शाब्दिक फ़ंक्शन या विधि तर्कों द्वारा - जितना लंबा यह निकला, यह वर्तमान शीर्षक की तुलना में बहुत अधिक सटीक और व्याख्यात्मक है।)

यहाँ एक सरल बेंचमार्क उदाहरण है (उदाहरण के लिए पर्याप्त) जो दिखाता है कि इस सुविधा को सक्षम करने की आवश्यकता है:

इस फ़ंक्शन का प्रकार लिखें, जो:

• वादा क्षेत्रों से युक्त एक वस्तु लेता है, और
• एक ही वस्तु देता है, लेकिन सभी क्षेत्रों को हल करने के साथ, प्रत्येक क्षेत्र में उचित प्रकार होता है।

function awaitObject(obj) {
  var result = {};
  var wait = Object.keys(obj)
    .map(key => obj[key].then(val => result[key] = val));
  return Promise.all(wait).then(_ => result)
}

जब निम्नलिखित वस्तु पर कॉल किया जाता है:

var res = awaitObject({a: Promise.resolve(5), b: Promise.resolve("5")})

परिणाम res का प्रकार {a: number; b: string} होना चाहिए

इस सुविधा के साथ (@Artazor द्वारा पूरी तरह से हटा दिया गया) हस्ताक्षर होंगे

awaitObject<p, T[p]>(obj: {...p: Promise<T[p]>}):Promise<{...p: T[p]}>

संपादित करें: ऊपर दिया गया रिटर्न प्रकार तय किया गया था, Promise<...> ^ ^ गायब था

@ संभावना

एक उदाहरण प्रदान करने की कोशिश करने के लिए धन्यवाद, लेकिन यहां कहीं भी मुझे एक उचित और संक्षिप्त विनिर्देश मिला है और स्पष्ट कम उदाहरणों का एक सेट है जो व्यावहारिक अनुप्रयोगों से _detached_ हैं और शब्दार्थ और विभिन्न किनारे के मामलों को उजागर करने की कोशिश करते हैं कि यह कैसे काम करेगा; मूल रूप में भी कुछ:

function func<T extends object>(name: string): T[name] {
 ...
}

1. एक प्रभावी और व्याख्यात्मक शीर्षक प्रदान करने के लिए बहुत कम प्रयास किया गया है (जैसा कि मैंने उल्लेख किया है 'टाइप प्रॉपर्टी टाइप' भ्रामक है और इस सुविधा के लिए बहुत व्याख्यात्मक नाम नहीं है, जो वास्तव में किसी विशेष प्रकार के बारे में नहीं है लेकिन एक प्रकार के संदर्भ के बारे में है)। मेरा सबसे अच्छा सुझाव दिया गया शीर्षक था _Interface संपत्ति प्रकार संदर्भ स्ट्रिंग शाब्दिक फ़ंक्शन या विधि आर्ग्युमेंट्स_ द्वारा (यह मानते हुए कि मैंने इस के दायरे को गलत नहीं समझा)।
2. इस बात का स्पष्ट उल्लेख नहीं किया गया है कि यदि name संकलित समय, अशक्त, या अपरिभाषित पर ज्ञात नहीं है, जैसे func<MyType>(getRandomString()) , func<MyType>(undefined) ।
3. इस बात का स्पष्ट उल्लेख नहीं किया गया है कि यदि T एक आदिम प्रकार है जैसे number या null ।
4. इस बात पर कोई स्पष्ट विवरण नहीं दिया गया था कि क्या यह केवल फ़ंक्शन पर लागू होता है और फ़ंक्शन बॉडी में T[name] का उपयोग किया जा सकता है या नहीं। और उस स्थिति में, अगर name फ़ंक्शन बॉडी में पुन: असाइन किया जाता है और इस तरह इसका मूल्य अब संकलित समय पर नहीं जाना जा सकता है?
5. वाक्यविन्यास की कोई वास्तविक विशिष्टता नहीं: उदाहरण के लिए T["propName"] या T[propName] काम होगा? एक पैरामीटर या चर के संदर्भ के बिना, मेरा मतलब है - यह उपयोगी हो सकता है!
6. कोई उल्लेख या चर्चा नहीं है अगर T[name] का उपयोग अन्य मापदंडों या यहां तक ​​कि फ़ंक्शन स्कोप के बाहर भी किया जा सकता है, जैसे

function func<T extends object>(name: string, val: T[name]) {
 ...
}

type A = { abcd: number };
const name = "abcd";
let x: A[name]; // Type of 'x' resolves to 'number'

_7। अतिरिक्त सामान्य पैरामीटर और typeof (हालांकि इसका उल्लेख किया गया था, लेकिन सुविधा के बाद अपेक्षाकृत पहले ही स्वीकार कर लिया गया था) का उपयोग करके अपेक्षाकृत सरल वर्कअराउंड की कोई वास्तविक चर्चा नहीं:

function get<T, V>(obj: T, propName: string): V {
    return obj[propName];
}

type MyType = { abcd: number };
let x: MyType  = { abcd: 12 };

let result = get<MyType, typeof x.abcd>(x, "abcd"); // Type of 'result' is 'number'

निष्कर्ष में: यहां कोई वास्तविक प्रस्ताव नहीं है, केवल उपयोग केस प्रदर्शनों का एक सेट है। मुझे आश्चर्य है कि यह टाइपस्क्रिप्ट टीम द्वारा स्वीकार किए गए या यहां तक ​​कि सकारात्मक ब्याज प्राप्त किया गया है क्योंकि मुझे विश्वास नहीं होगा कि यह उनके मानकों पर निर्भर होगा। मुझे खेद है कि अगर मैं यहां थोड़ा कठोर लग सकता हूं (मेरे लिए विशिष्ट नहीं), लेकिन मेरी कोई भी आलोचना व्यक्तिगत नहीं है या किसी विशेष व्यक्ति के लिए निर्देशित नहीं है।

क्या हम वास्तव में मेटा-प्रोग्रामिंग के संदर्भ में उस दूर जाना चाहते हैं?

JS एक गतिशील भाषा है, कोड वस्तुओं को मनमाने तरीके से जोड़ सकता है।
टाइप सिस्टम में हम जो मॉडल कर सकते हैं उसकी सीमाएं हैं और उन कार्यों के साथ आना आसान है जिन्हें आप टीएस में मॉडल नहीं कर सकते।
सवाल यह है: यह कहाँ तक उचित और उपयोगी है?

@Spion से अंतिम उदाहरण ( awaitObject ) एक ही समय में है:

• _Very complex_ भाषा की दृष्टि से (मैं यहाँ @malibuzios से सहमत हूँ)।
• प्रयोज्यता के संदर्भ में _Very संकीर्ण_। वह उदाहरण विशिष्ट बाधाओं का चयन करता है और अच्छी तरह से सामान्य नहीं करता है।

BTW @spion से आपको अपने उदाहरण का रिटर्न प्रकार सही नहीं मिला ... यह एक Promise रिटर्न देता है।

हम मूल मुद्दे से बहुत दूर हैं, जो टाइपिंग एपीआई के बारे में था, जो कि _.pluck जैसे फ़ील्ड का प्रतिनिधित्व करने वाला स्ट्रिंग लेते हैं
वे API _should be_ समर्थित हैं क्योंकि वे सामान्य हैं और वे जटिल नहीं हैं। हमें इसके लिए { ...p: T[p] } जैसे मेटा-मॉडल की आवश्यकता नहीं है।
ओपी में कई उदाहरण हैं, नेमफ्लो मुद्दे में
एक अलग दृष्टिकोण उन उपयोग-मामलों को कवर कर सकता है, एक संभावित विचार के लिए ऊपर मेरी टिप्पणी देखें।

@ jods4 इसकी संकीर्ण नहीं है। इसका उपयोग कई चीजों के लिए किया जा सकता है, जो वर्तमान में टाइप सिस्टम में मॉडलिंग करना असंभव है। मैं कहूँगा कि TS प्रकार प्रणाली में पिछले बड़े गायब भागों में से एक। @Artazor https://github.com/Microsoft/TypeScript/issues/1295#issuecomment -177287714 ऊपर दिए गए सरल सामान से ऊपर वास्तविक दुनिया के बहुत सारे उदाहरण हैं, sql क्वेरी बिल्डर - इस उदाहरण का चयन करें और इसी तरह।

यह ब्लूबर्ड में awaitObject । इसकी एक वास्तविक विधि है। वर्तमान में प्रकार बेकार है।

एक अधिक सामान्य समाधान बेहतर होगा। यह सरल और जटिल दोनों मामलों के लिए काम करेगा। आधे मामलों में एक कमज़ोर समाधान पाया जाएगा और आसानी से अनुकूलता की समस्या पैदा हो सकती है यदि भविष्य में अधिक सामान्य एक को अपनाने की आवश्यकता हो।

हां, इसके लिए बहुत अधिक काम करने की आवश्यकता है, लेकिन मुझे यह भी लगता है कि @Artazor ने उन सभी पहलुओं का विश्लेषण और अन्वेषण करने के लिए एक उत्कृष्ट काम किया, जो हमने पहले नहीं सोचा था। मैं नहीं रहूँगा कि हम मूल समस्या से भटक गए हैं, हमें केवल इसकी बेहतर समझ है।

हमें इसके लिए एक बेहतर नाम की आवश्यकता हो सकती है, मैं कोशिश करूंगा लेकिन मुझे ये चीजें आमतौर पर सही नहीं लगती हैं। "ऑब्जेक्ट जेनरिक" के बारे में कैसे?

@ स्थान , केवल

awaitObject<p,T[p]>(obj: {...p:Promise<T[p]>}): Promise<{...p:T[p]}>

(आपने आउटपुट सिग्नेचर में एक प्रॉमिस मिस किया है)
-)

@ jods4 , मैं @spion से सहमत हूं
वास्तविक दुनिया की बहुत सारी समस्याएं हैं जहां { ...p: T[p] } का समाधान है। किसी एक का नाम: प्रतिक्रिया + प्रवाह / redux

@spion @Artazor
मुझे बस चिंता है कि यह सटीक रूप से निर्दिष्ट करने के लिए काफी जटिल हो रही है।

इस मुद्दे के पीछे की प्रेरणा बह गई है। मूल रूप से यह एपीआई का समर्थन करने के बारे में था जो एक वस्तु क्षेत्र को दर्शाने के लिए एक स्ट्रिंग को स्वीकार करता है। अब यह ज्यादातर एपीआई पर चर्चा कर रहा है जो वस्तुओं का उपयोग नक्शे या रिकॉर्ड के रूप में करता है। ध्यान दें कि यदि हम एक पत्थर से दो पक्षियों को मार सकते हैं तो मैं इसके लिए हूं।

अगर हम APIs पर वापस जाते हैं जो स्ट्रिंग्स की समस्या लेते हैं, तो T[p] मेरी राय में पूर्ण समाधान नहीं है (मैंने पहले क्यों कहा)।

शुद्धता के लिए _Just_ awaitObject को गैर-वादा गुणों को भी स्वीकार करना चाहिए, कम से कम Bluebird props करता है। तो अब हमारे पास है:

awaitObject<p,T[p]>(obj: { ...p: T[p] | Promise<T[p]> }): Promise<T>

मैंने वापसी प्रकार को Promise<T> बदल दिया क्योंकि मुझे उम्मीद है कि यह अंकन काम करेगा।
अन्य अतिभार हैं, उदाहरण के लिए एक ऐसी वस्तु के लिए एक वादा करता है (इसका हस्ताक्षर और भी मजेदार है)। तो इसका मतलब है कि { ...p } नोटेशन को किसी भी अन्य प्रकार की तुलना में एक खराब मैच माना जाना चाहिए।

इन सभी को निर्दिष्ट करना कठिन काम है। अगर आप इसे आगे बढ़ाना चाहते हैं तो मैं कहूंगा कि यह अगला कदम है।

@spion @ jods4

मैं यह उल्लेख करना चाहता था कि यह सुविधा जेनरिक के बारे में नहीं है और न ही उच्च प्रकार के बहुरूपी प्रकारों के बारे में है। यह केवल एक प्रकार से युक्त संपत्ति के प्रकार को संदर्भित करने के लिए एक वाक्यविन्यास है (नीचे वर्णित कुछ "उन्नत" एक्सटेंशन के साथ), जो अवधारणा में typeof से दूर नहीं है। उदाहरण:

type MyType = { abcd: number };
let y: MyType["abcd"]; // Technically this could also be written as MyType.abcd

अब इसकी तुलना करें:

type MyType = { abcd: number };
let x: MyType;

let y: typeof x.abcd;

typeof साथ दो मुख्य अंतर हैं। typeof विपरीत, यह उदाहरणों के बजाय टाइप (कम से कम गैर-आदिम लोगों, एक तथ्य जो अक्सर यहां छोड़ दिया जाता है) पर लागू होता है। इसके अलावा (और यह एक प्रमुख बात है) इसे शाब्दिक स्ट्रिंग स्थिरांक (जिसे संकलन समय पर ज्ञात होना चाहिए) को संपत्ति पथ विवरणक, और जेनरिक के रूप में उपयोग करने के लिए विस्तारित किया गया था:

const propName = "abcd";
let y: MyType[propName];
// Or with a generic parameter:
let y: T[propName];

हालाँकि तकनीकी रूप से typeof को स्ट्रिंग शाब्दिकों के समर्थन के लिए बढ़ाया जा सकता था (इसमें वह मामला भी शामिल है जहाँ x का एक सामान्य प्रकार है):

let x: MyType;
const propName = "abcd";
let y: typeof x[propName];

और इस विस्तार के साथ इसका उपयोग कुछ लक्ष्य मामलों को हल करने के लिए भी किया जा सकता है:

function get<T>(propName: string, obj: T): typeof obj[propName]

typeof हालांकि अधिक शक्तिशाली है क्योंकि यह घोंसले के शिकार के स्तर की अनिश्चित मात्रा का समर्थन करता है:

let y: typeof x.prop.childProp.deeperChildProp

और यह केवल एक स्तर पर जाता है। Ie ने योजना नहीं बनाई है (जहां तक ​​मुझे पता है) समर्थन करने के लिए:

let y: MyType["prop"]["childProp"]["deeperChildProp"];
// Or alternatively
let y: MyType["prop.childProp.deeperChildProp"];

मुझे लगता है कि इस प्रस्ताव का दायरा (यदि इसे अस्पष्टता के स्तर पर प्रस्ताव भी कहा जा सकता है) बहुत संकीर्ण है। यह एक विशेष समस्या को हल करने में मदद कर सकता है (हालांकि वैकल्पिक समाधान हो सकता है), जो कई लोगों को इसे बढ़ावा देने के लिए बहुत उत्सुक बनाता है। हालाँकि यह भाषा से मूल्यवान वाक्य रचना का भी उपभोग कर रहा है। एक व्यापक योजना और डिजाइन-उन्मुख दृष्टिकोण के बिना, यह जल्दबाजी में कुछ ऐसा पेश करने के लिए नासमझ लगता है, जैसा कि इस तारीख को भी स्पष्ट विनिर्देश नहीं है।

_Edits: कोड में कुछ स्पष्ट गलतियों को सही किया example_

मैंने typeof विकल्प पर थोड़ा शोध किया है:

typeof x["abcd"] और typeof x[42] लिए भविष्य की भाषा का समर्थन स्वीकृत किया गया है , और अब # 6606 के अंतर्गत आता है, जो वर्तमान में विकास के अधीन है (एक कार्य कार्यान्वयन है)।

यह आधा रास्ता जाता है। इनकी जगह पर, बाकी कई चरणों में किया जा सकता है:

(1) स्ट्रिंग शाब्दिक स्थिरांक (या समकालिक स्थिरांक के लिए समर्थन जोड़ें - टुपल्स के लिए उपयोगी हो सकता है?) प्रकार के भावों में गुण निर्दिष्ट करने वाले के रूप में, जैसे:

let x: MyType;
const propName = "abcd";
let y: typeof x[propName];

(2) इन स्पेसरों को जेनेरिक प्रकारों पर लागू करने की अनुमति दें

let x: T; // Where T should extend 'object'
const propName = "abcd";
let y: typeof x[propName];

(3) इन विनिर्देशकों को पारित करने की अनुमति दें, और व्यवहार में "तर्कों" को संदर्भ तर्क के माध्यम से, फ़ंक्शन तर्कों के माध्यम से ( typeof list[0] की योजना बनाई गई है, इसलिए मेरा मानना ​​है कि यह अधिक जटिल मामलों जैसे pluck को कवर कर सकता है:

function get<T extends object>(obj: T, propertyName: string): typeof obj[propertyName];
function pluck<T extends object>(list: Array<T>, propertyName: string): Array<typeof list[0][propertyName]>;

( object प्रकार यहाँ # 1809 पर प्रस्तावित है)

यद्यपि अधिक शक्तिशाली (जैसे typeof obj[propName][nestedPropName] समर्थन कर सकता है) यह संभव है कि यह वैकल्पिक दृष्टिकोण यहां वर्णित सभी मामलों को कवर नहीं कर सकता है। कृपया मुझे बताएं कि क्या ऐसे उदाहरण हैं जो इसके द्वारा नियंत्रित नहीं होंगे (एक परिदृश्य जो मन में आता है वह तब होता है जब ऑब्जेक्ट उदाहरण बिल्कुल भी पारित नहीं होता है, हालांकि, मेरे लिए यह मुश्किल है इस बिंदु पर एक मामले की कल्पना करें इसकी आवश्यकता होगी, हालांकि मुझे लगता है कि यह संभव है)।

_Edits: code_ में कुछ गलतियों को सुधारा

@ मालिबुज़ियोस
कुछ विचार:

• यह एपीआई परिभाषा को ठीक करता है लेकिन यह कॉलर की मदद नहीं करता है। हमें अभी भी कॉल साइट पर किसी प्रकार के nameof या Expression ।
• यह .d.ts परिभाषाओं के लिए काम करता है, लेकिन यह आम तौर पर TS कार्यों / कार्यान्वयनों में वैधानिक रूप से कमजोर या यहां तक ​​कि सत्यापन योग्य नहीं होगा।

जितना अधिक मैं इसके बारे में सोचता हूं, उतना अधिक Expression<T, U> उस तरह के एपीआई के लिए समाधान की तरह दिखता है। यह कॉल साइट की समस्याओं को ठीक करता है, परिणाम की टाइपिंग और एक कार्यान्वयन में बांझ + सत्यापन योग्य हो सकता है।

@ jods4

आपने पिछले टिप्पणी के तरीके में ऊपर उल्लेख किया pluck को भावों के साथ लागू किया जा सकता है। यद्यपि मैंने C # से बहुत परिचित होने का उपयोग किया था, मैंने वास्तव में उनके साथ कभी प्रयोग नहीं किया, इसलिए मैं मानता हूं कि मुझे वास्तव में इस बिंदु पर उनकी बहुत अच्छी समझ नहीं है।

वैसे भी, सिर्फ टाइपस्क्रिप्ट का उल्लेख करना चाहता था टाइप टाइप तर्क का समर्थन करता pluck का उपयोग करने के बजाय, कोई भी map उपयोग कर सकता है और वही परिणाम प्राप्त कर सकता है, जिसे सामान्य पैरामीटर निर्दिष्ट करने की आवश्यकता नहीं होगी ( यह अनुमान है) और यह भी पूर्ण प्रकार की जाँच और पूर्णता देगा:

let x = [{name: "John", age: 34}, {name: "Mary", age: 53}];

let result = x.map(obj => obj.name);
// 'result' is ["John", "Mary"] and its type inferred as 'string[]' 

जहाँ map (प्रदर्शन के लिए अत्यधिक सरलीकृत) घोषित किया गया है

map<U>(mapFunc: (value: T) => U): U[];

एक ही लैंबडा के किसी भी परिणाम को पारित करने के लिए एक ही चालन पैटर्न का उपयोग 'ट्रिक' के रूप में किया जा सकता है (जिसे कॉल करने की भी आवश्यकता नहीं है) और इसके रिटर्न प्रकार को इसमें सेट करें:

function thisIsATrick<T, U>(obj: T, onlyPassedToInferTheReturnType: () => U): U {
   return;
}

let x = {name: "John", age: 34};

let result = thisIsATrick(x, () => x.age) // Result inferred as 'number' 

_Edit: यह यहाँ एक मेमने में पारित करने के लिए मूर्खतापूर्ण लग सकता है और न केवल खुद बात! हालांकि नेस्टेड ऑब्जेक्ट्स (जैसे x.prop.Childprop ) जैसे अधिक जटिल मामलों में त्रुटि होने पर अपरिभाषित या अशक्त संदर्भ हो सकते हैं। इसे लंबोदर में रखना, जिसे जरूरी नहीं कहा जाता है, इससे बचा जाता है ।_

मैं मानता हूँ कि मैं यहाँ उपयोग किए गए कुछ मामलों से बहुत परिचित नहीं हूँ। व्यक्तिगत रूप से मुझे कभी भी एक फ़ंक्शन को कॉल करने की आवश्यकता महसूस नहीं हुई जो एक संपत्ति का नाम स्ट्रिंग के रूप में लेता है। प्रकार तर्क इंटरफ़ेस के साथ संयोजन में एक लैम्ब्डा (जहां आपके द्वारा वर्णित फायदे भी हैं) पास करना आमतौर पर कई सामान्य समस्याओं को हल करने के लिए पर्याप्त है।

जिस कारण से मैंने typeof वैकल्पिक दृष्टिकोण का सुझाव दिया था, वह यह है कि समान उपयोग के मामलों को कवर करने के लिए लगता है और जो लोग यहां वर्णन करते हैं, उनके लिए समान कार्यक्षमता प्रदान करते हैं। क्या मैं खुद इसका इस्तेमाल करूंगा? मुझे नहीं पता, कभी भी इसकी ज़रूरत महसूस नहीं हुई (यह बस इतना हो सकता है कि मैं लगभग कभी भी बाहरी पुस्तकालयों का उपयोग नहीं करता हूं जैसे कि अंडरस्कोर, मैं लगभग हमेशा अपने द्वारा आवश्यक आधार पर उपयोगिता कार्यों को विकसित करता हूं)।

@malibuzios सच है, pluck लंबोदा + map अब बिल्ट-इन के साथ मूर्खतापूर्ण है।

इस टिप्पणी में मैं 5 अलग-अलग एपीआई देता हूं जो सभी तार लेते हैं - वे सभी परिवर्तनों को देखने से जुड़े हैं।

@ jods4 और अन्य

केवल यह उल्लेख करना चाहता था कि जब # 6606 पूरा हो गया है, केवल चरण 1 को लागू करके (संपत्ति स्ट्रिंगरों के रूप में निरंतर स्ट्रिंग शाब्दिक उपयोग करने की अनुमति दें) यहां आवश्यक कार्यक्षमता में से कुछ हासिल किया जा सकता है, हालांकि यह उतने ही सुरुचिपूर्ण ढंग से नहीं हो सकता है (इसकी आवश्यकता हो सकती है) संपत्ति का नाम एक अतिरिक्त के रूप में घोषित किया जा सकता है, अतिरिक्त विवरण)।

function observeProperty<T, U>(obj: T, propName: string ): Subscriber<U> {
    ....
}

let x = { name: "John", age: 42 };

const propName = "age";
observeProperty<typeof x, typeof x[propName]>(x, propName);

हालांकि, इसे लागू करने के प्रयास की मात्रा चरण 2 और 3 को लागू करने की तुलना में काफी कम हो सकती है (मुझे यकीन नहीं है लेकिन यह संभव है कि 1 पहले से ही # 6606 द्वारा कवर किया गया हो)। चरण 2 को लागू करने के साथ, यह उस मामले को भी कवर करेगा जहां x का एक सामान्य प्रकार है (लेकिन मुझे यकीन नहीं है कि अगर वास्तव में इसकी आवश्यकता है?)।

संपादित करें: कारण कि मैंने एक बाहरी स्थिरांक का उपयोग किया है और न केवल संपत्ति के नाम को दो बार लिखा है न केवल टाइपिंग कम करने के लिए, बल्कि यह भी सुनिश्चित करें कि नाम हमेशा मेल खाते हैं, हालांकि यह अभी भी "नाम बदलें" और "सभी खोजें" जैसे उपकरणों के साथ उपयोग नहीं किया जा सकता है संदर्भ ", जो मुझे एक गंभीर नुकसान लगता है।

@ jods4 मैं अभी भी एक बेहतर समाधान की तलाश कर रहा हूं जो स्ट्रिंग्स का उपयोग नहीं करता है। मैं यह सोचने की कोशिश करूंगा कि nameof और इसके वेरिएंट के साथ क्या किया जा सकता है।

यहाँ एक और विचार है।

चूंकि स्ट्रिंग शाब्दिक पहले से ही प्रकारों के रूप में समर्थित हैं, जैसे कोई पहले से ही लिख सकता है:

let x: "HELLO"; 

कोई कार्य करने के लिए पारित शाब्दिक स्ट्रिंग को सामान्य विशेषज्ञता के रूप में देख सकता है

(_Edit: इन उदाहरणों को यह सुनिश्चित करने के लिए सही किया गया था कि s फ़ंक्शन बॉडी में अपरिवर्तनीय है, इस बिंदु पर पैरामीटर पदों पर const समर्थित नहीं है ( readonly बारे में निश्चित नहीं है) हालांकि)।_) :

function func(const s: string)

string s साथ जुड़े पैरामीटर प्रकार को यहां अंतर्निहित जेनेरिक के रूप में देखा जा सकता है (जैसा कि इसे स्ट्रिंग शाब्दिक के लिए विशेष किया जा सकता है)। स्पष्टता के लिए मैं इसे और अधिक स्पष्ट रूप से लिखूंगा (हालांकि मुझे यकीन नहीं है कि अगर वास्तव में इसकी आवश्यकता है):

function func<S extends string>(const s: S)
func("TEST");

आंतरिक रूप से विशेषज्ञ हो सकते हैं:

function func(s: "TEST")

और अब इसे संपत्ति के नाम को "पास" करने के लिए एक वैकल्पिक तरीके के रूप में इस्तेमाल किया जा सकता है, जो मुझे लगता है कि यहां के शब्दार्थ को बेहतर तरीके से कैप्चर करता है।

function observeProperty<T, S extends string>(obj: T, const propName: S): Subscriber<T[S]>

x = { name: "John",  age: 33};

observeProperty(x, nameof(x.age))

चूँकि T[S] , दोनों T , और S सामान्य पैरामीटर हैं। रन-टाइम और टाइप स्कोप एलिमेंट्स (जैसे T[someString] ) को मिक्स करने की तुलना में एक प्रकार की स्थिति में दो प्रकारों का संयुक्त होना अधिक स्वाभाविक है।

_Edits: एक अपरिवर्तनीय स्ट्रिंग पैरामीटर प्रकार को फिर से लिखने के लिए उदाहरण ।_

चूंकि मैं TS 1.8.7 और नवीनतम संस्करण का उपयोग नहीं कर रहा हूं, इसलिए मुझे इस बात की जानकारी नहीं थी कि हाल के संस्करणों में

const x = "Hello";

x का प्रकार पहले से ही शाब्दिक प्रकार "Hello" , (यानी: x: "Hello" ) के रूप में अनुमानित है, जो बहुत अधिक समझ में आता है (# 6554 देखें)।

तो स्वाभाविक रूप से अगर कोई पैरामीटर const (या शायद readonly भी काम करेगा?) को परिभाषित करने का एक तरीका था:?

function func<S extends string>(const s: S): S

फिर मुझे विश्वास है कि यह पकड़ सकता है:

let result = func("abcd"); // type of 'result' inferred as the literal type "abcd"

चूंकि इनमें से कुछ नया है और हाल की भाषा सुविधाओं पर निर्भर करता है, इसलिए मैं इसे स्पष्ट रूप से संक्षेप में प्रस्तुत करने की कोशिश करूंगा:

(1) जब const (और शायद readonly रूप में अच्छी तरह से?) स्ट्रिंग चर का एक मूल्य प्राप्त होता है जिसे संकलन-समय पर जाना जाता है, चर स्वचालित रूप से एक शाब्दिक प्रकार प्राप्त करता है जिसका समान मूल्य होता है ( मेरा मानना ​​है कि यह एक हालिया व्यवहार है जो 1.8.x ) पर नहीं होता है, उदा

const x = "ABCD";

के प्रकार x होने के लिए मान लिया जाता है "ABCD" , नहीं string !, जैसे एक के रूप में इस राज्य सकता है x: "ABCD" ।

(२) यदि readonly फ़ंक्शन मापदंडों की अनुमति थी, तो एक सामान्य प्रकार के साथ एक readonly पैरामीटर स्वाभाविक रूप से एक स्ट्रिंग शाब्दिक के लिए अपने विशेषज्ञ को ले जाएगा जब यह एक तर्क के रूप में प्राप्त होता है, क्योंकि पैरामीटर अपरिवर्तनीय है!

function func<S extends string>(readonly str: S);
func("ABCD");

यहाँ S प्रकार के हल किया गया है "ABCD" , नहीं string !

हालांकि, अगर str पैरामीटर अपरिवर्तनीय नहीं था, तो कंपाइलर गारंटी नहीं दे सकता है कि यह फ़ंक्शन के शरीर में पुन: असाइन नहीं किया गया है, इस प्रकार, यह अनुमान केवल string ।

function func<S extends string>(str: S) {
    str = "DCBA"; // This may happen
}

func("ABCD");

(३) इसका लाभ लेना संभव है और मूल प्रस्ताव को संशोधित करने के लिए संपत्ति का निर्दिष्ट प्रकार एक संदर्भ होना चाहिए, जिसे string to

function get<T extends object, S extends string>(obj: T, readonly propName: S): T[S]

इसे कॉल करने के लिए किसी भी प्रकार के तर्क को स्पष्ट रूप से निर्दिष्ट करने की आवश्यकता नहीं होगी, क्योंकि टाइपस्क्रिप्ट टाइप तर्क का समर्थन करता है:

let x = { name: "John", age: 42 };

get(x, "age"); // result type is inferred to be 'number'
// or for stronger type safety:
get(x, nameof(x.age)); // result type is inferred to be 'number'

_Edits: कुछ वर्तनी और कोड गलतियों को सुधार दिया ।_
_Note: इस संशोधित दृष्टिकोण का एक सामान्यीकृत और विस्तारित संस्करण अब # 7730._ में भी ट्रैक किया गया है

यहाँ संपत्ति के प्रकार का एक और उपयोग है (या "अनुक्रमित जेनरिक" जैसा कि मैं उन्हें हाल ही में कॉल करना चाहता हूं) जो @Raynos के साथ चर्चा में आया था

हम पहले से ही सरणियों के लिए निम्न सामान्य चेकर लिख सकते हैं:

function tArray<T>(f:(t:any) => t is T) {
    return function (a:any): a is Array<T> {
        if (!Array.isArray(a)) return false;
        for (var k = 0; k < a.length; ++k)
            if (!f(a[k])) return false;
        return true;
    }
}

function tNumber(n:any): n is number {
    return typeof n === 'number'
}
var isArrayOfNumber = tArray(tNumber)

function test(x: {}) {
    if (isArrayOfNumber(x)) {
        return x[x.length - 1].toFixed(2); // this type checks
    }
}

एक बार जब हमने जेनेरिक अनुक्रमित कर लिया, तो हम वस्तुओं के लिए एक सामान्य चेकर भी लिख सकेंगे:

function tObject<p, T[p]>(checker: {...p: (t:any) => t is T[p]}) {
  return function(obj: any): obj is {...p: T[p] } {
    for (var key in checker) if (!checker[key](obj[key])) return false;
    return true;
  }
}

जो स्ट्रिंग, संख्या, बूलियन, अशक्त और अपरिभाषित के लिए आदिम चेकर्स के साथ मिलकर आपको इस तरह की चीजें लिखने देंगे:

var isTodoList = tObject({
  items: tArray(tObject({text: tString, completed: tBoolean})),
  showCompleted: tBoolean
})

और यह सही रनटाइम चेकर _and_ संकलित समय प्रकार गार्ड के साथ परिणाम है, एक ही समय में :)

क्या किसी ने इस पर अभी तक कोई काम किया है, या यह किसी के रडार पर है? यह एक बड़ा सुधार होगा कि कितने मानक पुस्तकालय टाइपिंग का उपयोग कर सकते हैं, जिसमें lodash या ramda और कई डेटाबेस इंटरफेस पसंद हैं।

@malibuzios का मानना ​​है कि आप @Artazor के सुझाव पर पहुँच रहे हैं :)

अपनी चिंताओं को दूर करने के लिए:

function func<S extends string>(readonly str: S): T[str] {
 ...
}

यह होगा

function func<S extends string, T[S]>(str: S):T[S] { }

इस तरह, नाम को सबसे विशिष्ट प्रकार (एक स्ट्रिंग स्थिर प्रकार) के साथ लॉक किया जाएगा, जब इसे कहा जाता है:

func("test")

प्रकार S "test" ( string ) बन जाता है। इस तरह के str को एक अलग मूल्य पर भरोसा नहीं किया जा सकता है। अगर आपने कोशिश की है, जैसे

str = "other"

कंपाइलर एक त्रुटि उत्पन्न कर सकता है (जब तक कि विचरण ध्वनि मुद्दे नहीं हैं;))

केवल एक संपत्ति के प्रकार को प्राप्त करने के बजाय, मैं एक मनमाना सुपर प्रकार का विकल्प प्राप्त करना चाहूंगा।

तो मेरा सुझाव निम्न सिंटैक्स जोड़ना है: केवल T[prop] होने के बजाय, मैं सिंटैक्स T[...props] जोड़ना चाहूंगा। जहाँ props को T सदस्यों का एक सरणी होना चाहिए। और जिसके परिणामस्वरूप प्रकार का एक सुपर प्रकार है T के सदस्यों के साथ T में परिभाषित props ।

मुझे लगता है कि यह Sequelize में अत्यधिक उपयोगी होगा - नोड के लिए एक लोकप्रिय ORM.js. सुरक्षा कारणों और सही कारणों के लिए, तालिका में केवल विशेषताओं को क्वेरी करना बुद्धिमान है, जिनका आपको उपयोग करने की आवश्यकता है। जिसका अर्थ अक्सर सुपर प्रकार का होता है।

interface IUser {
    id: string;
    name: string;
    email: string;
    createdAt: string;
    updatedAt: string;
    password: string;
    // ...
}

interface Options<T> {
     attributes: (memberof T)[];
}

interface Model<IInstance> {
     findOne(options: Options<IInstance>): IInstance[...options.attributes];
}

declare namespace DbContext {
   define<T>(): Model<T>;
}

const Users = DbContext.define<IUser>({
   id: { type: DbContext.STRING(50), allowNull: false },
   // ...
});

const user = Users.findOne({
    attributes: ['id', 'email', 'name'],
    where: {
        id: 1,
    }
});

user.id
user.email
user.name

user.password // error
user.createdAt // error
user.updatedAt // error

(मेरे उदाहरण में इसमें ऑपरेटर memberof , जो कि आप इससे होने की उम्मीद करते हैं, और अभिव्यक्ति options.attributes भी है, जो typeof options.attributes , लेकिन मुझे लगता है typeof ऑपरेटर इस मामले में बेमानी है, क्योंकि यह एक ऐसी स्थिति में है जो एक प्रकार की अपेक्षा करता है))।

अगर कोई जोर नहीं देता, तो मैंने इस पर काम करना शुरू कर दिया।

फंक्शन के अंदर टाइप सेफ्टी के बारे में आपका क्या विचार है, यानी रिटर्न स्टेटमेंट सुनिश्चित करें कि रिटर्न टाइप के लिए कुछ काम हो?

interface A {
     a: string;
}
function f(p: string): A[p] {
    return 'aaa'; // This is string, but can we ensure it is the intended A[p] ?
}

साथ ही यहां इस्तेमाल किया गया "प्रॉपर्टी टाइप" नाम थोड़ा गलत लगता है। यह बताता है कि प्रकार में गुण होते हैं, जो लगभग सभी प्रकार के होते हैं।

"संपत्ति संदर्भित प्रकार" के बारे में क्या?

फ़ंक्शन के अंदर आपकी सुरक्षा के बारे में आपका क्या विचार है

मेरा विचार मंथन:

let a: A;
function f(p: string): A[p] {
  let x = a[p]; // typeof A[p], only when:
  // 1. p is directly referencing function argument
  // 2. function return type is Property Reference Type

  p = "abc"; // not allowed to assign a new value when p is used on Property Reference Type

  return x; // x is A[p], so okay
}

और वापसी लाइन पर सामान्य स्ट्रिंग को हटा दें।

आपके विचार के साथ @malibuzios समस्या यह है कि इसके लिए सभी जेनरिक को निर्दिष्ट करने की आवश्यकता होती है, यदि वे अनुमान

Https://github.com/Microsoft/TypeScript/issues/1295#issuecomment -239653337 के बारे में TS टीम की कोई टिप्पणी?

@RyanCavanaugh @mhegazy आदि?

नाम के बारे में, मैंने इस सुविधा को कॉल करना शुरू कर दिया (कम से कम वह रूप जो @Artazor ने प्रस्तावित किया) "अनुक्रमित जेनरिक"

इस समस्या के लिए दूसरे कोण से समाधान हो सकता है। मुझे यकीन नहीं है कि अगर यह पहले से ही लाया गया है, तो यह एक लंबा धागा है। एक स्ट्रिंग जेनेरिक सुझाव विकसित करना, हम इंडेक्सेशन हस्ताक्षर का विस्तार कर सकते हैं। चूंकि स्ट्रिंग लिटरल्स को इंडेक्सर प्रकार के लिए इस्तेमाल किया जा सकता है, इसलिए हम इनका समकक्ष हो सकते हैं (जैसा कि मुझे पता है कि वे इस समय नहीं हैं):

interface A1 {
    a: number;
    b: boolean;
}
interface A2 {
    [index: "a"]: number;
    [index: "b"]: boolean;
}

इसलिए, हम तब लिख सकते थे

declare function pluck<P, T extends { [indexer: P]: R; }, R>(obj: T, p: P): R;

कुछ बातों पर विचार करने की आवश्यकता है:

• कैसे इंगित करें कि P केवल एक स्ट्रिंग शाब्दिक हो सकता है?
  
  
  
  • चूंकि स्ट्रिंग तकनीकी रूप से सभी स्ट्रिंग शाब्दिक रूप से फैली हुई है, P extends string बहुत विचारधारा नहीं होगी
  
  
  • अन्य चर्चा P super string बाधा (# 7265, # 6613, https://github.com/Microsoft/TypeScript/issues/6613#issuecomment-175314703) की अनुमति देने के बारे में हो रही है
  
  
  • क्या हमें वास्तव में इस बारे में परवाह करने की आवश्यकता है? हम इंडेक्सर प्रकार के लिए जो कुछ भी स्वीकार्य है उसका उपयोग कर सकते हैं - यदि T में string s या number s का अनुक्रमणिका है। तब P string या number ।
  
  
• वर्तमान में, यदि हम दूसरे तर्क के रूप में "something" पास करते हैं, तो यह string प्रकार का होगा
  
  
  
  • स्ट्रिंग शाब्दिक # 10195 उत्तर हो सकता है
  
  
  • या टीएस यह अनुमान लगा सकता है कि स्वीकार्य होने पर अधिक विशिष्ट P का उपयोग किया जाना चाहिए
  
  
• इंडेक्सर्स स्पष्ट रूप से वैकल्पिक { [i: string]: number /* | undefined */ }
  
  
  
  • अगर हम वास्तव में डोमेन में undefined नहीं करना चाहते हैं तो कैसे लागू करें?
  
  
• P , T और R के बीच सभी संबंधों के लिए स्वचालित प्रकार का निष्कर्ष यह काम करने के लिए एक कुंजी है

@weswigham @mhegazy , और मैं हाल ही में इस पर चर्चा कर रहा हूं; हम आपको हमारे द्वारा चलाए जा रहे किसी भी घटनाक्रम के बारे में बताएंगे, और यह ध्यान में रखें कि यह केवल विचार का प्रोटोटाइप है।

वर्तमान विचार:

• एक keysof Foo ऑपरेटर स्ट्रिंग शाब्दिक प्रकारों के रूप में Foo से संपत्ति के नामों की यूनियन को हथियाने के लिए।
• Foo[K] प्रकार जो निर्दिष्ट करता है कि कुछ प्रकार K लिए एक स्ट्रिंग शाब्दिक प्रकार या स्ट्रिंग शाब्दिक प्रकारों का मिलन है।

इन बुनियादी ब्लॉकों से, यदि आपको उपयुक्त प्रकार के रूप में एक स्ट्रिंग शाब्दिक अनुमान लगाने की आवश्यकता है, तो आप लिख सकते हैं

function foo<T, K extends keysof T>(obj: T, key: K): T[K] {
    // ...
}

यहां, K keysof T का एक उपप्रकार होगा जिसका अर्थ है कि यह एक स्ट्रिंग शाब्दिक प्रकार या स्ट्रिंग शाब्दिक प्रकारों का एक संघ है। आपके द्वारा key पैरामीटर के लिए जो कुछ भी पास किया जाता है, उसे शाब्दिक रूप से उस शाब्दिक / शाब्दिक संघ द्वारा टाइप किया जाना चाहिए, और एक सिंगलटन स्ट्रिंग शाब्दिक प्रकार के रूप में अनुमान लगाया जाना चाहिए।

उदाहरण के लिए

interface HelloWorld { hello: any; world: any; }

function foo<K extends keysof HelloWorld>(key: K): K {
    return key;
}

// 'x' has type '"hello"'
let x = foo("hello");

सबसे बड़ा मुद्दा यह है कि keysof अक्सर इसके संचालन में "देरी" करने की आवश्यकता होती है। यह बहुत उत्सुक है कि यह एक प्रकार का मूल्यांकन कैसे करता है, जो टाइप पैरामीटर के लिए एक समस्या है जैसे कि मैंने जो पहला उदाहरण पोस्ट किया था (यानी जिस मामले को हम वास्तव में हल करना चाहते हैं वह वास्तव में कठिन हिस्सा है: मुस्कान :)।

आशा है कि आप सभी को एक अद्यतन देता है।

@DanielRosenwasser अपडेट के लिए धन्यवाद। मैंने अभी देखा @weswigham ने keysof ऑपरेटर के बारे में PR सबमिट किया, इसलिए शायद इस मुद्दे को आप लोगों को सौंपना बेहतर है।

मुझे आश्चर्य है कि आपने मूल प्रस्तावित सिंटैक्स से प्रस्थान करने का निर्णय क्यों लिया?

function get(prop: string): T[prop];

और keysof परिचय

T[prop] कम सामान्य है, और इसके लिए बहुत सारे इंटरलेक्टेड मशीनरी की आवश्यकता होती है। एक बड़ा सवाल यहाँ कैसे आप भी का शाब्दिक सामग्री से संबंधित होता है prop की संपत्ति के नाम करने के लिए T । मुझे भी पूरा यकीन नहीं है कि आप क्या करेंगे। क्या आप एक अंतर्निहित प्रकार पैरामीटर जोड़ेंगे? क्या आपको प्रासंगिक टाइपिंग व्यवहार बदलने की आवश्यकता होगी? क्या आपको हस्ताक्षरों में कुछ विशेष जोड़ना होगा?

जवाब शायद उन सभी चीजों के लिए हाँ है। मैंने हमें उससे दूर कर दिया क्योंकि मेरी आंत ने मुझे बताया कि दो सरल, अलग अवधारणाओं का उपयोग करना और वहां से निर्माण करना बेहतर था। नकारात्मक पक्ष कुछ मामलों में थोड़ा अधिक बॉयलरप्लेट है।

यदि नए पुस्तकालय हैं जो इन प्रकार के पैटर्न का उपयोग करते हैं और यह कि बॉयलरप्लेट उनके लिए टाइपस्क्रिप्ट में लिखना कठिन बना रहा है, तो शायद हमें उस पर विचार करना चाहिए। लेकिन कुल मिलाकर यह सुविधा मुख्य रूप से पुस्तकालय उपभोक्ताओं की सेवा के लिए है, क्योंकि उपयोग-स्थल वह है जहां आपको वैसे भी लाभ मिलता है।

@DanielRosenwasser बमुश्किल खरगोश छेद नीचे चला गया। मुझे अभी भी @SaschaNaz विचार को लागू करने में कोई समस्या नहीं है? मुझे लगता है कि इस मामले में keysof बेमानी है। T[p] पहले से ही संबंधित है कि p को T के शाब्दिक रंगमंच की सामग्री में से एक होना चाहिए।

मेरा खुरदरा कार्यान्वयन सोचा था कि PropertyReferencedType नामक एक नए प्रकार का परिचय दिया जाए।

export interface PropertyReferencedType extends Type {
        property: Symbol;
        targetType: ObjectType;
}

जब एक समारोह की वापसी प्रकार की है कि के साथ घोषित में प्रवेश PropertyReferencedType या एक समारोह में प्रवेश कि संदर्भ PropertyReferencedType : एक प्रकार की एक ElementAccessExpression एक संपत्ति के साथ संवर्धित किया जाएगा कि संदर्भ पहुंच संपत्ति का प्रतीक।

export interface Type {
        flags: TypeFlags;                // Flags
        /* <strong i="20">@internal</strong> */ id: number;      // Unique ID
        //...
        referencedProperty: Symbol; // referenced property
}

तो एक संदर्भित संपत्ति प्रतीक के साथ एक प्रकार PropertyReferencedType । जाँच के दौरान, referencedProperty को p T[p] अनुरूप होना चाहिए। इसके अलावा मूल तत्व अभिव्यक्ति का प्रकार T लिए असाइन किया जाना चाहिए। और चीजों को आसान बनाने के लिए p को भी const होना चाहिए।

नया प्रकार PropertyReferencedType केवल "अनसुलझे प्रकार" के रूप में फ़ंक्शन के अंदर मौजूद है। कॉल साइट पर किसी को p प्रकार के साथ हल करना होगा:

interface A { a: string }
declare function getProp(p: string): A[p]
getProp('a'); // string

PropertyReferencedType केवल फ़ंक्शन असाइनमेंट के माध्यम से प्रचारित करते हैं और कॉल एक्सप्रेशन के माध्यम से प्रचार नहीं कर सकते, क्योंकि PropertyReferencedType केवल एक अस्थायी प्रकार है जो रिटर्न प्रकार T[p] साथ किसी फ़ंक्शन के शरीर की जांच करने में मदद करता है।

यदि आप keysof और T[K] प्रकार के ऑपरेटरों का परिचय देते हैं, तो क्या इसका मतलब है कि हम उनका इस तरह उपयोग कर सकते हैं:

interface A {
  a: number;
  b: string;
}
type AK = keysof A; // "a" | "b"
type AV = A[AK]; // number | string ?
type AA = A["a"]; // number ?
type AB = A["b"]; // string ?
type AC = A["c"]; // error?
type AN = A[number]; // error?

type X1 = keysof { [index: string]: number; }; // string ?
type X2 = keysof { [index: string]: number; [index: number]: string; }; // string | number ?

@DanielRosenwasser आपके उदाहरण का मेरे साथ समान अर्थ नहीं होगा

function foo<T, K extends keysof T>(obj: T, key: K): T[K] {
    // ...
}
// same as ?
function foo<K, V, T extends { [k: K]: V; }>(obj: T, key: K): V {
    // ...
}

मैं यह नहीं देख रहा हूं कि अंडरस्कोर के _.pick के लिए हस्ताक्षर कैसे लिखे जाएंगे:

o2 = _.pick(o1, 'p1', 'p2');

pick(Object, ...props: String[]) : WHAT GOES HERE;

@rtm मैंने इसे https://github.com/Microsoft/TypeScript/issues/1295#issuecomment -234724380 में सुझाया है। यद्यपि यह एक नया मुद्दा खोलने के लिए बेहतर हो सकता है, भले ही यह इस एक से संबंधित हो।

कार्यान्वयन अब # 11929 में उपलब्ध है।