Moment: पल को ज्यादातर अपरिवर्तनीय बनाएं

मेरे दो सेंट यह है कि हमें या तो पूर्ण-अपरिवर्तनीयता के लिए जाना चाहिए या बिल्कुल नहीं। कुछ विधियों का अपरिवर्तनीय होना ( startOf , add ) और कुछ नहीं ( year , get ) केवल भ्रमित करने वाला है, और डेवलपर्स को इसका ट्रैक रखना होगा कौन से हैं।

मैं डिफ़ॉल्ट रूप से अपरिवर्तनीय सब कुछ भी पसंद करूंगा। क्या गेटर्स पहले से ही अपरिवर्तनीय नहीं हैं?

यहाँ बड़े मुद्दे हैं जो मुझे अपरिवर्तनीयता पर स्विच करने के साथ दिखाई दे रहे हैं।

छद्म अपरिवर्तनीयता

जावास्क्रिप्ट की प्रकृति के कारण, हम कभी भी वास्तविक अपरिवर्तनीयता प्राप्त करने में सक्षम नहीं होंगे।

सबसे अच्छा हम एक कॉपी बना सकते हैं और फिर उस कॉपी को म्यूट करके वापस कर सकते हैं। हम यह सुनिश्चित करने के लिए सभी सार्वजनिक तरीकों को सावधानी से लपेट सकते हैं कि हम केवल उत्परिवर्तित करने के बजाय हमेशा नकल और परिवर्तन कर रहे हैं, लेकिन यह किसी को m._d = new Date() या यहां तक ​​कि m._d.setHours(1) करने से नहीं रोकता है।

मैं @icambron से सहमत बढ़ते हैं , तो यह एक पूर्ण परिवर्तन होना चाहिए। कोई भी तरीका जो संभवतः एक पल में एक संपत्ति को बदल सकता है, इसके बजाय पल की एक प्रति बनाएगा और इसके बजाय कॉपी में बदलाव करेगा।

एपी सतह क्षेत्र

छद्म अपरिवर्तनीयता पर स्विच करने के बारे में दुर्भाग्यपूर्ण बात यह है कि अगर हम अभी भी परिवर्तनशीलता का समर्थन करना चाहते हैं तो कई नए एपिस बनाने की जरूरत है।

इससे पहले, एक पल को बदलने से क्लोनिंग और एक पल को बदलने के लिए सही जगह पर .clone() जोड़ने जितना आसान था। अब, हमें सभी सेटर्स के लिए परिवर्तनशील इंटरफेस बनाना होगा, जो एपीआई सतह क्षेत्र में काफी वृद्धि करता है।

इसमें ~20 सेटर विधियां, जोड़ें/घटाना, स्थानीय/यूटीसी/जोन/टीजेड, स्टार्टऑफ/एंडऑफ, लैंग, और तृतीय पक्ष प्लगइन्स में उपयोग की जाने वाली कोई अन्य विधियां शामिल हैं।

स्मृति चिंताएं

क्योंकि अब हम हर बार जब हम कोई मान बदलना चाहते हैं तो कॉपी बना रहे हैं, मेमोरी का उपयोग बढ़ जाएगा। बेशक, नए पलों में कचरा इकट्ठा किया जाएगा, लेकिन इस बदलाव से जुड़ी अतिरिक्त लागत को ध्यान में रखना चाहिए।

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

यह ट्रैक करने के लिए कि किन विधियों को बुलाया जा रहा है, मैंने इस छोटे से फ़ंक्शन रैपर का उपयोग किया।

for (var method in moment.fn) {
  moment.fn[method] = (function (fn, method) {
    return function () {
      console.log(method);
      return fn.apply(this, arguments)
    }
  })(moment.fn[method], method)
}

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

moment().isSame(moment(), 'year')
isSame
clone        // clone
startOf      // clone
month        // clone
date         // clone
year         // clone
date         // clone
hours        // clone
minutes      // clone
seconds      // clone
milliseconds // clone
valueOf
local        // clone
zone         // clone
startOf      // clone
month        // clone
date         // clone
year         // clone
date         // clone
hours        // clone
minutes      // clone
seconds      // clone
milliseconds // clone
valueOf

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

प्रदर्शन संबंधी चिंताएं

एक पल को क्लोन करना एक पल को बदलने की तुलना में बहुत धीमा है। मैंने इसके लिए कुछ jsperf परीक्षणों को एक साथ फेंक दिया।

http://jsperf.com/moment-cloning

http://jsperf.com/moment-cloning-2

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

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

सारांश

अपरिवर्तनीयता पर स्विच करने से आंतरिक और बाहरी एपिस की जटिलता बहुत बढ़ जाती है और इसमें प्रमुख प्रदर्शन और स्मृति संबंधी चिंताएं होती हैं। मुझे नहीं लगता कि वे लागतें उन लाभों के लायक हैं जो अपरिवर्तनीयता प्रदान करेंगे।

मुझे लगता है कि यहां सूचीबद्ध प्रदर्शन चिंताओं में यह बात नहीं है:

आम तौर पर, उत्परिवर्तन करने से पहले शुद्धता सुनिश्चित करने के लिए प्रारंभिक .clone() की आवश्यकता होती है।

हम वर्तमान एपीआई के साथ क्लोन() की आवश्यकता नहीं होने का नाटक नहीं कर सकते हैं। यहां मुख्य मामला जो अलग है वह कई अनुक्रमिक उत्परिवर्तन कर रहा है। उस मामले को एक बिल्डर एपीआई बनाकर संबोधित किया जाता है जैसे कि सभी उत्परिवर्तन एक क्लोन पर उत्परिवर्तन के रूप में किए जाते हैं।

क्या मुझे अन्य सामान्य उपयोग के मामले याद आ रहे हैं?

मेरा मूल मुद्दा विशेष रूप से startOf और endOf विधियों के बारे में था। किसी कारण से मेरे लिए ये नाम "मुझे एक महीने की शुरुआत करें" की तरह थे, न कि "इस पल को एक महीने की शुरुआत में सेट करें"। add और subtract जैसे तरीके पूरी तरह से ठीक हैं जिस तरह से वे शब्दार्थ के अर्थ में हैं। किसी ऑब्जेक्ट में कुछ नया बनाए बिना कुछ जोड़ना बिल्कुल ठीक है।
मेरे लिए व्यक्तिगत रूप से startOf और endOf का नाम बदलकर toStartOf और toEndOf (जैसे "इस पल को एक महीने की शुरुआत में ले जाएं") का समाधान होगा मुद्दा। IMHO

@gregwebs क्षमा करें, मेरा मतलब ऊपर set ।

मैं @soswow से असहमत हूं; मुझे लगता है कि इसे सुसंगत रहने की जरूरत है। वास्तव में, मुझे लगता है कि toStartOf अपरिवर्तनीयता को और भी अधिक दृढ़ता से दर्शाता है, जैसे कि यह एक वैकल्पिक प्रस्तुति प्रदान कर रहा है a la toISOString । इससे भी महत्वपूर्ण बात यह है कि मुझे लगता है कि हमें "पल के सेटर्स म्यूटेट मोमेंट्स" या "मोमेंट्स सेटर्स रिटर्न कॉपी" जैसे बयान देने में सक्षम होना चाहिए, न कि "ठीक है, इन तरीकों के लिए ..."

@timrwood की चिंताओं पर:

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

सतह क्षेत्र और पूर्ण के बारे में: मुझे लगता है कि हमें उस सभी सीपीयू और मेमोरी [1] का उपयोग करने से बचने के लिए आंतरिक रूप से म्यूटेटर का उपयोग करने की आवश्यकता होगी, इसलिए हमें किसी स्तर पर उनका समर्थन करना होगा। फिर हम उन्हें बाहरी रूप से बेनकाब कर सकते हैं, जैसे setYear() , आदि। यह सतह क्षेत्र का एक गुच्छा जोड़ता है, लेकिन यह वास्तव में बहुत जटिलता नहीं जोड़ता है; गैर-स्पष्ट-म्यूटेटर के लिए, बाहरी रूप से क्लोन करें, आंतरिक रूप से उत्परिवर्तित करें।

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

[१] एफपी भूमि में शांत बच्चे इसे _स्ट्रक्चरल शेयरिंग_ के साथ हल करते हैं, लेकिन यह शायद यहां अव्यावहारिक है।

[२] परंपरागत रूप से, लोग बिल्डर्स बनाते हैं जो अलग-अलग ऑब्जेक्ट होते हैं, लेकिन यह वास्तव में यहां वर्बोज़ होगा, क्योंकि आपको पूरे सेटर एपीआई को कॉपी करना होगा। बस स्पिटबॉलिंग, लेकिन एक विकल्प यह है कि .chain() एक क्लोन पल बनाता है जिस पर बस isBuilding ध्वज सेट होता है। फिर आंतरिक क्लोन को नजरअंदाज कर दिया जाता है, बस वस्तु को उत्परिवर्तन के लिए वापस कर दिया जाता है। फिर build() ध्वज को अनसेट करता है और उस क्लोन को लौटाता है। परेशानी यह है कि अगर झंडा फहराया जाता है तो आपको खूनी हत्या चिल्लाने के लिए अपने गेटर्स की आवश्यकता होती है, या लोग जंजीर लेकिन अनबिल्ट मोमेंट्स का उपयोग कर समाप्त कर देंगे जो अचानक परिवर्तनशील होते हैं। फिर आपको बाहरी और आंतरिक रूप से गेटर्स नामक अंतर करने की आवश्यकता है। ब्लीच। एक अन्य विकल्प यह है कि बिल्डर द्वारा आवश्यक कार्यक्षमता को एक मिक्सिन में आंतरिक रूप से विघटित किया जाए और इसे बिल्डर और मोमेंट दोनों में उपयोग किया जाए, लेकिन यह शायद कोड-संगठन के दृष्टिकोण से व्यावहारिक नहीं है।

मेरे लिए क्या काम किया, कार्यों के लिए एक अतिरिक्त पैरामीटर जोड़ रहा था, एक ध्वज (मैंने स्वयं नाम दिया) उत्परिवर्तन को इंगित करने के लिए, डिफ़ॉल्ट रूप से अपरिवर्तनीय है (एक प्रतिलिपि या नई वस्तु लौटाएं), और जब मैं परफॉर्मेंस का पता लगाता हूं तो मैं ध्वज को सत्य पर सेट करता हूं

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

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

एक मूल उदाहरण जो यहां हो सकता है:
पल। जोड़ें = फ़ंक्शन (माप, राशि, स्वयं) {
}

पल। जोड़ें = फ़ंक्शन (माप, राशि, स्वयं) {
वर $ पल = स्वयं? यह: यह। क्लोन ();
// वास्तविक कोड
$ पल वापस करें;
}

उनके 2 सेंट के लिए सभी को धन्यवाद :)

प्रोटोकॉल के लिए, मैं सभी बिंदुओं पर @icambron की अंतिम पोस्ट पर सहमत हूं।

दो बड़े सवाल बाकी हैं।

नया एपीआई क्या होना चाहिए, यह आसान है, दो विकल्प:
1.1 अलग-अलग नामित तरीके (परिवर्तनीय और अपरिवर्तनीय) year / setYear , startOf / setStartOf
1.2 या बिल्डर एपीआई chain().mutators().build() , जो कि @lfnavess द्वारा प्रस्तावित गैर-

बिल्डर एपीआई निश्चित रूप से कामुक दिखता है, लेकिन इस बात का ध्यान रखा जाना चाहिए कि ऑब्जेक्ट बहुत लंबे समय तक बिल्ड मोड में न रहें, जो हमारे और उपयोगकर्ताओं के लिए परेशानी का एक और स्रोत जोड़ता है।

अब कठिन समस्या - नए संस्करण में माइग्रेट करना। मुझे यहां दो विकल्प दिखाई देते हैं:
2.1 देवों को अपना कोड फिर से लिखना होगा (पागल रेगेक्स 1.1 में काम कर सकता है और 1.2 के लिए एएसटी-स्तरीय समाधान - कोई भी year और month का उपयोग अपने तरीकों के नाम के रूप में नहीं करता है)। अजगर ने यह तरीका अपनाया - हम सभी परिणाम देख सकते हैं - एक नई भाषा का जन्म हुआ!
2.2 बिल्डर एपीआई को हमेशा चालू करने का विकल्प (अब जैसा ही), और नए कोड के लिए इसे निष्क्रिय करने का एक तरीका। यह अधिक _evolutionary_ दिखता है, लेकिन इससे जितना भ्रम होगा, वह शायद इसके लायक नहीं है। हर पल में अब दो झंडे हैं: क्या यह परिवर्तनशील है, और यदि यह है - क्या यह सख्ती से परिवर्तनशील (कोई गेटर्स नहीं) या संक्रमणीय रूप से परिवर्तनशील (गेटर्स ओके) है। कार्यों में क्षण वस्तुओं को प्राप्त करने का उल्लेख नहीं करना - आपको जांचना चाहिए कि मोड क्या है, इसे बनाए रखना सुनिश्चित करें ... क्या गड़बड़ है!

और अब एक पागल विचार जो अब मेरे पास आया

कॉपी-ऑन-राइट क्लोन

m = moment();
funcIDontTrust(m.clone());  // doesn't actually clone

function funcIDontTrust(m) {
  m.year(2005);  // perform the clone here
  console.log(m);
}

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

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

मुझे यकीन नहीं है कि हम यहां क्या हासिल कर रहे हैं।

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

मुख्य लाभ डेवलपर वरीयता प्रतीत होते हैं। क्या यह सब इसलिए है कि डेवलपर्स के पास नहीं है
एक पल के स्वामित्व के बारे में सोचने के लिए इसे पास करते समय?

मुझे नहीं लगता कि अपरिवर्तनीयता पर स्विच करने से बग कम हो जाएंगे, यह उचित होगा
बग के प्रकार को बदलें। @ichernev का उदाहरण सटीक प्रकार की बग दिखाता है जो होगा
सतह, जिसे ट्रैक करना उतना ही कठिन है।

m = moment();
funcIDontTrust(m.clone());  // doesn't actually clone

function funcIDontTrust(m) {
  m.year(2005);  // perform the clone here
  // m is still in 2014
  // m.year(2005) created a clone but did not assign it to anything
  // it should be `m = m.year(2005)`
  console.log(m);
}

यहाँ परिवर्तनशीलता और अपरिवर्तनीयता के बीच एक पेशेवर/विपक्ष सूची है। अगर मुझे कुछ याद आया,
मुझे बताएं और मैं इस टिप्पणी को संपादित करूंगा।

| अपरिवर्तनीय | परिवर्तनशील |
| --- | --- |
| कुछ देव इसे पसंद करते हैं | कुछ अन्य देव इसे पसंद करते हैं |
| पल-पल गुजरते समय कीड़ों से बचा जाता है | क्लोन किए गए पलों को असाइन करना भूल जाने पर बग से बचा जाता है |
| कुछ दर्जन नई एपीआई विधियों के साथ, परिवर्तनशीलता का भी समर्थन किया जाएगा | मौजूदा .clone() पद्धति के साथ, अपरिवर्तनीयता पहले से ही समर्थित है |
| | परिमाण का एक क्रम तेज |
| | काफी कम मेमोरी का उपयोग करता है |

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

typeof a === "object" बिल्ट-इन के लिए अधिकांश एपिस परिवर्तनशील हैं। Array#push,pop,reverse,sort,shift,splice,unshift सभी एक नई सरणी को वापस करने के बजाय एक सरणी की सामग्री को बदलते हैं। Date#setX विधियों में से सभी 16 अपने उदाहरण को बदल देती हैं।

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

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

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

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

var newM = m.year(2005) // wrong, these are both the same!

तो अपरिवर्तनीय और परिवर्तनीय दोनों में अभी एक ही समस्या है। यदि आप चेनिंग एपीआई से छुटकारा पा लेते हैं तो आप वर्तमान परिवर्तनशील संस्करण से बच सकते हैं।

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

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

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

यह बहुत स्पष्ट है कि आपने अपरिवर्तनीय उपयोग के मामले को समझने के लिए समय नहीं लिया है

यह अनुचित बयान है। मेरा तर्क यह है कि मैं लाभ देखता हूं, लेकिन यह नहीं सोचता कि वे लागत से अधिक हैं।

आप कार्यों के बीच सुरक्षित रूप से एक पल गुजार सकते हैं

हमें क्लोन कॉल करना याद रखने की आवश्यकता नहीं है

क्या यह अपरिवर्तनीयता के लिए उपयोग का मामला नहीं है? यदि इसके अलावा और भी कुछ है जिसे समझने के लिए मैंने समय नहीं लिया है, तो कृपया मुझे बताएं, लेकिन पिछले कुछ वर्षों से यह एकमात्र तर्क प्रतीत होता है।

@timrwood हाँ, यह पूरा मामला है।

लेकिन मुझे आपकी ओर से यह स्वीकार करते हुए कोई संकेत नहीं दिख रहा है कि आपका मामला _against_ अपरिवर्तनीयता (भयानक प्रदर्शन, एक अलग प्रकार की बग को बढ़ावा देता है जो कि परिवर्तनशील एपीआई में मौजूद नहीं है) मान्य नहीं है।

मुझे नहीं पता कि फ्रीज () मदद कर सकता है या नहीं?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze

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

http://blogorama.nerdworks.in/preventextensionssealandfreeze/

फ्रीज ऑब्जेक्ट बनाने के लिए कंस्ट्रक्टर में एक अतिरिक्त पैरामीटर हो सकता है, क्योंकि फ्रीज ऑब्जेक्ट को अनफ्रीज नहीं किया जा सकता है

@lfnavess मैंने लिखने पर प्रतिलिपि का उल्लेख करने से पहले freeze बारे में सोचा। समस्या यह है कि ... कोई भी इसका उपयोग नहीं करता है / इसके बारे में जानता है, न ही यह तब मदद करता है जब यह अपवाद नहीं फेंकता (गैर-सख्त मोड में) - यह वास्तव में आपके लिए ट्रैक करने के लिए पागल बग बनाता है।

@timrwood मुझे नहीं लगता कि मैंने अपना उदाहरण स्पष्ट कर दिया है। लाइन पर m.year(2014) // clone here मेरा मतलब था कि आंतरिक रूप से पल वास्तव में एक क्लोन (अधिक मेमोरी आवंटित) करेगा और एम स्वचालित रूप से उस नई मेमोरी को इंगित करेगा। वैसे इसका मूल रूप से मतलब है कि clone() को थोड़ी सी शेल मेमोरी भी आवंटित करनी चाहिए (आंतरिक तिथि प्रतिनिधित्व को इंगित करने के लिए कुछ), मुझे यकीन नहीं है कि ऐसा करने से कितना प्राप्त होगा।

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

मौजूदा पुस्तकालयों/पल के उपयोगकर्ताओं को माइग्रेट करने से निपटने के तरीके पर मुझे कोई टिप्पणी नहीं मिली। मुझे ऊपर सूचीबद्ध किए गए विकल्पों में से कोई भी वास्तव में पसंद नहीं है।

रिवर्स-संगतता, आईएमओ, इसके खिलाफ सबसे मजबूत तर्क है। अगर हम ऐसा करते हैं, तो हमें बस यह स्वीकार करना होगा कि यह एक बड़ा ब्रेकिंग बदलाव है। अगर हम इसे स्वीकार नहीं करना चाहते हैं, तो हमें ऐसा नहीं करना चाहिए।

यह फिर से ध्यान देने योग्य है: perf कि कुछ बड़े फायदे भी हैं जिन्हें आप अपरिवर्तनीयता से प्राप्त कर सकते हैं; यह एक मोनोटोनिक पूर्ण हिट नहीं है। उदाहरण के लिए, आप वस्तु स्तर पर चीजों को कैश कर सकते हैं, क्योंकि वे कभी नहीं बदलेंगे। मुझे यह भी लगता है कि हमें clone() में से जीवित बकवास को अनुकूलित करने में सक्षम होना चाहिए; AFAIK इसमें एक तारीख को क्लोन करना और पांच मानों की तरह प्रतिलिपि बनाना शामिल है; मुझे लगता है कि हमें उन्हें केवल newThing._offset = oldThing._offset तरह हार्डकोड करना चाहिए।

संपादित करें, तर्क, नहीं - प्लगइन्स फ़ील्ड भी जोड़ते हैं (उदाहरण के लिए यहां )।

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

इसके अलावा: पुन: संरचनात्मक साझाकरण पर @ichernev का विचार, एक संभावना साझा राज्य वस्तु को लपेटने के बजाय प्रोटोटाइप विरासत का उपयोग करना है।

हम व्हूपइंक पर काफी समय से इस चर्चा में दुबके हुए हैं। चूंकि यहां चर्चा मंडलियों में हो रही है, इसलिए मुझे इस सप्ताह के अंत में यह पता लगाने में कुछ समय लगा कि बिल्डर एपीआई के साथ पल का अपरिवर्तनीय संस्करण कैसा दिख सकता है। (जब तक मुझे ऐसा करने के लिए आमंत्रित नहीं किया जाता है, तब तक मैं पल के खिलाफ पीआर जमा करने का कोई इरादा नहीं रखता, क्योंकि मैं जानबूझकर और अधिक कठोर एपीआई परिवर्तन कर रहा हूं, जिसे मैं कभी भी पल में लागू करने की अपेक्षा करता हूं।) यहां परिणाम है: https://github। कॉम/व्हूपइंक/फ्रोजन-मोमेंट

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

मैं आज रात उस रेपो पर कुछ अद्यतन दस्तावेज़ प्रकाशित करने का प्रयास करूंगा, लेकिन मूल रूप से मैंने सभी सेटर और उत्परिवर्तन विधियों को एक अलग बिल्डर ऑब्जेक्ट में विभाजित कर दिया है। तो एपीआई का उपयोग frozenMoment("2014-07-21").thaw().subtract(1, "day").startOf("day").freeze().format("YYYY-MM-DD") जैसा दिख सकता है। (हालांकि इस विशेष उदाहरण में frozenMoment.build("2014-07-21").subtract... का उपयोग करके किसी बिल्डर को फ्रोजनमोमेंट से प्रारंभ करने के बजाय केवल एक बिल्डर के साथ श्रृंखला शुरू करना अधिक कुशल होगा)

एफडब्ल्यूआईडब्ल्यू, जब मैंने पल का उपयोग करना शुरू किया तो मैंने मान लिया था कि यह एफपी सिद्धांतों का पालन करता है और हर बार जब मैं कोई फ़ंक्शन कॉल करता हूं तो वही मान वापस कर देगा:

var now = moment();
var yesterday = now.subtract(1, 'days');
var dayBeforeYesterday = now.subtract(2, 'days');

बेशक, मुझे अपेक्षित परिणाम नहीं मिले। इसने मुझे एक नए उपयोगकर्ता के रूप में बंद कर दिया।

इस छद्म कोड पर विचार करें, जो दर्शाता है कि मैंने कोड के व्यवहार की अपेक्षा कैसे की होगी:

var now = now;
var yesterday = now - 1day;
var dayBeforeYesterday = now - 2days;

लेकिन इसके बजाय यह इस तरह काम करना समाप्त कर दिया, जो मुझे अजीब लगता है:

var now = now;
var yesterday = now = now - 1day;
var dayBeforeYesterday = now = now - 2days;

अभी के लिए, हालांकि यह काफी थकाऊ है, मैं हर जगह केवल .clone() ध्यान से देखता हूं।

var now = moment();
var yesterday = now.clone().subtract(1, 'days');
var dayBeforeYesterday = now.clone().subtract(2, 'days');

आईएमओ, जावास्क्रिप्ट सूक्ष्म त्रुटियों से ग्रस्त है और मुझे लगता है कि एफपी सिद्धांत उन त्रुटियों को कम करने में मदद करते हैं।

मुझे सहानुभूति है कि यह एक कठिन निर्णय है। मैं आपके काम की सराहना करता हूं। Moment.js अद्भुत है।

100% अपरिवर्तनीयता के लिए +1।

यह अपरिवर्तनीय नहीं होने के कारण ईमानदारी से निराशाजनक है।

संस्करण ३ में १००% अपरिवर्तनीयता के लिए +1

निश्चित रूप से एक अपरिवर्तनीय एपीआई होना चाहिए। अन्य दिनांक पुस्तकालयों के उपयोगकर्ता के रूप में (विशेष रूप से, .NET DateTime और Joda Time / Noda Time), मैं सहज रूप से अपेक्षा करता हूं कि add विधि दिनांक वस्तु को परिवर्तित नहीं करेगी।

अपरिवर्तनीयता के लिए +1

100% अपरिवर्तनीयता के लिए +1

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

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

@dsherret यही सेवर है। हम सिर्फ प्रमुख संस्करण को टक्कर देंगे।

हालांकि, कुछ प्रयासों के साथ इसे कॉन्फ़िगरेशन विकल्प के रूप में पेश किया जा सकता है: "क्या आप सब कुछ अपरिवर्तनीय चाहते हैं? सही या गलत"। डिफ़ॉल्ट गलत होगा।

यहाँ असमर्थित अनौपचारिक ymmv अपरिवर्तनीय क्षण प्लगइन: https://gist.github.com/timrwood/fcd0925bb779f4374a7c

हाहा! मुझे बहुत बाद में यहां आकर आश्चर्य हुआ और पता चला कि मैं अधिक अपरिवर्तनीय एपीआई के पहले समर्थकों में से एक था .. :)

और हाँ, मैं अगले प्रमुख संस्करण के लिए अपरिवर्तनीयता के लिए +1 हूँ।

मेरे द्वारा अपरिवर्तनीय-दर-डिफ़ॉल्ट क्षण के लिए एक और +1।
और यहाँ मेरा 'इमोमेंट' मनगढ़ंत कहानी है: https://gist.github.com/idrm/a91dc7a4cfb381dca24e (अपने जोखिम पर उपयोग करें!)। बस अपने पल () कॉल को इमोमेंट () से बदलें और यह पर्याप्त होना चाहिए। सभी स्थिर क्षण। xyz () (जैसे क्षण। मिनट (), क्षण। अधिकतम (), आदि) फ़ंक्शन कॉल यथावत रहना चाहिए।

+1 मिलियन डॉलर

अपरिवर्तनीयता के लिए +1

क्या मैं कुछ कार्यों का नाम बदलने के लिए इस चर्चा धागे से पिछले सुझाव में +1 भी जोड़ सकता हूं ताकि उन्हें पढ़ना आसान हो ("स्टार्टऑफ" से "टूस्टार्टऑफ", "जोड़ें" से "प्लस", "महीना" से "साथ में" ", आदि।)? यही है, यह मानते हुए कि आप अपरिवर्तनीय-दर-डिफ़ॉल्ट मार्ग अपनाते हैं। मैं जोडा टाइम का बहुत उपयोग करता हूं, और यह पता लगाने के लिए एक स्नैप है, उदाहरण के लिए, "date.withDayOfMonth(1).withDayOfWeek(DateTimeConstants.MONDAY)" का अर्थ क्या है।
इन्हें मुख्य डिस्ट्रो जेएस में होना जरूरी नहीं है; एक ऐड-ऑन जो इन्हें वेनिला जेएस के शीर्ष पर थप्पड़ मारता है, ठीक उसी तरह काम करेगा (बिल्ली, मैं अपने "इमोमेंट" मॉड के साथ संयोजन करने के लिए इस तरह के जोडा टाइम-एलाइन ऐड-ऑन को लिखने पर दृढ़ता से विचार कर रहा हूं)।

@ichernev , @icambron , क्या आपने इस पर कोई निर्णय लिया है? क्या 3.0 में क्षण अपरिवर्तनीय होंगे? यदि हां: आप कब 3.0 के बाहर होने की उम्मीद करते हैं? मैं पूछ रहा हूं 'क्योंकि मैं फ्रोजन-मोमेंट का उपयोग करने या खुद एक छोटा आवरण लिखने पर विचार कर रहा हूं - और मुझे आश्चर्य है कि मुझे इंतजार करना चाहिए या नहीं।

FYI करें, फ्रोजन-मोमेंट ज्यादातर हाल ही में होल्डिंग पैटर्न में रहा है - मैंने अपस्ट्रीम मोमेंट से PRs का एक गुच्छा पोर्ट किया है, लेकिन वास्तव में किसी भी अन्य रिफैक्टरिंग पर काम नहीं किया है जो आदर्श रूप से उस कांटे में होना चाहिए।

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

एक बार जब हमारे पास मोमेंट 3.0 के लिए निर्णय हो जाता है, तो मैं मोमेंट में अपरिवर्तनीयता के काम पर, या फ्रोजन-मोमेंट फोर्क पर, जैसा उपयुक्त हो, थोड़ा और गंभीरता से काम करने की योजना बनाऊंगा। मेरा प्रारंभिक लक्ष्य लोकेल समर्थन को ठीक करना और मोमेंट 3.0 के एपीआई के साथ फीचर समानता बनाए रखना होगा।

अपरिवर्तनीयता के लिए +1

अपरिवर्तनीयता के लिए +1। format विधि के बारे में क्या है जो वस्तु को भी बदलता है?

एक अपरिवर्तनीय क्षण के लिए +1।js
या शायद पल का कांटा।जेएस? अपरिवर्तनीय-क्षण.जेएस? चूंकि यह निश्चित रूप से एक महत्वपूर्ण बदलाव होगा।

:100:
इमूटेबल्स करो!

+1 इन दिनों अपरिवर्तनीयता ऐसी चीज है जिसकी मैं किसी भी अच्छे JS API में अपेक्षा करता हूं

:+1: हाँ कृपया, हम इसे बहुत पसंद करेंगे। वर्तमान में हम हर जगह .clone() छिड़कते हैं।

+1 यह एक बहुत अच्छा सुधार होगा

:+1: अपरिवर्तनीय सभी चीजें

अपरिवर्तनीय के लिए +1

यह सब अपरिवर्तनीय बनाओ। मैं अब चर पर काम करने से पहले हर पल (अब) चर क्लोनिंग के बीमार हूँ और फिर अब फिर से बदल दिया गया है।

अपरिवर्तनीयता के लिए +1

मैंने startOf('day') को उत्परिवर्तित करने की अपेक्षा नहीं की होगी (हालाँकि मैं इसके अच्छी तरह से प्रलेखित होने को स्वीकार करूँगा यदि मैंने अधिक ध्यान से पढ़ा होता)। इससे मेरे आवेदन में एक मजेदार बग हो गया।

मैं निश्चित रूप से सहमत हूं कि अधिकांश क्षण.जेएस ऑपरेटर अपनी परिवर्तनशीलता में अजीब हैं। mmnt.startOf('day') सुपर काउंटर सहज ज्ञान युक्त है जो mmnt को उत्परिवर्तित करता है।

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

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

मेरे 2¢ :-)

@jdurand मैं स्पष्ट रूप से क्लोन के बजाय स्पष्ट रूप से उत्परिवर्तित करूंगा।

@dsherret मुझे स्पष्ट रूप से कुछ भी बुरा नहीं लगता। मेरी मुख्य चिंता परोक्ष रूप
किसी ने उल्लेख किया है कि बसने वालों को एक क्लोन कॉपी वापस करने की आवश्यकता होगी और इससे मुझे डर लगा; यह बहुत अक्षम होगा।

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

सिडेनोट: इस परिवर्तन के साथ मुझे लगता है कि कुछ प्रदर्शन सुधार किए जा सकते हैं ... उदाहरण के लिए, पिछली अपरिवर्तनीय वस्तु को संदर्भित करने के बजाय क्लोनिंग को समाप्त किया जा सकता है और फिर इस ऑब्जेक्ट के लिए किए जाने वाले ऑपरेशन को संग्रहीत किया जा सकता है (उदा। add(1, 'days') )। परिणाम की गणना केवल संचालन को निष्पादित करके की जाएगी जब .toString() , .format() , .toDate() , .day() , आदि... कहा जाता है। यह एक नाटकीय परिवर्तन होगा और यह तेजी से समाप्त नहीं हो सकता है ... प्रदर्शन की तुलना करने के लिए कुछ यूनिट परीक्षण करने की आवश्यकता होगी (इसके अतिरिक्त ऐसे अन्य मुद्दे भी हो सकते हैं जिन पर मैंने विचार नहीं किया है क्योंकि मैंने कभी किसी कोड को नहीं देखा है पल में। जेएस के अलावा यह कैसे क्लोन करता है)।

@dsherret मुझे _builder_/_lazy_ दृष्टिकोण पसंद है; पीछे देखते हुए, इसे शायद शुरू से ही इस तरह बनाया जाना चाहिए था।
जैसा कि आपने कहा, मुझे लगता है कि एपीआई संगतता के साथ एक अपरिवर्तनीय-ईश कांटा दिमाग में सबसे अच्छा होगा।

2 और सेंट:

1. क्या हमें वास्तव में प्रदर्शन के बारे में चिंतित होना चाहिए, जब क्षण स्पष्ट रूप से प्रदर्शन के बजाय सुविधा के लिए बनाया गया हो? मुझे लगता है कि m.add('year',1) में 'वर्ष' को पार्स करना क्लोनिंग की तुलना में बहुत धीमा है।
2. जब तक कुल कांटा (अलग-अलग नाम, अलग-अलग डॉक्टर) न हो, तब तक 2 संस्करणों को बनाए रखने के लिए गधे में दर्द होगा। मुझे लगता है कि किसी चतुर को एक ही कोड बेस से क्षण उत्पन्न करने के लिए एक विचार के साथ आना चाहिए।

हम कब से बदलाव को तोड़ने से इतना डरते हैं? वर्तमान संस्करण स्थिर है और लोग अभी भी अपने कोड आधार को पुन: सक्रिय किए बिना इसका उपयोग कर सकते हैं।

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

तो चलिए पूरी तरह से अपरिवर्तनीय क्षण के साथ चलते हैं, प्रमुख संस्करण को टक्कर देते हैं और इसके साथ किया जाता है: नर्तक:

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

बेशर्म प्लग: मैं यहाँ एक दृढ़ निर्णय की प्रतीक्षा करते-करते थक गया हूँ। पिछले कुछ दिनों में, मैंने फ्रोजन मोमेंट को पुनर्जीवित किया है और इसे मोमेंट के लिए एक प्लगइन के रूप में कार्य करने के लिए फिर से लिखा है। सप्ताहांत में पहला पूर्वावलोकन रिलीज़ करने में मेरी मदद करने के लिए @wyantb को हैट टिप।

फ्रोजन मोमेंट एक अपरिवर्तनीय प्रकार प्रदान करता है जो मोमेंट की तरह ही काम करता है। मूल रूप से, अपरिवर्तनीय संस्करण मोमेंट की कार्यक्षमता को लपेटता है और जब भी उपयुक्त हो आपके लिए .clone() कॉल करता है।

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

उन लोगों के लिए जो सिर्फ एक सुविधाजनक अपरिवर्तनीय एपीआई के साथ काम करना चाहते हैं - ठीक है, मैं भी इसका समर्थन करना चाहता हूं। मैंने एक कंस्ट्रक्टर नहीं बनाया है जो सीधे फ्रोजन इंस्टेंस का निर्माण करेगा, लेकिन यह TODO सूची में है । अल्पावधि में, समाधान सब कुछ moment().freeze() या moment.utc().freeze() ।

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

ओह, एक और बात: मैं अभी तक इसका विज्ञापन नहीं कर रहा हूं, लेकिन फ्रोजन मोमेंट इंस्टेंस को अधिकांश मोमेंट प्लगइन्स के साथ "बस काम" करना चाहिए। बस यह सुनिश्चित करें कि आपके सभी अन्य मोमेंट प्लगइन्स फ्रोजन मोमेंट से पहले खुद को पंजीकृत करें। यदि आपको कोई ऐसा प्लगइन मिलता है जो अपरिवर्तनीय फ्रोजन मोमेंट्स के साथ अपेक्षित रूप से काम नहीं करता है, तो एक बग फाइल करें और मैं इसे देख लूंगा।

अपरिवर्तनीयता पर +1

अपरिवर्तनीय के लिए +1

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

+1
मैंने इसके कारण 3 साल पुराना बग ठीक किया: https://github.com/Saleslogix/argos-saleslogix/commit/87b35b22c1a42670da369701b15e2bdb3786cabc

तो उपयोगकर्ता अपरिवर्तनीयता के लिए पूछते हैं लेकिन कोर टीम ऐसा न करने का बहाना ढूंढती है? :पी
चलो दोस्तों, यह परिवर्तन ES6 ^^ में कोड को फिर से लिखने से कहीं अधिक महत्वपूर्ण है, अपने वर्तमान स्वरूप में, एपीआई बस खराब है, जेएस ऐरे की तरह थोड़ा सा जहां कुछ विधियां अपरिवर्तनीय हैं (फ़िल्टर, कॉन्सैट, आदि) लेकिन कुछ अन्य (रिवर्स, सॉर्ट) नहीं हैं, सिवाय इसके कि पिछड़ी संगतता के लिए उनकी बाधा एक पुस्तकालय की तुलना में असीम रूप से अधिक है।

+1

एक छोटा सा जाल जो मुझे हमेशा मिलता है (और IMHO यह अपरिवर्तनीयता का अच्छा कारण है):

var today = moment();
for (var i = 0; i < 7; i++) {
   week.push(today.subtract(i, 'days').format('dd').toUpperCase());
}

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

i = 0 = today -0;
i = 1 = today -0 -1;
i = 2 = today -0 -1 -2;
etc

तो आपको इसमें इसे दोबारा करना होगा:

var today = moment();
for (var i = 0; i < 7; i++) {
            if (i == 0) {
                week.push(today.subtract(0, 'days').format('dd').toUpperCase());
            }
            else {
                week.push(today.subtract(1, 'days').format('dd').toUpperCase());
            }
        }

@faebser उत्कृष्ट उदाहरण

अपरिवर्तनीयता के लिए +1

+1

@faebser आज सुबह मेरे साथ हुआ। एंगुलर की टू-वे बाइंडिंग + परिवर्तनशीलता **s में मौजूदा तारीखों को संशोधित करने से रोकने के लिए क्लोनिंग तिथियों को रखने के लिए दर्द बनाती है।

अपरिवर्तनीयता के लिए +1, यह मुझे बस कुछ घंटे खर्च करता है।

:+1:

अपरिवर्तनीयता के लिए +1

मैं इस विषय पर थोड़ा फटा हुआ हूँ।

मुझमें शुद्धतावादी चिल्लाना चाहता है "अपरिवर्तनीयता के लिए +1! क्षण वस्तुएं स्पष्ट रूप से ValueObject प्रकार की हैं।"

हालांकि, हम नजरअंदाज नहीं कर सकते कि moment.js है 13 वीं GitHub पर सबसे लोकप्रिय जावास्क्रिप्ट रेपो (और 24 वें ऑल-अराउंड), और bower.io रिटर्न पर "पल" के लिए कि खोज 111 परिणाम मेल नहीं खाते। भले ही हम एप्लिकेशन बिल्डरों को पल के अपरिवर्तनीय संस्करण को लागू करने के लिए क्रमिक तरीके से प्रदान कर सकते हैं, यह इसकी निर्भरता के बीच एक बड़ी गड़बड़ी पैदा करने वाला है।

@ichernev शायद एक और विनम्र सुझाव: क्या यह संभव होगा कि परिवर्तनशीलता बनाम अपरिवर्तनीयता के बारे में बात करने के लिए पल के दस्तावेज़ीकरण पृष्ठ का एक छोटा सा हिस्सा समर्पित हो? आप इस विषय पर अपने आधिकारिक रुख को संक्षेप में बता सकते हैं, और शायद तर्कों का एक संक्षिप्त सारांश जोड़ सकते हैं, इस धागे के लिए एक लिंक डाल सकते हैं, या यदि आप विशिष्ट चर्चा इनपुट चाहते हैं तो यह सीटीए की तरह काम कर सकता है।

अभी प्रलेखन पृष्ठ "अपरिवर्तनीय" शब्द का उल्लेख नहीं करता है। गुगलिंग "पल अपरिवर्तनीय" आपको इस पृष्ठ पर ले जाता है, लेकिन मुझे पढ़ने में दो घंटे लग गए और मैं अभी भी इस विषय पर आपके वर्तमान रुख के बारे में निश्चित नहीं हूं। यह बहुत अच्छा होगा अगर "पल अपरिवर्तनीय" के लिए Google की शीर्ष हिट ने पल में अपरिवर्तनीयता के भविष्य पर त्वरित उत्तर दिया :)

@ Jehoshua02 को उद्धृत करने के लिए:
"मुझे सहानुभूति है कि यह एक कठिन निर्णय है। मैं आपके काम की सराहना करता हूं। Moment.js अद्भुत है।"

यहाँ मेरा प्रस्ताव है। आधार क्षण को अपरिवर्तनीय बनाने के बजाय, एक moment.immutable फ़ैक्टरी जोड़ें। इसके बारे में एक संपत्ति हो जाएगा moment समारोह और के रूप में एक ही सटीक एपीआई हस्ताक्षर संलग्न हैं moment , लेकिन अपरिवर्तनीय।

यह उस प्रोटोटाइप के कार्यों का उपयोग करते हुए, बल्कि इसके बजाय क्लोनिंग, परिवर्तनशील moment कारखाने का एक प्रोटोटाइप विस्तार भी हो सकता है।

संपादित करें: ऐसा प्रतीत होता है कि व्हूपइंक/जमे हुए-पल वही है जो मैं ढूंढ रहा हूं।

@thomasvanlankveld ब्रेकिंग परिवर्तन प्रमुख संस्करण संख्याएं हैं। बोवर और एनपीएम का उपयोग करने वाले किसी भी व्यक्ति के पास वर्तमान प्रमुख संस्करण संख्या से चिपके रहने का विकल्प होगा; हमें यहां पश्चगामी संगतता के बारे में चिंता नहीं करनी चाहिए - शायद उन लोगों को छोड़कर जो सीडीएन से इसे सेवा दे रहे हैं। लेकिन अगर वे सीडीएन से मोमेंटज का उपयोग कर रहे हैं, तो संभवतः वे पुस्तकालय को समय-समय पर अपडेट करने में दिलचस्पी नहीं रखते हैं।

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

तो ऐसा लगता है कि मैं अभी भी इस मुद्दे में भाग गया हूं।

http://stackoverflow.com/questions/33002430/moment-js-formatting-inrect-date

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

+1 अपरिवर्तनीयता के लिए

इस आश्चर्यजनक और अप्रत्याशित व्यवहार में बस एक शाम खो गई।
इसे स्पष्ट करने के लिए संबंधित प्रमुख संस्करण परिवर्तन के साथ अपरिवर्तनीयता के लिए एक और +1।

+1 अपरिवर्तनीयता के लिए

पूर्ण अपरिवर्तनीयता के लिए +1।
"कभी-कभी परिवर्तनीय, कभी-कभी अपरिवर्तनीय" के कारण खोए गए घंटों की सामूहिक मात्रा काफी बड़ी होनी चाहिए।

हाँ मेरा मतलब गंभीरता से है। डेटाटाइम लाइब्रेरी में प्रदर्शन की परवाह कौन करता है? जैसे सचमुच? मेरा अनुमान है कि ९९.९% उपयोगकर्ता ऐसा कुछ नहीं कर रहे हैं जिसके लिए दूर से भी अच्छे प्रदर्शन की आवश्यकता हो। आम तौर पर आप कुछ तिथियों को संभालते हैं, या सबसे खराब स्थिति में कुछ सौ। कुछ उपयोगकर्ता जो प्रति सेकंड लाखों तिथियों को संभाल रहे हैं, वे अनुकूलित परिवर्तनशील एपीआई बिंदुओं का उपयोग कर सकते हैं।

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

अपरिवर्तनीयता के लिए +1। इसमें मुझे एक दो घंटे का समय लगा।

समस्या का एक हिस्सा यह है कि .startOf() जैसे विधि नाम अंतर्निहित वस्तु के उत्परिवर्तन का संकेत नहीं देते हैं।

मैंने मोमेंट के साथ प्रदर्शन बाधाओं को मारा है, इसलिए मैं आपको आश्वस्त कर सकता हूं कि ऐसा कभी-कभी हो सकता है।

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

यह बहस बहुत पहले जावा दुनिया में तय हो गई थी। अपरिवर्तनीय तिथियां जीत गईं, और सबसे लोकप्रिय कार्यान्वयन (जोडाटाइम) अंततः जावा 8 में मानक पुस्तकालय का हिस्सा बन गया।

जावा 8 के LocalTime साथ काम करना उन थप्पड़ों में से एक रहा है "हम हमेशा ऐसा क्यों नहीं करते?" क्षण। मैं शायद ही कभी प्रौद्योगिकियों को प्रचारित करता हूं, लेकिन मैं ईमानदारी से परिवर्तनीय तिथि वस्तुओं के लिए कोई अपसाइड नहीं देख सकता।

तो, हाँ.... मुझे नफरत है कि इन थ्रेड्स में +1 की बाढ़ आ जाती है, लेकिन इस मामले की सच्चाई यह है कि अगर मोमेंट नहीं करता है तो कोई और अपरिवर्तनीय JS डेट लाइब्रेरी बनाने जा रहा है।

मैंने हाल ही में एक नए एनपीएम मॉड्यूल पर ठोकर खाई है जो जेएस को जोडाटाइम एपीआई (यानी जावा 8 तिथियां) पोर्ट करने का उद्देश्य रखता है।

यह अपरिवर्तनीयता, लोकलडेट और लोकलटाइम को नोड और ब्राउज़र में लाएगा।

जावा में इन अवधारणाओं के साथ काम करने के बाद, बाकी सब कुछ कीचड़ और बग-प्रवण लगता है।

संपर्क?

शुक्र, 11 दिसंबर, 2015, शाम 4:30 बजे एंड्रयू श्माडेल नोटिफिकेशन @github.com
लिखा था:

मैंने हाल ही में एक नए npm मॉड्यूल पर ठोकर खाई है जो कि बहुत से पोर्ट करने का इरादा रखता है
जोडाटाइम एपीआई (यानी जावा 8 तिथियां) जेएस को।

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

जावा में इन अवधारणाओं के साथ काम करने के बाद, बाकी सब कुछ अजीब लगता है
और बग-प्रवण।

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

वाउट।
(मोबाइल पर टाइप किया, संक्षिप्तता का बहाना)

चूंकि मैंने अभी तक आवाज नहीं उठाई है, इसलिए मैं केवल यह बताऊंगा कि मैं पल ३.० में अपरिवर्तनीयता के पक्ष में हूं। मुख्य रूप से क्योंकि मैं डीडीडी स्कूल ऑफ थिंक से आता हूं, जहां moment जैसी वस्तुओं को _value ऑब्जेक्ट्स_ माना जाएगा, और इस प्रकार अपरिवर्तनीय के रूप में सर्वोत्तम रूप से कार्यान्वित किया जाता है।

भले ही कोई महत्वपूर्ण प्रदर्शन हिट हो, फिर भी यह करना सही काम है। पल दूसरों के डिजाइन में स्वाभाविक रूप से फिट होना चाहिए। सहज ज्ञान युक्त एपीआई सही मायने रखता है, और उत्परिवर्तन मूल्य वस्तुओं (आईएमएचओ) पर सहज नहीं है।

मुझे यह भी लगता है कि पल 3.0 को Date ऑब्जेक्ट पर अपनी निर्भरता को हटा देना चाहिए, लेकिन यह एक अलग धागे के लिए एक चर्चा है।

मैं यहां @mj1856 से पूरी तरह सहमत हूं।

मैं पल के उदाहरणों पर Object.freeze का उपयोग कर रहा हूं और इसने आम तौर पर मुझे जो चाहिए वह हासिल किया है; सिवाय इसके कि मैंने अभी पाया है कि निम्नलिखित विफल रहता है:

let now = Object.freeze(moment());
if (now.isSameOrBefore(anotherTime)) { // throws exception
}

अपवाद:

TypeError: Can't add property _isValid, object is not extensible
 at valid__isValid (C:\git\quick-test\node_modules\moment\moment.js:93:24)
 at Moment.moment_valid__isValid [as isValid] (C:\git\quick-test\node_modules\moment\moment.js:2195:16)
 at Moment.isSame (C:\git\quick-test\node_modules\moment\moment.js:1945:44)
 at Moment.isSameOrBefore (C:\git\quick-test\node_modules\moment\moment.js:1962:21)

क्या इसे ठीक किया जा सकता है ताकि वांछित होने पर Object.freeze का उपयोग किया जा सके?

@wmertens मुझे लगता है कि यह है: https://github.com/pithu/js-joda

@ichernev , @ mj1856 , जैसा कि मैं कुछ समय के लिए मुख्य विकास में शामिल नहीं हुआ हूं और अपरिवर्तनीयता में काफी महत्वपूर्ण रुचि है, मैं अपने पिछले रुख को वापस ले रहा हूं।

मुझे यकीन नहीं है कि मैं इस पर एकमात्र अवरोधक था, लेकिन मैं 3.0 में अपरिवर्तनीयता के साथ आगे बढ़ने में सहज हूं।

@gabrielmaldi हाँ @wmertens। वह यह था। मेरी सीमा रेखा-असंगत टिप्पणी के लिए खेद है -- मैंने आधी-अधूरी पोस्ट पर 'सबमिट' बटन पर स्पष्ट रूप से क्लिक किया।

मेरे कुछ असंबद्ध विचारों को इकट्ठा करने के लिए:

• जेएस के लिए अपरिवर्तनीय तिथि वस्तुओं में स्पष्ट रूप से कुछ रुचि है। कई अन्य भाषाओं में परिपक्व अपरिवर्तनीय तिथि पुस्तकालय हैं, और JS में अपरिवर्तनीय वस्तुओं की ओर बहुत अधिक सामान्य गति है ( अपरिवर्तनीय .js में 10,500 सितारे हैं यदि यह कोई संकेत है)। कम से कम, मुझे लगता है कि यह एक सबूत की अवधारणा का हकदार है।
• इस रुचि के बावजूद, ऐसा लगता है कि बहुत कम कोड लिखा गया है। जेएस-जोडा जेएस के लिए अपरिवर्तनीय तिथि पुस्तकालय लिखने का पहला गंभीर प्रयास प्रतीत होता है।
• अपरिवर्तनीय क्षण एक बहुत बड़ा ब्रेकिंग परिवर्तन होगा, जो कुछ दार्शनिक प्रश्न उठाता है। जबकि मैं बहुत बड़े मोमेंटजेएस समुदाय के समर्थन को खोने से नफरत करता हूं, यह जरूरी नहीं कि हममें से उन लोगों के लिए एक भयानक बात होगी जो एक साफ ब्रेक बनाने के लिए अपरिवर्तनीय जेएस तिथियों में रुचि रखते हैं, और कोशिश करने के बजाय जेएस-जोडा में योगदान करते हैं मोमेंट (एक बड़े और स्थापित उपयोगकर्ता-आधार के साथ एक परिपक्व पुस्तकालय) पर काफी आमूल-चूल परिवर्तन को आगे बढ़ाने के लिए।
• इसके अलावा: जेएस-जोडा अभी भी बहुत छोटा है, और यह स्पष्ट नहीं है कि पुस्तकालय के लिए लेखक के लक्ष्य और इरादे क्या हैं। विशेष रूप से, उसे एक लाइसेंस लेने की जरूरत है, और हम इस पर विचार करना चाहेंगे कि क्या विशिष्ट जेएस डेवलपर की जरूरतों को जोडा टाइम या जेएसआर-310 के वफादार पुन: कार्यान्वयन से पूरा किया जाएगा।

एक अपरिवर्तनीयता के लिए +1, और परिणामस्वरूप सैनर कोड।

यह एक बड़ा प्रयास होगा, इसलिए उन लोगों के लिए ईमानदारी से धन्यवाद जो इसे कर रहे हैं (और रहे हैं)।

पल का व्यापक रूप से उपयोग किया जाता है कि मुझे लगता है कि यह निम्नलिखित के साथ जाने के लिए कार्रवाई योग्य होगा, यह मानते हुए कि @butterflyhug के https://github.com/WhoopInc/frozen-moment के समान ही लागू किया गया है

3.x: एक विकल्प के रूप में अपरिवर्तनीय, गलत पर डिफ़ॉल्ट, और वैश्विक क्षण निर्यात पर एक ध्वज सेट है जो सत्य पर सेट होगा; लाइब्रेरी लोड पर कंसोल.वार्न (देव मोड में)
4.x: एक विकल्प के रूप में अपरिवर्तनीय, डिफॉल्ट टू ट्रू, फ्लैग अभी भी असत्य के रूप में सेट होने के लिए उपलब्ध है; कंसोल. चेतावनी 5.x के लिए शेड्यूल के बारे में (देव मोड में)
5.x: एकमात्र तरीका के रूप में अपरिवर्तनीय

लंबी अवधि की अपरिवर्तनीय दृष्टि का वर्णन करने वाला एक पृष्ठ अप-फ्रंट और केंद्र है - कहें, 3.x/4.x/5.x रूपरेखा के साथ एक वर्ष में एक प्रमुख रिलीज - और मुझे लगता है कि यह उचित होगा अपने कोड को अपडेट करने के लिए प्रभावित किसी भी व्यक्ति के लिए राशि।

कुछ अवलोकन:

1. मैंने व्हूपइंक/फ्रोजन-मोमेंट का निर्माण

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

1. यदि पल 3.0 में अपरिवर्तनीयता लागू करता है, तो किसी के लिए अपरिवर्तनीय 3.x एपीआई के शीर्ष पर परिवर्तनीय क्षण 2.x एपीआई को लागू करने के लिए एक रैपर लिखना और बनाए रखना बहुत आसान होगा। संकल्पनात्मक रूप से, यह वास्तव में जमे हुए क्षण की तरह दिखता है: हर जगह जमे हुए पल में clone() s, यह उत्परिवर्तनीय आवरण इसके बजाय एक नए अपरिवर्तनीय क्षण मान के आंतरिक संदर्भ को बदल देगा। यह बड़े कोडबेस में पल का उपयोग करने वाले लोगों के लिए संक्रमण को आसान बनाने में भी मदद कर सकता है।
2. मैं संभावित मुद्दों के माध्यम से सोचने और क्षण 3 में अपरिवर्तनीयता को लागू करने में मदद करने के लिए तैयार हूं, यदि वांछित है।
3. js-joda सीधे JSR-310 को BSD लाइसेंस का उपयोग करके जावास्क्रिप्ट में पोर्ट करेगा।

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

मुझे नहीं पता कि कितने अन्य लोगों की विचार प्रक्रियाएँ समान रही होंगी।

मैं उत्सुक हूं अगर यहां के लोग सोचते हैं कि प्रदर्शन कारणों से Date ऑब्जेक्ट (या यहां तक ​​​​कि किसी प्रकार के आलसी मूल्यांकन में जोड़ने) पर निर्भरता को तोड़ने की धारणा के साथ अपरिवर्तनीयता का पता लगाया जाना चाहिए।

मैं एक समय में चीजों को एक कदम उठाने का सुझाव दूंगा, @schmod। यह पहले से ही (जाहिरा तौर पर) बड़ा बदलाव है

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

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

अपरिवर्तनीयता के लिए +1 :)

मुझे अपरिवर्तनीयता की परवाह नहीं है, इस उत्कृष्ट मुक्ति को अकेला छोड़ दें!

@es6Test आप किस आधार पर अपरिवर्तनीयता से असहमत हैं? क्या आपके पास बदलाव के विरोध के अलावा कोई ठोस कारण है?

+1
मुझे लगता है कि यह पुस्तकालय के उपयोग को आसान बना देगा यदि यह अपरिवर्तनीय था तो मेरा कोड .clone() विधि से भरा है और कभी-कभी परिवर्तनशीलता बग को खोजने के लिए बहुत कठिन होती है।

+1 कृपया, अधिक अपरिवर्तनीयता ^_^

@danpantry कुछ और ऐप्स बनाने के बाद, मैंने अपना विचार बदल दिया है। मैं अपरिवर्तनीयता पसंद करूंगा।

लेकिन मैं अभी भी कुछ युद्धों को बदलना चाहता हूं, मैं अक्सर क्षणों में दिन जोड़ना चाहता हूं और मैं परिणाम रखने के लिए और अधिक संस्करण नहीं बनाना चाहता हूं।

@es6Test बस let यदि आप _वास्तव में इसे नापसंद करते हैं?

let date = moment()
// with immutability
date = date.add(5)

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

रिएक्ट / रिडक्स दुनिया में, अपरिवर्तनीयता सुपर सर्वोपरि है। मैं पहले से ही कुछ गंभीर मुद्दों में भाग गया क्योंकि पल आंतरिक रूप से अपरिवर्तनीय नहीं है। प्रदर्शन यहां अप्रासंगिक है क्योंकि इसे कम किया जा सकता है। Facebook से ImmutableJs लाइब्रेरी यह साबित करती है कि प्रदर्शन को त्यागे बिना अपरिवर्तनीय किया जा सकता है।

मैं भी सभी तरह से अपरिवर्तनीयता पर +1 करूंगा। तब तक आपको अपरिवर्तनीयता का कोई लाभ नहीं मिलता है, इसलिए आधे रास्ते में करने का कोई मतलब नहीं है।

अपरिवर्तनीयता और कार्यात्मक प्रोग्रामिंग का उपयोग अब पहले से कहीं अधिक किया जा रहा है (और मुझे यह पसंद है)। मैं इस पहल में योगदान करने के लिए अपना समय दूंगा। योगदानकर्ता कृपया मुझसे संपर्क करें और मुझे बताएं कि मैं कैसे मदद कर सकता हूं।

टीम इस पर एक अपडेट देना चाहती थी क्योंकि हमारी बहुत रुचि थी।

इस समय, हम चाहते हैं कि आपको पता चले कि हमने आपकी चिंताओं को सुना है। पूरी रखरखाव टीम इस बात से सहमत है कि अगर हम पुस्तकालय को जमीन से लिख रहे थे, तो हम इसे अपरिवर्तनीय बनाना पसंद करेंगे। हालांकि, अभी ऐसा नहीं है।

जैसा कि यह खड़ा है, हमारे पास एक महीने में 4 मिलियन एनपीएम डाउनलोड हैं, साथ ही अनगिनत संख्या में उपयोगकर्ता अन्य चैनलों के माध्यम से क्षण प्राप्त करने पर निर्भर हैं। इन सभी उपयोगकर्ताओं के पास कोड है जो उम्मीद करता है कि क्षण आज की तरह परिवर्तनशील होगा। इसके अलावा, हमारे पास कई प्लगइन्स हैं जो पल-पल पर निर्भर हैं।

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

• फ्रोजन मोमेंट प्लगइन आपकी आवश्यकताओं को पूरा क्यों नहीं करता है?
• क्या आपको केवल एक अपरिवर्तनीय एपीआई (एक एपीआई जो हमेशा एक क्लोन देता है) की आवश्यकता होती है, या क्या हमें किसी कारण से वस्तुओं को आंतरिक रूप से वास्तव में उत्परिवर्तित करने की आवश्यकता नहीं है?
• क्या वर्तमान कोड में दूसरा, अपरिवर्तनीय API जोड़ने से आपकी ज़रूरतें पूरी होंगी?

फ्रोजन मोमेंट प्लगइन के साथ समस्या यह है कि यह ऑप्ट-इन है, ऑप्ट-आउट नहीं। प्रत्येक
पल () को अपरिवर्तनीय होने के लिए एक .freeze () की आवश्यकता होती है।

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

मुझे लगता है कि एक कामकाज कई चीजें करना है:

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

मुझे लगता है कि यह सभी को संतुष्ट करेगा। तुम क्या सोचते हो?

सोम, 23 मई, 2016 को दोपहर 12:11 बजे, मैगी पिंट सूचनाएं @github.com
लिखा था:

टीम इस पर एक अपडेट देना चाहती थी क्योंकि हमारे पास बहुत कुछ है
ब्याज।

इस समय, हम चाहते हैं कि आपको पता चले कि हमने आपकी चिंताओं को सुना है। NS
पूरी अनुरक्षक टीम इस बात से सहमत है कि क्या हम पुस्तकालय से लिख रहे थे
ग्राउंड अप, हम इसे अपरिवर्तनीय बनाना चुनेंगे। हालाँकि, ऐसा नहीं है
यह अभी है।

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

कोड लिखना काफी आसान है, लेकिन इस तरह के समर्थन की जरूरत है
हमारे अतिरिक्त में ऐसा करने वाली एक छोटी टीम के रूप में परिवर्तन करना मुश्किल है
समय। उन्होंने कहा, हम इस पर विचार करने को तैयार हैं। हम हालांकि सोच रहे हैं:

• फ्रोजन मोमेंट प्लगइन आपकी आवश्यकताओं को पूरा क्यों नहीं करता है?
• क्या आपको बस एक अपरिवर्तनीय एपीआई की आवश्यकता है (एक एपीआई जो हमेशा वापस आती है a
  क्लोन), या क्या हमें किसी कारण से आंतरिक रूप से वास्तव में उत्परिवर्तित करने की आवश्यकता नहीं है
  वस्तुएं?
• वर्तमान कोड में एक दूसरा, अपरिवर्तनीय API जोड़ना आपके
  जरूरत है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/moment/moment/issues/1754#issuecomment -221062274

जीमेल अकाउंट से एरिक लाउ।

@Maggiepint का जवाब देने के लिए धन्यवाद।

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

start = moment();
end = start.add(10, 'minutes');

1. क्या आपका मतलब 'एड' के अलावा 'अपरिवर्तनीय जोड़ें' जैसे कार्य करना है? यदि ऐसा है तो हाँ तकनीकी रूप से यह होगा, खासकर यदि आप समान नामों का उपयोग करके अपरिवर्तनीय कार्यों का उपयोग करने के लिए एक रैपर बनाते हैं:

import "moment/immutable";
start = moment();
end = start.add(10, 'minutes'); // immutable version of add

मेरी राय में यह दृष्टिकोण उन लोगों के लिए एक सुंदर उन्नयन के लिए स्वयं को उधार देता है जो अपरिवर्तनीय एपीआई का उपयोग करना चाहते हैं - मौजूदा कोड अभी भी काम करेगा, किसी को भी मजबूर नहीं किया जाता है, और उन लोगों के लिए कम बदलाव की आवश्यकता होती है जो अपरिवर्तनीय एपीआई का उपयोग करना चाहते हैं।

कोड को साइड इफेक्ट मुक्त बनाने का हमारा हर इरादा है। मूल पैटर्न मौजूदा कार्यों में शामिल होना होगा, उन्हें क्लोन कॉल करना होगा, और फिर उस क्लोन पर काम करना होगा।

तकनीकी रूप से हालांकि, यदि आप वास्तव में अपरिवर्तनीय कोड बना रहे हैं, तो वस्तुओं का निर्माण उन मूल्यों के साथ किया जाना चाहिए जो नहीं बदलेंगे। हालांकि ऐसा करने से यह बदलाव करने में कठिनाई बढ़ जाएगी। क्लोन को कॉल करना और फिर वही करना बहुत आसान है जो हम पहले कर रहे थे।

मैं दूसरा ड्रू का विचार:

आयात "क्षण/अपरिवर्तनीय";
प्रारंभ = पल ();
अंत = प्रारंभ। जोड़ें (10, 'मिनट'); // Add . का अपरिवर्तनीय संस्करण

यह बहुत अच्छा होगा क्योंकि यह अपरिवर्तनीय ऑप्ट-आउट है और इसमें कोई परिवर्तन नहीं है
समारोह के नाम।

सोम, २३ मई २०१६ को दोपहर १२:५३ बजे, मैगी पिंट नोटिफिकेशन @github.com
लिखा था:

कोड को साइड इफेक्ट मुक्त बनाने का हमारा हर इरादा है। बुनियादी
पैटर्न मौजूदा कार्यों में शामिल होना होगा, उन्हें क्लोन कॉल करना होगा,
और फिर उस क्लोन पर काम करते हैं।

तकनीकी रूप से हालांकि, यदि आप वास्तव में अपरिवर्तनीय कोड बना रहे हैं, तो ऑब्जेक्ट
उन मूल्यों के साथ निर्मित किया जाना चाहिए जो नहीं बदलेंगे। ऐसा करने से
हालांकि यह परिवर्तन करने में कठिनाई बढ़ाएं। यह बहुत आसान है
क्लोन कॉल करें और फिर वही करें जो हम पहले कर रहे थे।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/moment/moment/issues/1754#issuecomment -221076796

जीमेल अकाउंट से एरिक लाउ।

@ एरिक्लौ-सॉलिड

1. एक वैश्विक क्षण () सेटिंग है जहां अगर यह अपरिवर्तनीय मोड पर सेट है, तो सभी
   पल () बनाए गए उदाहरण अपरिवर्तनीय हैं, यदि एक परिवर्तनशील कॉल का प्रयास किया जाता है,
   उत्परिवर्तित नहीं होगा और इसके बजाय अपरिवर्तनीय उपयोग करने के लिए उपयुक्त संदेश के साथ त्रुटि होगी
   एपीआई कॉल।

यह टूट जाएगा यदि पृष्ठ पर 2 पुस्तकालय पल के विभिन्न व्यवहारों की अपेक्षा करते हैं। उदाहरण के लिए आप डेटपिकर का उपयोग करते हैं, जो एक परिवर्तनशील क्षण की अपेक्षा करता है, और आपका अपना कोड अपरिवर्तनीय की अपेक्षा करता है - यह काम नहीं करेगा।

अपरिवर्तनीय एपीआई (अला फ्रोजन-मोमेंट) होना

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

आयात "क्षण/अपरिवर्तनीय";

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

सबसे अच्छा विकल्प है कि एपीआई को वर्तमान की तरह बनाया जाए, लेकिन अपरिवर्तनीय वस्तुओं के साथ। एक कांटा क्रम में हो सकता है। आखिर फ्री सॉफ्टवेयर का यही तरीका है।

संगतता के लिए "दूसरा एपीआई जोड़ें / एक सबमॉड्यूल प्रकाशित करें" विकल्प सबसे अच्छा होगा, क्योंकि डेवलपर्स अपने कोड को क्रमिक रूप से अपग्रेड करने में सक्षम होंगे। यदि संभव हो, तो moment() (मॉड्यूल-लैंड में import moment; माध्यम से, या ब्राउज़र बिल्ड में moment ग्लोबल) का अर्थ बिल्कुल भी नहीं बदलना चाहिए, क्योंकि एक है वहाँ विरासत कोड का टन।

आईएमओ, एक समाधान जो निम्नलिखित की अनुमति देता है वह आदर्श होगा:

import moment from 'moment';
import {immutable as immoment} from 'moment';

var a = moment(); // mutable moment
var b = moment().immutable(); // immutable moment
var c = immoment(); // also an immutable moment; shorthand

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

लाइब्रेरी को फोर्क करना संभावित रूप से कोड के आकार को दोगुना कर देगा, जिसे अधिकांश डेवलपर्स को लोड करने की आवश्यकता होगी, जो कि अधिकांश वेब अनुप्रयोगों के लिए अवांछनीय होगा।

मुझे नहीं लगता कि यह मान लेना एक अच्छा विचार होगा कि कोई भी प्लगइन्स "बॉक्स से बाहर" अपरिवर्तनीय क्षणों के साथ काम करेगा और इसे उचित आवश्यकता नहीं मानेगा।

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

मुझे यह भी लगता है कि "अपरिवर्तनीय" एपीआई कैसा दिखेगा, इस बारे में बहस/तर्क के लिए बहुत जगह है। बिल्डर पैटर्न? कंस्ट्रक्टर इंस्टेंटेशन? मूल्य वस्तु? वर्तमान एपीआई लागू करें, लेकिन क्या कोई "सेटर" विधियां क्लोन लौटाती हैं?

मेरा एक अनुरोध है कि नया एपीआई स्पष्ट और स्पष्ट होना चाहिए कि हम किस तरह के पल के साथ काम कर रहे हैं। आईएमओ, freeze उस परीक्षण में विफल रहता है, और हर बार जब मैं एक पल पास करता हूं तो clone() पर कॉल करने से परे थोड़ी सुरक्षा प्रदान करता है।

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

एक अलग पुस्तकालय नहीं, एक ही पुस्तकालय के चारों ओर सिर्फ एक पतला आवरण। पल के केवल एक संस्करण को स्थापित करने की आवश्यकता होगी। आप 'पल/अपरिवर्तनीय' आयात कर सकते हैं और डेटपिकर बिना किसी समस्या के उसी प्रोजेक्ट में 'पल' आयात कर सकता है।

ऐसे प्लगइन्स के साथ इंटरफेस करने में समस्या हो सकती है जो एक पल लेते हैं या एक पल वापस करते हैं यदि वे अपरिवर्तनीय क्षणों को संभालने के लिए अपडेट नहीं किए गए हैं।

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

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

@maggiepint हां मैं आपकी बात समझता हूं लेकिन मुझे लगता है कि यह एक छलांग लगाने के लिए बहुत बड़ा हो सकता है। व्यक्तिगत रूप से मैं इस दृष्टिकोण के साथ ठीक रहूंगा कि पर्दे के पीछे बस clone । खासकर जब किंक पर काम किया जा रहा है।

@tacomanator यही मैं भी करना चाहता हूं। आंतरिक रूप से वास्तव में अपरिवर्तनीय होने के लिए पूरी चीज को फिर से करना बहुत ही उचित नहीं है।
मुझे नहीं पता था कि किसी कारण से लोग ऐसा चाहते हैं।

@schmod क्या आप संक्षेप में विस्तार से बता सकते हैं कि आपको क्यों नहीं लगता कि freeze एक स्पष्ट और स्पष्ट एपीआई है?

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

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

@butterflyhug आप ठीक वही कह रहे हैं जो @ichernev सोच रहा था। वह आधिकारिक प्लगइन की ओर झुक रहा था जिसे पुस्तकालय के साथ भेज दिया गया था। हो सकता है कि हम इस पर किसी बिंदु पर Gitter में समन्वय कर सकें? मुझे व्यवसाय के सिलसिले में तीन दिनों के लिए दूर रहना है, इसलिए मेरे पास सीमित उपलब्धता होगी। बाकी लड़कों को आसपास होना चाहिए।

@butterflyhug

मुझे लगता है कि freeze एक अच्छा नाम है, _हर एक_ पल के आह्वान के बाद इसका उपयोग करना याद रखना बेकार है।

मुझे यह भी लगता है कि import 'moment/immutable' में समान मुद्दे हैं, इसे भूलना आसान है।

ईमानदारी से, आप सेवर का अनुसरण कर रहे हैं, मुझे लगता है कि सही तरीका यह है कि सब कुछ अपरिवर्तनीय _by default_ का उपयोग करें और इस परिवर्तन को अपने स्वयं के प्रमुख संस्करण के रूप में जारी करें, एक समय अवधि (12 महीने?) के बाद पुराने संस्करणों का समर्थन नहीं करने की योजना के साथ। परिवर्तनशील संस्करण का उपयोग करने वाले उपयोगकर्ताओं को दी गई माइग्रेशन योजना के साथ, नई सुविधाओं / सुधारों को अपरिवर्तनीय और परिवर्तनशील दोनों पटरियों में मिला दिया जा सकता है।

उपरोक्त १२ महीनों के बाद, पुराने संस्करण _स्टिल_ काम करेंगे, लेकिन उन्हें कोई टीएलसी प्राप्त नहीं होगा।

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

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

एक ही पुस्तकालय के दो संस्करण होने पर केवल एक मुद्दा होगा यदि आप वैश्विक वस्तु पर भरोसा कर रहे हैं और freeze() का उपयोग जारी रखने के अलावा वास्तव में इसके आसपास कोई साफ तरीका नहीं है।

TLDR ऐसा लगता है कि जिस समस्या को आप हल करने का प्रयास कर रहे हैं वह सेवर द्वारा हल हो गई है, जिसका आप पहले से उपयोग कर रहे हैं। क्यों न इसका उपयोग उसी रूप में किया जाए जैसा कि इसका उपयोग किया जाना चाहिए? परिवर्तनों को तोड़ने के लिए प्रमुख संस्करण। यह एकमात्र अवसर है जब आप वैश्विक moment चर पर भरोसा कर रहे हैं और एक सीडीएन का उपयोग कर रहे हैं, लेकिन हम यहां जो भी बदलाव करेंगे, वह वैसे भी टूट जाएगा

मेरा वोट सेवर और अपरिवर्तनीय 3.0 रिलीज पर भी है।

मुझे freeze नाम पर कोई आपत्ति नहीं है, लेकिन यह स्वाभाविक रूप से समस्याग्रस्त लगता है कि एक पल रुका हुआ है या नहीं, इस बारे में सुरक्षित धारणा बनाना मुश्किल है। ( Object.freeze() में एक समान समस्या है)

एक अपरिवर्तनीय क्षण अन-फ्रीजेबल नहीं होना चाहिए, और इसमें कभी कोई संदेह नहीं होना चाहिए कि यह जमे हुए है या नहीं। यह बिल्डर पैटर्न के सख्त संस्करण के माध्यम से पूरा किया जा सकता है (यानी ऑब्जेक्ट _only_ में बसने तक .build() कहा जाता है, जिसके बाद इसे _only_ गेटर्स होता है), या पल होने पर "जमे हुए" जैसे ही यह तत्काल है, सभी सेटर्स एक क्लोन लौटा रहे हैं।

उदाहरण के लिए:

/* BUILDER PATTERN */
var bldr = moment.immutable()
  .hours(5)
  .minutes(30)
  .seconds(25);

bldr.hours();  // throws exception.  builder has no getters

var time = bldr.build();

time.hours(); // 5
time.hours(6); // throws, OR returns a clone

/*  A more explicit variant:  */
var bldr = moment.immutable()
  .setHours(5);

bldr.getHours; // undefined

var time = bldr.build();
time.getHours(); // 5
time.setHours;   // undefined

/* VALUE OBJECT */
var time = moment.immutable()   // 00:00:00
  .hours(5)       // new object => 05:00:00
  .minutes(30)    // new object => 05:30:00
  .seconds(25);   // new object => 05:30:25

/*  Same thing, but more efficient:  */
var time2 = moment.immutable(5,30,25); // 05:30:25

time.hours();   // 5
time.hours(6);  // new object => 06:30:25

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

मैं निर्मित क्षणों पर अपवादों को फेंकने के पक्ष में हूं, क्योंकि यह व्यवहार अस्पष्टता को कम करेगा (वर्बोसिटी की कीमत पर), और डेवलपर्स को जब भी वे नए क्षण बना रहे हैं तो स्वीकार करने के लिए मजबूर करें।

दूसरा उदाहरण ऐसा लगता है कि इसमें बहुत अधिक ओवरहेड है, क्योंकि हम बहुत सारी वस्तुओं को बना रहे हैं (और त्याग रहे हैं)। लेकिन, अनुकूलन के लिए बहुत जगह है। आधुनिक जीसी बहुत अच्छा है; आलसी मूल्यांकन मदद कर सकता है; हम मोमेंट ऑब्जेक्ट्स को जितना संभव हो उतना हल्का बना सकते हैं (अंतर्निहित Date छोड़कर), आदि। (कुछ तुलना के लिए, यह पैटर्न जावास्क्रिप्ट में स्ट्रिंग्स को संभालने के तरीके के विपरीत नहीं है)

मैं सेवर का प्रशंसक हूं, लेकिन ब्राउज़र उपयोग-मामला ब्रेकिंग परिवर्तनों को समस्याग्रस्त बनाता है, क्योंकि मॉड्यूल-लोडर के बिना एक ही पृष्ठ पर पल के दो संस्करण होना असंभव होगा।

जैसा कि पहले उल्लेख किया गया है, वहाँ विरासत कोड का एक _lot_ है जो Moment पर निर्भर करता है। कम से कम, हमें एक ऐसी रिलीज़ की ज़रूरत है जो दोनों पैटर्नों का समर्थन करती हो, ताकि एक सुगम संक्रमण अवधि की अनुमति मिल सके।

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

@alexyuly आपके लिए क्लोन काम क्यों नहीं करता है? यदि आप इनलाइन लिखना चाहते हैं तो आप कुछ ऐसा कर सकते हैं:

var a = moment();
var b = a.clone().subtract(1, 'week').startOf('day');

जो कुछ भी।

@maggiepint वैसे मुझे मूर्खतापूर्ण लगता है, ऐसा लगता है कि आप सभी तरीकों की रचना कर सकते हैं। पारितोषिक के लिए धन्यवाद। शायद इसे दस्तावेज़ों में थोड़ा स्पष्ट करें? उदाहरण के लिए http://momentjs.com/docs/#/manipulating/start -of/ <- किसी भी वापसी मूल्य का कोई उल्लेख नहीं है।

थोड़ा अपडेट - यह ब्लॉग पोस्ट इस समय इस मुद्दे पर मेरी स्थिति है: https://maggiepint.com/2016/06/24/why-moment-js-isnt-immutable-yet/

मैं बाकी टीम के लिए नहीं बोलता, लेकिन उन्होंने इसे देखा है, और मैं आम तौर पर कहूंगा कि हम सभी एक ही जगह पर हैं।

@maggiepint महान और बहुत ही मान्य अंक

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

एरिक लाउ - जीमेल

शुक्र, 24 जून, 2016 को पूर्वाह्न 11:12 बजे -0700 बजे, "मैगी पिंट" नोटिफिकेशन @github.com ने लिखा:

थोड़ा अपडेट - यह ब्लॉग पोस्ट इस समय इस मुद्दे पर मेरी स्थिति है: https://maggiepint.com/2016/06/24/why-moment-js-isnt-immutable-yet/

मैं बाकी टीम के लिए नहीं बोलता, लेकिन उन्होंने इसे देखा है, और मैं आम तौर पर कहूंगा कि हम सभी एक ही जगह पर हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

उत्परिवर्तन के कारण कुछ और विशिष्ट बग/भ्रम: http://stackoverflow.com/questions/2613103/moment-js-start-and-end-of-given-month

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

मैं इसे मुख्य रूप से इसलिए करता हूं क्योंकि तब राज्य को बिना किसी अतिरिक्त काम के क्रमबद्ध और deserialize करना आसान है, लेकिन यह प्रतिक्रिया और Redux से उत्परिवर्तन को अच्छी तरह से छुपाता है।

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

बड़े अपडेट की तैयारी में छोटा अपडेट, क्योंकि मैंने देखा है कि उस ब्लॉग पोस्ट पर अभी भी कुछ ट्रैफ़िक आ रहा है। मैं वर्तमान में बेबेल का उपयोग करने के लिए पल के निर्माण को फिर से काम कर रहा हूं। यह हमें @butterflyhug के प्लगइन को कोर रिपॉजिटरी में लाने और इसे आधिकारिक रूप से समर्थित बनाने के लिए @butterflyhug बहुत कृपा से हमें इसमें एक टन मदद कर रहा है। इसके अलावा, मैं आधिकारिक प्लगइन लाते समय रणनीति पर चर्चा करने के लिए LoDash (हम दोनों माइक्रोसॉफ्ट में काम करते हैं) के जॉन-डेविड डाल्टन के साथ मिल रहे हैं, क्योंकि उन्होंने पहले से ही लोडैश कार्यात्मक के साथ ऐसा किया था। लंबा ब्लॉग पोस्ट और RFC जल्द ही आ रहा है।

@maggiepint फ्रोजन- https://github.com/WhoopInc/frozen-moment/issues/20 को संबोधित करने की योजना बना रहे हैं

मुझे लगता है कि अपरिवर्तनीयता के लिए यह दृष्टिकोण काफी अच्छा है जब तक कि प्रत्येक कॉल moment() डिफ़ॉल्ट रूप से एक जमे हुए क्षण को लौटाता है, और देवों को हर बार .freeze() कॉल करना याद नहीं रखना पड़ता है।

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

मैंने ड्राफ्ट RFC लिखना समाप्त कर लिया है और एक PR खोला है ।

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

हमारे प्राथमिक प्रश्नों के उत्तर के साथ RFC का कार्यकारी सारांश: https://maggiepint.com/2016/07/16/immutability-its-happening/

@maggiepint मैंने उस लेख पर एक टिप्पणी पोस्ट करने की कोशिश की, लेकिन किसी कारण से इसे निगल लिया गया। यहाँ मैंने क्या लिखा है:

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

गिटहब के धागे व्यापक विकास समुदाय का सूक्ष्म जगत नहीं हैं। यह साइट वेब पर कई मंचों के समान भागीदारी पूर्वाग्रह से ग्रस्त है, और एक निश्चित प्रकार के डेवलपर के प्रति पक्षपाती है: बौद्धिक रूप से कंप्यूटिंग के सिद्धांत से जुड़ा हुआ है; अनुप्रयोगों के बजाय विचारों में रुचि; और मैं यह भी कहने की हिम्मत करता हूं कि सामाजिक रूप से लोकप्रिय प्रवृत्तियों के इर्द-गिर्द रैली करने की इच्छा है। ये डेवलपर्स स्वाभाविक रूप से अपरिवर्तनीयता और कार्यात्मक प्रोग्रामिंग जैसे दार्शनिक कारणों से आकर्षित होते हैं, और किसी भी अन्य समूह की तुलना में आपके पास करीब पहुंच होती है। वे कमरे में सबसे ऊंची आवाज होंगे, और वे इस बदलाव के लिए चिल्लाएंगे - लेकिन व्यापक दुनिया का क्या?

व्यापक दुनिया स्टफ दैट वर्क्स चाहती है। यह जानना चाहता है कि वह जिस पुस्तकालय का वर्तमान में उपयोग करता है उसे अपडेट प्राप्त होते रहेंगे - कम से कम बगफिक्स, लेकिन आदर्श रूप से छोटे वृद्धिशील सुधार जो उनके जीवन को बेहतर बनाते हैं। लेकिन यह ऐसा नहीं कहता है, क्योंकि यह सक्रिय रूप से इन मंचों की तलाश नहीं करता है, और क्योंकि यह प्रवृत्ति के खिलाफ बोलने के लिए एक मोटी त्वचा लेता है।

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

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

पहली बार उपयोगकर्ता के रूप में मैं स्टार्टऑफ एंडऑफ के साथ कुछ समय खो जाने के बाद यहां समाप्त हुआ। ये तरीके आश्चर्यजनक रूप से परिवर्तनशील हैं!

पूर्ण अपरिवर्तनीयता के लिए +1

हो सकता है कि एक और उपाय यह है कि यह

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

व्यापक दुनिया स्टफ दैट वर्क्स चाहती है।
...आपको इन लोगों के सामने एक बहुत ही स्पष्ट मामला बनाना होगा कि यह परिवर्तन उनके जीवन को बेहतर क्यों बना देगा

हर कोई जिसे मैंने पल-पल नया होते देखा है, "क्षणों" के उत्परिवर्तित होने के जाल में पड़ जाता है।
पल का उपयोग करने के 3 साल बाद भी मुझे अभी भी खुद को बताना है "ओह शिट आप उपयोग कर रहे हैं। यहां शुरू करें .. अगर आपको एक प्रति की आवश्यकता है तो दो बार बेहतर जांच करें"।

वर्तमान व्यवहार सहज नहीं है और यह लंबे समय से अतिदेय है।
array.filter/map mutate बनाने का प्रयास करें और देखें कि यह कितना मजेदार है।

के बारे में...
प्रदर्शन/स्मृति: मैंने कभी भी 2 से अधिक funcs को क्षण में नहीं बांधा है और आमतौर पर यह .set().get()
छद्म-अपरिवर्तनीयता: जावा-पास-बाय-रेफ-जेन बाहर होने तक इसमें कई पीढ़ियों का समय लगेगा।

मुझे यह चुनने का @AdamHess का विचार पसंद है कि आप OOP की तलाश में हैं या अपरिवर्तनीयता।

हम भ्रमित क्यों हो जाते हैं इसके बारे में मेरे दो सेंट यह है: वापसी मूल्य। यदि moment.add('1', 'days') अपरिभाषित लौट रहा था, जैसे जेएस में उत्परिवर्तनीय कार्य आम तौर पर करते हैं, तो भ्रम दूर हो जाएगा। मेरे लिए कम से कम एक ही वस्तु लौटाने का तात्पर्य है कि मेरे पास एक नई प्रति है। बेशक, यह श्रृंखलाबद्धता को तोड़ देगा।

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

डिफ़ॉल्ट रूप से अपरिवर्तनीय के लिए +1

PHP के लिए भी यही समस्या मौजूद है। क्या आप PHP की तरह बनना चाहते हैं ?! मैं

PHP में, वे इसे DateTimeImmutable (सामान्य DateTime ) प्रदान करके हल करते हैं।

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

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

वैसे क्लोनिंग अवधि के बारे में कैसे? ऐसा करने का सबसे अच्छा तरीका क्या है, ऐसा कोई नहीं मिला जो हैकी महसूस न करे।

@ngerritsen मेरा मानना ​​​​है कि सबसे अच्छा उपलब्ध विकल्प moment.duration(existingDuration) ।

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

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

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

मैं @mull से भी सहमत

जबकि पल.फ्रोजन नेमस्पेस काम कर रहा है, मैं अनुशंसा करता हूं - जैसा कि पिछले पोस्टर ने सुझाव दिया था-- बस

परिवर्तनशील क्षणों के कारण बस एक और बग को ठीक किया

मूर्त रूप से संबंधित, यह बहुत अच्छा होगा यदि 3.0 ES6 कक्षाओं में जा सकता है:

let mom1 = new Moment();
let mom2 = Moment.parse('2019-03-01T14:55');
// etc

इस तरह का कदम अपरिवर्तनीय चर्चा का मार्गदर्शन भी कर सकता है। मैं कहूंगा कि सभी विधियों को एक अपवाद के साथ अपरिवर्तनीय होना चाहिए। .set('minute/hour/year/etc', 18) नामक एक विधि।

मैंने अभी क्षण का उपयोग करना शुरू किया है, और _horrified_ था कि यह पुस्तकालय शुरू से ही पूरी तरह से अपरिवर्तनीय नहीं था। मैं पल-अपरिवर्तनीय उपयोग कर रहा हूँ जब तक यह ठीक नहीं हो जाता।

@alncnet पल शायद कभी नहीं बदला जाएगा। यह बहुत अधिक परिवर्तन है और उन उपयोगकर्ताओं से पर्याप्त धक्का-मुक्की हुई है जिन्होंने वर्तमान व्यवहार को अपनाना सीख लिया है।

उनकी नई परियोजना देखें: लक्सन
यह बहुत अच्छा है, आधुनिक, अपरिवर्तनीय है (!) और की तुलना में बेहतर प्रदर्शन करना चाहिए जिस तरह से पल-अपरिवर्तनीय जो सिर्फ में सब कुछ लपेटता .clone() कॉल।

जो लोग मोमेंटज से आधुनिक दृष्टिकोण में संक्रमण करना चाहते हैं, उनके लिए कृपया https://github.com/you-dont-need/You-Dont-Need-Momentjs देखें।

बहुत आश्चर्य है कि यह परिवर्तनशील है!

एक प्रतिस्थापन होने के लिए लक्सन कितनी दूर है? जिन कारणों से मैं Moment.js का उपयोग कर रहा हूं उनमें से एक टाइमज़ोन समर्थन है - यह मेरे प्रोजेक्ट के लिए आवश्यक है।

@alamothe वेबसाइट पर इस प्रश्न का स्पष्ट उत्तर दिया गया है: https://moment.github.io/luxon/docs/manual/moment.html

इसको बंद करना। जैसा कि अन्य ने इंगित किया है, यदि आप अधिकतर अपरिवर्तनीय एपीआई चाहते हैं तो लक्सन का उपयोग करें। धन्यवाद।