Object. फ़ंक्शंस के अलावा कुछ API की सूची बनाना उपयोगी होगा जो इससे लाभान्वित होंगे।

जावास्क्रिप्ट कोर एपीआई में Object को छोड़कर शायद कुछ es6 कंस्ट्रक्शन को इससे (WeakMap, Proxy आदि) फायदा होगा।
लेकिन उदाहरण के लिए हर अंडरस्कोर संग्रह फ़ंक्शन भी बेहतर टाइपिंग प्राप्त करेगा, जैसे कि रिएक्ट एक 'सेटस्टैट' पद्धति का उपयोग करता है जो केवल ऑब्जेक्ट या null , ImmutableJS, मोरी आदि को स्वीकार करते हैं।

संपादित करें: किसी भी प्रकार के साथ अंडरस्कोर संग्रह कार्य

सुझाव समीक्षा बैठक में चर्चा की गई। यह सब समझ में आता है, लेकिन हमें एक नए आदिम प्रकार की जटिलता को सही ठहराने की आवश्यकता है, जिसमें यह वर्णन करने में सक्षम त्रुटियों / समृद्धि की संख्या है। मूल रूप से, एपीआई के और उदाहरण जो प्राथमिकताओं पर काम नहीं कर सकते, विशेष रूप से वे जो "विशेषज्ञ" एपीआई नहीं हैं (उदाहरण के लिए प्रॉक्सी)

सिफारिश से अधिक संदर्भ के रूप में पोस्टिंग: पलक:

interface String { _primitiveBrand?: string; }
interface Boolean { _primitiveBrand?: boolean; }
interface Number { _primitiveBrand?: number; }

interface ObjectOnly {  _primitiveBrand?: void; }

function fn(x: ObjectOnly) { }

// Error
fn(43);
// Error
fn('foo');
// OK
fn({});
// OK
fn(window);

इस प्रस्ताव पर +1। मैं WeakMap एक "विशेषज्ञ" एपीआई पर विचार नहीं करूंगा, लेकिन मैं इसे लागू करने के लिए इसे पर्याप्त कारण मानता हूं। चूंकि रनटाइम ऑब्जेक्ट प्रकारों और आदिम प्रकारों के बीच अंतर करता है, इसलिए यह केवल टाइपस्टस्क्रिप्ट में सुविधा के साथ-साथ अंतर बनाने के लिए भी समझ में आता है।

यह प्रस्ताव "ऑब्जेक्ट बैग" टाइप करने की समस्या को भी हल करेगा जहां प्रत्येक संपत्ति वैकल्पिक है, लेकिन अन्य आदिम प्रकारों को बंद कर दिया जाना चाहिए।

Object.observe लिए एक गैर-आदिम लक्ष्य की भी आवश्यकता होती है: http://arv.github.io/ecmascript-object-observe/#Object.observe

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

let isObject (x) => typeof x === "object";

एमडीएन के अनुसार, यह typeof का आउटपुट है:

अपरिभाषित : "अपरिभाषित"
अशक्त : "वस्तु" (नीचे देखें)
बूलियन : "बूलियन"
संख्या : "संख्या"
स्ट्रिंग : "स्ट्रिंग"
प्रतीक (ECMAScript 2015 में नया) : "प्रतीक"
मेजबान वस्तु (जेएस पर्यावरण द्वारा प्रदान की गई) : कार्यान्वयन-निर्भर
फंक्शन ऑब्जेक्ट (औजार [[कॉल]] ECMA-२६२ शब्दों में) : "फ़ंक्शन"
कोई अन्य वस्तु : "वस्तु"

इस प्रकार के बिना, उपर्युक्त गार्ड के लिए सटीक प्रकार से मिलान करने का कोई तरीका नहीं है, यहां तक ​​कि उपयोगकर्ता-परिभाषित गार्ड के रूप में भी नहीं। यह किसी भी फ़ंक्शन के साथ उपयोग करने के लिए भी आवश्यक है, जिसमें कड़ाई से एक ऑब्जेक्ट की आवश्यकता होती है जिसमें गुण होते हैं और for in लूप और Object प्रोटोटाइप के लिए कॉल करते हैं, और T extends object जैसे सामान्य बाधाओं को लागू करने के लिए और फिर सुरक्षित रूप से गुणों को संदर्भित करना या प्रोटोटाइप फ़ंक्शंस का उपयोग करना।

फ़ंक्शंस और कंस्ट्रक्टर होने के बावजूद, कुछ मामलों में थोड़ा सीमित होगा, इसलिए एक और प्रकार हो सकता है जिसमें उन्हें भी शामिल किया जाएगा और _ "गैर-आदिम ऑब्जेक्ट प्रकार" _ कहा जाएगा। एक आंशिक समाधान यूनियन object | Function हो सकता है, हालांकि इसे सही ढंग से संभालने के लिए कलाकारों या अतिरिक्त गार्ड की आवश्यकता होगी।

पीआर स्वीकार कर रहे हैं। यह एक आम समस्या लगती है; यह किसी भी बहादुर के लिए एक ब्रेकिंग परिवर्तन होगा जो interface object { ... } लिखा होगा। कार्यान्वयन सीधा होना चाहिए और ऊपर उल्लिखित नियमों का पालन करना चाहिए।

साइड नोट: हम सभी सोच रहे हैं कि @fdecampredon कहां है!

@RyanCavanaugh कार्य के शहर का परिवर्तन, और दुर्भाग्य से मेरी नई नौकरी में बहुत सी टाइपस्क्रिप्ट नहीं: डी

महान। मैं TS1.8 में इस प्रकार का उपयोग करना चाहता हूं।

मैं भी object प्रकार की तरह कुछ देखना चाहूंगा। हालाँकि, मैं सवाल करता हूं कि क्या यह typeof value === 'object' अनुरूप होना चाहिए, क्योंकि यह फ़ंक्शन को बाहर करेगा। इसके बजाय, यह मुझे लगता है कि संभावित object प्रकार को ऑब्जेक्ट भाषा के प्रकार को प्रतिबिंबित करना चाहिए, जिसमें फ़ंक्शन शामिल हैं। इसके लिए कुछ कारण हैं:

• एपीआई जो सादे वस्तुओं को हमेशा स्वीकार करते हैं, जहां तक ​​मुझे पता है, कार्यों को भी स्वीकार करते हैं।
• कार्य Object निर्माता से विरासत में मिलते हैं।

मैं इन्हें क्रम में लूंगा।

शहद की मक्खी

API जैसे WeakMap जो केवल ऑब्जेक्ट्स को लेते हैं, वे ऑब्जेक्ट भाषा के प्रकार को स्वीकार करते हैं, न कि केवल सादे ऑब्जेक्ट्स को। निम्नलिखित ठीक है:

function theAnswer() {}

let map = new WeakMap();

map.set(theAnswer, 42);
console.log(map.get(theAnswer)); // 42

यह कस्टम API के लिए उतना ही सही है, जितना कि बिल्ट-इन API के लिए है। अगर मुझे किसी वस्तु की उम्मीद है, तो मैं आमतौर पर केवल गुणों का एक बंडल चाहता हूं। कार्य गुण के केवल कॉल करने योग्य बंडल हैं।

विरासत

चूँकि Function Object कन्स्ट्रक्टर का विस्तार करता है, Object पर उपलब्ध स्थिर और आवृत्ति विधियों का भी उपयोग कर सकते हैं। उदाहरण के लिए, निम्नलिखित संभव है:

class DeepThought {
  static getAnswer() {
    return 42;
  }
}

let computer = Object.create(DeepThought);

console.log(computer.getAnswer()); // 42
console.log(Object.getPrototypeOf(computer)); // [Function: DeepThought]

जबकि ऊपर का उदाहरण थोड़ा मूर्खतापूर्ण है, यह सिर्फ उस एपीआई को दिखाता है जो Object विधियों का आंतरिक रूप से उपयोग करता है और साथ ही साथ कार्यों को स्वीकार भी कर सकता है।

इसलिए मैं सुझाव दूंगा कि object प्रकार निम्नलिखित के अनुरूप है, जो ऑब्जेक्ट भाषा प्रकार से मेल खाती है (सिवाय इसके कि इसमें null , लेकिन टाइपस्क्रिप्ट में null मुकाबले कोई रखवाली नहीं होती है किसी भी स्थिति में)।

function isObject(value) {
  return typeof value === 'object' || typeof value === 'function';
}

उदाहरण

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

interface NonPrimitive {
  [key: string]: any;
  [index: number]: any;
}

export class DeepMap {
  // ...
  private mapObject(obj: NonPrimitive): NonPrimitive { /* ... */ }
}

यह पहली बार नहीं है जब मुझे NonPrimitive इंटरफ़ेस को परिभाषित करना पड़ा है। यह अच्छा होगा अगर मैं बस ऐसा कर सकता हूं:

export class DeepMap {
  // ...
  private mapObject(obj: object): object { /* ... */ }
}

जैसा कि मैंने ऊपर सुझाव दिया है, मुझे वास्तव में परवाह नहीं है कि obj पैरामीटर कॉल करने योग्य है या नहीं। यह सब मायने रखता है कि यह Object _language type_ है, अर्थात, यह उन संपत्तियों का एक बंडल है, जिनके प्रमुख-मूल्य जोड़े मैं इसके माध्यम से पुनरावृत्ति कर सकता हूं।

मैं सहमत हूँ कि कार्य object s हैं। अभिप्राय आदिम को बाहर करना है।

ठीक है, मैंने सोचा था कि इरादा रहा होगा। मुझे लगा कि शायद मैं typeof value === 'object' की इस बात के साथ कुछ याद कर रहा था।

क्या यह object प्रकार को तदर्थ संपत्ति असाइनमेंट (जैसे any ) की अनुमति देगा? उदाहरण के लिए:

const foo: object = {};

foo.bar = 'baz';

नहीं

क्या व्यावहारिक अंतर है

export class DeepMap {
  // ...
  private mapObject(obj: object): object { /* ... */ }
}

तथा

export class DeepMap {
  // ...
  private mapObject(obj: Object): Object { /* ... */ }
}

? ( object बनाम Object )। यह मुझे लगता है कि Function Object से फैली हुई है, इसलिए मैं यह नहीं देखता कि हम पहले से ही ऐसा क्यों नहीं कर सकते। क्या तुम समझा सकते हो?

@trusktr null और undefined अलावा सभी मान Object प्रकार के लिए असाइन किए जाते हैं; एक फ़ंक्शन जो Object स्वीकार करता है वह एक स्ट्रिंग, संख्या, बूलियन या प्रतीक ले जाएगा। केवल गैर-आदिम मूल्य object लिए असाइन किए जाते हैं; एक स्ट्रिंग, आदि पारित करना, एक संकलन-समय त्रुटि पैदा करेगा। object प्रकार उपयोगी है जहां हम एक गैर-आदिम मूल्य की उम्मीद करते हैं, लेकिन जहां हमें परवाह नहीं है कि इसके गुण क्या हैं।