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

Afaics, आपका चतुर "हैक" एक कारखाने को उदारतापूर्वक संदर्भित करने में सक्षम बनाता है (जैसे lift ), लेकिन विशेष प्रकार के फ़न के लिए जेनेरिक फ़ैक्टरी के प्रत्येक टंकण (अपडेट) के लिए मॉड्यूल ऑग्मेंटेशन के अतिरिक्त बॉयलरप्लेट की आवश्यकता होती है , जैसे Option । क्या जेनेरिक फैक्ट्री के हर जेनेरिक उपयोग के लिए बॉयलरप्लेट की आवश्यकता नहीं होगी, जैसे जेनेरिक sort उदाहरण @keean और मैंने चर्चा की? संभवतः अन्य कोने के मामले भी खोजे जा सकते हैं?

क्या कोटलिन ने आपके विचार की नकल की या इसके विपरीत? (उस लिंक पर कुछ अतिरिक्त आलोचनाएं लेकिन मुझे नहीं पता कि क्या वे टाइपस्क्रिप्ट केस पर लागू होते हैं)

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

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

_{नोट मैं यह भी पता लगाने के लिए सीलोन में देख रहा हूँ कि EMCAScript संकलन लक्ष्य में उनके निवेश का स्तर क्या होगा। (मुझे और अधिक अध्ययन की जरूरत है)।}

मैं भी सिर्फ इस सीमा से काट दिया गया है। मैं निम्न उदाहरण में I स्वचालित रूप से अनुमान लगाना चाहूंगा:

interface IdType<T> {
  id: T;
}

interface User {
  id: number;
  name: string;
}

function doStuff<T extends IdType<I>>() {
  const recs = new Map<I, T>();
  return {
    upsert(rec: T) {
      recs.set(rec.id, rec);
    },
    find(id: I) {
      return recs.get(id);
    },
  };
}

(function () {
  const stuff = doStuff<User>();
  stuff.upsert({id: 2, name: "greg"});
  console.log(stuff.find(2));
})();

जहां तक ​​मैं बता सकता हूं, इसके लिए एक उच्च-प्रकार के प्रकार की आवश्यकता होती है या कोई डुप्लिकेट जेनेरिक पैरामीटर निर्दिष्ट करता है (जैसे doStuff<User, number>() ) जो बेमानी लगता है।

मैं हाल ही में इस सीमा के साथ मारा गया हूँ।

मैं वादों के लिए एक

पुस्तकालय की एक केंद्रीय विशेषता यह है कि यह उसी प्रकार का वादा करता है जो आप इसके अंदर रखते हैं। इसलिए यदि आप एक ब्लूबर्ड वादा का उपयोग कर रहे हैं और एक फ़ंक्शन को कॉल करते हैं, तो यह सभी अतिरिक्त कार्यक्षमता प्रदान करने के साथ ब्लूबर्ड वादा लौटाएगा।

मैं इस प्रकार की प्रणाली में सांकेतिक शब्दों में बदलना चाहता था, लेकिन मुझे जल्दी से एहसास हुआ कि इसके लिए P * -> * जैसे P<T> extends Promise<T> ।

यहाँ इस तरह के एक समारोह का एक उदाहरण है:

/**
* Returns a promise that waits for `this` to finish for an amount of time depending on the type of `deadline`.
* If `this` does not finish on time, `onTimeout` will be called. The returned promise will then behave like the promise returned by `onTimeout`.
* If `onTimeout` is not provided, the returned promise will reject with an Error.
*
* Note that any code already waiting on `this` to finish will still be waiting. The timeout only affects the returned promise.
* <strong i="14">@param</strong> deadline If a number, the time to wait in milliseconds. If a date, the date to wait for.
* <strong i="15">@param</strong> {() => Promise<*>} onTimeout Called to produce an alternative promise once `this` expires. Can be an async function.
*/
timeout(deadline : number | Date, onTimeout ?: () => PromiseLike<T>) : this;

उपर्युक्त स्थिति में मैं this के बजाय hacky के उपयोग से उच्च प्रकार की आवश्यकता से बचने में सक्षम था।

हालाँकि, निम्न मामले को हल नहीं किया जा सकता है:

/**
* Returns a promise that will await `this` and all the promises in `others` to resolve and yield their results in an array.
* If a promise rejects, the returned promise will rejection with the reason of the first rejection.
* <strong i="21">@param</strong> {Promise<*>} others The other promises that must be resolved with this one.
* <strong i="22">@returns</strong> {Promise<*[]>} The return type is meant to be `Self<T[]>`, where `Self` is the promise type.
*/
and(...others : PromiseLike<T>[]) : ExtendedPromise<T[]>;

क्योंकि कोई हैक नहीं है जो मुझे this<T[]> या कुछ करने की अनुमति देता है।

दस्तावेज़ में मेरी छोटी माफी पर ध्यान दें।

जैसा कि मुझे लगता है कि यह विशेषता उपयोगी होगी (जैसा कि मैंने प्रस्ताव को सही बताया है) मान लिया, जैसा कि उपरोक्त संदर्भ से संकेत मिलता है।

प्रश्न में पैकेज में, एक अनपेक्षित जेनेरिक वर्ग या फ़ंक्शन का एक प्रकार के रूप में उपयोग करना आवश्यक है, क्योंकि सामान्य प्रकार आमतौर पर उपयोगकर्ता बनाए जाते हैं।

मेरे परिदृश्य के प्रस्ताव को लागू करते हुए, मुझे विश्वास है कि यह कुछ ऐसा दिखाई देगा:

import { Component, FunctionalComponent } from 'preact';

interface IAsyncRouteProps {
    component?: Component<~,~> | FunctionalComponent<~>;
    getComponent?: (
        this: AsyncRoute,
        url: string,
        callback: (component: Component<~,~> | FunctionalComponent<~>) => void,
        props: any
    ) => Promise<any> | void;
    loading?: () => JSX.Element;
}

export default class AsyncRoute extends Component<IAsyncRouteProps, {}> {
    public render(): JSX.Element | null;
}

यह देखते हुए कि मेरे कार्यान्वयन में सामान्य प्रकार के संदर्भ देने का कोई तरीका नहीं है, मुझे यकीन है कि मैंने कुछ याद किया है।

@ Silic0nS0ldier वास्तव में उस मामले को अभी हल किया जा सकता है। आप इस तरह एक संरचनात्मक निर्माता प्रकार का उपयोग करें:

type ComponentConstructor = {
    new<A, B>() : Component<A, B>;
}

और फिर कहते हैं, component ?: ComponentConstructor ।

और भी आम तौर पर, आप वास्तव में एक सामान्य प्रकार का कार्य कर सकते हैं:

let f : <T>(x : T) => T

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

यदि आप एक विशिष्ट TComponent<T, S> का संदर्भ देने की आवश्यकता है, तो यहां चर्चा की गई सीमा दिखाई देगी। लेकिन आपके मामले में यह अनावश्यक लगता है।

आप typeof Component का भी उपयोग कर सकते हैं जो आपको Component के कंस्ट्रक्टर का प्रकार प्राप्त करेगा लेकिन इससे उपप्रकारों के साथ विभिन्न मुद्दे पैदा होंगे।

@GregRos आपका प्रस्तावित समाधान आशाजनक लग रहा था (यह परिभाषा फ़ाइल के अंदर के प्रकारों को स्वीकार करता है), लेकिन संगत प्रकारों को अस्वीकार किया जा रहा है। https://gist.github.com/Silic0nS0ldier/3c379367b5e6b1abd76e4a41d1be8217

@ Silic0nS0ldier जीस्ट पर मेरी टिप्पणी देखें।

@chrisdavies क्या यह काम करता है?

interface IdType<T> {
    id: T;
}

interface User {
    id: number;
    name: string;
}

function doStuff<T extends IdType<any>>() {
    type I = T['id']; // <==== Infer I
    const recs = new Map<I, T>();
    return {
        upsert(rec: T) {
            recs.set(rec.id, rec);
        },
        find(id: I) {
            return recs.get(id);
        },
    };
}

(function() {
    const stuff = doStuff<User>();
    stuff.upsert({ id: 2, name: "greg" });
    console.log(stuff.find(2));
})();

@ जैक-विलियम्स हां। जो मेरे परिदृश्य के लिए काम करता है। मुझे वह उदाहरण डॉक्स में नहीं मिला था (हालाँकि मैं लापता चीजों के लिए जाना जाता हूँ!)। धन्यवाद!

मैं इस सुविधा के बारे में बहुत सोच रहा हूं, और मुझे इस मामले पर कुछ विचार हैं, कुछ प्रकार के विनिर्देश की ओर झुकाव है, लेकिन मैं अभी भी बहुत सारे मुद्दे देख सकता हूं। मेरे सुझाव अभी तक प्रस्तावित किए गए से थोड़ा अलग हैं।

सबसे पहले, मुझे लगता है कि टाइप कंस्ट्रक्टर्स के लिए किसी भी तरह के T<*, *> सिंटैक्स का उपयोग करना एक बुरा विचार है क्योंकि यह टाइप कंस्ट्रक्टर की जटिलता के साथ अच्छी तरह से स्केल नहीं करता है। मुझे यकीन नहीं है कि जब भी संदर्भित किया जाता है, तब भी इस प्रकार के कंस्ट्रक्टर के प्रकार को निर्दिष्ट करने में एक बिंदु होता है, क्योंकि हम फ़ंक्शन के लिए ऐसा नहीं करते हैं, यहां तक ​​कि प्रकार के मापदंडों के लिए भी।

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

मुझे लगता है कि हमें कुछ प्रकार के उपसर्ग या पोस्टफ़िक्स का उपयोग करना चाहिए ताकि उन्हें अन्य प्रकारों से अलग किया जा सके, मुख्य रूप से उपयोगकर्ताओं को उन प्रकार के कंस्ट्रक्टर्स से जुड़े असंगत त्रुटि संदेशों से बचाने के लिए जब वे केवल नियमित कोड लिखना चाहते हैं। मुझे इस तरह का दिखना पसंद है: ~Type, ^Type, &Type या ऐसा कुछ।

उदाहरण के लिए, एक फ़ंक्शन हस्ताक्षर हो सकता है:

interface List<T> {
    push(x : T);
}

function mapList<~L extends ~List, A, B>(list : L<A>, f : (x : A) => B) : L<B>;

(मैं उद्देश्य पर निर्मित प्रकारों के लिए ~ उपसर्ग का उपयोग नहीं कर रहा हूं)

extends का उपयोग करके मैंने मूल रूप से दो बातें कही हैं:

** 1। यदि यह आवश्यक है: ~L एक प्रकार का कंस्ट्रक्टर है, जिसका ~List के समान प्रकार है, अर्थात * -> * (या शायद * => * , => बाद से

1. ~L ~List का एक उपप्रकार है। **

का उपयोग करते हुए extends जैसी चीज़ों सहित मनमाने ढंग से जटिल प्रकार कंस्ट्रक्टर्स, करने के लिए एक प्रकार निर्माता तराजू की तरह निरूपित करने के लिए ((* => *) => (* => *)) => * ।

आप वास्तव में उस प्रकार को पहचानकर्ता में नहीं देख सकते हैं, लेकिन मुझे नहीं लगता कि आपको इसकी आवश्यकता है। मुझे यकीन नहीं है कि टाइप कंस्ट्रक्टर्स के बीच एक उपप्रकार संबंध को प्रकारों को संरक्षित करना है, इसलिए (1) आवश्यक नहीं हो सकता है।

अपूर्ण प्रकार का निर्माण नहीं

मुझे लगता है कि हमें अपूर्ण प्रकार के निर्माण का समर्थन नहीं करना चाहिए। वह कुछ इस तरह है:

(*, *) => * => *

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

प्रकार के निर्माताओं को परिभाषित करने का संरचनात्मक तरीका

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

~<A, B> { 
    a : A,
    b : B
}

प्रकार पैरामीटर के साथ फ़ंक्शन प्रकारों के लिए मौजूदा सिंटैक्स के समान है:

<A, B>() => { a : A, b : B};

इसे प्राप्त करने के लिए दोनों को संयुक्त भी किया जा सकता है:

~<A><B, C> => [A, B, C]

जो कि जेनेरिक फंक्शन टाइप का निर्माण करने वाला टाइप कंस्ट्रक्टर है।

लाभ यह है कि इन संरचनात्मक प्रकारों का उपयोग अन्य संरचनात्मक प्रकारों को निर्दिष्ट करते समय, प्रकार की बाधाओं को निर्दिष्ट करते समय, और इसी तरह किया जा सकता है। कभी-कभी इसका मतलब है कि वे संदर्भ स्थानीय प्रतीकों का उपयोग कर सकते हैं जिन्हें कहीं और से संदर्भित नहीं किया जा सकता है।

यहाँ एक उदाहरण है:

type List<A, B> = ...;

type AdvancedType<~L extends ~<A>List<A, B>, B> = ...;

उपरोक्त उदाहरण में, संरचनात्मक प्रकार के निर्माता ~<A>List<A, B> प्रकार के पैरामीटर B संदर्भ देते हैं। इस संबंध को किसी अन्य तरीके से निर्दिष्ट करना संभव नहीं है, कम से कम आंशिक रूप से निर्मित List<A, *> एन्कोडिंग के बिना। इसके अन्य उदाहरण भी हैं।

उपप्रकार संबंध

उपप्रकार संबंध समझ में आता है, लेकिन मैं इसे चित्रित करने की कोशिश कर रहा हूं।

मेरा पहला विचार निम्नलिखित था। ~A लिए ~B का उपप्रकार होना चाहिए:

1. (a) उनके पास एक ही तरह का होना चाहिए (arity के मामले में, अड़चन नहीं)।
2. (b) प्रत्येक कानूनी परिमाण के लिए T₁, T₂, ... ~A , A<T₁, T₂, ...> B<T₁, T₂, ...> का उपप्रकार होना चाहिए।

हालाँकि, इसकी कई सीमाएँ हैं।

1. वर्ग MySpecialPromise के वादे PromiseLike {} इस मामले में, ~MySpecialPromise ~PromiseLike का उपप्रकार नहीं है क्योंकि उनके पास विभिन्न प्रकार हैं।

2. वर्ग MyArrayPromiseवादे PromiseLike

   इस मामले में उपप्रकार संबंध संरक्षित नहीं है।

(B) का अधिक सामान्यीकृत संस्करण निम्नलिखित है:

(b) प्रत्येक कानूनी मानकीकरण के लिए T₁, T₂, ... ~A , वहाँ एक पैरामीटर S₁, S₂, ... ~B कि A<T₁, T₂, ...> का एक उपप्रकार है B<S₁, S₂, ...> ।

दूसरे शब्दों में, उपरोक्त गुणों के साथ एक मैपिंग F (T₂, T ..., ...) = S₂, S₂, ... है। इस मैपिंग का उपयोग पैरामीटराइज्ड B<...> पैरामीटर किए गए A<...> निर्माण के लिए किया जाना चाहिए। यह हमें ऐसा करने की अनुमति दे सकता है, भले ही टाइप कंस्ट्रक्टर अलग-अलग प्रकार के हों।

इस संबंध में समस्या यह है कि मुझे यकीन नहीं है कि सही मैपिंग कैसे संभव होगी। नाममात्र टाइपिंग वाली भाषाओं में, हर कथन:

A<...> extends B<...>

~A के प्रकार के मापदंडों और ~B के प्रकार के मापदंडों के बीच एक मैपिंग को परिभाषित करता है, इसलिए इस तरह से मैपिंग को पुनर्प्राप्त किया जा सकता है। हालाँकि, टाइपस्क्रिप्ट के संरचनात्मक टाइपिंग के संदर्भ में, हम इस प्रकार के स्पष्ट कथनों पर भरोसा नहीं कर सकते।

एक तरीका केवल सही प्रकार के मुखबिर के साथ प्रकारों के लिए प्रकार के निर्माणकर्ताओं का समर्थन करना है, जैसे implements खंड या कुछ प्रकार के सार प्रकार के सदस्य जैसे Scala। मुझे यकीन नहीं है कि यह आगे का रास्ता है, हालांकि।

@GregRos - दिलचस्प नोट्स! कुछ प्रश्न।

ठोस प्रकार से आपका क्या मतलब है? क्या आपका मतलब किसी तरह के * , या बिना किसी प्रकार के पैरामीटर के साथ एक प्रकार है?

अपूर्ण प्रकार का निर्माण नहीं
मुझे लगता है कि हमें अपूर्ण प्रकार के निर्माण का समर्थन नहीं करना चाहिए। वह कुछ इस तरह है:
(*, *) => * => * *

अपूर्ण प्रकारों के निर्माण से आपका क्या अभिप्राय है? क्या आपका मतलब है कि हर एप्लिकेशन जैसे L<A> तरह * । उदाहरण के लिए, जोड़ीदार निर्माता आपके उदाहरण में विशेष है, क्या (* => *) => * => * ठीक होगा?

प्रकार के निर्माताओं को परिभाषित करने का संरचनात्मक तरीका

~<A, B> { 
    a : A,
    b : B
}

inferface TyCon<A, B> { 
    a : A,
    b : B
}

क्या ये उदाहरण पहले अनाम होने के अलावा अलग हैं?

उपप्रकार संबंध

~A और ~B प्रकारों को संदर्भित नहीं करते हैं तो क्या यह उनके लिए एक उपसर्ग संबंध है? आपको वास्तव में यह जांचने की आवश्यकता है कि एक निर्माता दूसरे का 'उपप्रकार' है? क्या कंस्ट्रक्टरों के लागू होने तक इंतजार करना और परिणामी प्रकारों की जांच करना संभव है?

@ जैक-विलियम्स प्रतिक्रिया के लिए धन्यवाद!

अपूर्ण प्रकारों के निर्माण से आपका क्या अभिप्राय है? क्या आपका मतलब है कि हर एप्लीकेशन जैसे L<A> तरह * होनी चाहिए। उदाहरण के लिए, जोड़ीदार निर्माता आपके उदाहरण में विशेष है, क्या (* => *) => * => * ठीक होगा?

हाँ बिल्कुल। हर एप्लीकेशन जैसे L<A> तरह * होना चाहिए। मुझे यकीन नहीं है कि मैं उस पर कैसे बेची गई हूं।

क्या ये उदाहरण पहले अनाम होने के अलावा अलग हैं?

पहला एक प्रकार की अभिव्यक्ति है, जबकि दूसरा एक घोषणा है। वे ज्यादातर मामलों में समान हैं, उसी तरह से कि ये प्रकार ज्यादातर मामलों में समान हैं:

{
     a : number;
     b : string;
}

interface Blah {
    a : number;
    b : string;
}

वाक्य-विन्यास में कई प्रेरणाएँ हैं:

1. टाइपस्क्रिप्ट में बाकी सब की तरह, यह टाइप कंस्ट्रक्टर्स को संरचनात्मक रूप से और गुमनाम रूप से निर्दिष्ट करने देता है।
2. एक प्रकार की अभिव्यक्ति (जैसे कि ऊपर बताई गई अनाम वस्तु) कुछ संदर्भों में उपयोग की जा सकती है, जहां घोषणा विवरण का उपयोग नहीं किया जा सकता है, जैसे कि कार्यों के प्रकार में हस्ताक्षर। यह उन्हें स्थानीय पहचानकर्ताओं को पकड़ने और उन चीजों को व्यक्त करने की अनुमति देता है जिन्हें अन्यथा व्यक्त नहीं किया जा सकता है।

~A और ~B प्रकारों को संदर्भित नहीं करते हैं तो क्या यह उनके लिए एक उपप्रकार संबंध है? आपको वास्तव में यह जांचने की आवश्यकता है कि एक निर्माता दूसरे का 'उपप्रकार' है? क्या कंस्ट्रक्टरों के लागू होने तक इंतजार करना और परिणामी प्रकारों की जांच करना संभव है?

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

एक उपप्रकार संबंध से, मेरा मतलब है कि कुछ प्रकार के "अनुरूपता" संबंध हैं जिनका उपयोग प्रकार के निर्माणकर्ताओं को विवश करने के लिए किया जा सकता है। उदाहरण के लिए, यदि मैं एक फ़ंक्शन लिखना चाहता हूं जो सभी प्रकार के वादों पर काम करता है, जैसे Promise<T> , Bluebird<T> , और इसी तरह, मुझे टीसी मापदंडों को कसने की क्षमता की आवश्यकता है इंटरफ़ेस PromiseLike<T> किसी तरह से।

इस प्रकार के संबंध के लिए प्राकृतिक शब्द एक उपप्रकार संबंध है।

आइए एक उदाहरण देखें। यह मानकर कि हमने टाइप कंस्ट्रक्टर्स के बीच एक उपप्रकार संबंध बनाया है, मैं इस तरह से एक फ़ंक्शन लिख सकता हूं:

function mapPromise<~P extends ~PromiseLike, A, B>(promise : P<A>, func : (x : A) => B) : P<B>;

और बाधा ~P extends ~PromiseLike की गारंटी है यह एक ऐसा कार्य है जो वादों पर काम करता है, और केवल वादे करता है। बाधा यह भी गारंटी देगी कि फ़ंक्शन के शरीर के अंदर promise PromiseLike<A> लागू करने के लिए जाने जाएंगे, और इसी तरह। आखिरकार, फ़ंक्शन के शरीर में टाइपस्क्रिप्ट द्वारा मान्यता प्राप्त सदस्य ठीक वही हैं जो बाधाओं के माध्यम से मौजूद साबित हो सकते हैं।

उसी तरह Promise<T> extends PromiseLike<T> , क्योंकि वे संरचनात्मक रूप से संगत हैं और एक दूसरे के साथ बदले जा सकते हैं, ~Promise extends ~PromiseLike क्योंकि वे संरचनात्मक रूप से संगत प्रकार का निर्माण करते हैं और इस प्रकार एक दूसरे के साथ प्रतिस्थापित किया जा सकता है।

सबटाइप समस्या के साथ समस्या को रेखांकित करने के लिए, एक बार फिर से विचार करें:

interface MyPromise<T> extends Promise<T[]> {}

क्या हम ~MyPromise से अधिक उसी तरह से अमूर्त कर सकते हैं जिस तरह से हम ~Promise से अधिक का अमूर्त करते हैं? हम उनके बीच के रिश्ते को कैसे पकड़ते हैं?

मैंने पहले जिस मैपिंग की बात की थी, वह है मैपिंग, जिसे ~MyPromise का एक पैरामीटर दिया गया है, ~Promise पैरामीटर का उत्पादन करेगा ताकि ~MyPromise द्वारा निर्मित प्रकार एक उपप्रकार हो। ~Promise द्वारा निर्मित।

इस मामले में, मैपिंग इस तरह है:

T => T[]

@GregRos

इस मामले में, ~MySpecialPromise ~PromiseLike का उपप्रकार नहीं है क्योंकि उनके पास विभिन्न प्रकार हैं।

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

आपके उदाहरण में, MySpecialPromise को MySpecialPromise<TSpecial, TPromiseVal> रूप में परिभाषित किया जाएगा, और ~MySpecialPromise<SpecialType> का समान ~Promise ।

@GregRos

एक उपप्रकार संबंध से, मेरा मतलब है कि कुछ प्रकार के "अनुरूपता" संबंध हैं जिनका उपयोग प्रकार के निर्माणकर्ताओं को विवश करने के लिए किया जा सकता है। उदाहरण के लिए, यदि मैं एक फ़ंक्शन लिखना चाहता हूं जो सभी प्रकार के वादों पर काम करता है, जैसे कि वादा, ब्लूबर्ड, और इसी तरह, मुझे इंटरफ़ेस प्रॉमिसलाइक के साथ टीसी मापदंडों को कसने की क्षमता की आवश्यकता हैकिसी तरह।
function mapPromise<~P extends ~PromiseLike, A, B>(promise : P<A>, func : (x : A) => B) : P<B> ;

मुझे लगता है कि जब यह प्रकार्य-जाँच की बात आती है, तो आप BlueBird<T> और PromiseLike<T> चुने हुए T लिए कोशिश करेंगे और एकजुट होंगे, ये सिर्फ ठोस प्रकार हैं और उप-योग के अंतर्गत आते हैं। मैं नहीं देखता कि आपको निर्माणकर्ताओं के लिए ~BlueBird और ~PromiseLike लिए एक विशेष संबंध की आवश्यकता क्यों होगी।

मुझे लगता है कि यह इस तरह से कुछ में इस्तेमाल किया जाएगा?

let x: <P extends ~PromiseLike>(input : P<A>, func : (x : A) => B) : P<B>;
let y: <P extends ~BlueBird>(input : P<A>, func : (x : A) => B) : P<B>;
x = y;

यहां आप यह जांचना चाहते हैं कि y की बाधाएं x की बाधाएं हैं, लेकिन क्या टाइपस्क्रिप्ट में पहले से ही यह जांचने की मशीनरी नहीं है कि BlueBird<T> PromiseLike<T> उपयोग किया जा सकता है?

@ जैक-विलियम्स यह नीचे आता है कि आप निम्नलिखित बाधा कैसे निर्दिष्ट करते हैं:

~ P एक प्रकार का कंस्ट्रक्टर है जो A , P<A> के लिए PromiseLike<A> का उप-प्रकार है।

आप किस तरह के वाक्यविन्यास का उपयोग करेंगे? आप किस तरह की अवधारणा का उपयोग करेंगे? आप कुछ इस तरह लिख सकते हैं:

function mapPromise<~P, A, B where P<A> extends PromiseLike<A>>

लेकिन इस वाक्य-विन्यास की सीमाएँ हैं। उदाहरण के लिए, आप इस वर्ग को बिल्कुल भी व्यक्त नहीं कर सकते हैं, क्योंकि हम उस बिंदु पर P<A> निर्माण नहीं कर सकते हैं, जहां इसे बाधित करने के लिए घोषित किया गया है:

class PromiseCreator<~P extends ~PromiseLike> {
    create<A>() : P<A>;
}

लेकिन मुझे लगता है कि आप इसके लिए अस्तित्व के प्रकारों का उपयोग कर सकते हैं, जैसे:

//Here A is not a captured type parameter
//It's an existential type we introduce to constrain ~P
class PromiseCreator<~P with some A where P<A> extends PromiseLike<A>> {
    create<A>() : P<A>;
}

फिर आप सभी प्रकार के निर्माणकर्ताओं को फ़ंक्शन या प्रकार के हस्ताक्षर के भीतर उनके निर्मित प्रकारों के माध्यम से विवश होने के लिए वैकल्पिक रूप से अस्तित्वगत प्रकारों का उपयोग कर सकते हैं।

अस्तित्वगत प्रकारों के साथ, यह एक मैपिंग के साथ उप-प्रकार के संबंध के रूप में एक ही अभिव्यंजक शक्ति होगी।

हालाँकि, इसके कई मुद्दे होंगे:

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

@GregRos

आप किस तरह के वाक्यविन्यास का उपयोग करेंगे? आप किस तरह की अवधारणा का उपयोग करेंगे?

_Personally_ मैं किसी विशेष वाक्यविन्यास का उपयोग नहीं करूंगा और केवल उपयोग करूंगा:

function mapPromise<P extends PromiseLike, A, B>(p: P<A>, f: (x: A) => B): P<B>

class PromiseCreator<P extends PromiseLike> {
    create<A>() : P<A>;
}

लेकिन यह सिर्फ मेरी राय है क्योंकि मैं number जैसी चीजों को एक नल-आर्य निर्माता के रूप में देखता हूं: इसलिए एक अंतर होने की आवश्यकता नहीं है।

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

आंशिक आवेदन उन मामलों में गोल हो सकते हैं, जहां उनके पास अलग-अलग धमनी है (मैं प्रकार के निर्माणकर्ताओं के लिए ऑटो-करी का मन नहीं बनाऊंगा ताकि आप सिर्फ MySpecialPromise<SpecialType> लिख सकें)।

उदाहरण में interface MyPromise<T> extends Promise<T[]> {} मुझे ईमानदार होना होगा और कहूँगा कि मुझे यकीन नहीं है कि यह इस मामले को संभालने की जटिलता के लायक है - मुझे लगता है कि यह इसके बिना एक उपयोगी पर्याप्त सुविधा होगी।

उस मामले को संभालना (मुझे लगता है) के बराबर है, कह रहा है: ~MyPromise extends ~(Promise . []) जहां [] सूची निर्माता है और . कंस्ट्रक्टर रचना है। ऐसा लगता है कि चीजें बहुत कठिन हो गई हैं क्योंकि अब यह केवल निर्माणकर्ताओं की संरचना का निरीक्षण करने के लिए पर्याप्त नहीं है, लेकिन आपको रचना के बारे में भी तर्क करना होगा!

@ जैक-विलियम्स यह डिफ़ॉल्ट प्रकार के मापदंडों के साथ काम नहीं करता है। अगर मैं P extends Foo लिखूं, जहाँ Foo का डिफ़ॉल्ट प्रकार पैरामीटर है, अर्थात type Foo<T = {}> = ... , तो P किस तरह का है?

मैं सिर्फ यह कहना चाहूंगा कि मैं उच्च-क्रम के प्रकारों को स्वीकार करता हूं (मुझे वास्तविक टाइपस्क्रिप्ट परियोजनाओं में परिस्थितियां मिली हैं जहां वे उपयोगी होंगे)।

हालाँकि मुझे नहीं लगता कि उन्हें करीने का समर्थन करना चाहिए। मुझे हास्केल बहुत पसंद है, लेकिन यह टाइपस्क्रिप्ट के साथ बिल्कुल फिट नहीं है।

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

Foo<number, _>  // equivalent to `type Foo1<A> = Foo<number, A>`

@ कैमरून-मार्टिन

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

P यह अपनी तरह का है, है ना? सवाल यह नहीं होगा कि क्या हम Foo ~Foo Foo रूप में व्यवहार करते हैं, या Foo<{}> : मेरा तर्क है कि पी के प्रकार द्वारा संचालित किया जाएगा। इसलिए यदि P एक प्रकार है जो हम डिफ़ॉल्ट पैरामीटर को बल देते हैं, और यदि P एक निर्माता * => * , तो हम Foo समान व्यवहार करते हैं।

@Pauan आपके सुझावों से सहमत है।

@ जैक-विलियम्स मैंने माना है कि उपमा की धारणा, जैसा कि मैंने पहले उल्लेख किया है:

मेरा पहला विचार निम्नलिखित था। ~A लिए ~B का उपप्रकार होना चाहिए:

1. (a) उनके पास एक ही तरह का होना चाहिए (arity के मामले में, अड़चन नहीं)।
2. (b) प्रत्येक कानूनी परिमाण के लिए T₁, T₂, ... ~A , A<T₁, T₂, ...> B<T₁, T₂, ...> का उपप्रकार होना चाहिए।

समस्या यह है कि यदि हम चीजों को यथासंभव सरल रखते हैं, तो हम एक उप-प्रकार के संबंध के साथ समाप्त हो जाएंगे जो विरोधाभासी है और भाषा में फिट नहीं होता है।

यदि MyPromise<T> extends Promise<T[]> का अर्थ है कि MyPromise<T> को कहीं भी Promise<T[]> योग्य होना है, लेकिन यह अब ऐसा नहीं होगा।

यदि आप के लिए इस्तेमाल किया as एक कन्वर्ट करने के लिए a : MyPromise<T> करने के लिए Promise<T[]> , आप upcasting होगा, लेकिन यह विडंबना होगा a अधिक आबंटित।

मौजूदा सामान्य बाधाओं, जो मौजूदा उपप्रकार संबंध का पालन करते हैं, का उपयोग एक समान प्रभाव प्राप्त करने और अजीब व्यवहार करने के लिए भी किया जा सकता है:

function id1<A, ~P extends ~PromiseLike>(p : P<A>) : P<A>;

function id2<A, P extends Promise<A[]>>(p : P) : P {
    //ERROR - P does not extend PromiseLike<A>
    return id1(p);
}

टाइपिंग एक साइड-इफ़ेक्ट के रूप में कम से कम आंशिक रूप से नाममात्र की हो जाएगी। ये प्रकार अचानक भिन्न होंगे, जहां वे वर्तमान में समान हैं:

type GenericNumber<T> = number;

type RegularNumber = number;

मुझे यह भी पता नहीं है कि जटिल संघ / चौराहे के प्रकारों के प्रकारों, विशुद्ध रूप से संरचनात्मक प्रकारों, सदस्य समझ के साथ प्रकारों और इस तरह के प्रभाव पर इसका क्या प्रभाव पड़ेगा।

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

टाइप कंस्ट्रक्टर्स के लिए कुछ विशेष संकेतन का उपयोग करने का सबसे बड़ा कारण यह है कि 99% डेवलपर्स को पता नहीं है कि एक प्रकार का कंस्ट्रक्टर क्या है और उनके बारे में त्रुटि संदेशों के साथ बमबारी नहीं करना चाहते हैं।

यह हास्केल से बहुत अलग है, जहां हर डेवलपर को कानून द्वारा श्रेणी सिद्धांत में एक उन्नत पाठ्यक्रम लेने की आवश्यकता होती है।

एक माध्यमिक कारण यह है कि कुछ मामलों में (जैसे कि डिफ़ॉल्ट पैरामीटर केस), सिंटैक्स या तो अस्पष्ट होगा या फिर किसी विशिष्ट प्रकार के कंस्ट्रक्टर पर सार करना संभव नहीं होगा।

संपादित करें: क्षमा करें @GregRos मैंने आपकी बाद की टिप्पणियां नहीं

टाइप कंस्ट्रक्टर्स पर उपप्रकार संबंध को मौजूदा का सम्मान करना होगा, इसका विरोध नहीं करना चाहिए।

अगर यह हासिल किया जा सकता है तो मैं सहमत हूं। मैंने अभी तक सभी विवरणों के आसपास अपना सिर नहीं डाला है और यह कितना आसान होगा।

एक माध्यमिक कारण यह है कि कुछ मामलों में (जैसे कि डिफ़ॉल्ट पैरामीटर केस), सिंटैक्स या तो अस्पष्ट होगा या फिर किसी विशिष्ट प्रकार के कंस्ट्रक्टर पर सार करना संभव नहीं होगा।

मुझे यकीन नहीं है कि मैं सहमत हूं कि यह अस्पष्ट होगा यदि आप हमेशा उच्चतम प्रकार के अवरोधों को मानते हैं जब तक कि आपको इसे कम करने की आवश्यकता न हो। यह दावा नहीं है और अगर अन्य उदाहरण हैं जो अन्यथा अन्यथा काफी हद तक सही हैं।

समस्या यह है कि यदि हम चीजों को यथासंभव सरल रखते हैं, तो हम एक उप-प्रकार के संबंध के साथ समाप्त हो जाएंगे जो विरोधाभासी है और भाषा में फिट नहीं होता है।

यह सच हो सकता है, मुझे लगता है कि मैं बस इस बात से चिंतित हूं कि क्या विकल्प वास्तव में लागू करना संभव है। क्या इसके लायक है, अगर अधिक जटिल समाधान काम करता है जो महान होगा!

उपप्रकार की अधिक सामान्य धारणा होने से पता चलता है कि मानचित्रण फ़ंक्शन का अस्तित्व सामान्य रूप से लागू करना कठिन लगता है। क्या मेरा निम्नलिखित उदाहरण आपके नियमों की सही व्याख्या कर रहा है?

(b) प्रत्येक कानूनी परिसीमन के लिए T, T of, ... ~ A का, वहां एक पैरामीटर S₁, S ~, ... का ~ B मौजूद है जैसे कि A

क्या X, F (A, B) = (संख्या, B) की मैपिंग दिए जाने पर, निम्न स्थिति में Y का एक उपप्रकार होगा।

type X = ~<A,B> = {x : B};
type Y = ~<A,B> = A extends number ? {x: B} : never;

हालांकि X<string,number> Y<string,number> का उपप्रकार नहीं होगा।

मुझे लगता है कि मैपिंग का _existence_ पर्याप्त होने पर मैं स्पष्ट नहीं हूं। यदि हम कार्य करने के लिए ~ ए और ~ बी लेते हैं, और हम यह दिखाना चाहते हैं कि ~ बी सन्निकट ~ ए, या ~ ए ~ बी का एक उपप्रकार है, तो यह दर्शाता है कि कुछ कार्य ~ सी है, जैसे कि ~ ए एक है सबटाइप (~ बी। ~ सी), पर्याप्त नहीं है जो मुझे लगता है (सी मैपर है)। मुझे _all_ मैपिंग के लिए मामला बनना है।

function id1<A, ~P extends ~PromiseLike>(p : P<A>) : P<A>;

function id2<A, P extends Promise<A[]>>(p : P) : P {
    //ERROR - P does not extend PromiseLike<A>
    return id1(p);
}

मैं इस उदाहरण का पालन नहीं करता हूं, क्या यहां त्रुटि नहीं होनी चाहिए? इनमें से मेरा पठन यह है कि id1 P फ़ंक्शन द्वारा निर्मित एक इनपुट होना चाहिए जो सभी _inputs_ के लिए PromiseLike देता है। जबकि id2 एक ऐसे मूल्य के बारे में बात कर रहे हैं जो Promise to A [] को लागू करने का एक उपप्रकार होना चाहिए। मुझे यकीन है कि अगर यह जानकारी के लिए आवश्यक ठीक करने के लिए संभव है नहीं कर रहा हूँ id1 , के प्रकार से id2 । मुझे लगता है कि मैं आपकी बात को गलत समझ सकता हूं।

ये प्रकार अचानक भिन्न होंगे, जहां वे वर्तमान में समान हैं

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

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

हाँ, आप सही हैं, और इसलिए आपके द्वारा प्रदान किया गया काउंटर-उदाहरण है। मुझे अन्य प्रति-उदाहरण मिले हैं। बिल्कुल काम नहीं करता है।

मैंने इस धागे और आपके बहुत सारे उत्तरों को फिर से पढ़ा है। मुझे लगता है कि आप बहुत सारी चीजों में सही हैं और मैं समस्या को गलत तरीके से देख रहा हूं। मेरा जो मतलब है, वह करूंगा।

मुझे यकीन नहीं है कि मैं सहमत हूं कि यह अस्पष्ट होगा यदि आप हमेशा उच्चतम प्रकार के अवरोधों को मानते हैं जब तक कि आपको इसे कम करने की आवश्यकता न हो। यह दावा नहीं है और अगर अन्य उदाहरण हैं जो अन्यथा अन्यथा काफी हद तक सही हैं।

यह या तो अस्पष्ट है या कुछ और संदर्भ के लिए असंभव हो जाता है। Foo के टाइप कंस्ट्रक्टर के ऊपर के उदाहरण की तरह संदर्भ के लिए असंभव हो जाता है क्योंकि यह स्वयं प्रकार से छिपा होता है। यदि आप ~Foo या उस मामले के लिए Foo<*> या ~<A>Foo<A> या कुछ और लिखते हैं जो अन्य सामान के साथ संघर्ष नहीं करता है, तो आपको इस तरह की समस्या नहीं होगी।

हां, आप एक उपनाम को परिभाषित करके उसके चारों ओर जा सकते हैं, हालांकि यह बहुत सुंदर नहीं है:

type Foo2<T> = Foo<T>

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

मैं इस उदाहरण का पालन नहीं करता हूं, क्या यहां त्रुटि नहीं होनी चाहिए? इनमें से मेरी रीडिंग यह है कि id1 में फ़ंक्शन P द्वारा निर्मित एक इनपुट होना चाहिए जो सभी इनपुट के लिए एक PromiseLike देता है। जबकि id2 एक मूल्य के बारे में बात कर रहा है जो Promise to A [] को लागू करने का एक उपप्रकार होना चाहिए। मुझे यकीन नहीं है कि यह आईडी 1 के प्रकार से आईडी 1 के लिए आवश्यक जानकारी को पुनर्प्राप्त करना संभव है। मुझे लगता है कि मैं आपकी बात को गलत समझ सकता हूं।

यही सही रीडिंग है, हाँ। लेकिन अगर P extends Promise<A[]> यह किसी भी जगह पर लागू होना चाहिए जो Promise<A[]> स्वीकार करता है, जैसे id1 । इस तरह से यह अभी है, और क्या घटाव का मतलब है।

मुझे नहीं लगता कि अब इसे टाला जा सकता है।

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

मेरा मतलब यह है: GenericNumber<T> , सभी T , और RegularNumber प्रकार समान और विनिमेय हैं। ऐसा कोई संदर्भ नहीं है, जिसमें एक चेक टाइप करेगा और दूसरा नहीं। अभी, कम से कम।

हम जिस बारे में बात कर रहे हैं वह उन्हें अलग बना देगा। क्योंकि GenericNumber<T> एक TC से है, यह उन जगहों पर स्वीकार्य होगा जहाँ RegularNumber नहीं हो सकते। तो यह अब विनिमेय नहीं होगा।

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

इसके बारे में सोचने का एक तरीका यह है कि प्रकार पैरामीटर प्रकार की "संरचना" का हिस्सा बन जाता है।

मुझे लगता है कि TC कुछ और अलग व्यवहार का नेतृत्व करेंगे।

नई दिशा

सबसे पहले, मुझे लगता है कि आप सही हैं कि सही उपप्रकार संबंध वह है जिसमें मैपिंग नहीं है:

मेरा पहला विचार निम्नलिखित था। ~A ~B का उपप्रकार होने के लिए:

1. (a) उनके पास एक ही तरह का होना चाहिए (arity के मामले में, अड़चन नहीं)।
2. (b) प्रत्येक कानूनी मापदण्ड के लिए T₁, T₂, ... ~A , A<T₁, T₂, ...> B<T₁, T₂, ...> का उपप्रकार होना चाहिए।

मानचित्रण बात ... ईमानदारी से, यह बहुत बेवकूफ है। मुझे नहीं लगता कि MyPromise<T> extends Promise<T[]> और ~Promise को एकजुट करने का कोई तरीका नहीं है। मुझे यह जानकर अच्छा लगेगा कि कोई और सोचता है या नहीं।

मुझे यह जानकर भी अच्छा लगेगा कि क्या कोई उदाहरण है जो मुझे याद आ रहा है जहाँ यह नियम भी काम नहीं करता है।

अगर हम इस बात से सहमत हैं कि टाइप कंस्ट्रक्टर बाधाओं को एक उपप्रकार संबंध का उपयोग करके व्यक्त किया जाना चाहिए, जो बहुत अच्छी तरह से काम करता है, तो हम अन्य चीजों के लिए आगे बढ़ सकते हैं।

वाक्य-विन्यास के बारे में

हम वास्तव में इस विषय पर सहमत नहीं हैं, ऐसा लगता है। मैं दृढ़ता से ~Promise समान एक उपसर्ग सिंटैक्स पसंद करता हूं। वैचारिक रूप से, ~ को "ऑपरेटर की टीसी के संदर्भ में" या कुछ और के रूप में देखा जा सकता है।

मुझे लगता है कि मैंने कई कारण बताए हैं कि यह विकल्पों में से बेहतर क्यों है:

1. पूरी तरह से असंदिग्ध।
   
   
   
   1. इस सिंटैक्स में शामिल त्रुटियाँ भी असंदिग्ध हैं। यदि कोई व्यक्ति किसी प्रकार के पैरामीटर को भूल जाता है, तो उन्हें टाइप कंस्ट्रक्टरों के बारे में त्रुटियां नहीं मिलेंगी जब वे नहीं जानते कि वे क्या हैं।
   
   
   2. साइड-इफेक्ट के रूप में, मौजूदा त्रुटि ग्रंथों और तर्क को बदलना नहीं होगा। यदि कोई Promise लिखता है तो त्रुटि संदेश बिलकुल वैसा ही होगा जैसा अभी है। टीसी के बारे में बात करने के लिए इसे बदलना नहीं पड़ेगा।
   
   
2. एक संरचनात्मक वाक्यविन्यास के लिए अच्छी तरह से फैली हुई है।
3. आसान है, मुझे विश्वास है। किसी भी ~\w जहां एक प्रकार की उम्मीद की जाती है, उसे टीसी के संदर्भ में इंगित करने के लिए मान लिया जाएगा।
4. टाइप करना आसान है।

मुझे उम्मीद है कि अन्य लोग अपनी राय दे सकते हैं।

यूनियनों, चौराहों और डिफ़ॉल्ट प्रकार के मापदंडों के बारे में

क्या ओवरलोडेड / मिश्रित प्रकार के फॉर्म * & (* => *) , * | (* => *) , और इसी तरह कानूनी हैं? क्या उनके पास दिलचस्प उपयोग हैं?

मुझे लगता है कि वे एक बुरे विचार और कारण के बारे में कठिन हैं। मुझे यह भी पता नहीं है कि आपको किस प्रकार के एनोटेशन के लिए * | (* => *) ताकि आप उससे एक प्रकार का निर्माण कर सकें।

इस तरह के एक प्रकार को अभी अस्तित्व में कहा जा सकता है, यह डिफ़ॉल्ट प्रकार के मापदंडों के साथ प्रकार है:

type Example<A = number> = {}

इस प्रकार को * & (* => *) कहा जा सकता है क्योंकि यह एक प्रकार का निर्माण करने के लिए एक प्रकार के पैरामीटर को स्वीकार कर सकता है, लेकिन यह करने की आवश्यकता नहीं है।

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

हालांकि, यह ~Promise | ~Array जैसे प्रकारों के बारे में बात करने के लिए समझ में आता है। उनके पास एक ही तरह का है, इसलिए वे असंगत नहीं हैं। मुझे लगता है कि इसका समर्थन किया जाना चाहिए।

जिन चीजों से निपटना होगा

संबंधित स्थितियों से निपटना होगा, जैसे कि इस स्थिति:

type Example = (<~P extends ~Promise>() => P<number>) | (<~M extends ~Map>() => Map<string, number>);

लेकिन यह वास्तव में (* => *) | (*, *) => * की तरह शामिल नहीं है, लेकिन कुछ अलग है

अन्य टीसी का निर्माण?

जैसा कि मैंने पहले उल्लेख किया है, मुझे नहीं लगता कि टीसी के लिए एक अच्छा विचार है जो अन्य टीसी का निर्माण करता है, जैसे * => (* => *) । वे भाषाओं में आदर्श हैं जो करी और समर्थन का समर्थन करते हैं, लेकिन टाइपस्क्रिप्ट में नहीं।

ऐसा कोई तरीका नहीं है कि मैं ~ वाक्यविन्यास और उपप्रकार संबंध का उपयोग करते हुए ऐसे प्रकारों को परिभाषित करने के लिए देख सकता हूं, इसलिए उन्हें मना करने के लिए किसी विशेष नियम की आवश्यकता नहीं होगी। उन्हें काम करने के लिए विशेष नियमों की आवश्यकता होगी।

मुझे लगता है कि आप यकीनन उन्हें इस तरह से संरचनात्मक रूप से परिभाषित कर सकते हैं:

~<A>~<B>{a : A, b : B}

मुझे लगता है कि यह एकमात्र तरीका है।

उच्च-रैंक कार्यों के साथ सहभागिता?

फ़ंक्शन प्रकारों के साथ एक प्राकृतिक, लेकिन जटिल बातचीत है जो टाइप पैरामीटर लेते हैं:

type Example<T> = <~P extends ~Promise>(p : P<T>) : P<T>;

क्या इस बातचीत को किसी तरह रोका जाना चाहिए? मैं इस तरह के प्रकारों को बहुत जटिल होते हुए देख सकता हूँ।

सामान्य तौर पर, क्या ऐसे स्थान हैं जहां टीसी पैरामीटर दिखाई नहीं देना चाहिए?

क्या मेरा संरचनात्मक वाक्यविन्यास एक अच्छा विचार है?

मुझे नहीं लगता कि इसे तुरंत लागू किया जाना चाहिए, लेकिन मुझे अभी भी लगता है कि मेरा संरचनात्मक वाक्यविन्यास एक अच्छा विचार है। यह आपको देता है:

1. अपने अवरोधों में अन्य प्रकार के मापदंडों की तरह स्थानीय पहचानकर्ताओं का उपयोग करें।
2. आंशिक रूप से, बहुत ही स्पष्ट और लचीले तरीके से टाइप कंस्ट्रक्टर लागू करें: ~<A>Map<string, A> , ~<A, B>Map<B, A> , और इसी तरह।
3. एक प्रकार के हर दूसरे पहलू में एक संरचनात्मक वाक्यविन्यास होता है, इसलिए टीसीएस में भी इस तरह का वाक्यविन्यास होना चाहिए।

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

सशर्त प्रकारों के साथ सहभागिता

सशर्त प्रकारों के साथ फीचर कैसे काम करेगा? क्या आपको ऐसा करने में सक्षम होना चाहिए?

type Example<~P extends ~PromiseLike> = ~P extends ~Promise ? 0 : 1

मुझे खुद पर पूरा यकीन नहीं है। अभी भी पूरी तरह से सशर्त प्रकारों को अभी तक पचा नहीं है।

अधिभार का संकल्प

मुझे लग रहा है कि यह करना मुश्किल होगा। यह वास्तव में बहुत महत्वपूर्ण है क्योंकि विभिन्न प्रकार के अधिभार संकल्प विभिन्न प्रकार के निर्माण को समाप्त करेंगे।

उस ने कहा, मैं अभी किसी अच्छे उदाहरण के साथ नहीं आ सकता।

तुम्हें पता है, अगर एक प्रारंभिक बिंदु के रूप में टाइपस्क्रिप्ट का वर्णन करने के लिए एक अच्छी तरह से परिभाषित मध्यस्थ भाषा का उपयोग किया गया था, तो यह एक बहुत ही महत्वपूर्ण बिंदु होगा। उदाहरण के लिए: सिस्टम F <: या साउंड डिपेंडेंट एमएल जैसे साउंड डिपेंडेंट टाइप सिस्टम में से एक।

मैं ईमानदारी से आश्चर्यचकित रहूँगा यदि यह पहले हल हो जाए
https://github.com/Microsoft/TypeScript/issues/14833

मुझे लगता है कि # 17961 शायद इसे अप्रत्यक्ष रूप से हल कर सकता है। अधिक जानकारी के लिए यह देखें।

ध्यान दें कि Bifunctor और Profunctor प्रकार बाधा स्तर पर थोड़े जटिल हैं - अगर infer T बजाय मेरे पास काम करने के लिए स्पष्ट सार्वभौमिक प्रकार हों, तो यह बहुत सरल होगा। this उपयोग कर सकता हूं (जो कि पूरी तरह से टाइप स्तर है) - जिसने मेरे अधिकांश इंटरफेस को परिभाषित करना आसान बना दिया होगा।

(मैं एक भारी TS उपयोगकर्ता नहीं हूं, इसलिए मैंने गलतियाँ की हो सकती हैं। @ tycho01 क्या आप उस पर एक नज़र

@isiahmeadows @ tycho01 वाह ...

आप सही हे। अगर मैं इसे सही तरीके से समझूं, तो इसके बहुत ही समान परिणाम हैं।

कुछ अंतर हैं। लेकिन कार्यात्मक रूप से, वे बहुत अधिक समान हैं, और मुझे लगता है कि इन मतभेदों को हल किया जा सकता है।

सही प्रकार के फ़ंक्शन का अनुमान लगाना संभव नहीं है

function example<~P extends ~PromiseLike>(p : P<number>) : P<string>;

यहाँ आप ~Promise और ~Bluebird p अनुमान लगा सकते हैं। हालाँकि, यदि आप इसे इस तरह करते हैं:

function example<F extends <T>(t: T) => PromiseLike<T>>(p : F(number)) : F(string)

मुझे बहुत संदेह है कि यह काम करेगा:

example(null as Promise<number>)

यह अनुमान लगाने का कोई तरीका नहीं है कि F का अर्थ है:

<T>(t : T) => Promise<T>

क्योंकि इस कार्य को किसी भी तरह से विशेष नहीं माना जाता है। जबकि टीसी के साथ, कुछ प्रकारों में अनिवार्य रूप से एक "निहित" प्रकार-स्तरीय फ़ंक्शन होता है: उनकी टीसी।

मौजूदा टीसी को आसानी से संदर्भित करना संभव नहीं है

आप मेरे प्रस्ताव में ~Promise नहीं कर सकते। आपको संरचनात्मक प्रारूप का उपयोग करके सीधे प्रकार को एनकोड करना होगा:

type PromiseTC = <T>() => Promise<T>

सच है, और यह एक चिंता का विषय है। यह एक प्रकार का इंफ़ेक्शन मुद्दा है, जहाँ आपको एक ज्ञात तर्क प्रकार (आमतौर पर जो होता है उसका उल्टा) से सामान्य कार्य को समझने की क्षमता की आवश्यकता होती है। यह एक तरह से सामान्य है जो अधिकांश मामलों के लिए काम करने के लिए पर्याप्त है, लेकिन इसके लिए एक नए विशेष मामले की आवश्यकता होती है जो गैर-तुच्छ हो।

यह NoInfer<T> रणनीतिक उपयोग के माध्यम से भाग में हल हो सकता है, लेकिन मुझे 100% यकीन नहीं है कि इसे कैसे करना होगा, और यह आम मामले को भी कितना संबोधित कर सकता है।

@GregRos

मैं दृढ़ता से किसी भी वाक्य रचना के पक्ष में नहीं हूं यह सिर्फ मेरी प्राथमिकता है, ~ लिए बहुत सारे गुण हैं। मुझे लगता है कि विचार करने के लिए मुख्य बात यह होगी कि क्या स्पष्ट प्रकार के एनोटेशन के लिए सिंटैक्स की आवश्यकता है क्योंकि इंट्रेंस हमेशा संभव नहीं है।

मानचित्रण बात ... ईमानदारी से, यह बहुत बेवकूफ है। मुझे नहीं लगता कि MyPromise को एकजुट करने का कोई तरीका हैवादा करता है

मुझे लगता है कि मैपिंग की चीज अभी भी एक उपयोगी धारणा हो सकती है, लेकिन ऊपर के मामले में मुझे नहीं लगता कि हमें कभी भी ~MyPromise ~Promise साथ एकीकरण करने की कोशिश करनी चाहिए, जिस चीज़ को एकीकृत करने की आवश्यकता है ~MyPromise और ~<T>Promise<T[]> , जिसे हम ~(Promise . []) भी लिख सकते हैं। मुझे लगता है कि जो बात याद आ रही थी वह यह है कि मैपिंग को उप-संबंध के हिस्से का हिस्सा होना चाहिए: यह Promise रूप में निर्माता का एक हिस्सा है। उस उदाहरण में मानचित्रण केवल सूची निर्माता है।

interface A<T> {
    x: T;
} 

interface B<T> {
    x: T[];
}

क्या ~<T>B<T> ~<T>A<T[]> ? हाँ। क्या ~<T>B<T> ~<T>A<T> ? नहीं, लेकिन अंततः वे दो असंबंधित प्रश्न हैं।

अगर हम इस बात से सहमत हैं कि टाइप कंस्ट्रक्टर बाधाओं को एक उपप्रकार संबंध का उपयोग करके व्यक्त किया जाना चाहिए, जो बहुत अच्छी तरह से काम करता है, तो हम अन्य चीजों के लिए आगे बढ़ सकते हैं।

हां मुझे लगता है कि यह चीजों का वर्णन करने का एक अच्छा तरीका है।

सही प्रकार के फ़ंक्शन का अनुमान लगाना संभव नहीं है

function example<~P extends ~PromiseLike>(p : P<number>) : P<string>;
यहां आप पी से ~Promise और ~Bluebird अनुमान लगा सकते हैं।

यह दावा नहीं है, अधिक खुला प्रश्न है क्योंकि मुझे पूरी तरह से यकीन नहीं है कि प्रकार की जाँच कैसे होती है। मैंने सोचा था कि, उदाहरण के रूप में A इंटरफ़ेस का उपयोग करते हुए, प्रकार A<number> और {x: number} अप्रभेद्य हैं और इसलिए मुझे यकीन नहीं है कि कंस्ट्रक्टर का अनुमान लगाना संभव होगा कंस्ट्रक्टर के एक एप्लिकेशन से लौटाए गए प्रकार से। क्या P P<number> से वसूलना संभव होगा? मुझे यकीन है कि इसका समर्थन करने के लिए चीजों को बदला जा सकता है, मैं बस सोच रहा हूं कि यह अब क्या करता है।

# 17961 से क्रॉस-प्रतिक्रिया, लेकिन मुझे यकीन नहीं है कि दुर्भाग्य से @isiahmeadows के दृष्टिकोण को कैसे बनाया जाए। मुझे डर है कि टाइप कॉल पर पिछड़े इंट्रेंस गैर-तुच्छ हैं।

ऐसा लगता है कि यह एक इनपुट Promise<number> या Bluebird<number> हम इन प्रकारों के अनपेक्षित संस्करणों का पता लगाने में सक्षम होना चाहते हैं, जैसे कि हम उन्हें string साथ पुन: लागू कर सकते हैं। हालांकि यह कठिन लगता है।

यहां तक ​​कि अगर इनपुट प्रकार कुछ संरचनात्मक समकक्ष के बजाय इस तरह हैं (हम एक संरचनात्मक रूप से टाइप की गई भाषा है, ठीक है?), तो यह तर्क भी नकली हो जाता है यदि उदा Bluebird बजाय दो परम प्रकार थे, जिस बिंदु पर हमारा <string> प्रकार के परम एप्लिकेशन का अब कोई मतलब नहीं हो सकता है।
मैं वहाँ एक अच्छा समाधान के बारे में सुनिश्चित नहीं हूँ। (अस्वीकरण: मैं यहाँ चर्चा पर थोड़ा पीछे हट गया हूँ।)

@ tycho01 क्या ये सभी समस्याएं दूर हो T तत्काल

मुझे लगता है कि यह उचित है, यह देखते हुए कि मुझे संदेह है कि सभी मामलों के लिए निष्कर्ष को हल किया जा सकता है।

@ जैक-विलियम्स: # 17961 के साथ अब तक नहीं, लेकिन मुझे लगता है कि डिस्पैचिंग के लिए इसका इस्तेमाल करने से मदद मिल सकती है:

let arr = [1, 2, 3];
let inc = (n: number) => n + 1;
let c = arr.map(inc); // number[]
let map = <Functor extends { map: Function }, Fn extends Function>(x: Functor, f: Fn) => x['map'](f); // any on 2.7 :(
let e = map(arr, inc);

@ tycho01 हां मुझे एहसास हुआ कि मेरा सुझाव बहुत ही भयानक था क्योंकि T की विधि कॉल पर त्वरित नहीं है।

निम्नलिखित कार्य के लिए कुछ करना चाहेंगे?

interface TyCon<A> {
    C: <A>(x: A) => TyCon<A>
}

interface Functor<A> extends TyCon<A> {
    C: <A>(x: A) => Functor<A>;
    fmap<B>(this: this["C"](A), f: (x: A) => B): this["C"](B);
}

interface Option<A> extends Functor<A> {
    C: <A>(x: A) => Option<A>;
}

@ जैक-विलियम्स मुझे लगता है कि सवाल यह होना चाहिए कि यह fp-ts में ADT कार्यान्वयन के व्यवहार में तुलना कैसे करेगा, लेकिन ऐसा लगता है कि यह काम कर सकता है, हाँ। शायद TyCon बिना भी।

@ जैक-विलियम्स @isiahmeadows :

मैंने विचार की कोशिश की प्रवाह में , क्योंकि यह पहले से ही $Call उपलब्ध है। मेरे लिए यह किसी भी तरह से अनुत्तरदायी बन जाता है, हालांकि ...

interface Functor<A> {
    C: <A>(x: A) => Functor<A>;
    fmap<B>(f: (x: A) => B): $Call<$ElementType<this, "C">, B>;
}
// this: $Call<$ElementType<this, "C">, A>, 
// ^ flow doesn't seem to do `this` params

interface Option<A> extends Functor<A> {
    C: <A>(x: A) => Option<A>;
}

let o: Option<string>;
let f: (s: string) => number;
let b = o.fmap(f);

@ tycho01 मुझे लगता है कि आप केवल $ElementType this प्रवाह के साथ गुण प्राप्त नहीं कर सकते

@ tycho01 आपको वास्तव में टाइपस्क्रिप्ट में भी काम करने के लिए नहीं मिल सकता है
खेल का मैदान: https://goo.gl/tMBKyJ

@goodmind : hm, ऐसा लगता है कि यह Maybe<number> बजाय Functor<number> Functor Maybe fmap से कॉपी करने के बाद Maybe ।
टाइप कॉल के साथ मुझे लगता है कि टाइप के लिए रन-टाइम कार्यान्वयन की आवश्यकता के बजाय वहां केवल टाइप करने में सुधार होगा।
अब, फंक्शनलर्स को पहले से ही अपने fmap कार्यान्वयन की आवश्यकता होगी। हालांकि व्युत्पन्न तरीकों के लिए चूसना होगा।
एक वर्ग को वापस। : /

Https://github.com/SimonMeskens/TypeProps/issues/1 पर कुछ प्रासंगिक विचार

मैं एक अल्फा संस्करण एएसएपी जारी करने की योजना बना रहा हूं, लेकिन आप मेरे साथ इस मुद्दे में उदाहरण लिखने के साथ-साथ इसके बारे में पहले से ही महसूस कर सकते हैं।

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

हेड्स अप मैंने इसे # 23809 पर लागू करने का प्रयास शुरू कर दिया है। यह अभी भी बहुत अधूरा है, लेकिन अगर आप रुचि रखते हैं तो इसे देखें।

मैंने आप लोगों से एक सरल उदाहरण का वादा किया था, यह यहाँ है। यह कुछ ट्रिक्स का उपयोग करता है जो मैंने अपने पुस्तकालय को लिखने से सीखा है।

type unknown = {} | null | undefined;

// Functor
interface StaticFunctor<G> {
    map<F extends Generic<G>, U>(
        transform: (a: Parameters<F>[0]) => U,
        mappable: F
    ): Generic<F, [U]>;
}

// Examples
const arrayFunctor: StaticFunctor<any[]> = {
    map: <A, B>(fn: (a: A) => B, fa: A[]): B[] => {
        return fa.map(fn);
    }
};
const objectFunctor: StaticFunctor<object> = {
    map: <A, B>(fn: (a: A) => B, fa: A): B => {
        return fn(fa);
    }
};
const nullableFunctor: StaticFunctor<object | null | undefined> = {
    map: <A, B>(
        fn: (a: A) => B,
        fa: A | null | undefined
    ): B | null | undefined => {
        return fa != undefined ? fn(fa) : fa;
    }
};

const doubler = (x: number) => x * 2;

const xs = arrayFunctor.map(doubler, [4, 2]); // xs: number[]
const x = objectFunctor.map(doubler, 42); // x: number
const xNull = nullableFunctor.map(doubler, null); // xNull: null
const xSome = nullableFunctor.map(doubler, 4 as number | undefined); // xSome: number | undefined

const functor: StaticFunctor<unknown | any[]> = {
    map(fn, fa) {
        return Array.isArray(fa)
            ? arrayFunctor.map(fn, fa)
            : fa != undefined
                ? objectFunctor.map(fn, fa)
                : nullableFunctor.map(fn, fa);
    }
};

const ys = functor.map(doubler, [4, 2]); // ys: number[]
const y = functor.map(doubler, 42); // y: number
const yNull = functor.map(doubler, null); // yNull: null
const ySome = functor.map(doubler, 42 as number | undefined); // ySome: number | undefined

// Plumbing
interface TypeProps<T = {}, Params extends ArrayLike<any> = never> {
    array: {
        infer: T extends Array<infer A> ? [A] : never;
        construct: Params[0][];
    };
    null: {
        infer: null extends T ? [never] : never;
        construct: null;
    };
    undefined: {
        infer: undefined extends T ? [never] : never;
        construct: undefined;
    };
    unfound: {
        infer: [NonNullable<T>];
        construct: Params[0];
    };
}

type Match<T> = T extends infer U
    ? ({} extends U ? any
        : TypeProps<U>[Exclude<keyof TypeProps, "unfound">]["infer"]) extends never
    ? "unfound"
    : {
        [Key in Exclude<keyof TypeProps, "unfound">]:
        TypeProps<T>[Key]["infer"] extends never
        ? never : Key
    }[Exclude<keyof TypeProps, "unfound">] : never;


type Parameters<T> = TypeProps<T>[Match<T>]["infer"];

type Generic<
    T,
    Params extends ArrayLike<any> = ArrayLike<any>,
    > = TypeProps<T, Params>[Match<T>]["construct"];

मैंने नमूना अद्यतन किया और सरल किया, यहाँ एक खेल का मैदान लिंक भी है:
खेल का मैदान

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

जीथब लिंक

मैं संतृप्त विवरण के भीतर आभासी प्रकार चर स्थानापन्न करने के लिए सशर्त प्रकारों का उपयोग करके एचकेटी का अनुकरण करने के लिए एक सरल दृष्टिकोण के साथ खेल रहा हूं:

declare const index: unique symbol;

// A type for representing type variables
type _<N extends number = 0> = { [index]: N };

// Type application (substitutes type variables with types)
type $<T, S, N extends number = 0> =
  T extends _<N> ? S :
  T extends undefined | null | boolean | string | number ? T :
  T extends Array<infer A> ? $Array<A, S, N> :
  T extends (x: infer I) => infer O ? (x: $<I, S, N>) => $<O, S, N> :
  T extends object ? { [K in keyof T]: $<T[K], S, N> } :
  T;

interface $Array<T, S, N extends number> extends Array<$<T, S, N>> {}

// Let's declare some familiar type classes...

interface Functor<F> {
  map: <A, B>(fa: $<F, A>, f: (a: A) => B) => $<F, B>;
}

interface Monad<M> {
  pure: <A>(a: A) => $<M, A>;
  bind: <A, B>(ma: $<M, A>, f: (a: A) => $<M, B>) => $<M, B>;
}

interface MonadLib<M> extends Monad<M>, Functor<M> {
  join: <A>(mma: $<M, $<M, A>>) => $<M, A>;
  // sequence, etc...
}

const Monad = <M>({ pure, bind }: Monad<M>): MonadLib<M> => ({
  pure,
  bind,
  map: (ma, f) => bind(ma, a => pure(f(a))),
  join: mma => bind(mma, ma => ma),
});

// ... and an instance

type Maybe<A> = { tag: 'none' } | { tag: 'some'; value: A };
const none: Maybe<never> = { tag: 'none' };
const some = <A>(value: A): Maybe<A> => ({ tag: 'some', value });

const { map, join } = Monad<Maybe<_>>({
  pure: some,
  bind: (ma, f) => ma.tag === 'some' ? f(ma.value) : ma,
});

// Not sure why the `<number>` annotation is required here...
const result = map(join<number>(some(some(42))), n => n + 1);
expect(result).toEqual(some(43));

यहां प्रोजेक्ट करें: https://github.com/pelotom/hkts

प्रतिक्रिया का स्वागत!

@pelotom मुझे आपके दृष्टिकोण के वाक्य रचना की लपट पसंद है। इस धागे में दो अन्य दृष्टिकोणों का उल्लेख नहीं किया गया है जो वर्तमान और भविष्य के समाधानों के निर्माण में कुछ रचनात्मकता को उत्तेजित कर सकते हैं। दोनों इस समस्या के ऑब्जेक्ट ओरिएंटेड समाधान हैं।

1. बर्ट्रेंड मेयर ने अपनी 1988 की पुस्तक "ऑब्जेक्ट-ओरिएंटेड सॉफ्टवेयर कंस्ट्रक्शन" में जेनेरिक प्रकारों का अनुकरण करने का एक तरीका बताया।

उदाहरण एफिल में हैं, लेकिन टाइपस्क्रिप्ट के लिए एक मोटा अनुवाद इस तरह दिखता है:

https://gist.github.com/mlhaufe/089004abd14ad8e7171e2a122198637f

आपको लगता है कि वे मध्यवर्ती वर्ग के प्रतिनिधित्व की आवश्यकता के कारण बहुत भारी हो सकते हैं, लेकिन क्लास-फैक्टरी के एक प्रकार के साथ या टाइपस्क्रिप्ट मिक्सिन दृष्टिकोण के साथ यह काफी कम हो सकता है।

# 17588 पर कुछ प्रयोज्यता हो सकती है

1. ऑब्जेक्ट एलजेब्रा (और एब्सट्रैक्ट फैक्ट्रीज़) का अनुकरण करते समय दूसरे दृष्टिकोण का उपयोग किया जाता है:

C<T> का प्रतिनिधित्व App<t,T> जहाँ T वर्ग है, और t C साथ जुड़ा हुआ एक अनूठा टैग है

interface App<C,T> {}

नमूना:

interface IApp<C,T> {}

interface IList<C> {
    Nil<T>(): IApp<C,T>
    Cons<T>(head: T, tail: IList<C>): IApp<C,T>
}

// defining data
abstract class List<T> implements IApp<typeof List, T> {
    // type-safe down-cast
    static prj<U>(app: IApp<typeof List, U>): List<U> { return app as List<U> }
}
class Nil<T> extends List<T> { }
class Cons<T> extends List<T> {
    constructor(readonly head: T, readonly tail: List<T>) {
        super()
    }
}

// The abstract factory where the HKT is needed
class ListFactory<T> implements IList<typeof List> {
    Nil<T>(): IApp<typeof List, T> { return new Nil() }
    Cons<T>(head: T, tail: IApp<typeof List, T>): IApp<typeof List, T> {
        return new Cons(head, tail)
    }
}

आप नीचे दिए गए पेपर में अधिक विवरण और औचित्य देख सकते हैं।

https://blog.acolyer.org/2015/08/13/streams-a-la-carte-extensible-pipelines-with-object-algebras/

@metaweta , क्या आप इस मुद्दे का नाम बदलकर Higher kinded types in TypeScript ताकि इसे Google खोज से बेहतर दृश्यता प्राप्त हो?

शायद हमारे बुद्धिमान और परोपकारी रिपॉजिटरी मेंटेनर (जैसे, @DanielRosenwasser ) शीर्षक को संपादित कर सकते हैं, अगर इस तरह के बदलाव को उनके हस्तक्षेप के योग्य माना जाए?

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

यह पाया गया: "समुदाय" मील का पत्थर स्पष्ट रूप से "बैकलॉग" के पक्ष में पदावनत है , और इसलिए यह मुद्दा संभवतः तरह से माइग्रेट किया गया था।

टीएस सदस्य नहीं, बस किसी ने लिंक पर क्लिक करने का फैसला किया जहां इसे फिर से मिलाया गया।

+1

यहाँ कुछ है जो मैं बस बनाने की कोशिश कर रहा था जो उच्च-प्रकार के प्रकारों के लिए वास्तव में व्यावहारिक मामला लगता है।

मैं एक डेटाबेस के लिए एक अमूर्त बनाना चाहता हूं जो या तो तुल्यकालिक या अतुल्यकालिक रूप से चल सकता है। कॉलबैक का उपयोग करने और उसके आसपास हैक करने के बजाय, मैं एक सामान्य उपयोग करना चाहता था। यहाँ मैं क्या करना चाहता हूँ:

type Identity<T> = T

interface DatabaseStorage<Wrap<T> extends Promise<T> | Identity<T>> {
    get(key: string): Wrap<any>
    set(key: string, value: any): Wrap<void>
}

यह वास्तव में शक्तिशाली होगा!

@ccorcos thats को fp-ts के साथ शुद्ध कार्यात्मक उदाहरण के लिए https://github.com/gcanti/fp-ts/blob/master/tutorials/mtl.ts पर एक नज़र डाल सकते हैं।

@mlegenhausen मुझे क्षमा करें, लेकिन मेरे पास उस उदाहरण के बाद एक कठिन समय है।

जब भी मैं fp-ts में खुदाई करता हूं, मुझे चिंता होती है कि चीजें इतनी जटिल हो रही हैं कि वे भंगुर होने वाली हैं। @pelotom का उदाहरण हालांकि अनुसरण करने में आसान लगता है ...

किसी भी कारण से यह टाइपस्क्रिप्ट में नहीं अपनाया जाता है?

@ccorcos IMHO तब भी जब मैंने fp-ts से उदाहरण की सिफारिश की, मैं MTL / tagless शैली की बिल्कुल भी सिफारिश नहीं करता। आप प्रत्येक प्रभावी मोनाड में अमूर्तता की एक अतिरिक्त परत जोड़ते हैं जिसे आपको मैन्युअल रूप से प्रबंधित करने की आवश्यकता होती है टाइपस्क्रिप्ट का पता लगाने में सक्षम नहीं है कि आप किस मोनाड का उपयोग करना चाहते हैं और यह वह जगह है जहां चीजें जटिल हो जाती हैं। जो कुछ मैं fp-ts समुदाय से देख रहा हूं वह एक async monad का उपयोग करना है (मैं TaskEither की सिफारिश करूंगा) और इसके साथ रहना होगा। यहां तक ​​कि एमटीएल के लाभों के परीक्षण में भी आपके गैर-परीक्षण कोड में आपको होने वाली परेशानी के लायक नहीं है। fp-ts पर आधारित हाइपर-टीएस एक पुस्तकालय का एक उदाहरण है जिसने हाल ही में MTL के लिए समर्थन गिरा दिया।

दिलचस्प ... hyper-ts वास्तव में अच्छा लग रहा है ...

मैं एफ-बाउंड पॉलीमॉर्फिज्म पर आधारित हल्के उच्च-प्रकार के एन्कोडिंग के साथ आया था: https://github.com/strax/tshkt

इस दृष्टिकोण का लाभ यह है कि आपको टाइप कंस्ट्रक्टर्स को टाइप करने के लिए लुकअप टेबल (स्ट्रिंग कंडीशंस के साथ एक सिंगल कंडीशनल टाइप या ऑब्जेक्ट) की आवश्यकता नहीं है। तकनीक का उपयोग प्रकार-स्तरीय जेनेरिक कार्यों के अनुप्रयोग को एनकोड करने के लिए भी किया जा सकता है ( ReturnType<<T>(value: T) => Array<T>> सोचो)।

यह अभी भी अवधारणा का एक प्रमाण है इसलिए इस दृष्टिकोण की व्यवहार्यता पर प्रतिक्रिया बहुत सराहना की जाती है!

मैं उस @strax पर एक नज़र

इस बीच, यहाँ एक मूर्खतापूर्ण उदाहरण है कि अब हम क्या कर सकते हैं:

type Test1 = λ<Not, [True]>;        // False
type Test2 = λ<And, [True, False]>; // False
type Test3 = λ<And, [True, True]>;  // True

// Boolean

interface True extends Func {
    expression: Var<this, 0>;
}

interface False extends Func {
    expression: Var<this, 1>;
}

interface Not extends Func {
    expression: λ<Var<this, 0>, [False, True]>
}

interface And extends Func {
    expression: λ<Var<this, 0>, [Var<this, 1>, Var<this, 0>]>
}

// Plumbing

type Func = {
    variables: Func[];
    expression: unknown;
}

type Var<F extends Func, X extends number> = F["variables"][X];

type λ<Exp extends Func, Vars extends unknown[]> = (Exp & {
    variables: Vars;
})["expression"];

मैं डी ब्रुजन सूचकांकों को जोड़ना चाहूंगा, क्योंकि इसका मतलब होगा कि हमें अब इंटरफेस की आवश्यकता नहीं है, लेकिन मुझे लगता है कि मुझे कुछ टफ गणित की आवश्यकता होगी और मैं इससे बचने की कोशिश कर रहा हूं।

प्रस्ताव

उच्च आदेश, लमडा, संदर्भ प्रकार

संदर्भ के रूप में एक प्रकार पास करें

सीधे शब्दों में कहें, एक संदर्भ प्रकार या एक उच्च आदेश प्रकार बाद में के लिए एक प्रकार के द्वारा लिए गए मापदंडों को स्थगित करने की अनुमति देता है, या इसके बाद के प्रकार (जेनरिक) का भी अनुमान लगा सकता है। लेकिन हमें परवाह क्यों करनी चाहिए?

यदि हम एक प्रकार को संदर्भ के रूप में पारित कर सकते हैं, तो इसका मतलब है कि हम टाइपस्क्रिप्ट को एक प्रकार का मूल्यांकन करने से देरी कर सकते हैं जब तक कि हम ऐसा करने का निर्णय नहीं लेते। आइए एक वास्तविक विश्व उदाहरण देखें:

पाइप के साथ पूर्वावलोकन करें

कल्पना करें कि आप pipe लिए एक सामान्य प्रकार विकसित कर रहे हैं। अधिकांश काम यह जांचने के बारे में है कि पाइप किए जाने वाले कार्य वास्तव में पाइप-सक्षम हैं, अन्यथा हम उपयोगकर्ता को एक त्रुटि देंगे। ऐसा करने के लिए, हम pipe(...) जैसे कार्यों के प्रकारों को पाइप करने के लिए मैप किए गए प्रकार का उपयोग करेंगे:

type  PipeSync<Fns  extends  Function[], K  extends  keyof  Fns> = 
    K  extends  '0'
    // If it's the first function, we leave it unchanged
    ?  Fns[K]
    // For all the other functions, we link input<-output
    : (arg:  Return<Fns[Pos<Prev<IterationOf<K & string>>>]>) =>
        Return<Fns[Pos<IterationOf<K & string>>]>;

अब, हमें केवल एक मैप किए गए प्रकार के साथ इस कार्य को दोहराना होगा:

type  Piper<Fns  extends  Function[]> = {
    [K  in  keyof  Fns]:  PipeSync<Fns, K>
}

( पूरा कार्यान्वयन देखें )

अब हम एक साथ कार्य करने में सक्षम हैं और टाइपस्क्रिप्ट हमें चेतावनी दे सकते हैं:

declare  function  pipe<Fns  extends  F.Function[]>(...args:  F.Piper<Fns>):  F.Pipe<Fns>

const  piped  =  pipe(
    (name:  string, age:  number) => ({name, age}),
    (info: {name:  string, age:  number}) =>  `Welcome, ${info.name}`,
    (message:  object) =>  false, // /!\ ERROR
)

यह काम करता हैं! हमें एक उचित त्रुटि मिली:

प्रकार '(संदेश: वस्तु) का तर्क => बूलियन' प्रकार के पैरामीटर के लिए लागू नहीं है '(arg: string) => बूलियन'।

समस्या

लेकिन एक समस्या है। जब यह सरल ऑपरेशन के लिए बहुत अच्छी तरह से काम करता है, तो आप पाएंगे कि यह पूरी तरह से विफल हो जाता है जब आप जेनेरिक (टेम्प्लेट) का उपयोग करना शुरू कर देते हैं:

const  piped  =  pipe(
    (a:  string) =>  a,
    <B>(b:  B) =>  b, // any
    <C>(c:  C) =>  c, // any
)

type  piped  =  Piper<[
    (a:  string) =>  string,
    <B>(b:  B) =>  B,
    <C>(c:  C) =>  C,
]>
// [
//     (a:  string) =>  string,
//     (b:  string) =>  unknown,
//     (c:  unknown) => unknown
// ]

दोनों मामलों में, टाइपस्क्रिप्ट फ़ंक्शन प्रकारों का ट्रैक खो देता है।
> यह वह जगह है जहाँ उच्च क्रम प्रकार खेलने में आते हैं <

वाक्य - विन्यास

type  PipeSync<Fns  extends  Function[], K  extends  keyof  Fns> = 
    K  extends  '0'
    // If it's the first function, we leave it unchanged
+   ?  *(Fns[K]) // this will preserve the generics
    // For all the other functions, we link input<-output
+   :  *( // <- Any type can be made a reference
+       <T>(arg:  T) => Return<*(Fns[Pos<IterationOf<K  &  string>>])>
+       // vvv It is now a reference, we can assign generics
+       )<Return<*(Fns[Pos<Prev<IterationOf<K  &  string>>>])>>
+       // ^^^ We also tell TS not to evaluate the previous return
+       // and this could be achieved by making it a reference too

संक्षेप में, हमने * साथ जेनरिक रूप से मैन्युअल रूप से अनुमान लगाया है। वास्तव में, * का उपयोग करते हुए जेनरिक के मूल्यांकन को स्थगित कर दिया। तो * के संदर्भ के आधार पर अलग-अलग व्यवहार होते हैं। यदि * एक प्रकार पर है:

• जेनेरिक प्राप्त कर सकते हैं : यह अपने जेनेरिक का अधिग्रहण करता है / इसका संदर्भ प्राप्त करता है
• एक सामान्य बात है : यह संदर्भ का पता चलने तक मूल्यांकन को बाधित करता है। इसके लिए, माता-पिता के नीचे से एक संदर्भ वृक्ष बनाया गया है। दूसरे शब्दों में, रिफरेन्स को नस्ट किया जा सकता है। यह वास्तव में क्या साथ ऊपर होता है Return<*(Fns[Pos<Prev<IterationOf<K & string>>>])> को निर्दिष्ट किया गया T । इस संदर्भ में, हम कह सकते हैं कि * "तात्कालिक निकासी के खिलाफ" सुरक्षा करता है।
• उपरोक्त में से कोई भी नहीं है : यह कुछ भी नहीं करता है, उसी प्रकार का समाधान करता है

type  piped  =  Piper<[
    (a:  string) =>  string,
    <B>(b:  B) =>  B
    <C>(c:  C) =>  C
]>
// [
//     (a:  string) =>  string,
//     (b:  string) =>  string,
//     (c:  string) =>  string
// ]

इसलिए टाइपस्क्रिप्ट को केवल तभी शुरू करना चाहिए / मूल्यांकन करना जारी रखना चाहिए यदि जेनेरिक प्रदान किया गया है, और मूल्यांकन को ब्लॉक करें जब आवश्यक हो (अपूर्ण जेनेरिक)। फिलहाल, टीएस एक शॉट में unknown प्रकारों में जेनरिक का मूल्यांकन करता है। इस प्रस्ताव के साथ, जब कुछ हल नहीं किया जा सकता है:

type  piped  =  Piper<[
    <A>(a:  A) =>  A, // ?
    <B>(b:  B) =>  B, // ?
    <C>(c:  C) =>  C, // ?
]>
// [
//     <A>(a:  A) =>  A,
//     (b:  A) =>  A,
//     (c:  A) =>  A
// ]

विवरण

* एक प्रकार के संदर्भ को फिर से प्राप्त करता है, जिससे इसकी जेनरिक पर जोड़तोड़ हो सकती है। तो वाइल्डकार्ड को एक प्रकार के सामने रखने से इसका एक संदर्भ प्राप्त होता है:

*[type]

किसी प्रकार के संदर्भ को पुन: प्राप्त करना स्वचालित रूप से जेनरिक हेरफेर को सक्षम करता है:

*[type]<T0, T1, T2...>

जेनरिक केवल लक्षित प्रकार से खपत / निर्धारित किया जाता है यदि यह हो सकता है। तो यह कर:

*string<object, null> // Will resolve to `string`

लेकिन इसे टाइपस्क्रिप्ट द्वारा भी जांचा जा सकता है, चाहे उसे चेतावनी प्रदर्शित करनी चाहिए या नहीं। लेकिन आंतरिक रूप से, टीएस को इससे कुछ नहीं करना चाहिए।

मैंने यह भी सोचा था कि * का उपयोग करना एक अच्छा विचार था क्योंकि यह किसी चीज़ (जैसे C / C ++ भाषाओं) के लिए एक संकेतक का प्रतीक हो सकता है, और टाइपस्क्रिप्ट द्वारा उधार नहीं लिया जाता है।

उच्च आदेश प्रकार

अब जब हमने देखा कि यह अपने सबसे बुनियादी रूप में कैसे काम करता है, तो मैं मुख्य अवधारणा: लैम्ब्डा प्रकारों को पेश करना चाहूंगा। जावास्क्रिप्ट में कॉलबैक, लैम्ब्डा, संदर्भों के समान अनाम प्रकार होना अच्छा होगा।

ऊपर दिए गए उदाहरण से पता चलता है कि किसी फ़ंक्शन की उत्पत्ति को कैसे लेना है। लेकिन जब से हम संदर्भों के बारे में बात कर रहे हैं, किसी भी प्रकार का उपयोग * के साथ संयोजन में किया जा सकता है। सीधे शब्दों में कहें, एक प्रकार का संदर्भ एक प्रकार है जिसे हम चारों ओर से गुजर सकते हैं, लेकिन यह प्राप्त नहीं हुआ है कि यह अभी तक जेनरिक नहीं है:

type  A<T  extends  string> = {0:  T}
type  B<T  extends  string> = [T]
type  C<T  extends  number> = 42

// Here's our lamda
type  Referer<*Ref<T  extends  string>, T  extends  string> =  Ref<T>
// Notice that `T` & `T` are not in conflict
// Because they're bound to their own scopes

type  testA  =  Referer<A, 'hi'> // {0: 'hi'}
type  testB  =  Referer<B, 'hi'> // ['hi']
type  testC  =  Referer<C, 'hi'> // ERROR

उच्च प्रकार के प्रकार

interface Monad<*T<X extends any>> {
  map<A, B>(f: (a: A) => B): T<A> => T<B>;
  lift<A>(a: A): T<A>;
  join<A>(tta: T<T<A>>): T<A>;
}

खोज शब्द

उच्च # मोड # टाइप #references # लेम्बडा #HKTs

@ पिरिक्स-जीएच यदि आप कुछ संदेश पढ़ते हैं, तो आप देख सकते हैं कि आप जो मांगते हैं, वह या तो पहले से ही संभव है या पहले से ही मांगा जा चुका है।

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

मैंने उपरोक्त प्रस्ताव को एक बेहतर व्याख्या के लिए संपादित किया कि हम कैसे संदर्भों को श्रृंखलाबद्ध कर सकते हैं, और जिस तरह से Pipe एक तरह से इसके साथ काम करेंगे (इसके तर्क के बारे में कुछ गलतियाँ थीं)।

किसी भी अद्यतन?

फिर भी कोई अपडेट नहीं? मेरी राय में, यह समस्या टाइप करने के लिए नंबर एक बाधा के रूप में रैंक करती है ताकि इसकी पूरी क्षमता प्राप्त हो सके। ऐसे कई उदाहरण हैं जहां मैं अपने पुस्तकालयों को ठीक से टाइप करने की कोशिश करता हूं, केवल लंबे संघर्ष के बाद हार मान लेता हूं, यह महसूस करते हुए कि मैं इस सीमा के खिलाफ फिर से चला गया हूं। यह व्यापक है, जो प्रतीत होता है कि बहुत ही सरल परिदृश्यों में भी दिखाई देता है। वास्तव में उम्मीद है कि इसे जल्द ही संबोधित किया जाएगा।

interface Monad<T<X>> {
    map1<A, B>(f: (a: A) => B): (something: A) => B;

    map<A, B>(f: (a: A) => B): (something: T<A>) => T<B>;

    lift<A>(a: A): T<A>;
    join<A>(tta: T<T<A>>): T<A>;
}

type sn = (tmp: string) => number

function MONAD(m: Monad<Set>,f:sn) {
    var w = m.map1(f);    // (method) Monad<Set>.map1<string, number>(f: (a: string) => number): (something: string) => number
    var w2 = m.map(f);    // (method) Monad<Set>.map<string, number>(f: (a: string) => number): (something: Set<string>) => Set<number>
    var q = m.lift(1);    // (method) Monad<Set>.lift<number>(a: number): Set<number>
    var a = new Set<Set<number>>();
    var w = m.join(q);    // (method) Monad<Set>.join<unknown>(tta: Set<Set<unknown>>): Set<unknown>.  You could see that typeParameter infer does not work for now.
    var w1 = m.join<number>(q);    // (method) Monad<Set>.join<number>(tta: Set<Set<number>>): Set<number>
}

बहुत सारे काम अभी भी किए जाने की आवश्यकता है, जैसे: quickinfo को ठीक करें, टाइप करेंपार्टीफ़ायर, त्रुटि संदेश जोड़ें, हाईलाइट उसी प्रकार टाइपकर्ता। .....
लेकिन यह काम करना शुरू कर देता है, और यहां वह है जो मुझे अभी तक मिल सकता है।
उदाहरण इंटरफ़ेस @millsp https://github.com/microsoft/TypeScript/issues/1213#issuecomment -523245130 से है, निष्कर्ष वास्तव में मददगार है, इसके लिए बहुत धन्यवाद।

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

यह एचकेटी / फंक्शन प्रोग्रामिंग / लैम्ब्डा के बारे में कुछ जानकारी प्रदान करने के लिए भी मीठा होगा (जब मैं lambda कहता हूं, मेरा मतलब है कि गणित, मैं केवल गणित के बिना, कुछ भाषा द्वारा लिखित उदाहरण पा सकता हूं)

यहां ऐसी चीजें हैं जो मेरी बहुत मदद करती हैं:

• http://adriaanm.github.io/files/higher.pdf
  
  
  
  • इस पेपर में BNF के अनुसार पार्सर को बदलें।
  
  

@ShuiRuTian उस m.join(q) Set<unknown> लौटाने के संबंध में, मुझे लगता है कि --noImplicitAny कारण बनता है कि चेतावनी भी छोड़ दें?

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

यह एचकेटी / फंक्शन प्रोग्रामिंग / लैम्ब्डा के बारे में कुछ जानकारी प्रदान करने के लिए भी मीठा होगा (जब मैं lambda कहता हूं, मेरा मतलब है कि गणित, मैं केवल गणित के बिना, कुछ भाषा द्वारा लिखित उदाहरण पा सकता हूं)

किसी भी आगे जाने के बिना, मैंने हाल ही में एक जेनेरिक करी filter फंक्शन बनाने की कोशिश की, और मैं चाहता था कि इसके लिए कुछ किया जाए:

const filterNumbers = filter(
    (item: number | string): item is number => typeof item === "number"
);

const array = ["foo", 1, 2, "bar"]; // (number | string)[]
const customObject = new CustomObject(); // CustomObject<number | string>

filterNumbers(array); // number[] inferred
filterNumbers(customObjectWithFilterFunction); // CustomObject<number> inferred

और मेरे पास वास्तव में ऐसा करने का कोई तरीका नहीं है, क्योंकि मुझे टाइपस्क्रिप्ट कहने का एक तरीका चाहिए "जो आपको प्राप्त हुआ है उसी प्रकार को लौटाएं, लेकिन इस अन्य पैरामीटर के साथ"। कुछ इस तरह:

const filter = <Item, FilteredItem>(predicate: (item: Item) => item is FilteredItem) =>
  <Filterable<~>>(source: Filterable<Item>): Filterable<FilteredItem> => source.filter(predicate);

@lukeshiru हाँ, अनिवार्य रूप से यह https://pursuit.purescript.org/packages/purescript-filterable/2.0.1/docs/Data.Filterable#v : फ़िल्टर है
टाइपस्क्रिप्ट में एचकेटी के लिए इसी तरह के अन्य बहुत सारे यूजेस हैं।

@isiahmeadows मैंने इसे आज़माया। तुम सही हो।
@lukeshiru और @raveclassic धन्यवाद! यह सुविधा बहुत गूंजनीय लगती है। Https://gcanti.github.io/fp-ts/learning-resource/ पढ़ने के बाद इस पर मेरी नज़र होगी

मैं अटक कर रहा हूँ और मैं नहीं जानता कि वर्तमान ⸘workaround‽ है क्या ...
मैं चेन विनिर्देश को लागू करने की कोशिश कर रहा हूं:

m['fantasy-land/chain'](f)

एक मान जो श्रृंखला विनिर्देश को लागू करता है उसे भी लागू विनिर्देश को लागू करना चाहिए।

a['fantasy-land/ap'](b)

मैंने FunctorSimplex किया, जो बाद में FunctorComplex बढ़ाया गया, फिर Apply बढ़ाया गया, लेकिन अब मैं Apply Chain Apply रूप में बढ़ाना चाहता हूँ Chain यह टूट रहा है ...

इसलिए मुझे इसकी आवश्यकता है (नीचे छवि और कोड से लिंक):

(मुझे ApType एक प्रकार पास करने की आवश्यकता है ताकि लाइन 12 Apply «हार्डकोड» नहीं है, लेकिन सामान्य है ... किसी भी प्रकार को IApply से विस्तारित करने के लिए।

7ff8b9c में कोड स्निपेट

`` `टाइपप्रति
निर्यात प्रकार ApType = ( एपी: लागू करें <(वैल: ए) => बी>, ) => IApply ;

/ * [...] * /

निर्यात इंटरफ़ेस IApply का विस्तार FunctorComplex {
/ ** Fantasy-land/ap :: Apply f => f a ~> f (a -> b) -> f b * /
एपी: एपाइप ;
}
`` `

एक ढेर अतिप्रवाह प्रश्न में संदर्भित: टाइपस्क्रिप्ट जेनेरिक प्रकार समस्या: वर्कअराउंड आवश्यक