मुझे यह पसंद है कि यह दिखने में कितना समान है।

const OldAPI => NewPackage.API
func  OldAPI => NewPackage.API
var   OldAPI => NewPackage.API
type  OldAPI => NewPackage.API

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

const OldAPI = NewPackage.API
func  OldAPI() { NewPackage.API() }
var   OldAPI = NewPackage.API
type  OldAPI = NewPackage.API

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

जैसा कि रस का लेख बताता है, किसी भी उपनाम जैसे समाधान को https://github.com/golang/go/issues/17746 और https://github.com/golang/go/issues/17784 को इनायत से हल करने की आवश्यकता है

उस लेख को लिखने के लिए धन्यवाद।

मुझे असाइनमेंट ऑपरेटर का सबसे अच्छा उपयोग करने वाले टाइप-ओनली उपनाम मिलते हैं:

type OldAPI = NewPackage.API

मेरे कारण:

• यह आसान है।
  वैकल्पिक समाधान => इसके संकार्य के आधार पर सूक्ष्म रूप से भिन्न अर्थ होने के कारण गो के लिए जगह से बाहर महसूस होता है।
• यह केंद्रित और रूढ़िवादी है।
  प्रकार के साथ समस्या हल हो गई है और आपको सामान्यीकृत समाधान की जटिलताओं की कल्पना करने की चिंता करने की आवश्यकता नहीं है।
• यह सौंदर्यवादी है।
  मुझे लगता है कि यह और अधिक सुखद लग रहा है।

उपरोक्त सभी: परिणाम सरल, केंद्रित, रूढ़िवादी और सौंदर्यपूर्ण होने के कारण मेरे लिए इसे गो का एक हिस्सा होने की तस्वीर बनाना आसान हो जाता है।

यदि समाधान केवल प्रकारों तक ही सीमित होगा तो वाक्य रचना

type NewFoo = old.Foo

पहले से ही विचार किया जा चुका है, जैसा कि @rsc के लेख में चर्चा की गई है, मुझे बहुत अच्छा लग रहा है।

अगर हम स्थिरांक, चर और कार्यों के लिए ऐसा करने में सक्षम होना चाहते हैं, तो मेरा पसंदीदा वाक्यविन्यास होगा (जैसा कि पहले प्रस्तावित किया गया था)

package newfmt

import (
    "fmt"
)

// No renaming.
export fmt.Printf // Note: Same as `export Printf fmt.Printf`.

export (
        fmt.Sprintf
        fmt.Formatter
)

// Renaming.
export Foo fmt.Errorf // Foo must be exported, ie. `export foo fmt.Errorf` would be invalid.

export (
    Bar fmt.Fprintf
    Qux fmt.State
)

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

नाम बदलने वाले पहचानकर्ताओं को पैकेज के दायरे में घोषित किया जाएगा, हालांकि, नए नाम पैकेज में दिखाई नहीं दे रहे हैं (उपरोक्त उदाहरण में newfmt) पुनर्घोषणा के संबंध में, जो हमेशा की तरह अस्वीकृत है। पिछले उदाहरण को देखते हुए, टीएलडी

var v = Printf // undefined: Printf.
var Printf int // Printf redeclared, previous declaration at newfmt.go:8.

आयात पैकेज में नाम बदलने वाले पहचानकर्ता सामान्य रूप से दिखाई देते हैं, जैसा कि (newftm's) पैकेज ब्लॉक के किसी अन्य निर्यात किए गए पहचानकर्ता के रूप में होता है।

package foo

import "newfmt"

type bar interface {
    baz(qux newfmt.Qux) // qux type is identical to fmt.State.
}

अंत में, यह दृष्टिकोण newfmt में बाध्यकारी किसी भी नए स्थानीय नाम का परिचय नहीं देता है, जो मेरा मानना ​​​​है कि # 17746 में चर्चा की गई कम से कम कुछ समस्याओं से बचा जाता है और # 17784 को पूरी तरह से हल करता है।

मेरी पहली प्राथमिकता केवल type NewFoo = old.Foo ।

यदि एक अधिक सामान्य समाधान वांछित है, तो मैं @cznic से सहमत export कीवर्ड सही अर्थ बताता है। न तो वाक्य रचना, न ही शब्दार्थ दर्पण import । alias बारे में क्या?

मैं समझता हूं कि @cznic क्यों नहीं चाहता कि नए नाम उन्हें घोषित करने वाले पैकेज में

[1] मैं लगभग 20 वर्षों से यूनिक्स का उपयोग कर रहा हूं, और मैं अभी भी पहली कोशिश में एक सिमलिंक नहीं बना सकता। और मैनुअल पढ़ने के बाद, मैं आमतौर पर दूसरे प्रयास में भी असफल हो जाता हूं।

मैं एक अतिरिक्त बाधा का प्रस्ताव करना चाहता हूं: मानक पुस्तकालय प्रकारों के लिए उपनाम केवल मानक पुस्तकालय में घोषित किया जा सकता है।

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

@iand : वह बाधा मानक पुस्तकालय में कुछ भी माइग्रेट करने के लिए इस सुविधा के उपयोग को अवरुद्ध कर देगी। उदाहरण के लिए, मानक पुस्तकालय में Context का वर्तमान प्रवास। Context का पुराना घर मानक पुस्तकालय में Context लिए उपनाम बनना चाहिए।

@quentinmit दुर्भाग्य से सच है। यह इस CL https://go-review.googlesource.com/#/c/32145/ में golang.org/x/image/draw के उपयोग के मामले को भी सीमित करता है

मेरी असली चिंता interface{} और error जैसी चीजों को अलियासिंग करने वाले लोगों के साथ है

यदि एक नया ऑपरेटर पेश करने का निर्णय लिया जाता है, तो मैं ~ का प्रस्ताव देना चाहूंगा। अंग्रेजी भाषा में, इसे आम तौर पर "के समान", "लगभग", "के बारे में", या "आसपास" के रूप में समझा जाता है। जैसा कि ऊपर @4ad कहा गया है, => भ्रमित दिशात्मकता वाला एक असममित ऑपरेटर है।

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

const OldAPI ~ NewPackage.API
func  OldAPI ~ NewPackage.API
var   OldAPI ~ NewPackage.API
type  OldAPI ~ NewPackage.API

@iand अगर हम दाएं हाथ को पैकेज-योग्य पहचानकर्ता तक सीमित करते हैं, तो यह आपकी विशिष्ट चिंता को खत्म कर देगा।

इसका मतलब यह भी होगा कि आपके पास मौजूदा पैकेज में किसी भी प्रकार के उपनाम या map[string]map[int]interface{} जैसे लंबे प्रकार के भाव नहीं हो सकते। लेकिन उन उपयोगों का क्रमिक कोड मरम्मत के मुख्य लक्ष्य से कोई लेना-देना नहीं है, इसलिए हो सकता है कि वे कोई बड़ा नुकसान न करें।

@cznic , @iand , अन्य: कृपया ध्यान दें कि _प्रतिबंध जटिलता_ जोड़ते हैं। वे सुविधा के स्पष्टीकरण को जटिल बनाते हैं, और वे सुविधा के किसी भी उपयोगकर्ता के लिए संज्ञानात्मक भार जोड़ते हैं: यदि आप प्रतिबंध के बारे में भूल जाते हैं, तो आपको यह समझना होगा कि आपके विचार से काम क्यों नहीं करना चाहिए।

केवल काल्पनिक दुरुपयोग के कारण किसी डिज़ाइन के परीक्षण पर प्रतिबंध लागू करना अक्सर एक गलती होती है। यह उपनाम प्रस्ताव चर्चाओं में हुआ, और इसने परीक्षण में उपनामों को लेख से io.ByteBuffer => bytes.Buffer रूपांतरण को संभालने में असमर्थ बना दिया। लेख लिखने के लक्ष्य का एक हिस्सा कुछ मामलों को परिभाषित करना है जिन्हें हम जानते हैं कि हम उन्हें संभालने में सक्षम होना चाहते हैं, ताकि हम अनजाने में उन्हें दूर न करें।

एक अन्य उदाहरण के रूप में, गैर-सूचक रिसीवर को अस्वीकार करने या गैर-संरचना प्रकारों पर विधियों को अस्वीकार करने के लिए दुरुपयोग तर्क बनाना आसान होगा। यदि हमने उनमें से कोई भी किया है, तो आप स्वयं को प्रिंट करने के लिए स्ट्रिंग() विधियों के साथ एनम नहीं बना सकते हैं, और आपके पास http.Headers दोनों एक सादा नक्शा नहीं हो सकते हैं और सहायक विधियां प्रदान करते हैं। दुरुपयोग की कल्पना करना अक्सर आसान होता है; सम्मोहक सकारात्मक उपयोगों को प्रदर्शित होने में अधिक समय लग सकता है, और प्रयोग के लिए जगह बनाना महत्वपूर्ण है।

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

var buf bytes.Buffer
io.Copy(buf, reader)

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

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

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

मूल उपनाम प्रस्ताव के बारे में एक बात यह है कि इच्छित उपयोग के मामले में (रीफैक्टरिंग को सक्षम करना) उपनाम प्रकार का वास्तविक उपयोग केवल अस्थायी होना चाहिए। प्रोटोबफ़र उदाहरण में, क्रमिक मरम्मत समाप्त होने के बाद io.BytesBuffer स्टब को हटा दिया गया था।

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

मैं सिंटैक्स के बारे में बाइकशेडिंग में भाग नहीं लूंगा (मुझे मूल रूप से परवाह नहीं है), एक अपवाद के साथ: यदि उपनाम जोड़ने का निर्णय लिया गया है और यदि उन्हें प्रकारों तक सीमित करने का निर्णय लिया गया है, तो कृपया एक सिंटैक्स का उपयोग करें जो कम से कम var तक लगातार एक्स्टेंसिबल हो func और const (सभी प्रस्तावित वाक्य रचनाएं type Foo = pkg.Bar को छोड़कर सभी के लिए अनुमति देती हैं)। इसका कारण यह है कि, जबकि मैं मानता हूं कि ऐसे मामले जहां var उपनामों में अंतर होता है, वे दुर्लभ हो सकते हैं, मुझे नहीं लगता कि वे अस्तित्वहीन हैं और ऐसा मानते हैं कि हम किसी बिंदु पर जोड़ने का निर्णय ले सकते हैं उन्हें भी। उस समय हम निश्चित रूप से चाहते हैं कि सभी उपनाम घोषणाएं सुसंगत हों, यह बुरा होगा यदि यह type Foo = pkg.Bar और var Foo => pkg.Bar ।

मैं भी चारों के होने के लिए थोड़ा तर्क दूंगा। कारण हैं

1) वहाँ के लिए एक अंतर है var और मैं इसका इस्तेमाल कभी कभी करते हैं। उदाहरण के लिए, मैं अक्सर वैश्विक var Debug *log.Logger पर्दाफाश करता हूं, या http.DefaultServeMux जैसे वैश्विक सिंगलटन को पुन: असाइन करता हूं ताकि उन पैकेजों के पंजीकरण को अवरुद्ध/निकाल सकें जो इसमें हैंडलर जोड़ते हैं।

2) मुझे यह भी लगता है कि, जबकि func Foo() { pkg.Bar() } वही काम करता है func Foo => pkg.Bar , बाद वाले का इरादा बहुत स्पष्ट है (विशेषकर यदि आप पहले से ही उपनामों के बारे में जानते हैं)। यह स्पष्ट रूप से कहता है "यह वास्तव में यहाँ होने के लिए नहीं है"। तो तकनीकी रूप से समान होने पर, उपनाम वाक्यविन्यास दस्तावेज़ीकरण के रूप में कार्य कर सकता है।

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

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

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

@jba

@iand अगर हम दाएं हाथ को पैकेज-योग्य पहचानकर्ता तक सीमित करते हैं, तो यह आपकी विशिष्ट चिंता को खत्म कर देगा।

इसका मतलब यह भी होगा कि आपके पास मौजूदा पैकेज में किसी भी प्रकार के उपनाम नहीं हो सकते हैं, […] लेकिन उन उपयोगों का क्रमिक कोड मरम्मत के मुख्य लक्ष्य से कोई लेना-देना नहीं है, इसलिए हो सकता है कि वे कोई बड़ा नुकसान न करें।

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

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

@btracey

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

gc लिए एक तंत्र का मतलब या तो यह होगा कि कोड केवल मरम्मत प्रक्रिया के दौरान gc के साथ निर्माण योग्य है, या यह कि तंत्र को अन्य कंपाइलरों द्वारा समर्थित होना होगा (जैसे gccgo और llgo ) भी। एक "गैर-भाषा-परिवर्तन" तंत्र जिसे सभी कार्यान्वयनों द्वारा समर्थित होना चाहिए, एक वास्तविक भाषा परिवर्तन है - यह केवल खराब दस्तावेज वाला एक है।

@btracey और @bcmills , और न केवल संकलक: कोई भी उपकरण जो स्रोत कोड का विश्लेषण करता है, जैसे गुरु या कुछ और जो लोगों ने बनाया है। यह निश्चित रूप से एक भाषा परिवर्तन है इससे कोई फर्क नहीं पड़ता कि आप इसे कैसे टुकड़ा करते हैं।

ठीक है शुक्रिया।

एक और संभावना है कि कॉन्स को छोड़कर हर चीज के लिए उपनाम (और @rsc कृपया मुझे प्रतिबंध का प्रस्ताव देने के लिए क्षमा करें!)

स्थिरांक के लिए, => वास्तव में = लिखने का एक लंबा तरीका है। कोई नया शब्दार्थ नहीं है, जैसा कि प्रकार और संस्करण के साथ है। funcs की तरह कोई सहेजे गए कीस्ट्रोक नहीं हैं।

यह कम से कम #17784 का समाधान करेगा।

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

उस ने कहा, मैं अभी के लिए सिर्फ उपनामों के साथ ठीक हूं, वे निश्चित रूप से सबसे महत्वपूर्ण हैं। मैं निश्चित रूप से @Merovius से सहमत

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

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

(1) और (2) के लिए प्रेरक विचार किसी तरह उपनाम के बजाय रूपांतरण का उपयोग करना है। # 17746 में, उपनाम एक ही प्रकार के लिए कई नाम रखने के आसपास के मुद्दों में भाग गया (या एक ही नाम की वर्तनी के कई तरीके, इस पर निर्भर करता है कि आप उपनामों को #define या हार्ड लिंक की तरह सोचते हैं)। रूपांतरण का उपयोग करना उस प्रकार को अलग रखकर दूर करता है।

1. अधिक स्वचालित रूपांतरण जोड़ें।

जब आप fmt.Println("abc") कॉल करते हैं या var e interface{} = "abc" लिखते हैं, तो "abc" अपने आप interface{} । हम भाषा बदल सकते हैं ताकि जब आपने type T struct { S } घोषित किया हो, और टी के पास कोई गैर-प्रचारित विधियां नहीं हैं, तो संकलक स्वचालित रूप से एस और टी के बीच आवश्यकतानुसार परिवर्तित हो जाएगा, जिसमें अन्य स्ट्रक्चर के अंदर पुनरावर्ती शामिल है। टी तब क्रमिक रिफैक्टरिंग उद्देश्यों के लिए एस (या इसके विपरीत) के वास्तविक उपनाम के रूप में कार्य कर सकता है।

1. एक नया "दिखता है" प्रकार का प्रकार जोड़ें।

चलो type T ~S एक नया प्रकार T घोषित करें जो एक प्रकार है जो "S जैसा दिखता है"। अधिक सटीक रूप से, टी "किसी भी प्रकार से और प्रकार एस से परिवर्तनीय" है। (हमेशा की तरह, सिंटैक्स पर बाद में चर्चा की जा सकती है।) इंटरफ़ेस प्रकारों की तरह, T में विधियाँ नहीं हो सकती हैं; मूल रूप से टी के साथ कुछ भी करने के लिए, आपको इसे एस (या एस से/से परिवर्तनीय प्रकार) में परिवर्तित करने की आवश्यकता है। इंटरफ़ेस प्रकारों के विपरीत, कोई "ठोस प्रकार" नहीं है, एस से टी और टी से एस के बीच रूपांतरण में कोई प्रतिनिधित्व परिवर्तन शामिल नहीं है। क्रमिक रिफैक्टरिंग के लिए, ये "दिखने वाले" प्रकार लेखकों को पुराने और नए दोनों प्रकारों को स्वीकार करते हुए एपीआई लिखने की अनुमति देंगे। ("ऐसा लगता है" प्रकार मूल रूप से अत्यधिक प्रतिबंधित, सरलीकृत संघ प्रकार हैं।)

1. टैग टाइप करें

बोनस सुपर-घृणित विचार। (कृपया मुझे यह बताने में परेशान न हों कि यह भयानक है - मुझे यह पता है। मैं केवल दूसरों में नए विचारों को प्रोत्साहित करने की कोशिश कर रहा हूं।) क्या होगा यदि हम टाइप टैग (जैसे स्ट्रक्चर टैग) पेश करते हैं, और सेट करने के लिए विशेष प्रकार के टैग का उपयोग करते हैं और नियंत्रण उपनाम, जैसे type T S "alias:\"T\"" कहें। टाइप टैग के अन्य उपयोग भी होंगे और यह पैकेज लेखक द्वारा केवल "यह प्रकार एक उपनाम है" की तुलना में उपनामों के अधिक विनिर्देश के लिए गुंजाइश प्रदान करता है; उदाहरण के लिए, कोड का लेखक एम्बेडिंग व्यवहार निर्दिष्ट कर सकता है।

यदि हम फिर से उपनामों का प्रयास करते हैं, तो "क्या करता है" और "एम्बेडिंग क्या करता है" मुद्दों के समान "गॉडोक क्या करता है" के बारे में सोचने लायक हो सकता है।

विशेष रूप से, यदि हमारे पास

type  OldAPI => NewPackage.API

और NewPackage.API में एक दस्तावेज़ टिप्पणी है, क्या हम उस टिप्पणी को "OldAPI टाइप करें" के बगल में कॉपी/पेस्ट करने की उम्मीद कर रहे हैं, क्या हम इसे बिना टिप्पणी किए छोड़ने की उम्मीद कर रहे हैं (godoc स्वचालित रूप से एक लिंक प्रदान करने या स्वचालित रूप से कॉपी/पेस्ट करने के साथ), या होगा कोई अन्य सम्मेलन हो?

कुछ हद तक स्पर्शरेखा, जबकि प्राथमिक प्रेरणा क्रमिक कोड मरम्मत का समर्थन कर रही है और होनी चाहिए, एक मामूली उपयोग मामला (उपनाम प्रस्ताव पर वापस जाना, क्योंकि यह एक ठोस प्रस्ताव है) एक एकल फ़ंक्शन प्रस्तुत करते समय डबल फ़ंक्शन-कॉल ओवरहेड से बचने के लिए हो सकता है एकाधिक, बिल्ड-टैग-निर्भर कार्यान्वयन द्वारा समर्थित। मैं अभी केवल हाथ हिला रहा हूं, लेकिन मुझे ऐसा लगता है कि उपनाम हाल ही में उपयोगी हो सकते हैं https://groups.google.com/d/topic/golang-nuts/wb5I2tjrwoc/discussion "पैकेज में फ़ंक्शन कॉल ओवरहेड से बचना गो + एएसएम कार्यान्वयन के साथ" चर्चा।

@nigeltao re Godoc, मुझे लगता है:

इसे हमेशा मूल से लिंक करना चाहिए, भले ही।

यदि उपनाम पर दस्तावेज़ हैं, तो उन्हें प्रदर्शित किया जाना चाहिए, भले ही।

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

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

मुझे यकीन नहीं है कि निम्नलिखित विचार पहले पोस्ट किए गए थे, लेकिन ज्यादातर टूल-आधारित "गोफिक्स"/"गोरनाम" जैसे दृष्टिकोण के बारे में क्या है? समझाने के लिए:

• किसी भी पैकेज में पुनर्लेखन नियमों का एक सेट हो सकता है (उदाहरण के लिए मैपिंग pkg.Ident => otherpkg.Ident )
• उन पुनर्लेखन नियमों को मनमाने ढंग से जाने वाली फाइलों के अंदर //+rewrite ... टैग के साथ निर्दिष्ट किया जा सकता है
• वे पुनर्लेखन नियम ABI संगत परिवर्तनों तक सीमित नहीं हैं, अन्य कार्य करना भी संभव है (जैसे pkg.MyFunc(a) => pkg.MyFunc(context.Contex(), a) )
• वर्तमान रिपॉजिटरी में सभी परिवर्तनों को लागू करने के लिए एक गोफिक्स जैसे टूल का उपयोग किया जा सकता है। इससे पैकेज के उपयोगकर्ताओं के लिए अपना कोड अपडेट करना आसान हो जाता है।
• सफलतापूर्वक संकलन करने के लिए gofix टूल को कॉल करना आवश्यक नहीं है। एक पुस्तकालय जो अभी भी एक निर्भरता एक्स के पुराने एपीआई का उपयोग करना चाहता है (एक्स के पुराने और नए संस्करणों के साथ संगत रहने के लिए) अभी भी ऐसा कर सकता है। गो बिल्ड कमांड को डिस्क पर फाइलों को बदले बिना ऑन-द-फ्लाई ट्रांसफॉर्मेशन (पैकेज एक्स के रीराइट टैग में निर्दिष्ट) लागू करना चाहिए।

अंतिम चरण संकलक को थोड़ा जटिल/धीमा कर सकते हैं, लेकिन यह मूल रूप से केवल एक प्री-प्रोसेसर है और फिर से लिखने के नियमों की मात्रा को वैसे भी छोटा रखा जाना चाहिए। तो, आज के लिए पर्याप्त मंथन :)

फ़ंक्शन कॉल ओवरहेड से बचने के लिए उपनामों का उपयोग करना गैर-पत्ती कार्यों को इनलाइन करने में कंपाइलर की अक्षमता के आसपास काम करने के लिए एक हैक की तरह लगता है। मुझे नहीं लगता कि कार्यान्वयन की कमियों को भाषा की कल्पना को प्रभावित करना चाहिए।

@josharian जबकि आपने उन्हें पूर्ण प्रस्तावों के रूप में इरादा नहीं किया था, मुझे प्रतिक्रिया दें (भले ही केवल, ताकि जो कोई भी आपसे प्रेरित हो, वह तत्काल आलोचना को ध्यान में रख सके):

1. वास्तव में समस्या का समाधान नहीं करता है, क्योंकि रूपांतरण वास्तव में कोई समस्या नहीं है। x/net/context.Context असाइन करने योग्य/परिवर्तनीय/जो कुछ भी context.Context । समस्या उच्च-क्रम के प्रकार हैं; अर्थात् प्रकार func (ctx x/net/context.Context) और func (ctx context.Context) समान नहीं हैं, भले ही तर्क असाइन करने योग्य हों। तो, समस्या को हल करने के लिए 1 के लिए, type T struct { S } का अर्थ यह होना चाहिए कि T और S समान प्रकार हैं। जिसका अर्थ है, कि आप बस उपनामों के लिए एक अलग वाक्यविन्यास का उपयोग कर रहे हैं (बस इस वाक्यविन्यास का पहले से ही एक अलग अर्थ है)।

2. फिर से उच्च-क्रम प्रकारों के साथ समस्या है, क्योंकि असाइन करने योग्य/परिवर्तनीय प्रकारों में समान स्मृति प्रतिनिधित्व नहीं होता है (और यदि वे करते हैं, तो व्याख्या महत्वपूर्ण रूप से बदल सकती है)। उदाहरण के लिए, एक uint8 एक के लिए परिवर्तनीय है uint64 और उपाध्यक्ष प्रतिकूल। लेकिन इसका मतलब यह होगा कि, उदाहरण के लिए, type T ~uint8 , संकलक यह नहीं जान सकता कि func(T) को कैसे कॉल किया जाए; क्या इसे स्टैक पर 1, 2,4 या 8 बाइट्स को पुश करने की आवश्यकता है? इस मुद्दे के आसपास के तरीके हो सकते हैं, लेकिन यह मेरे लिए बहुत जटिल लगता है (और उपनाम से समझने में कठिन)।

धन्यवाद, @ मेरोवियस।

1. हाँ, मैं यहाँ इंटरफ़ेस संतुष्टि से चूक गया। तुम सही हो, यह काम नहीं करता है।

2. मेरे मन में था "एक ही स्मृति प्रतिनिधित्व है"। परिवर्तनीय आगे और पीछे स्पष्ट रूप से इसका सही स्पष्टीकरण नहीं है - धन्यवाद।

@uluyol हाँ, यह मोटे तौर पर गैर-पत्ती कार्यों को इनलाइन करने में संकलक की अक्षमता के बारे में है, लेकिन स्पष्ट एलियासिंग गैर-पत्ती को इनलाइन कॉल को स्टैक ट्रेस, रनटाइम। कॉलर इत्यादि में दिखाना चाहिए या नहीं, इस संबंध में कम आश्चर्यजनक हो सकता है।

किसी भी मामले में, जैसा कि मैंने कहा, यह एक मामूली स्पर्शरेखा है।

@josarian इसी तरह की समस्या: [2]uintptr और interface{} में समान स्मृति प्रतिनिधित्व है; इसलिए केवल स्मृति प्रतिनिधित्व पर भरोसा करने से प्रकार की सुरक्षा को रोकने की अनुमति मिल जाएगी। uint64 और float64 दोनों में एक ही मेमोरी प्रतिनिधित्व है और आगे-पीछे परिवर्तनीय हैं, लेकिन फिर भी कम से कम वास्तव में अजीब परिणाम होंगे, यदि आप नहीं जानते कि कौन सा है।

हालांकि आप "समान अंतर्निहित प्रकार" से दूर हो सकते हैं। निश्चित नहीं है कि इसके लिए क्या निहितार्थ होंगे। मेरी टोपी के ऊपर से, उदाहरण के लिए, यदि फ़ील्ड में किसी प्रकार का उपयोग किया जाता है तो इससे गलतता हो सकती है। यदि आपके पास type S1 struct { T1 } और type S2 struct { T2 } ( T1 और T2 समान अंतर्निहित प्रकार के साथ) हैं, तो type L1 ~T1 तहत दोनों काम हो सकते हैं type S struct { L1 } , लेकिन T1 और T2 अभी भी एक अलग (हालांकि एक जैसे दिखने वाला) अंतर्निहित प्रकार है, type L2 ~S1 आपके पास S2 नहीं होगा S1 और L2 रूप में प्रयोग करने योग्य नहीं हैं।

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

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

@josharian के विचार के बाद, यहां उनके नंबर 2 का एक रूपांतर है:

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

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

इसके विपरीत दिशात्मकता के इस उलटफेर के कुछ फायदे हैं:

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

इसे कॉन्टेक्स्ट रिफैक्टरिंग में लागू करना: मानक पुस्तकालय संदर्भ पैकेज घोषित करेगा कि context.Context को golang.org/x/net/context.Context द्वारा प्रतिस्थापित किया जा सकता है। इसका मतलब है कि कोई भी उपयोग जो संदर्भ को स्वीकार करता है। संदर्भ इसके स्थान पर golang.org/x/net/context.Context भी स्वीकार कर सकता है। हालांकि संदर्भ पैकेज में कार्य जो एक संदर्भ लौटाते हैं वह हमेशा context.Context लौटाएगा।

यह प्रस्ताव एम्बेडिंग समस्या (#17746) को रोकता है क्योंकि एम्बेडेड प्रकार का नाम कभी नहीं बदलता है। हालांकि, एक विकल्प प्रकार के मान का उपयोग करके एक एम्बेडेड प्रकार को प्रारंभ किया जा सकता है।

@iand @josharian आप एक निश्चित प्रकार के सहसंयोजक प्रकारों के लिए पूछ रहे हैं।

@ जोशेरियन , सुझावों के लिए धन्यवाद।

Re type T struct { S } , जो उपनाम के लिए एक अलग सिंटैक्स की तरह दिखता है, और जरूरी नहीं कि एक स्पष्ट हो।

पुन: type T ~S , मुझे या तो यकीन नहीं है कि यह उपनाम से कैसे भिन्न है या यह सुनिश्चित नहीं है कि यह कैसे रिफैक्टरिंग में मदद करता है। मुझे लगता है कि एक रिफैक्टरिंग में (कहते हैं, io.ByteBuffer -> बाइट्स। बफर), आप लिखेंगे:

package io
type ByteBuffer ~bytes.Buffer

लेकिन फिर, जैसा कि आप कहते हैं, "टी के साथ मूल रूप से कुछ भी करने के लिए, आपको इसे एस में परिवर्तित करने की आवश्यकता है", तो सभी कोड io.ByteBuffer के साथ कुछ भी कर रहे हैं।

पुन: type T S "alias" : ऊपर दिए गए @bcmills का एक प्रमुख बिंदु यह है कि प्रकारों के लिए कई समान नाम होने से भाषा परिवर्तन होता है, चाहे वह किसी भी तरह से लिखा गया हो। सभी कंपाइलरों को यह जानने की जरूरत है कि, io.ByteBuffer और बाइट्स। बफ़र समान हैं, जैसे कोई भी उपकरण जो विश्लेषण करता है या यहां तक ​​​​कि कोड-चेक करता है। आपके सुझाव का मुख्य भाग मुझे कुछ इस तरह लगता है "शायद हमें अन्य परिवर्धन के लिए आगे की योजना बनानी चाहिए"। हो सकता है, लेकिन यह स्पष्ट नहीं है कि एक स्ट्रिंग उनका वर्णन करने का सबसे अच्छा तरीका होगा, और यह भी स्पष्ट नहीं है कि हम स्पष्ट आवश्यकता के बिना सिंटैक्स (जैसे जावा सामान्यीकृत एनोटेशन) डिज़ाइन करना चाहते हैं। यहां तक ​​​​कि अगर हमारे पास एक सामान्य रूप था, तब भी हमें अपने द्वारा पेश किए गए किसी भी नए शब्दार्थ के सभी निहितार्थों पर ध्यान से विचार करने की आवश्यकता होगी, और अधिकांश अभी भी भाषा परिवर्तन होंगे जिनके लिए सभी उपकरणों को अपडेट करने की आवश्यकता होगी (गोफएमटी को छोड़कर, माना जाता है)। संतुलन पर यह आसान लगता है कि एक या दूसरे प्रकार की मेटा-भाषा बनाने के बजाय हमें एक-एक करके उन रूपों को लिखने का सबसे स्पष्ट तरीका खोजना जारी रखना चाहिए।

@Merovius FWIW, मैं कहूंगा कि [2]uintptr और इंटरफ़ेस {} में समान स्मृति प्रतिनिधित्व नहीं है। एक इंटरफ़ेस{} एक [2]असुरक्षित है।सूचक [2]uintptr नहीं है। एक uintptr और एक सूचक अलग-अलग प्रतिनिधित्व हैं। लेकिन मुझे लगता है कि आपका सामान्य बिंदु सही है, कि हम अनिवार्य रूप से उस तरह की चीज़ के सीधे रूपांतरण की अनुमति नहीं देना चाहते हैं। मेरा मतलब है, क्या आप इंटरफ़ेस{} से [2]*बाइट में भी कनवर्ट कर सकते हैं? यहां जरूरत से कहीं ज्यादा है।

@jimmyfrasche और @nigeltao , re Godoc: मैं मानता हूं कि हमें भी जल्दी काम करने की ज़रूरत है। मैं सहमत हूं कि हमें इस धारणा को हार्ड-कोड नहीं करना चाहिए "नई सुविधा - जो भी हो - केवल कोडबेस रिफैक्टरिंग के लिए उपयोग की जाएगी"। इसके अन्य महत्वपूर्ण उपयोग हो सकते हैं, जैसे कि निगेल को उपनामों के साथ एक ड्रा एक्सटेंशन पैकेज लिखने में मदद करने के लिए मिला। मुझे उम्मीद है कि पदावनत चीजों को उनके दस्तावेज़ टिप्पणियों में स्पष्ट रूप से बहिष्कृत चिह्नित किया जाएगा, जैसा कि जिमी ने कहा था। यदि कोई वहां नहीं है तो मैंने स्वचालित रूप से एक डॉक्टर टिप्पणी उत्पन्न करने के बारे में सोचा था, लेकिन यह कहने के लिए कुछ भी स्पष्ट नहीं है कि पहले से ही वाक्यविन्यास (आमतौर पर बोलना) से स्पष्ट नहीं होना चाहिए। एक विशिष्ट उदाहरण बनाने के लिए, पुराने गो 1.8 उपनामों पर विचार करें। दिया गया

type ByteBuffer => bytes.Buffer

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

@iand , धन्यवाद। ऐसा लगता है कि आपके प्रस्ताव के लिए पुराने पैकेज से सटीक परिभाषा लिखने के लिए नए पैकेज के लेखक की आवश्यकता है और फिर दोनों को जोड़ने वाली एक घोषणा भी है, जैसे (वाक्यविन्यास बनाना):

package old
type T { x int }

package new
import "old"
type T1 { x int }
substitutable T1 <- old.T

मैं सहमत हूं कि आयात उलटफेर समस्याग्रस्त है और अपने आप में एक शो-स्टॉपर हो सकता है, लेकिन चलो इसे छोड़ दें। इस बिंदु पर कोडबेस ऐसा लगता है जैसे यह एक नाजुक स्थिति में है: अब पैकेज नए को पुराने पैकेज में एक स्ट्रक्चर फ़ील्ड जोड़ने के लिए एक बदलाव से तोड़ा जा सकता है। प्रतिस्थापन योग्य रेखा को देखते हुए, T1 के लिए केवल एक ही संभावित परिभाषा है: बिल्कुल पुराने के समान। यदि दो प्रकारों की अभी भी अलग-अलग परिभाषाएँ हैं तो आपको विधियों के बारे में भी चिंता करनी होगी: क्या विधि कार्यान्वयन को भी मेल खाना चाहिए? यदि नहीं, तो क्या होता है जब आप एक इंटरफ़ेस में एक टी डालते हैं {} और फिर टी 1 के रूप में एक प्रकार के दावे का उपयोग करके इसे बाहर निकालते हैं और एम () को कॉल करते हैं? क्या आपको T1.M मिलता है? क्या होगा यदि आप इसे सीधे T1 नाम दिए बिना एक इंटरफ़ेस {M ()} के रूप में बाहर निकालते हैं, और M () को कॉल करते हैं? क्या आपको टीएम मिलता है? स्रोत पेड़ में दोनों परिभाषाएं होने की अस्पष्टता के कारण बहुत जटिलता है।

बेशक, आप कह सकते हैं कि प्रतिस्थापन योग्य रेखा बाकी को बेमानी बनाती है और टाइप टी 1 या किसी भी तरीके की परिभाषा की आवश्यकता नहीं होती है। लेकिन फिर यह मूल रूप से लेखन जैसा ही है (पुराने उपनाम वाक्यविन्यास में) type T1 => old.T ।

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

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

@rsc कि टूटना परिदृश्य बताता है कि किसी भी प्रकार के अलियासिंग को द्विदिश होने की आवश्यकता है। यहां तक ​​​​कि पिछले उपनाम प्रस्ताव के तहत नए पैकेज में कोई भी बदलाव संभावित रूप से किसी भी संख्या में पैकेज को तोड़ सकता है जो कि प्रकार को अलियास करने के लिए होता है।

@iand यदि केवल एक परिभाषा है (क्योंकि दूसरा कहता है "

#13467 में, @joegrasse बताता है कि यह अच्छा होगा यदि यह प्रस्ताव समान सी प्रकारों को कई पैकेजों में सीजीओ का उपयोग करते समय समान सी प्रकारों को समान गो प्रकार बनने की अनुमति देने के लिए एक तंत्र प्रदान करता है। यह समस्या बिल्कुल वैसी नहीं है जैसी कि यह समस्या है, लेकिन दोनों समस्याएं टाइप एलियासिंग से संबंधित हैं।

क्या उपनामों पर प्रस्तावित/स्वीकृत/अस्वीकृत प्रतिबंधों/सीमाओं का कोई सारांश है? कुछ सवाल जो दिमाग में आते हैं वे हैं:

• क्या आरएचएस हमेशा पूरी तरह से योग्य होता है?
• यदि उपनामों के उपनामों की अनुमति है, तो हम उपनाम चक्रों को कैसे संभालेंगे?
• क्या उपनाम निर्यात न किए गए पहचानकर्ताओं को निर्यात करने में सक्षम होना चाहिए?
• क्या होता है जब आप एक उपनाम एम्बेड करते हैं? (आप एम्बेडेड फ़ील्ड तक कैसे पहुँचते हैं)
• क्या उपनाम निर्मित कार्यक्रम में प्रतीकों के रूप में उपलब्ध हैं?
• ldflags स्ट्रिंग इंजेक्शन: क्या होगा यदि हम एक उपनाम का उल्लेख करते हैं?

@rsc मैं बातचीत को बहुत अधिक नहीं

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

@thwd मुझे नहीं लगता कि अभी तक एक अच्छा राइटअप है। मेरी टिप्पणियाँ:

• उपनाम चक्र एक गैर-मुद्दा हैं। पैकेज-क्रॉसिंग उपनामों के मामले में, आयात-चक्र के कारण पहले से ही एक चक्र की अनुमति नहीं है। गैर पैकेज-क्रॉसिंग उपनामों के मामले में, उन्हें स्पष्ट रूप से अस्वीकार करने की आवश्यकता है, जो प्रारंभिक क्रम में चक्रों के समान ही है। व्यक्तिगत रूप से, मैं उपनामों के लिए उपनाम रखना चाहता हूं, क्योंकि मुझे नहीं लगता कि उन्हें क्रमिक मरम्मत उपयोग मामलों तक सीमित होना चाहिए (ऊपर मेरी टिप्पणी देखें) और यह दुखद होगा, अगर पैकेज ए किसी प्रकार को आगे बढ़ने से तोड़ सकता है एक उपनाम के साथ पैकेज बी (कल्पना करें x/image/draw.Image अलियासिंग draw.Image और फिर किसी ने draw.Image को एक उपनाम के माध्यम से image.Draw स्थानांतरित करने का निर्णय लिया, इसे सुरक्षित मानते हुए। अचानक x/image/draw टूट जाता है, क्योंकि उपनाम से उपनाम की अनुमति नहीं है)।
• मुझे लगता है कि पहले उपनामों के समर्थकों ने सहमति व्यक्त की है कि उर्फ-निर्यात न किए गए पहचानकर्ता शायद अजीबता के कारण एक बुरा विचार है जो इसका कारण हो सकता है। प्रभावी रूप से इसका मतलब है कि गैर-निर्यातित पहचानकर्ताओं के उपनाम बेकार हैं और पूरी तरह से अस्वीकृत हो सकते हैं।
• एम्बेडिंग प्रश्न, AFAIK, अभी तक अनसुलझा है। # 17746 में एक पूरी चर्चा है, मुझे उम्मीद है कि यह चर्चा जारी रहेगी यदि/कब/इससे पहले कि यह उपनामों के साथ आगे बढ़ने का निर्णय लिया जाए (लेकिन अभी भी एक वैकल्पिक समाधान की संभावना है या क्रमिक मरम्मत को लक्ष्य नहीं बनाने का निर्णय है) बिलकुल)

@iand , फिर से "केवल पुराने और नए दोनों का उपयोग करने वाले ग्राहक टूट जाएंगे", यह एकमात्र दिलचस्प मामला है। यह मिश्रित ग्राहक हैं जो इसे क्रमिक कोड मरम्मत करते हैं। जो ग्राहक केवल नए कोड या केवल पुराने कोड का उपयोग करते हैं, वे आज काम करेंगे।

विचार करने के लिए कुछ और है, जिसका उल्लेख मैंने अभी तक कहीं और नहीं देखा है:

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

किसी भी प्रकार की संकलक चेतावनी के बिना, पुस्तकालय के मालिक को कैसे विश्वास हो सकता है कि रिफैक्टरिंग को पूरा करना सुरक्षित है?

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

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

Error: os.time is obsolete, use time.time instead. Run "go upgrade" to fix this.

प्रकार के उपनामों के लिए, मुझे लगता है कि रिफैक्टरिंग एल्गोरिदम केवल "पुराने टाइप के सभी उदाहरणों को न्यू टाइप के साथ प्रतिस्थापित करेगा", लेकिन सूक्ष्मताएं हो सकती हैं, मुझे यकीन नहीं है।

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

@iainmerrick इनके लिए बग खुले हैं: गोलांग/लिंट # 238 और गोलंग/जीडीडीओ # 456

क्रमिक कोड मरम्मत समस्या को हल करना, जैसा कि @rsc के लेख में उल्लिखित है, दो प्रकार के विनिमेय होने के लिए एक तरीके की आवश्यकता को कम करता है (जैसा कि वर्कअराउंड vars, funcs और consts के लिए मौजूद है)।

इसके लिए या तो एक उपकरण या भाषा में बदलाव की जरूरत है।

चूंकि दो प्रकारों को विनिमेय बनाना, परिभाषा के अनुसार, भाषा के काम करने के तरीके को बदलना, कोई भी उपकरण संकलक के बाहर तुल्यता का अनुकरण करने के लिए एक तंत्र होगा, संभवतः पुराने प्रकार के सभी उदाहरणों को नए प्रकार में फिर से लिखकर। लेकिन इसका मतलब यह है कि इस तरह के एक उपकरण को उस कोड को फिर से लिखना होगा जो आपके पास नहीं है, जैसे एक विक्रेता पैकेज जो stdlib संदर्भ पैकेज के बजाय golang.org/x/net/context का उपयोग करता है। परिवर्तन के लिए विनिर्देश या तो एक अलग मेनिफेस्ट फ़ाइल या मशीन-पठनीय टिप्पणी में होना चाहिए। यदि आप उपकरण नहीं चलाते हैं तो आपको बिल्ड त्रुटियां मिलती हैं। इससे निपटने के लिए सब गड़बड़ हो जाता है। ऐसा लगता है कि एक उपकरण जितनी समस्याएं हल करता है उतनी ही समस्याएं पैदा करेगा। यह अभी भी एक समस्या होगी, इन पैकेजों का उपयोग करने वाले सभी को इससे निपटना होगा, हालांकि कुछ हद तक अच्छा है क्योंकि एक हिस्सा स्वचालित है।

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

जैसा कि @griesemer ने बताया (मुझे याद नहीं है कि इसके बारे में बहुत सारे सूत्र हैं) गो में पहले से ही अलियासिंग है, जैसे सामान के लिए byte ↔ uint8 , और जब आप एक पैकेज आयात करते हैं दो बार, अलग-अलग स्थानीय नामों के साथ, एक ही स्रोत फ़ाइल में।

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

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

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

अतिरिक्त प्रश्न: कृपया स्पष्ट करें कि क्या प्रकार के उपनाम नए पैकेज में प्रकारों को जोड़ने की अनुमति देंगे (यकीनन इनकैप्सुलेशन को तोड़ना) या नहीं? साथ ही, क्या नए पैकेज को पुराने स्ट्रक्चर के निजी क्षेत्रों तक पहुंच प्राप्त होगी या नहीं?

अतिरिक्त प्रश्न: कृपया स्पष्ट करें कि क्या प्रकार के उपनाम नए पैकेज में प्रकारों को जोड़ने की अनुमति देंगे (यकीनन इनकैप्सुलेशन को तोड़ना) या नहीं? साथ ही, क्या नए पैकेज को पुराने स्ट्रक्चर के निजी क्षेत्रों तक पहुंच प्राप्त होगी या नहीं?

एक उपनाम एक प्रकार के लिए सिर्फ एक और नाम है। यह प्रकार के पैकेज को नहीं बदलता है। तो आपके दोनों प्रश्नों के लिए नहीं (जब तक कि नया पैकेज == पुराना पैकेज नहीं)।

@akavel अभी तक, कोई प्रस्ताव नहीं है। लेकिन हम दो दिलचस्प संभावनाओं के बारे में जानते हैं जो गो 1.8 उर्फ ​​​​परीक्षणों के दौरान सामने आईं।

1. उपनाम (या केवल उपनाम टाइप करें) ड्रॉप-इन प्रतिस्थापन बनाने में सक्षम होंगे जो अन्य पैकेजों का विस्तार करते हैं। उदाहरण के लिए https://go-review.googlesource.com/#/c/32145/ देखें , विशेष रूप से प्रतिबद्ध संदेश में स्पष्टीकरण।

2. उपनाम (या केवल उपनाम टाइप करें) एक छोटे एपीआई सतह के साथ एक पैकेज को संरचित करने में सक्षम होगा लेकिन बेहतर आंतरिक संरचना के लिए पैकेजों के संग्रह के रूप में एक बड़ा कार्यान्वयन लेकिन अभी भी ग्राहकों द्वारा आयात और उपयोग किए जाने के लिए केवल एक पैकेज मौजूद है। https://github.com/golang/go/issues/16339#issuecomment -232813695 पर कुछ हद तक सार उदाहरण वर्णित है।

उपनामों का अंतर्निहित लक्ष्य बहुत अच्छा है, लेकिन ऐसा लगता है कि हम कोड को पुन: सक्रिय करने के लक्ष्य के प्रति काफी ईमानदार नहीं हैं, भले ही यह सुविधा के लिए नंबर एक प्रेरक है। कुछ प्रस्ताव नाम को बंद करने का सुझाव देते हैं, और मैंने अभी तक इसका उल्लेख नहीं देखा है कि प्रकार आमतौर पर इस तरह के रिफैक्टरिंग के साथ अपनी सतह भी बदलते हैं। यहां तक ​​​​कि os.Error => error का उदाहरण अक्सर उपनामों के आसपास उल्लेख किया गया है, इस तथ्य को अनदेखा करता है कि os.Error में String विधि थी न कि Error । अगर हम सिर्फ प्रकार को स्थानांतरित करते हैं और उसका नाम बदल देते हैं, तो सभी त्रुटि प्रबंधन कोड को तोड़ा जाएगा। रिफैक्टरिंग के दौरान यह सामान्य जगह है.. पुरानी विधियों का नाम बदल दिया जाता है, स्थानांतरित कर दिया जाता है, गिरा दिया जाता है, और हम उन्हें नए प्रकार में नहीं चाहते हैं क्योंकि यह नए कोड के साथ असंगति को बनाए रखेगा।

मदद करने के हित में, यहाँ एक बीज विचार है: क्या होगा यदि हम उपनाम के बजाय एडेप्टर के संदर्भ में समस्या को देखें? एक एडेप्टर एक मौजूदा प्रकार को एक वैकल्पिक नाम _और इंटरफ़ेस_ देगा, और इसका उपयोग उन जगहों पर किया जा सकता है जहां मूल प्रकार पहले देखा गया था। अंतर्निहित अनुकूलित प्रकार के समान इंटरफ़ेस मौजूद हैं, यह मानने के बजाय एडेप्टर को इसके द्वारा समर्थित विधियों को स्पष्ट रूप से परिभाषित करने की आवश्यकता होगी। यह काफी हद तक मौजूदा type foo bar व्यवहार जैसा होगा, लेकिन कुछ अतिरिक्त शब्दार्थ के साथ।

आईओ.बाइटबफर

उदाहरण के लिए, यहां अस्थायी "अनुकूलन" कीवर्ड का उपयोग करते हुए io.ByteBuffer मामले को संबोधित करने वाला एक उदाहरण कंकाल है:

type ByteBuffer adapts bytes.Buffer

func (old *ByteBuffer) Write(b []byte) (n int, err error) {
        buf := (*bytes.Buffer)(old)
        return buf.Write(b)
}

(... etc ...)

तो, उस एडेप्टर के साथ, यह कोड सभी मान्य होगा:

func newfunc(b *bytes.Buffer) { ... }
func oldfunc(b *io.ByteBuffer) { ... }

func main() {
        var newvar bytes.Buffer
        var oldvar io.BytesBuffer

        // New code using the new type obviously just works.
        newfunc(&newvar)

        // New code using the old type receive the underlying value that was adapted.
        newfunc(&oldvar)

        // Old code using the old type receive the adapted value unchanged.
        oldfunc(&oldvar)

        // Old code gets new variable adapted on the way in. 
        oldfunc(&newvar)
}

newfunc और oldfunc इंटरफेस संगत हैं। दोनों वास्तव में *bytes.Buffer स्वीकार करते हैं, oldfunc इसे रास्ते में *io.BytesBuffer अनुकूलित करते हैं। वही अवधारणा असाइनमेंट, परिणाम इत्यादि के लिए काम करती है।

ओएस.त्रुटि

इंटरफ़ेस पर भी काम करने के लिए शायद वही तर्क बनाया जाना चाहिए, हालांकि इसका कंपाइलर कार्यान्वयन थोड़ा मुश्किल है। यहां os.Error => error लिए एक उदाहरण दिया गया है, जो इस तथ्य को संभालता है कि विधि का नाम बदल दिया गया था:

package os

type Error adapts error

func (e Error) String() string { return error(e).Error() }

हालाँकि, इस मामले में और सोचने की ज़रूरत है, क्योंकि इस तरह के तरीके:

func (v *T) Read(b []byte) (int, os.Error) { ... }`

एक प्रकार लौटाएगा जिसमें String विधि है, इसलिए हम आमतौर पर विपरीत दिशा में अनुकूलित करना चाहते हैं ताकि कोड धीरे-धीरे तय किया जा सके।

_अद्यतन: आगे सोचने की जरूरत है।_

एम्बेडिंग समस्या

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

कुबेरनेट्स, डॉकर

पोस्ट में बताई गई समस्याएं उपरोक्त मुद्दों के बदलाव की तरह लगती हैं, और प्रस्ताव द्वारा हल की जाती हैं।

वार्स, const

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

गोडोक

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

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

कृपया कुछ अच्छा चुनें। ;)

@iainmerrick @zombiezen

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

दो अवलोकन:

1. प्रकार के संदर्भों के शब्दार्थ समर्थित रिफैक्टरिंग उपयोग के मामले पर निर्भर करते हैं

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

रॉस के नए प्रस्ताव में एक नया सिंटैक्स type OldAPI = newpkg.newAPI । लेकिन शब्दार्थ क्या हैं? क्या OldAPI को पुराने सार्वजनिक तरीकों या क्षेत्रों के साथ विस्तारित करना असंभव है? एक उत्तर के रूप में हाँ मानते हुए संगतता बनाए रखने के लिए सभी सार्वजनिक विधियों और OldAPI के क्षेत्रों का समर्थन करने के लिए newAPI की आवश्यकता होती है। कृपया ध्यान दें कि OldAPI के साथ पैकेज में कोई भी कोड जो निजी क्षेत्रों और विधियों पर निर्भर करता है, उसे केवल सार्वजनिक newAPI का उपयोग करने के लिए फिर से लिखा जाना चाहिए, यह मानते हुए कि संकुल की दृश्यता बाधाओं को संशोधित करना तालिका से बाहर है।

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

2. NewAPI के साथ पैकेज OldAPI के साथ पैकेज आयात नहीं कर सकता

OldAPI को फिर से परिभाषित करने के लिए उस पैकेज O की आवश्यकता होती है जिसमें OldAPI की परिभाषा हो, NewAPI के साथ पैकेज N आयात करता है। इसका मतलब है कि पैकेज एन ओ आयात नहीं कर सकता है। शायद यह इतना स्पष्ट है कि इसका उल्लेख नहीं किया गया है, लेकिन यह मुझे रिफैक्टरिंग उपयोग के मामले में एक महत्वपूर्ण बाधा लगता है।

अद्यतन: पैकेज N की पैकेज O पर कोई निर्भरता नहीं हो सकती है। उदाहरण के लिए यह O को आयात करने वाले पैकेज को आयात नहीं कर सकता है।

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

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

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

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

मैं एक और, थोड़ा अलग उपयोग के मामले को ध्यान में रखना चाहता हूं क्योंकि किसी भी प्रकार का उपनाम प्रस्ताव विकसित किया गया है।

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

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

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

तो यहाँ प्रक्रिया होगी:

1. उपनाम प्रकार को परिभाषित करें
2. उपनाम प्रकार का उपयोग करने के लिए कोड के प्रासंगिक निकाय को बदलें
3. टाइप एलियास को टाइप डेफिनिशन से बदलें।

इस प्रक्रिया के अंत में, दो स्वतंत्र प्रकार होंगे जो अपनी दिशाओं में विकसित होने के लिए स्वतंत्र होंगे।

ध्यान दें कि इस उपयोग के मामले में:

• वहाँ एक प्रकार का उपनाम जोड़ने के लिए मूल प्रकार की परिभाषा वाले पैकेज को बदलने का कोई विकल्प नहीं है (क्योंकि मालिकों के इससे सहमत होने की संभावना नहीं है)
• मूल प्रकार को बहिष्कृत नहीं किया गया है (हालाँकि इसे कोड के मुख्य भाग में इस प्रकार के "वीन ऑफ" होने की प्रक्रिया के रूप में माना जा सकता है)।

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

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

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

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

ऐसा लगता है कि आप 3a बनाम 3b करने के बारे में बहस कर रहे हैं। लेकिन जो मैं इंगित कर रहा था, वह 1. विधि-नामों के लिए पहले से ही संभव है लेकिन प्रकारों के लिए संभव नहीं है, यही वह है।

हालाँकि, अब मुझे एहसास हुआ है कि मुझे लगता है कि मैंने आपको गलत समझा :) आप शायद इशारा कर रहे होंगे, कि os.Error अलग-अलग इंटरफ़ेस-परिभाषाएँ हैं, इसलिए यह कदम वास्तव में समाप्त नहीं होता है। मुझे लगता है कि यह सच है; यदि आप एपीआई को हटाने से मना करते हैं, तो उपनाम टाइप करने से इंटरफ़ेस प्रकारों के तरीकों का नाम बदलना संभव नहीं होगा।

हो सकता है कि आप मेरे लिए अपने एडॉप्टर विचार के बारे में कुछ स्पष्ट कर सकें, हालांकि: क्या वह किसी भी fmt.Stringer को os.Error के रूप में उपयोग करने की अनुमति नहीं देगा (उदाहरण के लिए, os.Error मामले में)?

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

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

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

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

@Merovius ऊपर

@niemeyer जो ठोस प्रकारों को संभालेगा। .(interface{String() string}) बनाम .(interface{Error() string}) या इंटरफ़ेस के जो भी विशिष्ट टुकड़े बदल गए हैं, के लिए एक प्रकार के दावे के बारे में क्या? क्या चेक को किसी भी तरह संभावित अंतर्निहित प्रकारों पर विचार करना है?

@niemeyer नहीं। एक विधि का नाम बदलना गैर-परमाणु रूप से संभव है। उदाहरण के लिए A.Foo से A.Bar तक एक विधि को स्थानांतरित करने के लिए, do

1. विधि A.Bar को लगभग A.Foo रैपर के रूप में जोड़ें
2. उपयोगकर्ताओं को केवल A.Bar पर मनमाने ढंग से कई कमिट के माध्यम से कॉल करने के लिए माइग्रेट करें
3. या तो हटाएं A.Foo , या नहीं, इस पर निर्भर करता है कि आप एक बहिष्करण लागू करने के इच्छुक हैं या नहीं।

परिवर्तन कार्य तर्क गैर-परमाणु रूप से संभव है। उदाहरण के लिए x int को func Foo() पैरामीटर जोड़ने के लिए, करें

1. func FooWithInt(x int) { Foo(); // use x somehow; }
2. उपयोगकर्ताओं को मनमाने ढंग से कई कमिट के माध्यम से पैरामीटर जोड़ने के लिए माइग्रेट करें
3. यदि आप एक पदावनति को लागू करने के लिए तैयार नहीं हैं (या आप WithInt होने से परेशान नहीं हैं), तो आप कर रहे हैं। अन्यथा फू को func Foo(x int) { FooWithInt(x) } संशोधित करें।
4. उपयोगकर्ताओं को s/FooWithInt/Foo/g के साथ मनमाने ढंग से कई कमिट के माध्यम से माइग्रेट करें।
5. FooWithInt हटाएं।

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

आज चलने वाले प्रकारों और आज किसी फ़ंक्शन का नाम बदलने के बीच का अंतर यह है कि पूर्व मामले में, आपको वास्तव में एक परमाणु परिवर्तन की आवश्यकता होती है, जबकि बाद के लिए, आप स्वतंत्र रेपो और कमिट्स पर धीरे-धीरे परिवर्तन कर सकते हैं। "मैं एक प्रतिबद्धता बनाऊंगा जो एस/फू/बार/" करता है, लेकिन ऐसा करने की एक प्रक्रिया है।

वैसे भी। मुझे नहीं पता कि हम कहाँ हैं, जाहिरा तौर पर, एक दूसरे से बात कर रहे हैं। मुझे अपने पीओवी को व्यक्त करने के लिए @rsc का दस्तावेज़ बहुत स्पष्ट लगता है और वास्तव में आपका नहीं मिलता :)

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

@Merovius निश्चित रूप से, एक विधि का नाम बदलना तब तक संभव है जब तक _you वास्तव में इसका नाम नहीं बदलते हैं और कॉल साइटों को इसके बजाय एक नई एपीआई का उपयोग करने के लिए मजबूर करते हैं। इसी तरह, एक प्रकार को तब तक ले जाना संभव है जब तक _आप वास्तव में इसे स्थानांतरित नहीं करते हैं, और कॉल साइटों को इसके बजाय एक नए एपीआई का उपयोग करने के लिए मजबूर करते हैं। पुराने कोड को काम करने के लिए हम सभी वर्षों से इन दोनों चीजों को कर रहे हैं।

@niemeyer लेकिन फिर से: प्रकारों के लिए, आप चीजों को सभ्य तरीके से भी नहीं जोड़ सकते हैं। एक्स/छवि/ड्रा देखें। और हर किसी के पास स्थिरता के बारे में ऐसा पूर्ण दृष्टिकोण नहीं हो सकता है; मैं, स्वयं, यह कहकर ठीक हूं कि "6,12,… महीनों में $function,$type,… जा रहा है, सुनिश्चित करें कि आप उस बिंदु पर इससे दूर चले गए हैं" और फिर केवल उस असंबद्ध कोड को तोड़ दें जो नहीं करता है उस बहिष्करण नोटिस का पालन करने का प्रबंधन करें (यदि किसी को लगता है कि उन्हें एपीआई के लिए दीर्घकालिक समर्थन की आवश्यकता है, तो वे निश्चित रूप से इसे प्रदान करने के लिए भुगतान करने के लिए किसी को ढूंढ सकते हैं)। मैं यह भी दावा करूंगा कि अधिकांश लोगों का स्थिरता के बारे में पूर्ण दृष्टिकोण नहीं है; सिमेंटिक संस्करणों के लिए हालिया धक्का देखें, जो वास्तव में केवल तभी समझ में आता है जब आप संगतता को तोड़ने का विकल्प चाहते हैं। और डॉक्टर बहुत अच्छी तरह से तर्क देते हैं कि कैसे, उस स्थिति में भी, आप धीरे-धीरे मरम्मत करने की क्षमता से लाभ प्राप्त करेंगे और यह कैसे कम हो सकता है, यदि अनिवार्य रूप से हीरा निर्भरता समस्या को हल नहीं किया जाता है।

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

@niemeyer @rsc @Merovius मैं आपकी चर्चा (और पूरी चर्चा) का अनुसरण कर रहा हूं और मैं इस पोस्ट को ठीक इसके बीच में स्पष्ट रूप से स्मैक करना चाहता हूं।

जितना अधिक हम इस मुद्दे पर पुनरावृति करते हैं, हम किसी न किसी रूप में विस्तारित सहसंयोजक शब्दार्थ के करीब आते हैं। तो, यहाँ एक विचार है: हमारे पास पहले से ही उपप्रकार शब्दार्थ ("is-a") है जो ठोस प्रकारों से लेकर इंटरफेस और इंटरफेस के बीच परिभाषित है। मेरा प्रस्ताव उनके तरीकों के तर्कों के लिए इंटरफेस को पुनरावर्ती सहसंयोजक (वर्तमान विचरण नियमों के अनुसार) बनाना है।

यह सभी मौजूदा पैकेजों के लिए समस्या का समाधान नहीं करता है। लेकिन यह भविष्य के सभी पैकेजों के लिए समस्या को हल कर सकता है, फिर भी लिखा जाना है, जिसमें एपीआई के "चलने योग्य हिस्से" इंटरफेस हो सकते हैं (अच्छे डिजाइन को भी प्रोत्साहित करते हैं)।

मुझे लगता है कि हम इस तरह इंटरफेस का उपयोग करके (एबी) सभी आवश्यकताओं को हल कर सकते हैं। क्या हम गो 1.0 तोड़ रहे हैं? मुझे नहीं पता लेकिन मुझे लगता है कि हम नहीं हैं।

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

@thwd मैं असहमत हूं, कि इंटरफेस (यहां तक ​​​​कि सब कुछ एक इंटरफ़ेस बनाने की आवश्यकता होगी (क्योंकि आप कभी नहीं जानते कि आप किसी बिंदु पर क्या स्थानांतरित/बदलना चाहते हैं), जिसमें vars/consts/funcs/… और मुझे नहीं लगता पर सब, यह अच्छा डिजाइन है (मैंने इसे जावा में देखा है। यह मुझे बढ़ाता है)। अगर कुछ संरचना है, तो बस इसे एक संरचना बनाएं। बाकी सब कुछ आपके पैकेज में अजीब वाक्य रचनात्मक ओवरहेड जोड़ता है और वस्तुतः बिना किसी लाभ के हर रिवर्स निर्भरता जोड़ता है। जब आप शुरू करते हैं तो सचेत रहने का यही एकमात्र तरीका है; सरल शुरुआत करें और बाद में कुछ और सामान्य करें। एपीआई में बहुत सी जटिलताएं जो मैंने अब तक देखी हैं, वे लोगों से आती हैं जो एपीआई डिजाइन पर विचार कर रही हैं और जिस तरह से अधिक व्यापकता की आवश्यकता होगी, उसकी योजना बना रहे हैं। और फिर, मामलों के 80% (वह संख्या एक स्पष्ट झूठ है) में, कुछ भी नहीं होता है, क्योंकि कोई "क्लीन एपीआई डिज़ाइन" नहीं है।

(स्पष्ट होने के लिए: मैं यह नहीं कह रहा हूं कि सहसंयोजक इंटरफेस एक अच्छा विचार नहीं है। मैं सिर्फ इतना कह रहा हूं कि वे इन समस्याओं का अच्छा समाधान नहीं हैं)

@Merovius के बिंदु में जोड़ने के लिए, मैंने देखा है कि कई क्रमिक कोड मरम्मत ने आम तौर पर उपयोगी गैर-इंटरफ़ेस प्रकार को एक बड़े पैकेज से बाहर ले जाने का रूप ले लिया है। निम्न पर विचार करें:

package foo

type Authority struct {
  Host string
  Port int
}

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

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

@griesemer @Merovius मैं आप दोनों से सहमत हूं। लूप को बंद करने के लिए, हम इस बात से सहमत हो सकते हैं कि अब तक की चर्चा ने हमें उपप्रकार/सहप्रसरण की कुछ धारणाओं की ओर अग्रसर किया है। साथ ही, इसके किसी भी कार्यान्वयन में कोई रनटाइम संकेत नहीं होना चाहिए। इस तरह का @niemeyer प्रस्ताव दे रहा था (अगर मैं उसे सही समझा)। लेकिन मुझे और विचार पढ़ना अच्छा लगेगा। मैं भी समस्या के बारे में सोचूंगा।

@niemeyer @Merovius की टिप्पणियों में

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

तथा

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

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

@niemeyer आपके द्वारा adapts घोषणा हास्केल टाइपक्लास से instance से निकटता से संबंधित प्रतीत होती है। इसका संक्षेप में गो में अनुवाद करते हुए, यह कुछ इस तरह दिख सकता है:

package os

type Error interface {
  String() string
}

instance error Error (
  func (e error) String() string { return e.Error() }
)

दुर्भाग्य से ( @zombiezen नोट्स के रूप में), यह स्पष्ट नहीं है कि यह गैर-इंटरफ़ेस प्रकारों के लिए कैसे मदद करेगा।

यह मेरे लिए भी स्पष्ट नहीं है कि यह फ़ंक्शन प्रकारों (तर्क और रिटर्न-वैल्यू) के साथ कैसे इंटरैक्ट करेगा; उदाहरण के लिए, adapts का शब्दार्थ Context को मानक पुस्तकालय में स्थानांतरित करने में कैसे मदद करेगा?

मुझे उन बयानों से मेरोवियस के समान ही आभास हुआ - कि आप कुछ समय के लिए किसी चीज़ को चित्रित करने के लिए सहानुभूति नहीं रखते हैं

@jba ये पूर्ण तथ्य हैं, पूर्ण राय नहीं। यदि आप किसी विधि या प्रकार को हटाते हैं, तो इसका उपयोग करके गो कोड टूट जाता है, इसलिए इन परिवर्तनों को परमाणु रूप से करने की आवश्यकता है। मेरा प्रस्ताव, हालांकि, कोड के क्रमिक रिफैक्टरिंग के बारे में है, जो कि यहां विषय है और पदावनति का तात्पर्य है। हालाँकि, पदावनति की वह प्रक्रिया सहानुभूति की बात नहीं है। मेरे पास कई सार्वजनिक गो पैकेज हैं जिनमें हजारों जंगली निर्भरताएं हैं, और उस क्रमिक विकास के कारण कई स्वतंत्र एपीआई हैं। जब हम एक एपीआई तोड़ते हैं, तो बैचों में इस तरह के ब्रेकेज करना अच्छा होता है, बजाय उन्हें स्ट्रीम करने के, अगर हम लोगों को पागल नहीं होने की उम्मीद करते हैं। जब तक, निश्चित रूप से, आप एक दीवार वाले बगीचे में रहते हैं और इसे ठीक करने के लिए हर कॉल साइट तक पहुंच सकते हैं। लेकिन मैं खुद को दोहरा रहा हूं.. वह सब ऊपर मूल प्रस्ताव में अधिक स्पष्ट तरीके से पढ़ा जा सकता है।

@मेरोवियस

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

हम बेतहाशा बड़ी संख्या में नए और बहिष्कृत एपीआई के साथ पैकेज बनाए रखते हैं और पुराने (उपनाम) प्रकार की स्थिति की स्पष्ट व्याख्या के बिना उपनाम होने से क्रमिक कोड मरम्मत में मदद नहीं मिलेगी और केवल बढ़ी हुई एपीआई सतह की भारीता में योगदान होगा। मैं @niemeyer से सहमत

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

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

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

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

@rakyll मैं कंप्यूटर-पठनीय बहिष्करण नोटिस रखने के उपयोग के मामले में सहानुभूति

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

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

@rakyll मैं मानता हूं कि stdlib को उपनामों के रूढ़िवादी उपयोग के साथ शुरू करना चाहिए, क्या उन्हें पेश किया जाना चाहिए।

साइडबार:

गो और संबंधित टूलिंग में पदावनति टिप्पणियों की स्थिति से अनजान लोगों के लिए पृष्ठभूमि, क्योंकि यह काफी फैला हुआ है:

जैसा कि @Merovius ने ऊपर उल्लेख किया है, आइटम को पदावनत के रूप में चिह्नित करने के लिए एक मानक परंपरा है, #10909, देखें https://blog.golang.org/godoc-documenting-go-code

TL; DR: पदावनत आइटम के डॉक्स में एक पैराग्राफ बनाएं जो "बहिष्कृत:" से शुरू होता है और बताता है कि प्रतिस्थापन क्या है।

पदावनत वस्तुओं को अधिक उपयोगी तरीके से प्रदर्शित करने के लिए गोडोक के लिए एक स्वीकृत प्रस्ताव है: # 17056।

@rakyll ने प्रस्तावित किया कि जब पदावनत वस्तुओं का उपयोग किया जाता है तो गॉलिंट चेतावनी देता है: गोलांग/लिंट # 238।

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

ऐसा करने का अर्थ होगा इनमें से एक:

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

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

यह बेहतर टूलिंग को सरल और अधिक सामान्य होने की अनुमति देकर मौजूद होने में सक्षम बनाता है: इसे विशेष मामले की आवश्यकता नहीं है या यहां तक ​​​​कि प्रकार के उपनामों के बारे में भी पता है: इसे केवल दस्तावेज़ टिप्पणियों में "बहिष्कृत:" से मेल खाने की आवश्यकता है।

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

@niemeyer मेरा पिछला जवाब बिजली के नुकसान के कारण खो गया :( क्रम से बाहर:

लेकिन मैं खुद को दोहरा रहा हूं..

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

मेरा प्रस्ताव, हालांकि, कोड के क्रमिक रिफैक्टरिंग के बारे में है

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

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

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

और, निष्पक्ष होने के लिए: भ्रम वास्तव में वाक्यों से मदद नहीं करता है जैसे

जब तक, निश्चित रूप से, आप एक दीवार वाले बगीचे में रहते हैं और इसे ठीक करने के लिए हर कॉल साइट तक पहुंच सकते हैं।

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

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

साथ ही इस बारे में बात करें कि प्रोटोबफ सार्वजनिक आयात जैसी चीजों का समर्थन कैसे करें और कैसे करें ...
मुझे लगता है कि किसी बिंदु पर इस पर बहस करने की आवश्यकता है कि क्या हम वास्तव में रैपर-पैकेज, प्रोटोबफ सार्वजनिक आयात या आंतरिक पैकेज को उजागर करने पर विचार करते हैं-एपीआई इतनी बुरी चीज है

नाइट: मुझे नहीं लगता कि प्रोटोबफ सार्वजनिक आयात को विशेष माध्यमिक उपयोग के मामले के रूप में उल्लेख किया जाना चाहिए। वे क्रमिक कोड मरम्मत के लिए डिज़ाइन किए गए थे, जैसा कि आंतरिक डिज़ाइन दस्तावेज़ और यहां तक ​​कि सार्वजनिक दस्तावेज़ीकरण दोनों में स्पष्ट रूप से उल्लेख किया गया है, इसलिए वे पहले से ही इस मुद्दे द्वारा वर्णित समस्याओं की छत्रछाया में आते हैं। साथ ही, मेरा मानना ​​​​है कि प्रोटोबफ सार्वजनिक आयात को लागू करने के लिए टाइप उपनाम पर्याप्त होंगे। (प्रोटो कंपाइलर vars उत्पन्न करता है, लेकिन वे तार्किक रूप से स्थिर हैं, इसलिए "var Enum_name = import.Enum_name" पर्याप्त होना चाहिए।)

@Merovius उत्पादक प्रतिक्रिया के लिए धन्यवाद। मुझे कुछ संदर्भ प्रदान करने का प्रयास करें:

मुझे अभी भी आश्चर्य है कि आपका तर्क यहाँ क्या है। मैं परमाणुता की इकाई को सिंगल कमिट समझता हूं। उस धारणा के साथ, मुझे यह समझ में नहीं आता है कि आप क्यों आश्वस्त हैं कि किसी विधि या प्रकार का विलोपन पहले अलग से नहीं हो सकता है,

कभी नहीं कहा कि ऐसा नहीं हो सकता। मैं एक कदम पीछे हटता हूं और अधिक स्पष्ट रूप से बताता हूं।

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

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

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

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

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

@niemeyer मुझे विश्वास नहीं है कि आपका सुझाव गो टाइप सिस्टम में गंभीर व्यवधान के बिना व्यावहारिक है।

इस कोड द्वारा प्रस्तुत दुविधा पर विचार करें:

package old
import "new"
type A adapts new.A
func (a A) NewA() {}

package new
type A struct{}
func (a A) OldA() {}

package main
import (
    "new"
    "old"
    "reflect"
)
func main() {
    oldv := reflect.ValueOf(old.A{})
    newv := reflect.ValueOf(new.A{})
    if oldv.Type() == newv.Type() {
        // The two types are equal, therefore they must
        // have exactly the same method set, so either
        // oldv doesn't have the OldA method or newv doesn't
        // have the NewA method - both of which imply a contradiction
        // in the type system.
    } else {
         // The two types are not equal, which means that the
         // old adapted type is not fully compatible with the old
         // one. Any type that includes either new.A or new.B will
         // be incompatible as one of its components will likewise be
         // unequal, so any code that relies on dynamic type checking
         // will fail when presented with the type that's not using the
         // expected version.
    }
 }

प्रतिबिंबित पैकेज के वर्तमान स्वयंसिद्धों में से एक यह है कि यदि दो प्रकार समान हैं, तो उनका प्रतिबिंब। प्रकार मान समान हैं। यह गो के रनटाइम प्रकार रूपांतरण की दक्षता की नींव में से एक है। जहां तक ​​​​मैं देख सकता हूं कि इसे तोड़ने के बिना "अनुकूलन" कीवर्ड को लागू करने का कोई तरीका नहीं है।

@rogpeppe ऊपर प्रतिबिंब के बारे में @rsc के साथ बातचीत देखें। दो प्रकार समान नहीं हैं, इसलिए प्रतिबिंबित केवल सच कहेगा और इसके बारे में पूछे जाने पर एडेप्टर के लिए विवरण प्रदान करेगा।

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

हम कर सकते हैं:

package newimage
import "image"
type RGBA adapts image.RGB
func (r *RGBA) At(x, y) color.Color {
    return (*image.Buffer)(r).At(x, y)
}
etc for all the methods

क्रमिक कोड मरम्मत के उद्देश्य को देखते हुए, मुझे लगता है कि यह उम्मीद करना उचित है
नए पैकेज में बनाई गई छवि मौजूदा कार्यों के अनुकूल है
जो पुराने छवि प्रकार का उपयोग करते हैं।

आइए तर्क के लिए मान लें कि छवि/पीएनजी पैकेज है
नई छवि का उपयोग करने के लिए परिवर्तित किया गया है लेकिन छवि/जेपीईजी नहीं है।

मेरा मानना ​​​​है कि हमें इस कोड के काम करने की उम्मीद करनी चाहिए:

img, err := png.Decode(r)
if err != nil { ... }
err = jpeg.Encode(w, img, nil)

लेकिन, चूंकि यह *image.RGBA नहीं *newimage.RGBA के खिलाफ एक प्रकार का जोर देता है,
यह AFAICS विफल हो जाएगा, क्योंकि प्रकार भिन्न हैं।

मान लें कि हमने उपरोक्त प्रकार को सफल बनाया है, चाहे वह प्रकार *image.RGBA . हो
या नहीं। यह वर्तमान अपरिवर्तनीय को तोड़ देगा कि:

प्रतिबिंबित करें। टाइपऑफ (एक्स) == प्रतिबिंबित करें। टाइपऑफ (एक्स। (किसी भी स्टेटिक टाइप))

यही है, एक स्थिर प्रकार के दावे का उपयोग केवल स्थिर प्रकार के a . पर जोर नहीं देगा
मूल्य लेकिन कभी-कभी यह वास्तव में इसे बदल देगा।

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

यह एक और विरोधाभासी स्थिति की ओर जाता है:

// oldInterface is some interface with methods that
// are only supported by the old type.
type oldInterface interface {
    OldMethod()
}
var x = interface{} = newpackage.Type{}
switch x.(type) {
case oldInterface:
    // This would fail because the newpackage.Type
    // does not implement OldMethod, even though we
    // we just supposedly checked that x implements OldMethod.
    reflect.TypeOf(x).Method("OldMethod")
}

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

मैं "टाइप एक्स = वाई" प्रस्ताव का समर्थन करता हूं। इसे समझाना आसान है और नहीं
टाइप सिस्टम को बहुत ज्यादा बाधित करें।

@rogpeppe : मेरा मानना ​​​​है कि @niemeyer का सुझाव एक अनुकूलित प्रकार को इसके मूल प्रकार में परिवर्तित करना है, जो @josharian के पहले के सुझावों के समान है।

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

जैसा कि आपने नोट किया है, इससे कुछ दिलचस्प किनारे के मामले सामने आते हैं, लेकिन वे जरूरी नहीं कि "विरोधाभासी" हों:

type oldInterface interface {
    OldMethod()
}
var x = interface{} = newpackage.Type{}
switch y := x.(type) {
case oldInterface:
    reflect.TypeOf(y).Method("OldMethod")  // ok
    reflect.TypeOf(x).Method("NewMethod")  // ok

    // This would fail because y has been implicitly converted to oldInterface.
    reflect.TypeOf(y).Method("NewMethod")

    // This would fail because accessing OldMethod on newpackage.Type requires
    // a conversion to oldInterface.
    reflect.TypeOf(x).Method("OldMethod")
}

// This would fail because accessing OldMethod on newpackage.Type requires
// a conversion to oldInterface.

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

यहां चर्चा समाप्त होती दिख रही है। https://github.com/golang/go/issues/16339#issuecomment -247536289 में

कुल मिलाकर, ऐसा लगता है कि यहाँ भावना सामान्यीकृत उपनामों के बजाय प्रकार के उपनामों के लिए है। संभवतः गुस्तावो का एडेप्टर विचार प्रकार के उपनामों को विस्थापित करेगा, लेकिन संभवतः नहीं। फिलहाल यह थोड़ा जटिल लगता है, हालांकि शायद चर्चा के अंत तक एक सरल रूप में पहुंच जाएगा। मेरा सुझाव है कि चर्चा थोड़ी देर और जारी रहे।

मुझे अभी भी विश्वास नहीं है कि परिवर्तनीय वैश्विक संस्करण "आमतौर पर एक बग" होते हैं (और उन मामलों में जहां वे एक बग हैं, रेस डिटेक्टर उस तरह की बग खोजने के लिए पसंद का उपकरण है)। मैं अनुरोध करता हूं कि, यदि उस तर्क का उपयोग एक्स्टेंसिबल सिंटैक्स की कमी को उचित ठहराने के लिए किया जाता है, तो एक पशु चिकित्सक-जांच लागू की जाती है - कहें - कोड में वैश्विक चर के असाइनमेंट के लिए जांच विशेष रूप से init() या उनकी घोषणाओं द्वारा उपलब्ध नहीं है। मैं भोलेपन से सोचता हूं कि इसे लागू करना विशेष रूप से कठिन नहीं है और इसे चलाने के लिए अधिक काम नहीं होना चाहिए - कहते हैं - सभी godoc.org पंजीकृत पैकेज यह देखने के लिए कि परिवर्तनशील वैश्विक var के लिए उपयोग के मामले क्या हैं और क्या हम करते हैं उन सभी बग पर विचार करें।

(मैं यह भी मानना ​​​​चाहता हूं कि, यदि अपरिवर्तनीय वैश्विक युद्ध बढ़ते हैं, तो उन्हें कॉन्स-घोषणाओं का हिस्सा होना चाहिए, क्योंकि वे अवधारणात्मक रूप से यही हैं और क्योंकि यह पीछे की ओर संगत होगा, लेकिन मैं स्वीकार करता हूं कि इससे संभावित रूप से नेतृत्व होगा सरणी-प्रकारों में किस प्रकार के अभिव्यक्तियों का उपयोग किया जा सकता है, उदाहरण के लिए जटिलताओं और अधिक सोच की आवश्यकता होगी)

पुन: "प्रतिबंध? मानक पुस्तकालय प्रकारों के उपनाम केवल मानक पुस्तकालय में घोषित किए जा सकते हैं।" -- विशेष रूप से, यह x/image/draw लिए ड्रॉप-इन उपयोगकेस को रोकेगा, एक मौजूदा पैकेज जिसने उपनामों का उपयोग करने में रुचि व्यक्त की है। मैं बहुत अच्छी तरह से कल्पना भी कर सकता था, उदाहरण के लिए, राउटर पैकेज या समान रूप से net/http में उपनामों का उपयोग करना ( लहरें हाथ )।

मैं प्रतिवादों से भी सहमत हूं सभी प्रतिबंधों को हटा दें, अर्थात मैं उनमें से कोई भी नहीं रखने के पक्ष में हूं।

@Merovius , परिवर्तनशील _exported_ वैश्विक युद्धों के बारे में क्या? यह सच है कि एक गैर-निर्यातित वैश्विक ठीक हो सकता है क्योंकि पैकेज में सभी कोड जानता है कि इसे ठीक से कैसे संभालना है। यह कम स्पष्ट है कि निर्यात किए गए परिवर्तनीय ग्लोबल्स कभी भी समझ में आते हैं। मानक पुस्तकालय में हमने खुद कई बार यह गलती की है। उदाहरण के लिए रनटाइम को अपडेट करने का कोई पूरी तरह से सुरक्षित तरीका नहीं है। MemProfileRate। सबसे अच्छा आप यह कर सकते हैं कि इसे अपने कार्यक्रम में जल्दी सेट करें और आशा करें कि आपके द्वारा आयात किए गए किसी भी पैकेज ने प्रारंभिक गोरौटाइन को लात नहीं मारी जो स्मृति आवंटित कर सकती है। आप var बनाम const के बारे में सही हो सकते हैं, लेकिन हम इसे एक और दिन के लिए छोड़ सकते हैं।

एक्स/छवि/ड्रा के बारे में अच्छा बिंदु। अगले अपडेट में सारांश में जोड़ देंगे।

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

@rsc इस विषय के बारे में आपकी GothamGo प्रस्तुति को youtube https://www.youtube.com/watch?v=h6Cw9iCDVcU पर पोस्ट किया गया है और यह पहली पोस्ट में एक अच्छा जोड़ देगा।

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

@Merovius किसी भी निर्यात किए गए पैकेज-ग्लोबल

एक पैकेज के दिए गए संस्करण n p ,

package p
var Global = 0

संस्करण n+1 में गेटर्स और सेटर्स को पेश किया जा सकता है और वेरिएबल को पदावनत किया जा सकता है

package p
//Deprecated: use GetGlobal and SetGlobal.
var Global = 0
func GetGlobal() int {
    return Global
}
func SetGlobal(n int) {
   Global = n
}

और संस्करण n + 2 Global को निर्यात नहीं कर सकता है

package p
var global = 0
func GetGlobal() int {
    return global
}
func SetGlobal(n int) {
   global = n
}

(पाठक के लिए व्यायाम छोड़ दिया गया है: आप n + 2 में म्यूटेक्स में global तक पहुंच भी लपेट सकते हैं और GetGlobal() को अधिक मुहावरेदार Global() पक्ष में हटा सकते हैं।)

यह तेजी से ठीक नहीं है, लेकिन यह समस्या को कम करता है ताकि क्रमिक कोड मरम्मत के लिए केवल func उपनाम (या उनका वर्तमान समाधान) सख्ती से आवश्यक हो।

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

@jimmyfrasche आप सही हैं। मुझे गेटर्स और सेटर्स का उपयोग करने का विचार पसंद नहीं है (जैसे मैं उन्हें स्ट्रक्चर फ़ील्ड के लिए रखना पसंद नहीं करता) लेकिन आपका विश्लेषण निश्चित रूप से सही है।

उपनामों के गैर-मरम्मत उपयोगों (उदाहरण के लिए ड्रॉप-इन प्रतिस्थापन पैकेज बनाना) के बारे में एक बिंदु बनाया जाना है, लेकिन मैं मानता हूं कि यह var-aliases के मामले को कमजोर करता है।

@Merovius सभी बिंदुओं पर सहमत हुए। मैं इसके बारे में खुश नहीं हूँ, लेकिन तर्क का पालन करना होगा v☹v

@niemeyer क्या आप स्पष्ट कर सकते हैं कि एडेप्टर माइग्रेटिंग प्रकारों की सहायता कैसे करेंगे जहां पुराने और नए दोनों में एक ही नाम के साथ एक विधि है लेकिन अलग-अलग हस्ताक्षर हैं। किसी विधि में तर्क जोड़ना या तर्क के प्रकार को बदलना ऐसा लगता है कि वे एक कोडबेस के सामान्य विकास होंगे।

@rogpeppe ध्यान दें कि आज ऐसा ही होता है:

type two one

यह one और two स्वतंत्र प्रकार बनाता है, और चाहे प्रतिबिंबित कर रहा हो या interface{} तहत, यही आप देखते हैं। आप one और two के बीच भी कनवर्ट कर सकते हैं। ऊपर दिया गया एडॉप्टर प्रस्ताव उस अंतिम चरण को एडेप्टर के लिए स्वचालित बनाता है। आपको कई कारणों से प्रस्ताव पसंद नहीं आ सकता है, लेकिन इसमें कुछ भी विरोधाभासी नहीं है।

@iand जैसा कि type two one के मामले में है, दो प्रकारों में पूरी तरह से स्वतंत्र विधि सेट हैं, इसलिए मिलान नामों के बारे में कुछ खास नहीं है। पुराने कोड आधारों को माइग्रेट करने से पहले वे पिछले प्रकार (अब एक एडेप्टर) के तहत पुराने हस्ताक्षर का उपयोग करते रहेंगे। नए प्रकार का उपयोग करने वाला नया कोड नए हस्ताक्षर का उपयोग करेगा। नए प्रकार के मान को पुराने कोड में पास करना स्वचालित रूप से इसे अनुकूलित करता है क्योंकि संकलक जानता है कि बाद वाला पूर्व का एडाप्टर है, और इस प्रकार संबंधित विधि सेट का उपयोग करता है।

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

@jimmyfrasche उपनामों पर विधियों के संबंध में, निश्चित रूप से उपनाम सामान्य विधि परिभाषा प्रतिबंधों को दरकिनार करने की अनुमति नहीं देते हैं: यदि कोई पैकेज T1 = otherpkg.T2 प्रकार को परिभाषित करता है, तो यह T1 पर विधियों को परिभाषित नहीं कर सकता है, जैसे कि यह सीधे otherpkg.T2 पर विधियों को परिभाषित नहीं कर सकता है। हालांकि, यदि कोई पैकेज टाइप T1 = T2 (दोनों एक ही पैकेज में) को परिभाषित करता है, तो उत्तर कम स्पष्ट है। हम एक प्रतिबंध लगा सकते हैं लेकिन इसकी (अभी तक) कोई स्पष्ट आवश्यकता नहीं है।

शीर्ष-स्तरीय चर्चा सारांश अपडेट किया गया । परिवर्तन:

• GothamGo वीडियो में जोड़ा गया लिंक
• प्रति @jba संभावित उपयोग के रूप में "लंबे नामों को संक्षिप्त करना" जोड़ा गया।
• प्रति @Merovius मानक पुस्तकालय प्रतिबंध के खिलाफ तर्क के रूप में x/छवि/ड्रा जोड़ा गया।
• उपनामों पर विधियों के बारे में और पाठ जोड़ा गया, प्रति @jimmyfrasche।

डिज़ाइन दस्तावेज़ जोड़ा गया: golang.org/design/18130-type-alias

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

प्रस्ताव प्रक्रिया के बाद, कृपया इस मुद्दे पर _यहाँ_ प्रस्ताव पर मूल टिप्पणियाँ पोस्ट करें। वर्तनी/व्याकरण/आदि Gerrit codereview पृष्ठ https://go-review.googlesource.com/#/c/34592/ पर जा सकते हैं

मैं "एम्बेडिंग पर प्रभाव" पर पुनर्विचार करना चाहता हूं। यह क्रमिक कोड मरम्मत के लिए प्रकार के उपनामों की उपयोगिता को सीमित करता है। अर्थात्, यदि p1 एक प्रकार का नाम बदलना चाहता है type T1 = T2 और पैकेज p2 एक स्ट्रक्चर में p1.T2 एम्बेड करता है, तो वे उस परिभाषा को p1.T1 अपडेट नहीं कर पाएंगे। p3 नाम से एम्बेडेड संरचना को संदर्भित कर सकता है। p2 फिर p1.T1 को तोड़े बिना p3 स्विच नहीं किया जा सकता; p3 वर्तमान p2 को तोड़े बिना, नाम को p1.T1 अपडेट नहीं कर सकता।

इसका एक तरीका होगा, क) सामान्य सीमा में किसी भी संगतता / पदावनति-अवधि के वादे को कोड से जो नाम से एम्बेडेड फ़ील्ड को संदर्भित नहीं करता है, या बी) एक अलग बहिष्करण चरण जोड़ें, इसलिए p1 कहते हैं type T1 = T2 और deprecates T2 , तो p2 (माना) की चर्चा करते हुए deprecates s2.T2 नाम से, के सभी आयातकों p2 मरम्मत की जाएगी ऐसा नहीं करने के लिए, फिर p2 स्विच करता है।

अब, सिद्धांत रूप में, समस्या अनिश्चित काल तक पुनरावृत्ति कर सकती है; p4 p3 आयात कर सकता है, जो स्वयं p2 से प्रकार को एम्बेड करता है; मुझे ऐसा प्रतीत होता है, कि p3 भी दो बार एम्बेड किए गए फ़ील्ड को नाम से संदर्भित करने के लिए एक बहिष्करण अवधि की आवश्यकता है? उस स्थिति में, अंतरतम मूल्यह्रास अवधि असीम हो जाती है या सबसे बाहरी अनंत हो जाती है। लेकिन समस्या को पुनरावर्ती मानने के बिना भी, यह मुझे प्रतीत होता है, कि बी) समय के लिए बहुत कठिन होगा ( p2 की मूल्यह्रास अवधि को p1 की मूल्यह्रास अवधि में पूरी तरह से समाहित करने की आवश्यकता होगी। कम से कम 2T चुनना होगा, ताकि रिलीज़ लाइन अप हो जाए)।

ए) मुझे भी अव्यवहारिक लगता है; उदाहरण के लिए यदि कोई प्रकार *byte.Buffer एम्बेड करता है और मैं उस फ़ील्ड को सेट करना चाहता हूं (या उस बफर को किसी अन्य फ़ंक्शन में पास करना चाहता हूं), ऐसा करने का कोई तरीका नहीं है, इसे नाम से संदर्भित किए बिना (स्ट्रक्चर प्रारंभकर्ताओं का उपयोग करने के अलावा) नाम के बिना, जो संगतता गारंटी भी खो देता है :))।

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

एक उपनाम पर @rsc पुनः विधियाँ

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

नियम - यदि आपके पास type T = S , तो आप T पर विधियों की घोषणा नहीं कर सकते हैं - यह निरपेक्ष है और स्रोत में उस एकल पंक्ति से यह स्पष्ट है कि यह स्रोत की जांच किए बिना लागू होता है एस, जैसा कि आप उपनाम स्थिति के उपनाम में करेंगे।

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

@jimmyfrasche अगर हम type T1 = T2 लिख रहे हैं और T2 एक ही पैकेज में है, तो हम शायद T2 नाम को हटा रहे हैं। उस स्थिति में, हम चाहते हैं कि गोडोक में T2 की यथासंभव कम घटनाएं हों। इसलिए हम सभी विधियों को func (T1) M() रूप में घोषित करना चाहते हैं।

@jba उस उपनाम पर घोषित किए जाने वाले उपनाम के तरीकों की रिपोर्ट करने के लिए एक गॉडोक परिवर्तन स्रोत की पठनीयता को बदले बिना उस आवश्यकता को पूरा करेगा। सामान्य तौर पर यह अच्छा होगा यदि एलियासिंग और/या एम्बेडिंग शामिल होने पर गोडोक एक प्रकार का पूर्ण विधि सेट प्रदर्शित करता है, खासकर जब प्रकार किसी अन्य पैकेज से आता है। समस्या को स्मार्ट टूलिंग के साथ हल किया जाना चाहिए न कि अधिक भाषा शब्दार्थ।

@jba उस स्थिति में, आप उपनाम की दिशा को उलट क्यों नहीं देंगे? type T2 = T1 पहले से ही आपको समान पैकेज संरचना के साथ T1 पर विधियों को परिभाषित करने की अनुमति देता है; अंतर केवल reflect पैकेज द्वारा रिपोर्ट किए गए प्रकार के नाम का है, और आप उपनाम जोड़ने से पहले नाम-संवेदनशील कॉल साइटों को नाम-असंवेदनशील बनाने के लिए माइग्रेशन प्रारंभ कर सकते हैं।

@jimmyfrasche प्रस्ताव दस्तावेज़ से :

"चूंकि T1 T2 लिखने का एक और तरीका है, इसके पास विधि घोषणाओं का अपना सेट नहीं है। इसके बजाय, T1 का विधि सेट T2 के समान है। कम से कम प्रारंभिक परीक्षण के लिए, T1 का उपयोग करके विधि घोषणाओं के खिलाफ कोई प्रतिबंध नहीं है एक रिसीवर प्रकार, उसी घोषणा में T2 का उपयोग करके प्रदान किया गया मान्य होगा। "

एक विधि रिसीवर प्रकार के रूप में पीएफ का उपयोग करना कभी भी मान्य नहीं होता है।

@mdempsky मैं बहुत स्पष्ट नहीं था, लेकिन मैंने कहा कि यह अमान्य था।

मेरा मुद्दा यह है कि यह कम स्पष्ट रूप से स्पष्ट है कि यह कोड की उस विशिष्ट पंक्ति को देखकर मान्य है या नहीं।

type S = T , आपको यह सुनिश्चित करने के लिए T भी देखना होगा कि यह उपनाम भी नहीं है जो किसी अन्य पैकेज में एक प्रकार का उपनाम है। एकमात्र लाभ जटिलता है।

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

@मेरोवियस

यदि p1 एक प्रकार का नाम बदलना चाहता है T1 = T2 और पैकेज p2 एक स्ट्रक्चर में p1.T2 एम्बेड करता है, तो वे उस परिभाषा को p1.T1 में अपडेट करने में सक्षम नहीं होंगे, क्योंकि एक आयातक p3 नाम से एम्बेडेड स्ट्रक्चर को संदर्भित कर सकता है।

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

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

आपके उदाहरण से घोषणा को ध्यान में रखते हुए:

package p2

type S struct {
  p1.T2
}

एक क्षतिपूर्ति सुविधा "फ़ील्ड उपनाम" हो सकती है, जो उपनाम टाइप करने के लिए समान वाक्यविन्यास का पालन करेगी:

package p2

type S struct {
  p1.T1
  T2 = T1  // field T2 is an alias for field T1.
}

var s S  // &s.T2 == &s.T1

एक अन्य क्षतिपूर्ति सुविधा "प्रतिनिधिमंडल" हो सकती है, जो स्पष्ट रूप से एक अज्ञात क्षेत्र के विधि सेट को अपनाएगी:

package p2

type S struct {
  T2 p1.T1 delegated  // T2 is a field of type T1.
  // The method set of S includes the method set of T1 and forwards those calls to field T2.
}

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

@Merovius मुख्य मुद्दा तब होता है जब प्रकार का नाम उपनाम से बदल दिया जाता है।

मैंने इसे पूरी तरह से नहीं माना है - मुश्किल से गुजरने में, बस एक यादृच्छिक विचार:

क्या होगा यदि आप अपने पैकेज में एक उपनाम पेश करते हैं जो इसे वापस नाम देता है और उसे एम्बेड करता है?

मुझे नहीं पता कि यह कुछ भी ठीक करता है, लेकिन शायद यह लूप को तोड़ने के लिए कुछ समय खरीदता है?

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

@Merovius जितना अधिक मैं इसके बारे में सोचता हूं, उतना ही मुझे फील्ड उपनामों का विचार पसंद है।

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

@मेरोवियस

यदि p1 एक प्रकार का नाम बदलना चाहता है T1 = T2 और पैकेज p2 एक स्ट्रक्चर में p1.T2 एम्बेड करता है, तो वे उस परिभाषा को p1.T1 में अपडेट करने में सक्षम नहीं होंगे, क्योंकि एक आयातक p3 नाम से एम्बेडेड स्ट्रक्चर को संदर्भित कर सकता है। p2 तब p3 को तोड़े बिना p1.T1 पर स्विच नहीं कर सकता; p3 वर्तमान p2 को तोड़े बिना नाम को p1.T1 में अपडेट नहीं कर सकता।

अगर मैं आपका उदाहरण समझता हूं, तो हमारे पास है:

package p1

type T2 struct {}
type T1 = T2

package p2

import "p1"

type S struct {
  p1.T2
  F2 string // see below
}

मेरा मानना ​​​​है कि यह सामान्य मामले का एक विशिष्ट उदाहरण है जहां हम एक स्ट्रक्चर फ़ील्ड का नाम बदलना चाहते हैं; यदि हम S.F2 का नाम बदलकर S.F1 करना चाहते हैं तो यही समस्या लागू होती है।

इस विशिष्ट मामले में, हम स्थानीय प्रकार के उपनाम के साथ p1 के नए एपीआई का उपयोग करने के लिए पैकेज p2 को अपडेट कर सकते हैं:

package p2

import "p1"

type T2 = p1.T1

type S struct {
  T2
}

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

"पैकेजों के बीच चलती प्रकार" से संबंधित बस एक नोट। क्या यह सूत्रीकरण थोड़ा समस्याग्रस्त नहीं है?

जहां तक ​​​​मैं समझता हूं, प्रस्ताव किसी ऑब्जेक्ट परिभाषा को "संदर्भित" करने की अनुमति देता है जो किसी अन्य पैकेज में एक नए नाम के माध्यम से निहित है।

यह वस्तु परिभाषा को स्थानांतरित नहीं करता है, है ना? (जब तक कि कोई पहले स्थान पर उपनामों का उपयोग करके कोड नहीं लिखता है, उपयोगकर्ता उस स्थान को बदलने के लिए स्वतंत्र है जहां उपनाम संदर्भित है, जैसे ड्रॉ पीकेजी में)।

@atdiar एक अलग पैकेज में एक प्रकार का जिक्र करते हुए प्रकार को स्थानांतरित करने में एक कदम के रूप में इस्तेमाल किया जा सकता है। हां, एक उपनाम प्रकार को स्थानांतरित नहीं करता है, लेकिन इसे ऐसा करने के लिए एक उपकरण के रूप में उपयोग किया जा सकता है।

@Merovius ऐसा करने से प्रतिबिंब और प्लगइन्स टूटने की संभावना है।

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

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

@मेरोवियस
मैं स्पष्ट रूप से संकुल के बीच "चलती प्रकार" के बारे में बात कर रहा हूँ। यह वस्तु परिभाषा को बदलता है। उदाहरण के लिए, pkg रिफ्लेक्ट में, कुछ जानकारी उस पैकेज से जुड़ी होती है जिसमें ऑब्जेक्ट को परिभाषित किया गया था।
यदि आप परिभाषा को आगे बढ़ाते हैं, तो यह टूट सकती है।

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

@atdiar फिर से, कृपया मूल टिप्पणी और अब तक की चर्चा से लेख पढ़ें। चलने के प्रकार और आपकी चिंताओं को कैसे दूर किया जाए, यह इस धागे की प्राथमिक चिंता है। यदि आपको नहीं लगता कि Russ का लेख आपकी चिंताओं को पर्याप्त रूप से संबोधित करता है, तो कृपया इस बारे में विशिष्ट रहें कि उनका स्पष्टीकरण संतोषजनक क्यों नहीं है। :)

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

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

@atdiar मैं, कम से कम, समझ में नहीं आता। तुम कह रहे हो कि एक प्रकार को हिलाने से चीजें टूट जाएंगी; प्रस्ताव इस बारे में है कि धीरे-धीरे मरम्मत के साथ इस तरह के टूटने से कैसे बचें, उपनाम का उपयोग करके, फिर प्रत्येक रिवर्स निर्भरता को तब तक अपडेट करें जब तक कोई कोड पुराने प्रकार का उपयोग न करे, फिर पुराने प्रकार को हटा दें। मैं नहीं देखता, आपका दावा, कि "प्रतिबिंब और प्लगइन्स" इन धारणाओं के तहत टूटा हुआ है। यदि आप मान्यताओं पर सवाल उठाना चाहते हैं, तो इस पर पहले ही चर्चा की जा चुकी है।

मैं यह भी नहीं देखता कि उपनामों को 1.8 में प्रवेश करने से रोकने वाली कोई भी समस्या आपके द्वारा कही गई बातों से कैसे जुड़ती है। मेरी जानकारी के अनुसार संबंधित मुद्दे #17746 और #17784 हैं। यदि आप एम्बेडिंग मुद्दे का जिक्र कर रहे हैं (जिसे टूटने या प्रतिबिंब से संबंधित के रूप में व्याख्या किया जा सकता है, हालांकि मैं असहमत हूं), तो इसे औपचारिक प्रस्ताव में संबोधित किया गया है (हालांकि, ऊपर देखें, मेरा मानना ​​​​है कि प्रस्तावित समाधान अधिक चर्चा के योग्य है) और आपको इस बारे में विशिष्ट होना चाहिए कि आप ऐसा क्यों नहीं मानते हैं।

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

@Merovius तो संक्रमणीय निर्भरताओं के मामले में जहां इन निर्भरताओं में से एक प्रतिबिंबित कर रहा है। टाइप। पीकेजीपाथ (), क्या होता है?
एम्बेडिंग समस्या में भी यही समस्या हो रही है।

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

मुझे इसे संक्षेप में दोबारा दोहराएं:

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

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

(उसी तरह पैकेज में पॉइंटर के प्रकार को बदलने से कई अन्य पैकेज टूट जाएंगे, अगर वह समानांतर चीजों को स्पष्ट कर सकता है।)

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

@नीमेयर

यह एक और दो स्वतंत्र प्रकार बनाता है, और चाहे प्रतिबिंबित हो या इंटरफ़ेस के अंतर्गत {}, यही है
आप समझ सकते हैं। आप एक और दो के बीच कनवर्ट भी कर सकते हैं। ऊपर दिया गया एडॉप्टर प्रस्ताव इसे अंतिम बनाता है
एडेप्टर के लिए स्वचालित कदम। आपको कई कारणों से प्रस्ताव पसंद नहीं आ सकता है, लेकिन ऐसा कुछ भी नहीं है
उसके बारे में विरोधाभासी।

आप के बीच कनवर्ट नहीं कर सकते

 func() one

तथा

func() two

@Merovius आप संभवतः जंगली में मौजूद कोड-मरम्मत पैकेज के सभी आयातकों को बदलने पर विचार नहीं कर सकते हैं। और मैं यहाँ पर पैकेज संस्करण में तल्लीन करना शुरू करने के लिए बहुत उत्सुक नहीं हूँ।

स्पष्ट होने के लिए, मैं उपनाम प्रस्ताव के खिलाफ नहीं हूं, लेकिन "पैकेजों के बीच चलने वाले प्रकार" फॉर्मूलेशन का मतलब है कि एक उपयोग-मामला जो अभी तक सुरक्षित नहीं है।

@jimmyfrasche विधि-पर-उपनाम वैधता की पुन: पूर्वानुमेयता:

यह पहले से ही मामला है कि func (t T) M() कभी-कभी मान्य होता है, कभी-कभी अमान्य। यह बहुत ज्यादा नहीं आता क्योंकि लोग अक्सर इन सीमाओं को नहीं लांघते हैं। यानी यह व्यवहार में अच्छा काम करता है। https://play.golang.org/p/bci2qnldej। किसी भी स्थिति में, यह _possible_ प्रतिबंधों की सूची में है। सभी संभावित प्रतिबंधों की तरह, यह जटिलता जोड़ता है और हम उस जटिलता को जोड़ने से पहले ठोस वास्तविक दुनिया के सबूत देखना चाहते हैं।

@Merovius , पुनः एम्बेडिंग नाम:

मैं मानता हूं कि स्थिति सही नहीं है। हालांकि, अगर मेरे पास io.ByteBuffer के संदर्भों से भरा कोडबेस है और मैं इसे बाइट्स में ले जाना चाहता हूं। बफर, तो मैं परिचय देने में सक्षम होना चाहता हूं

package io
type ByteBuffer = bytes.Buffer

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

हमने #17746 में इस पर कुछ विस्तार से चर्चा की। मैं मूल रूप से एक एम्बेडेड io.ByteBuffer उपनाम बफ़र होने के पक्ष में था, लेकिन उपरोक्त तर्क ने मुझे आश्वस्त किया कि मैं गलत था। @jimmyfrasche ने विशेष रूप से एम्बेडेड चीज़ की परिभाषा के आधार पर कोड नहीं बदलने के बारे में कुछ अच्छे तर्क दिए। मुझे नहीं लगता कि एम्बेडेड उपनामों को पूरी तरह से अस्वीकार करना उचित है।

ध्यान दें कि आपके उदाहरण में p2 में वर्कअराउंड है। यदि p2 वास्तव में io.ByteBuffer को संदर्भित किए बिना बाइटबफ़र नामक एक एम्बेडेड फ़ील्ड चाहता है, तो यह परिभाषित कर सकता है:

type ByteBuffer = bytes.Buffer

और फिर एक io.ByteBuffer के बजाय एक बाइटबफ़र (अर्थात, एक p2.ByteBuffer) एम्बेड करें। यह भी सही नहीं है, लेकिन इसका मतलब है कि मरम्मत जारी रह सकती है।

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

(/cc @neild और @bcmills)

@atdiar , हाँ, यह सच है कि प्रतिबिंबित इस प्रकार के परिवर्तनों के माध्यम से देखेगा, और यदि कोड प्रतिबिंबित परिणामों पर निर्भर करता है तो यह टूटने वाला है। एम्बेड करने की स्थिति की तरह, यह सही नहीं है। एम्बेडिंग की स्थिति के विपरीत, मेरे पास कोई जवाब नहीं है सिवाय इसके कि कोड को उन विवरणों के प्रति काफी संवेदनशील होने के लिए प्रतिबिंबित का उपयोग करके नहीं लिखा जाना चाहिए।

@rsc जो मेरे मन में था वह था ए) एक ही संरचना में एक उपनाम और यह परिभाषित प्रकार दोनों को एम्बेड करने से मना करें (बी से अस्पष्टता को रोकने के लिए), बी) स्रोत कोड में किसी भी नाम से किसी फ़ील्ड को संदर्भित करने की अनुमति दें, सी) एक चुनें या अन्य उत्पन्न प्रकार की जानकारी/प्रतिबिंब में और जैसे (परवाह नहीं है)।

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

मुझे अभी यकीन नहीं है कि मैं आपके बाइटबफर तर्क को समझता हूं, लेकिन मैं भी एक लंबे कार्यदिवस के अंत में हूं, इसलिए आगे की व्याख्या करने की आवश्यकता नहीं है, अगर मुझे यह असंबद्ध लगता है तो मैं अंततः जवाब दूंगा :)

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

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

@ आरएससी

शायद ऑब्जेक्ट फ़ाइलों में अलियासिबिलिटी पर पैकेज स्तर की जानकारी जोड़ने से मदद मिल सकती है।
(यह ध्यान में रखते हुए कि गो प्लगइन्स को ठीक से काम करते रहना है या नहीं।)

@ मेरोवियस @rsc

ए) एक ही संरचना में उपनाम और उसके परिभाषित प्रकार दोनों को एम्बेड करने से मना करें

ध्यान दें कि कई मामलों में यह पहले से ही प्रतिबंधित है क्योंकि जिस तरह से एम्बेडिंग विधि सेट के साथ इंटरैक्ट करता है। (यदि एम्बेडेड प्रकार में एक गैर-रिक्त विधि सेट है और उन विधियों में से एक को कॉल किया जाता है, तो प्रोग्राम संकलित करने में विफल हो जाएगा: https://play.golang.org/p/XkaB2a0_RK।)

इसलिए डबल-एम्बेडिंग को प्रतिबंधित करने वाला एक स्पष्ट नियम जोड़ने से ऐसा लगता है कि यह केवल मामलों के एक छोटे से सबसेट में अंतर लाएगा; मुझे जटिलता के लायक नहीं लगता।

इसके बजाय प्रकार के उपनामों को बीजगणितीय प्रकारों के रूप में क्यों न देखें और उपनामों को प्रकारों के एक सेट के लिए समर्थन दें, इसलिए हमें एक बोनस के रूप में संकलन समय प्रकार की जाँच के साथ एक खाली इंटरफ़ेस भी मिलता है, एक ला

type Stringeroonie = {string,fmt.Stringer}

@j7b

इसके बजाय प्रकार के उपनामों को बीजगणितीय प्रकारों के रूप में क्यों न देखें और उपनामों को प्रकारों के समूह में समर्थन दें

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

@बीसीमिल्स

यह दोषपूर्ण तर्क हो सकता है, लेकिन मैंने सोचा कि समस्या से संपर्क किया जा सकता है क्योंकि उर्फ ​​​​ए टाइप टी का ए इंटरफ़ेस के रूप में ए घोषित करने के बराबर है {} और कंपाइलर को पारदर्शी रूप से ए से टी के चर को उन क्षेत्रों में परिवर्तित करने देता है जहां टाइप ए के चर घोषित किए जाते हैं। , जो मैंने सोचा था कि ज्यादातर रैखिक संकलन-समय लागत, स्पष्ट, और type T = सिंटैक्स का उपयोग करके बीजगणित सहित कंपाइलर-प्रबंधित छद्म प्रकारों के लिए आधार तैयार करेगा, और संभावित रूप से संकलन समय पर अपरिवर्तनीय संदर्भ जैसे कार्यान्वयन प्रकारों को भी अनुमति देता है जहां तक ​​उपयोगकर्ता कोड का संबंध था, वह केवल इंटरफ़ेस {} "हुड के नीचे" होगा।

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

@ j7b भले ही एडीटी जहां एक क्रमिक मरम्मत समस्या का समाधान हो, वे अपना स्वयं का निर्माण करते हैं; निर्भरता को तोड़े बिना ADT के किसी भी सदस्य को जोड़ना या हटाना असंभव है। तो, आप संक्षेप में अधिक समस्याएं पैदा करेंगे, जितना आप हल करेंगे।

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

एडीटी यहां समाधान नहीं हैं।

@Merovius मुझे पूरा यकीन है कि अगर बीजगणितीय प्रकार के निर्माण में नाम बदलना शामिल है (जो उसी की उचित परिभाषा के अनुरूप होगा) यह एक समाधान है, इंटरफ़ेस {} कंपाइलर-प्रबंधित प्रक्षेपण और चयन के रूप में प्रॉक्सी के रूप में कार्य कर सकता है वर्णित है, और मुझे यकीन नहीं है कि डेटा लेआउट कैसे प्रासंगिक है और न ही आप "उच्च-क्रम" प्रकारों को कैसे परिभाषित कर रहे हैं, एक प्रकार केवल एक प्रकार है यदि इसे घोषित किया जा सकता है और [] इंटरफ़ेस {} केवल एक प्रकार है।

वह सब एक तरफ, मैं सकारात्मक हूं type T = नाम बदलने से परे सहज, उपयोगी तरीकों से अतिभारित होने की क्षमता है, बीजगणितीय प्रकार और सार्वजनिक रूप से अपरिवर्तनीय संदर्भ सबसे स्पष्ट अनुप्रयोग प्रतीत होते हैं, इसलिए मुझे आशा है कि विनिर्देश उस वाक्यविन्यास को बताते हुए समाप्त होता है एक कंपाइलर-प्रबंधित मेटा या छद्म प्रकार को इंगित करता है और उन सभी तरीकों पर विचार किया जाता है जो एक कंपाइलर-प्रबंधित प्रकार उपयोगी हो सकता है और सिंटैक्स जो उन उपयोगों को सर्वोत्तम रूप से व्यक्त करता है। चूंकि क्वालिफायर के रूप में उपयोग किए जाने पर एक नए सिंटैक्स को विश्व स्तर पर आरक्षित शब्दों के सेट के साथ खुद को चिंतित करने की आवश्यकता नहीं होती है, जैसे type A = alias Type स्पष्ट और एक्स्टेंसिबल होगा।

@j7b

वह सब एक तरफ, मैं सकारात्मक प्रकार T = नाम बदलने से परे सहज, उपयोगी तरीकों से अतिभारित होने की क्षमता रखता हूं,

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

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

मैं एक अलग दृष्टिकोण बिंदु (समर्थन में) प्रकार के उपनामों में फेंकना पसंद करता हूं, जो कि रिफैक्टरिंग के अलावा वैकल्पिक उपयोग के मामलों में कुछ अंतर्दृष्टि प्रदान कर सकता है:

आइए एक पल के लिए पीछे हटें और मान लें कि हमारे पास type T <a type> फॉर्म की नियमित पुरानी गो प्रकार की घोषणाएं नहीं थीं, लेकिन केवल उपनाम घोषणाएं type A = <a type> टाइप करें।

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

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

दूसरे शब्दों में, अगर गो को इस तरह से डिजाइन किया गया होता, तो हम शायद ठीक होते, भी, बड़े पैमाने पर।

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

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

अन्य प्रोग्रामिंग भाषाओं में, मौजूदा प्रकार से एक नया, अलग प्रकार बनाने की धारणा को "ब्रांडिंग" कहा जाता है: एक प्रकार का एक ब्रांड इससे जुड़ा होता है जो इसे अन्य सभी प्रकारों से अलग बनाता है। उदाहरण के लिए, मोडुला -3 में, ऐसा करने के लिए एक विशेष कीवर्ड BRANDED था (उदाहरण के लिए TYPE T = BRANDED REF T0 T0 के लिए एक नया, अलग संदर्भ बनाएगा)। हास्केल में, एक प्रकार से पहले new शब्द का समान प्रभाव पड़ता है।

अपनी वैकल्पिक गो दुनिया में वापस जाने पर, हम हमें उस स्थिति में पा सकते हैं जहां हमें रिफैक्टरिंग में कोई समस्या नहीं है, लेकिन जहां हम अपने कोड की सुरक्षा में सुधार करना चाहते हैं ताकि type MyBuffer = []byte और type YourBuffer = []byte निरूपित हो सकें विभिन्न प्रकार ताकि हम गलती से गलत का उपयोग न करें। हम ठीक उसी उद्देश्य के लिए एक प्रकार की ब्रांडिंग शुरू करने का प्रस्ताव कर सकते हैं। उदाहरण के लिए, हम type MyBuffer = new []byte , या यहां तक ​​कि type MyBuffer = new YourBuffer इस आशय से लिखना चाह सकते हैं कि MyBuffer अब YourBuffer से एक अलग प्रकार है।

यह संक्षेप में हमारे पास अब जो है उसकी दोहरी समस्या है। ऐसा होता है कि गो में, पहले दिन से, हम हमेशा "ब्रांडेड" प्रकारों के साथ काम करते हैं जैसे ही उन्हें कोई नाम मिलता है। दूसरे शब्दों में, type T <a type> प्रभावी रूप से type T = new <a type> ।

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

मुद्दा यह है कि दोनों तंत्र स्वाभाविक रूप से उपयोगी हैं, और प्रकार के उपनामों के साथ हम अंततः उन दोनों का समर्थन करने के लिए तैयार हो जाते हैं।

@griesemer उस सुविधा का विस्तार प्रारंभिक उपनाम प्रस्ताव है जिसे आदर्श रूप से रिफैक्टरिंग को साफ करना चाहिए। मुझे डर है कि केवल टाइप एलियास ही इसके प्रतिबंधित दायरे के कारण मुश्किल रिफैक्टरिंग एज केस बनाएंगे।

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

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

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

एलियासिंग के उपयोग का पता लगाने का एक विकल्प यह होगा कि बड़े पैमाने पर एक ठोस संस्करण की कहानी हो, जो संदर्भ पैकेज के लिए किए गए पैकेजों में ऑब्जेक्ट परिभाषाओं को "स्थानांतरित" करने में सक्षम हो। लेकिन यह पूरी तरह से एक और मुद्दा है।

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

@atdiar मुझे यकीन नहीं है कि आपका मतलब है कि जब आप "अलग संकलन" कहते हैं तो मैं क्या करता हूं। यदि पैकेज P io और बाइट्स आयात करता है, तो तीनों को अलग-अलग चरणों के रूप में संकलित किया जा सकता है। हालाँकि, यदि io या बाइट्स बदलते हैं, तो P को फिर से कंपाइल करना होगा। यह _not_ मामला है कि आप io या बाइट्स में परिवर्तन कर सकते हैं और फिर P के पुराने संकलन का उपयोग कर सकते हैं। प्लगइन मोड में भी, यह सच है। क्रॉस-पैकेज इनलाइनिंग जैसे प्रभावों के कारण, आईओ या बाइट्स के कार्यान्वयन में गैर-एपीआई-दृश्यमान परिवर्तन भी प्रभावी एबीआई को बदल देते हैं, यही कारण है कि पी को फिर से संकलित किया जाना चाहिए। उपनाम टाइप करें इस समस्या को बदतर नहीं बनाते हैं।

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

एक प्रकार का कंस्ट्रक्टर ("एक प्रकार का उपयोग करने का एक तरीका" कहने का एक शानदार तरीका) सहसंयोजक है यदि यह उप-प्रकार के संबंध को संरक्षित करता है, यदि यह संबंध को उलट देता है, तो इसके विपरीत।

फ़ंक्शन परिणाम में एक प्रकार का उपयोग करना सहसंयोजक है। एक func() बफर "एक" func() रीडर है, क्योंकि बफर लौटने का मतलब है कि आपने एक रीडर वापस कर दिया है। फ़ंक्शन तर्क में एक प्रकार का उपयोग करना _not_ सहसंयोजक है। एक func (बफर) एक func (रीडर) नहीं है, क्योंकि func को बफर की आवश्यकता होती है, और कुछ पाठक बफर नहीं होते हैं।

फ़ंक्शन तर्क में एक प्रकार का उपयोग करना विरोधाभासी है। एक func (रीडर) एक func (बफर) है, क्योंकि func को केवल एक रीडर की आवश्यकता होती है, और एक बफर एक रीडर होता है। फ़ंक्शन परिणाम में किसी प्रकार का उपयोग करना _not_ contravariant है। एक func() रीडर एक func() बफर नहीं है, क्योंकि func एक रीडर लौटाता है, और कुछ पाठक बफर नहीं होते हैं।

दोनों को मिलाकर, एक func(Reader) Reader func(Buffer) Buffer नहीं है, न ही इसके विपरीत, क्योंकि या तो तर्क काम नहीं करते हैं या परिणाम काम नहीं करते हैं। (इन पंक्तियों के साथ काम करने वाला एकमात्र संयोजन यह होगा कि एक func (रीडर) बफर एक func (बफर) रीडर है।)

सामान्य तौर पर, यदि func(X1) X2 func(X3) X4 का एक (उपप्रकार) है, तो यह होना चाहिए कि X3 एक (उपप्रकार) X1 है और इसी तरह X2 एक (उपप्रकार) X4 है। उपनाम के उपयोग के मामले में जहां हम चाहते हैं कि T1 और T2 विनिमेय हों, एक func(T1) T1 func(T2) T2 का एक उपप्रकार है, यदि T1 T2 का एक उपप्रकार है _और_ T2 T1 का एक उपप्रकार है। इसका मूल रूप से मतलब है कि T1 _same_ प्रकार T2 के रूप में है, अधिक सामान्य प्रकार नहीं है।

मैंने फ़ंक्शन तर्कों और परिणामों का उपयोग किया क्योंकि यह विहित उदाहरण (और एक अच्छा) है, लेकिन जटिल परिणाम बनाने के अन्य तरीकों के लिए भी ऐसा ही होता है। आम तौर पर आपको आउटपुट (जैसे func() T, या <-chan T, या map[...]T) और इनपुट के लिए contravariance (जैसे func(T), या chan<-T, या map[T) के लिए कॉन्वर्सिस मिलता है। ]...) और इनपुट + आउटपुट (जैसे func(T) T, या chan T, या *T, या [10]T, या []T, या struct {फ़ील्ड T}, या एक चर के लिए मजबूर प्रकार समानता टी प्रकार)। वास्तव में गो में सबसे आम मामला, जैसा कि आप उदाहरणों से देख सकते हैं, इनपुट + आउटपुट है।

संक्षेप में, एक [] बफर एक [] रीडर नहीं है (क्योंकि आप एक फाइल को [] रीडर में स्टोर कर सकते हैं लेकिन [] बफर में नहीं), न ही एक [] रीडर ए [] बफर है (क्योंकि [] से प्राप्त करना [] पाठक एक फ़ाइल वापस कर सकता है, जबकि [] बफर से प्राप्त करने के लिए एक बफर वापस करना होगा)।

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

यही है, क्रमिक कोड मरम्मत समस्या को हल करने के लिए सबटाइपिंग पर्याप्त नहीं है। यही कारण है कि टाइप उपनाम एक ही प्रकार के लिए एक नया नाम पेश करते हैं, ताकि टी 1 = टी 2, सबटाइप करने का प्रयास करने के बजाय।

यह टिप्पणी दो हफ्ते पहले किसी प्रकार के "प्रतिस्थापन योग्य प्रकार" के @iand के सुझाव पर भी लागू होती है और मूल रूप से तब से @griesemer के उत्तर का विस्तार होता है।

शीर्ष-स्तरीय चर्चा सारांश अपडेट किया गया। परिवर्तन:

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

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

@atdiar सिस्टम में कहीं भी

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

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

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

दो सप्ताह दूर से वापस। ऐसा लगता है कि चर्चा एकाग्र हो गई है। यहां तक ​​कि दो हफ्ते पहले की चर्चा का अपडेट भी काफी मामूली था।

मेरा सुझाव है कि हम:

• ऊपर वर्णित समस्या के संभावित समाधान के रूप में अन्य नाम के प्रस्ताव को स्वीकार करें,
  बशर्ते गो 1.9 (1 फरवरी) की शुरुआत में लोगों द्वारा प्रयास करने के लिए एक कार्यान्वयन तैयार हो सकता है।
• एक dev.typealias dev शाखा बनाएं ताकि CL की अब (जनवरी) समीक्षा की जा सके और Go 1.9 की शुरुआत में मास्टर में विलय किया जा सके।
• गो 1.9 फ़्रीज़ की शुरुआत के पास प्रकार के उपनाम रखने के बारे में अंतिम निर्णय लें (जैसे हमने गो 1.8 चक्र में सामान्यीकृत उपनामों के लिए किया था)।

+1

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

@Merovius : मेरी पोस्ट संपादित करने के लिए खेद है! मुझे लगा कि कोई पढ़ नहीं रहा है। प्रारंभ में इस टिप्पणी में, मैंने कुछ संदेह व्यक्त किया कि इस भाषा परिवर्तन की आवश्यकता है जब पहले से ही gorename टूल जैसे उपकरण मौजूद हों।

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

अधिक स्वचालित टूलिंग के लिए (उदाहरण के लिए गो टूल या इसी तरह से एकीकृत), मूल टिप्पणी शीर्षक के तहत इसे संबोधित करती है "क्या यह एक टूलिंग- या कंपाइलर-केवल भाषा परिवर्तन के बजाय परिवर्तन हो सकता है?"।

अंत में, मान लें कि परिवर्तन लागू किया गया है। निःसंदेह, यह भाषा की एक मुख्य विशेषता के बजाय एक मामूली विवरण बन जाएगा।

मैं संदेह व्यक्त करना चाहता हूं। :) मैं इसे एक पूर्व निष्कर्ष नहीं मानता।

@मेरोवियस

मैं संदेह व्यक्त करना चाहता हूं। :) मैं इसे एक पूर्व निष्कर्ष नहीं मानता।

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

जिस तरह डॉट इंपोर्ट फीचर के मामले में, ट्यूटोरियल्स और डॉक्स के लिए यह समझदारी होगी कि वे उपयोग दिशानिर्देशों पर एक स्टेटमेंट के साथ इस फीचर का उल्लेख करें।

उदाहरण के लिए, मैं उपयोग करना चाहता था कहते हैं कि github.com/gonum/graph/simple".DirectedGraph " , और मैं के साथ उर्फ यह करना चाहता था digraph टाइपिंग से बचने के लिए simple.DirectedGraph , कि एक अच्छा होगा उदाहरण? या क्या इस तरह के नामकरण को प्रोटोबफ जैसी चीजों से उत्पन्न अनुचित रूप से लंबे नामों तक सीमित रखा जाना चाहिए?

@ jcao219 , इस पृष्ठ के शीर्ष पर चर्चा का सारांश आपके प्रश्नों का उत्तर देता है। विशेष रूप से, इन अनुभागों को देखें:

• क्या यह भाषा परिवर्तन के बजाय टूलिंग- या कंपाइलर-केवल परिवर्तन हो सकता है?
• उपनामों के और क्या उपयोग हो सकते हैं?
• प्रतिबंध (उस खंड से शुरू होने वाले सामान्य नोट)

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

ठीक है, यहां एकमत/शांति के आधार पर, मैं (जैसा कि मैंने पिछले सप्ताह https://github.com/golang/go/issues/18130#issuecomment-268614964 में सुझाव दिया था) इस प्रस्ताव को अनुमोदित कर दूंगा और एक dev.typealias शाखा बनाऊंगा। .

उत्कृष्ट सारांश में एक खंड है "प्रकार के उपनामों के प्रस्ताव को किन अन्य मुद्दों को संबोधित करने की आवश्यकता है?" प्रस्ताव को स्वीकृत घोषित किए जाने के बाद उन मुद्दों के समाधान की क्या योजना है?

CL https://golang.org/cl/34986 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/34987 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/34988 इस मुद्दे का उल्लेख करता है।

@ulikunitz मुद्दों को फिर से करें ( डिजाइन दस्तावेज़ से ये सभी उद्धरण 'टाइप टी 1 = टी 2' मानते हैं):

1. गोडोक में हैंडलिंग। डिज़ाइन दस्तावेज़ गोडोक में न्यूनतम परिवर्तनों को निर्दिष्ट करता है। इसके आ जाने के बाद हम देख सकते हैं कि अतिरिक्त सहायता की आवश्यकता है या नहीं। शायद, लेकिन शायद नहीं।
2. क्या उपनामों द्वारा नामित प्रकारों पर विधियों को परिभाषित किया जा सकता है? हां। डिज़ाइन दस्तावेज़: "चूंकि टी 1 टी 2 लिखने का एक और तरीका है, इसके पास विधि घोषणाओं का अपना सेट नहीं है। इसके बजाय, टी 1 का विधि सेट टी 2 के समान है। कम से कम प्रारंभिक परीक्षण के लिए, विधि घोषणाओं के खिलाफ कोई प्रतिबंध नहीं है T1 को एक रिसीवर प्रकार के रूप में उपयोग करना, बशर्ते उसी घोषणा में T2 का उपयोग करना मान्य होगा।"
3. यदि उपनामों से उपनामों की अनुमति है, तो हम उपनाम चक्रों को कैसे संभालेंगे? कोई चक्र नहीं। डिज़ाइन दस्तावेज़: "एक प्रकार के उपनाम घोषणा में, एक प्रकार की घोषणा के विपरीत, T2 को कभी भी, प्रत्यक्ष या परोक्ष रूप से, T1 को संदर्भित नहीं करना चाहिए।"
4. क्या उपनाम निर्यात न किए गए पहचानकर्ताओं को निर्यात करने में सक्षम होना चाहिए? हां। डिज़ाइन दस्तावेज़: "T2 के रूप पर कोई प्रतिबंध नहीं है: यह किसी भी प्रकार का हो सकता है, जिसमें अन्य पैकेजों से आयात किए गए प्रकारों तक सीमित नहीं है।"
5. क्या होता है जब आप एक उपनाम एम्बेड करते हैं (आप एम्बेडेड फ़ील्ड तक कैसे पहुँचते हैं)? नाम उपनाम (कार्यक्रम में दृश्यमान नाम) से लिया गया है। डिज़ाइन दस्तावेज़: https://golang.org/design/18130-type-alias#effect -on-embedding।
6. क्या उपनाम निर्मित कार्यक्रम में प्रतीकों के रूप में उपलब्ध हैं? नहीं। डिज़ाइन दस्तावेज़: "टाइप उपनाम अधिकतर रनटाइम पर अदृश्य होते हैं।" (इससे उत्तर मिलता है लेकिन स्पष्ट रूप से नहीं कहा जाता है।)
7. Ldflags स्ट्रिंग इंजेक्शन: क्या होगा यदि हम एक उपनाम का उल्लेख करते हैं? कोई वर उपनाम नहीं हैं, इसलिए यह उत्पन्न नहीं होता है।

CL https://golang.org/cl/35091 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35092 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35093 में इस मुद्दे का उल्लेख है।

@rsc स्पष्टीकरण के लिए बहुत धन्यवाद।

चलो मान लो:

package a

import "b"

type T1 = b.T2

जहाँ तक मैं समझता हूँ कि T1 b.T2 के समान अनिवार्य है और इसलिए यह एक गैर-स्थानीय प्रकार है और किसी भी नए तरीके को परिभाषित नहीं किया जा सकता है। हालांकि पहचानकर्ता T1 को पैकेज a में फिर से निर्यात किया जाता है। क्या यह सही व्याख्या है?

@ulikunitz जो सही है

T1 ठीक उसी प्रकार को दर्शाता है जैसे b.T2। यह बस एक अलग नाम है। कुछ निर्यात किया जाता है या नहीं, यह केवल उसके नाम पर आधारित होता है (इसका उस प्रकार से कोई लेना-देना नहीं है जो इसे दर्शाता है)।

@griesemer के उत्तर को स्पष्ट करने के लिए: हाँ, T1 को पैकेज a से निर्यात किया जाता है (क्योंकि यह T1 है, t1 नहीं)।

CL https://golang.org/cl/35099 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35100 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35101 इस मुद्दे का उल्लेख करता है।

CL https://golang.org/cl/35102 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35104 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35106 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35108 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35120 इस मुद्दे का उल्लेख करता है।

CL https://golang.org/cl/35121 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35129 इस मुद्दे का उल्लेख करता है।

CL https://golang.org/cl/35191 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35233 इस मुद्दे का उल्लेख करता है।

CL https://golang.org/cl/35268 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35269 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35670 इस मुद्दे का उल्लेख करता है।

CL https://golang.org/cl/35671 इस मुद्दे का उल्लेख करता है।

CL https://golang.org/cl/5575 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/35732 इस मुद्दे का उल्लेख करता है।

CL https://golang.org/cl/35733 इस मुद्दे का उल्लेख करता है।

CL https://golang.org/cl/35831 में इस मुद्दे का उल्लेख है।

CL https://golang.org/cl/36014 में इस मुद्दे का उल्लेख है।

यह अब मास्टर में है, गो 1.9 खोलने से पहले। कृपया बेझिझक मास्टर पर सिंक करें और चीजों को आजमाएं। धन्यवाद।

#18893 . से पुनर्निर्देशित

package main

import (
        "fmt"
        "q"
)

func main() {
        var a q.A
        var b q.B // i'm a named unnamed type !!!

        fmt.Printf("%T\t%T\n", a, b)
}

आपने क्या देखने की उम्मीद की थी?

deadwood(~/src) % go run main.go
q.A     q.B

इसके बजाय आपने क्या देखा?

deadwood(~/src) % go run main.go
q.A     []int

विचार - विमर्श

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

ओह, जब तक कि यह एक उपनाम न हो, उस स्थिति में आपको यह याद रखना होगा कि यह एक अनाम प्रकार हो सकता है, तब भी जब आप किसी अन्य पैकेज से आयात करते हैं।

और इससे भी बदतर, यह लोगों को पठनीयता विरोधी पैटर्न जैसे

type Any = interface{}

कृपया अनाम प्रकारों को उपनामित करने की अनुमति न दें।

@davecheney

एक अनाम प्रकार से दूसरे में जाने में कोई "कोड मरम्मत" कहानी नहीं है।

सच नहीं। क्या होगा यदि आप किसी विधि पैरामीटर के प्रकार को किसी नामित से अनाम प्रकार में बदलना चाहते हैं या इसके विपरीत? चरण 1 उपनाम जोड़ना है; चरण 2 उन प्रकारों को अद्यतन करना है जो नए प्रकार का उपयोग करने के लिए उस पद्धति को लागू करते हैं; चरण 3 उपनाम को हटाना है।

(यह सच है कि आज आप विधि का दो बार नाम बदलकर ऐसा कर सकते हैं। दोहरा-नाम बदलना सबसे कठिन है।)

और इससे भी बदतर, यह लोगों को पठनीयता विरोधी पैटर्न जैसे
type Any = interface{}

लोग आज ही type Any interface{} लिख सकते हैं। इस मामले में उपनाम क्या अतिरिक्त नुकसान पहुंचाते हैं?

लोग आज पहले से ही कोई भी इंटरफ़ेस {} टाइप कर सकते हैं। इस मामले में उपनाम क्या अतिरिक्त नुकसान पहुंचाते हैं?

मैंने इसे एक विरोधी पैटर्न कहा क्योंकि यह ठीक यही है। type Any interface{} , क्योंकि यह व्यक्ति _writing_ कोड कुछ छोटा टाइप करता है, जो उनके लिए थोड़ा अधिक समझ में आता है।

दूसरी ओर, _all_ पाठक, जो गो कोड पढ़ने में अनुभवी हैं और interface{} को सहज रूप से एक दर्पण में उनके चेहरे के रूप में पहचानते हैं, उन्हें Any प्रत्येक संस्करण को सीखना और फिर से सीखना होगा। , Object , T , और उन्हें प्रति पैकेज के आधार पर type Any interface{} , type Any map[interface{}]interface{} , type Any struct{} जैसी चीजों से मैप करें।

निश्चित रूप से आप सहमत हैं कि सामान्य गो मुहावरों के लिए पैकेज विशिष्ट नाम पठनीयता के लिए शुद्ध नकारात्मक हैं?

निश्चित रूप से आप सहमत हैं कि सामान्य गो मुहावरों के लिए पैकेज विशिष्ट नाम पठनीयता के लिए शुद्ध नकारात्मक हैं?

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

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

और, वास्तव में, टाइप उपनाम कोडबेस से उस एंटीपैटर्न के _gradual remove_ के लिए अनुमति देते हैं जिसमें यह पहले से मौजूद है।

विचार करना:

package antipattern

type Any interface{}  // not an alias

type Widget interface{
  Frozzle(Any) error
}

func Bozzle(w Widget) error {
  …
}

आज, antipattern.Bozzle उपयोगकर्ता अपने Widget कार्यान्वयन में antipattern.Any का उपयोग करके फंस जाएंगे, और क्रमिक मरम्मत के साथ antipattern.Any को हटाने का कोई तरीका नहीं है। लेकिन प्रकार के उपनामों के साथ, antipattern पैकेज का स्वामी इसे इस प्रकार फिर से परिभाषित कर सकता है:

// Any is deprecated; please use interface{} directly.
type Any = interface{}

और अब कॉल करने वाले धीरे-धीरे Any से interface{} माइग्रेट कर सकते हैं, जिससे antipattern मेंटेनर अंततः इसे हटा सकता है।

मेरा कहना है कि अज्ञात प्रकारों को अलियासिंग करने का कोई औचित्य नहीं है
इस विकल्प को अस्वीकार करने से की अनुपयुक्तता को रेखांकित करना जारी रहेगा
अभ्यास।

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

गुरु, 2 फरवरी 2017, 16:34 को ब्रायन सी. मिल्स नोटिफिकेशन @github.com ने लिखा:

निश्चित रूप से आप सहमत हैं कि सामान्य गो मुहावरों के लिए पैकेज विशिष्ट नाम हैं
पठनीयता के लिए शुद्ध नकारात्मक?

मैं सहमत हूं, लेकिन प्रश्न में उदाहरण के बाद से (अब तक का सबसे आम)
उस एंटीपैटर्न की घटना जिसका मैंने सामना किया है) बिना किया जा सकता है
उपनाम, मुझे समझ में नहीं आता कि यह उदाहरण किस प्रकार के प्रस्ताव से संबंधित है
उपनाम टाइप करें।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/18130#issuecomment-276872714 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcA6BGrFjjTi7eW1BPp7o81XIekbGXks5rYWr-gaJpZM4LBBEL
.

@davecheney मुझे नहीं लगता कि हमारे पास अभी तक कोई सबूत है कि एक मनमाना प्रकार का शाब्दिक नाम देने में सक्षम होना हानिकारक है। यह भी एक अप्रत्याशित "आश्चर्य" विशेषता नहीं है - डिजाइन दस्तावेज़ में इसकी विस्तार से चर्चा की गई है। इस बिंदु पर कुछ समय के लिए इसका उपयोग करना समझ में आता है और देखें कि यह हमें कहां ले जाता है।

एक प्रति-उदाहरण के रूप में, ऐसे सार्वजनिक एपीआई हैं जो केवल टाइप लिटरल्स का उपयोग करते हैं क्योंकि एपीआई क्लाइंट को एक विशिष्ट प्रकार तक सीमित नहीं करना चाहता है (उदाहरण के लिए https://golang.org/pkg/go/types/#Info देखें) ) उस स्पष्ट प्रकार का शाब्दिक होना उपयोगी दस्तावेज हो सकता है। लेकिन एक ही समय में एक ही प्रकार के अक्षर को हर जगह दोहराना काफी कष्टप्रद हो सकता है; और वास्तव में पठनीयता के लिए एक बाधा हो। map[int]struct{} w/o के बजाय IntSet बारे में आसानी से बात करने में सक्षम होने के कारण उसमें लॉक किया जा रहा है और केवल IntSet परिभाषा मेरे दिमाग में एक प्लस है। यहीं पर type IntSet = map[int]struct{} बिल्कुल सही है।

अंत में, यदि आप चूक गए हैं तो मैं https://github.com/golang/go/issues/18130#issuecomment -268411811 पर वापस जाना चाहता हूं। = का उपयोग करने वाली अप्रतिबंधित प्रकार की घोषणाएं वास्तव में "प्राथमिक" प्रकार की घोषणाएं हैं, और मुझे खुशी है कि हमने अंततः उन्हें गो में रखा है।

शायद type intSet = map[int]struct{} (निर्यात नहीं किया गया) अनाम प्रकार के उपनामों का उपयोग करने का एक बेहतर तरीका होगा, लेकिन यह सुविधा को सीमित करने के बजाय CodeReviewComments और अनुशंसित प्रोग्रामिंग प्रथाओं के डोमेन की तरह लगता है।

उस ने कहा, %T डिबगिंग या टाइप सिस्टम की खोज करते समय प्रकारों को देखने के लिए एक आसान टूल है। मुझे आश्चर्य है कि क्या एक समान प्रारूप क्रिया होनी चाहिए जिसमें उपनाम शामिल हो? q.B = []int @davecheney के उदाहरण में।

@nathany आप उस क्रिया को कैसे लागू करते हैं? उपनाम जानकारी रनटाइम पर मौजूद नहीं है। (जहां तक reflect पैकेज का संबंध है, उपनाम _the वही type_ है जिस चीज से इसे अलियास किया गया है।)

@bcmills मैंने सोचा कि ऐसा हो सकता है ...

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

2 फरवरी, 2017 को शाम 5:01 बजे, "नाथन यंगमैन" नोटिफिकेशन @github.com ने लिखा:

उस ने कहा, %T डिबगिंग या खोज करते समय प्रकारों को देखने के लिए एक आसान उपकरण है
प्रकार प्रणाली। मुझे आश्चर्य है कि क्या एक समान प्रारूप क्रिया होनी चाहिए कि
उपनाम शामिल हैं? qB = [] int in @davecheney
https://github.com/davecheney का उदाहरण।

मुझे लगता है कि इसका उत्तर देने के लिए गुरु के लिए एक क्वेरी मोड जोड़ना एक बेहतर उपाय है
प्रश्न:

जो पूरे GOPATH (या किसी दिए गए पैकेज) में घोषित उपनाम हैं
कमांड लाइन पर यह दिया गया प्रकार?

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

@davecheney मैंने आपके सुझाव को शीर्ष पर चर्चा सारांश के "प्रतिबंध" खंड में जोड़ा है। सभी प्रतिबंधों की तरह, हमारी सामान्य स्थिति यह है कि प्रतिबंध जटिलता जोड़ते हैं (ऊपर नोट देखें) और प्रतिबंध लगाने के लिए हमें व्यापक नुकसान के वास्तविक प्रमाण देखने की आवश्यकता होगी। आपके द्वारा गो सिखाने के तरीके को बदलना ही पर्याप्त नहीं है: भाषा में हमारे द्वारा किए गए किसी भी परिवर्तन के लिए आपके द्वारा गो सिखाने के तरीके को बदलने की आवश्यकता होगी।

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

@minux , जैसे @bcmills ने बताया, उपनाम जानकारी रनटाइम पर मौजूद नहीं है (डिजाइन के लिए पूरी तरह से मौलिक)। "%T जिसमें उपनाम शामिल है" को लागू करने का कोई तरीका नहीं है।

2 फरवरी, 2017 को रात 8:33 बजे, "रस कॉक्स" नोटिफिकेशन @github.com ने लिखा:

@minux https://github.com/minux , जैसे @bcmills
https://github.com/bcmills ने बताया, उर्फ ​​जानकारी मौजूद नहीं है
रनटाइम पर (डिजाइन के लिए पूरी तरह से मौलिक)। कोई रास्ता नहीं है
एक "%T लागू करें जिसमें उपनाम शामिल है"।

मैं एक गो गुरु का सुझाव दे रहा हूं (https://golang.org/x/tools/cmd/guru) क्वेरी मोड
रिवर्स उर्फ ​​मैपिंग के लिए, जो स्थिर कोड विश्लेषण पर आधारित है। यह
कोई फर्क नहीं पड़ता कि उपनाम जानकारी रनटाइम पर उपलब्ध है या नहीं।

@minux , ओह, मैं देख रहा हूँ, आप ईमेल के माध्यम से उत्तर दे रहे हैं और Github उद्धृत पाठ को आपके द्वारा लिखे गए पाठ की तरह बनाता है। मैं नाथन यंगमैन से आपके द्वारा उद्धृत पाठ का उत्तर दे रहा था, यह सोचकर कि यह आपका है। गलतफहमी के लिए खेद है।

शब्दावली और शिक्षण के संबंध में, मैंने पाया कि ब्रांडेड प्रकार की पृष्ठभूमि @griesemer काफी जानकारीपूर्ण पोस्ट की गई है। उसके लिए धन्यवाद।

प्रकार और प्रकार के रूपांतरणों की व्याख्या करते समय, बेबी गोफर शुरू में सोचते हैं कि मैं एक प्रकार के उपनाम के बारे में बात कर रहा हूं, संभवतः अन्य भाषाओं से परिचित होने के कारण।

अंतिम शब्दावली जो भी हो, मैं नामित (ब्रांडेड) प्रकारों से पहले प्रकार के उपनामों को पेश करने की कल्पना कर सकता था, खासकर जब से किसी भी पुस्तक या पाठ्यक्रम में byte और rune को पेश करने के बाद नए नामित प्रकारों की घोषणा होने की संभावना है। हालांकि, मैं विरोधी पैटर्न को प्रोत्साहित नहीं करने के लिए @davecheney की चिंता से सावधान रहना चाहता हूं।

type intSet map[int]struct{} हम कहते हैं कि map[int]struct{} _underlying_ प्रकार है। हम type intSet = map[int]struct{} दोनों ओर क्या कहते हैं? उपनाम और उपनाम प्रकार?

%T , मुझे पहले से ही यह समझाने की आवश्यकता है कि byte और rune परिणाम uint8 और int32 , इसलिए यह नहीं है विभिन्न।

यदि कुछ भी हो, तो मुझे लगता है कि टाइप उपनाम byte और rune को समझाने में आसान बना देंगे। आईएमओ, चुनौती यह जान रही होगी कि नामित प्रकार बनाम प्रकार उपनामों का उपयोग कब करना है, और फिर उसे संवाद करने में सक्षम होना चाहिए।

@नाथनी मुझे लगता है कि पहले "उपनाम प्रकार" पेश करना बहुत समझ में आता है - हालांकि मैं जरूरी शब्द का उपयोग नहीं करता। नई शुरू की गई "उपनाम" घोषणाएं केवल नियमित घोषणाएं हैं जो कुछ खास नहीं करती हैं। बाईं ओर के पहचानकर्ता और दाईं ओर के प्रकार एक ही हैं, वे समान प्रकारों को दर्शाते हैं। मुझे यह भी यकीन नहीं है कि हमें उपनाम या उपनाम प्रकार की आवश्यकता है (हम निरंतर नाम को उपनाम नहीं कहते हैं, और निरंतर मूल्य उपनाम स्थिरांक कहते हैं)।

पारंपरिक (गैर-उपनाम) प्रकार की घोषणा अधिक काम करती है: यह बाईं ओर के पहचानकर्ता को बाध्य करने से पहले दाईं ओर के प्रकार से एक नया प्रकार बनाता है। इस प्रकार पहचानकर्ता और दाईं ओर का प्रकार समान नहीं हैं (वे केवल समान अंतर्निहित प्रकार साझा करते हैं)। यह स्पष्ट रूप से अधिक जटिल अवधारणा है।

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

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

इस सादृश्य का उपयोग करके, हम कई अन्य मौजूदा नियमों को भी सुधार सकते हैं:

• एक रंगीन प्रकार हमेशा किसी भी अन्य प्रकार से अलग होता है (क्योंकि प्रत्येक प्रकार की घोषणा एक बिल्कुल नए, पहले कभी इस्तेमाल नहीं किए गए रंग का उपयोग करती है)।
• विधियाँ केवल रिसीवर आधार प्रकारों से संबद्ध हो सकती हैं जो रंगीन हैं।
• एक प्रकार का अंतर्निहित प्रकार वह प्रकार है जो उसके सभी रंग को छीन लेता है।
  आदि।

हम एक निरंतर नाम को उपनाम नहीं कहते हैं, और निरंतर मान को अलियास स्थिरांक कहते हैं

अच्छा बिंदु

मुझे यकीन नहीं है कि रंगीन बनाम बिना रंग की सादृश्यता को समझना आसान है, लेकिन यह प्रदर्शित करता है कि अवधारणाओं को समझाने के एक से अधिक तरीके हैं।

पारंपरिक नामित/ब्रांडेड/रंगीन प्रकारों को निश्चित रूप से अधिक स्पष्टीकरण की आवश्यकता होती है। विशेष रूप से जब किसी नामित प्रकार को मौजूदा नामित प्रकार का उपयोग करके घोषित किया जा सकता है। ध्यान में रखने के लिए काफी सूक्ष्म अंतर हैं।

type intSet map[int]struct{} // a new type with an underlying type map[int]struct{}

type myIntSet intSet // a new type with an underlying type map[int]struct{}

type otherIntSet = intSet // just another name (alias) for intSet, add methods to intSet (only in the same package)

type literalIntSet = map[int]struct{} // just another name for map[int]struct{}, no adding methods

हालांकि यह दुर्गम नहीं है। इस भूमि को गो 1.9 में मानते हुए, मुझे संदेह है कि हम कई गो पुस्तकों के दूसरे संस्करण देखेंगे। मैं

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

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

कुछ विचार:

• "विशिष्ट" या "विशिष्ट" (जैसा कि, अन्य प्रकारों से अलग किया जा सकता है)
• "अद्वितीय" (जैसा कि, यह अन्य सभी प्रकारों से भिन्न प्रकार है)
• "ठोस" (जैसा कि, यह एक इकाई है जो रनटाइम में मौजूद है)
• "पहचान योग्य" (जैसा कि, प्रकार की एक पहचान है)

@bcmills हम विशिष्ट, अद्वितीय, विशिष्ट, ब्रांडेड, रंगीन, परिभाषित, गैर-उपनाम, आदि प्रकारों के बारे में सोच रहे हैं। "कंक्रीट" भ्रामक है क्योंकि एक इंटरफ़ेस रंगीन भी हो सकता है, और एक इंटरफ़ेस एक अमूर्त प्रकार का अवतार है। "पहचान योग्य" भी भ्रामक लगता है क्योंकि "स्ट्रक्चर {int}" किसी भी स्पष्ट रूप से (गैर-उपनाम) नामित प्रकार के रूप में पहचाने जाने योग्य है।

मैं इसके खिलाफ सिफारिश करूंगा:

• "रंगीन" (गैर-प्रोग्रामिंग संदर्भों में वाक्यांश "रंगीन प्रकार" मजबूत नस्लीय-पूर्वाग्रह अर्थ रखता है)
• "गैर-उपनाम" (यह भ्रमित करने वाला है, क्योंकि उपनाम का लक्ष्य पहले "नामित प्रकार" कहलाता था या नहीं भी हो सकता है)
• "परिभाषित" (उपनाम भी परिभाषित किए गए हैं, उन्हें केवल उपनाम के रूप में परिभाषित किया गया है)

"ब्रांडेड" काम कर सकता है: यह "मवेशी के रूप में प्रकार" अर्थ रखता है लेकिन यह मुझे आंतरिक रूप से बुरा नहीं लगता है।

अद्वितीय और विशिष्ट अब तक के स्टैंड आउट विकल्पों की तरह प्रतीत होते हैं।

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

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

यह एक बाइकशेड तर्क की परिभाषा है। रॉबर्ट के पास https://go-review.googlesource.com/#/c/36213/ पर एक लंबित CL है जो बिल्कुल ठीक लगता है।

CL https://golang.org/cl/36213 इस मुद्दे का उल्लेख करता है।

मैं go fix के मुद्दे को फिर से लाना चाहता हूं।

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

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

मैं अभी भी कोड को सुधारने के लिए टूल को सबसे अच्छा तरीका मानता हूं, कुछ ऐसा विचार जो @ tux21b ने सुझाया था। उदाहरण के लिए:

$ cat "$GOROOT"/RENAME
# This file could be used for `go fix`
[package]
x/net/context=context
[type]
io.ByteBuffer=bytes.Buffer

$ go fix -rename "$GOROOT"/RENAME [packages]
# -- or --
# use a standard libraries rename table as default
$ go fix -rename [packages]
# -- or --
# include this fix as default
$ go fix [packages]

@rsc के यहाँ लेकिन मुझे लगता है कि यह इस कार्य प्रवाह में सच नहीं है : यदि कोई पुराना पैकेज है (उदाहरण के लिए एक निर्भरता) पैकेज के बहिष्कृत नाम/पथ का उपयोग करता है, उदाहरण के लिए x/net/context , तो हम पहले कोड को ठीक कर सकते हैं , ठीक वैसे ही जैसे दस्तावेज़ कहता है कि पाठ प्रारूप में एक विन्यास योग्य तालिका के माध्यम से कोड को नए संस्करण में कैसे माइग्रेट किया जाए, लेकिन हार्ड-कोडिंग नहीं। फिर आप किसी भी उपकरण का उपयोग कर सकते हैं जब भी आप नए संस्करण के गो के समान पसंद करते हैं। एक दुष्प्रभाव है: यह कोड को संशोधित करेगा।

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

CL https://golang.org/cl/36691 में इस मुद्दे का उल्लेख है।

टिप पर इस प्रस्ताव के साथ, मैं अब यह पैकेज बना सकता हूं:

package safe

import "unsafe"

type Pointer = unsafe.Pointer

जो प्रोग्राम को सीधे unsafe आयात किए बिना unsafe.Pointer मान बनाने की अनुमति देता है:

package main

import "safe"

func main() {
    x := []int{4, 9}
    y := *(*int)(safe.Pointer(uintptr(safe.Pointer(&x[0])) + 8))
    println(y)
}

मूल उपनाम घोषणाएं डिज़ाइन दस्तावेज़ इसे स्पष्ट रूप से समर्थित के रूप में कहते हैं। यह इस नए प्रकार के उपनाम प्रस्ताव में स्पष्ट नहीं है, लेकिन यह काम करता है।

उपनाम घोषणा मुद्दे पर इसके लिए तर्कसंगत है: _ "हम असुरक्षित के लिए एलियासिंग की अनुमति देते हैं। सूचक यह है कि असुरक्षित प्रकार को परिभाषित करना पहले से ही संभव है। अंतर्निहित प्रकार के रूप में सूचक।"_ https://github.com/ गोलांग/गो/मुद्दों/16339#मुद्दे टिप्पणी -232435361

हालांकि यह सच है, मुझे लगता है कि unsafe.Pointer उपनाम की अनुमति देना कुछ नया परिचय देता है: प्रोग्राम अब स्पष्ट रूप से असुरक्षित आयात किए बिना unsafe.Pointer मान बना सकते हैं।

इस प्रस्ताव से पहले कार्यक्रम को ऊपर लिखने के लिए, मुझे सेफ को स्थानांतरित करना होगा। पॉइंटर को एक पैकेज में डाला जाता है जो असुरक्षित आयात करता है। इससे उनके असुरक्षित उपयोग के लिए कार्यक्रमों का ऑडिट करना थोड़ा कठिन हो सकता है।

@crawshaw , क्या आपने पहले ऐसा नहीं किया होगा?

package safe

import (
  "reflect"
  "unsafe"
)

func Pointer(p interface {}) unsafe.Pointer {
  switch v := reflect.ValueOf(p); v.Kind() {
  case reflect.Uintptr:
    return unsafe.Pointer(uintptr(v.Uint()))
  default:
    return unsafe.Pointer(v.Pointer())
  }
}

मेरा मानना ​​है कि पैकेज main में आयात की समान कमी के साथ, ठीक उसी प्रोग्राम को संकलित करने की अनुमति देगा।

(यह अनिवार्य रूप से एक वैध कार्यक्रम नहीं होगा: uintptr -to- Pointer रूपांतरण में एक फ़ंक्शन कॉल शामिल है, इसलिए यह unsafe पैकेज बाधा को पूरा नहीं करता है कि " दोनों रूपांतरणों को एक ही अभिव्यक्ति में प्रकट होना चाहिए, उनके बीच केवल मध्यवर्ती अंकगणित के साथ। हालांकि, मुझे संदेह है कि unsafe को main से आयात किए बिना एक समकक्ष, वैध कार्यक्रम बनाना संभव होगा। reflect.SliceHeader जैसी चीजों का उपयोग।)

ऐसा लगता है कि एक छिपे हुए असुरक्षित प्रकार को निर्यात करना ऑडिट में जोड़ने का एक और नियम है।

हां, मैं यह बताना चाहता था कि सीधे अलियासिंग असुरक्षित। पॉइंटर कोड को ऑडिट करने के लिए कठिन बनाता है, इसलिए मुझे आशा है कि कोई भी ऐसा नहीं करेगा।

@crawshaw मेरी टिप्पणी के अनुसार, हमारे पास एलियासिंग टाइप करने से पहले यह भी सच था। निम्नलिखित मान्य है:

package a

import "unsafe"

type P unsafe.Pointer

package main

import "./a"
import "fmt"

var x uint64 = 0xfedcba9876543210
var h = *(*uint32)(a.P(uintptr(a.P(&x)) + 4))

func main() {
    fmt.Printf("%x\n", h)
}

यही है, पैकेज मुख्य में, मैं a.P का उपयोग करके असुरक्षित अंकगणित कर सकता हूं, भले ही कोई unsafe पैकेज न हो और a.P कोई उपनाम न हो। यह हमेशा संभव था।

क्या कुछ और है जिसका आप जिक्र कर रहे हैं?

मेरी गलती। मैंने सोचा कि यह काम नहीं किया। (मैं इस धारणा के तहत था कि विशेष नियम असुरक्षित पर लागू होते हैं। पॉइंटर इससे परिभाषित नए प्रकारों का प्रचार नहीं करेगा।)

इस पर युक्ति वास्तव में स्पष्ट नहीं है। गो/प्रकारों के कार्यान्वयन को देखते हुए, यह पता चला है कि मेरे प्रारंभिक कार्यान्वयन के लिए unsafe.Pointer है, न कि केवल कुछ प्रकार के लिए जो अंतर्निहित प्रकार का unsafe.Pointer । मुझे अभी-अभी #6326 मिला, जो तब हुआ जब मैंने gc के अनुरूप होने के लिए go/types को बदल दिया।

शायद हमें इसे नियमित प्रकार की परिभाषाओं के लिए अस्वीकार करना चाहिए और unsafe.Pointer उपनामों को भी अस्वीकार करना चाहिए। मुझे इसकी अनुमति देने का कोई अच्छा कारण नहीं दिख रहा है और यह असुरक्षित कोड के लिए unsafe आयात करने की व्याख्या से समझौता करता है।

मैंने https://github.com/golang/go/issues/19306 बनाया

यह हुआ। मुझे नहीं लगता कि यहां कुछ बचा है।