संभावित उद्देश्य से बचने के लिए एक स्विफ्ट क्लास को प्रीफ़िक्स किया जाना चाहिए-सी संगतता टकराव मुद्दे

Question

क्रॉस संगतता प्रदान करने के लिए, स्विफ्ट ब्रिजिंग हेडर की पीढ़ी के लिए अनुमति देता है ताकि उद्देश्य-सी स्विफ्ट कक्षाओं के साथ संवाद कर सके।

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

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

एक उदाहरण: कहें कि हमारे पास दो ढांचे हैं जिन्होंने Downloader नामक एक स्विफ्ट क्लास घोषित की है। Downloader इंटरफ़ेस प्रदान करता है: downloadWithURL(url: NSURL)

ब्रिजिंग हेडर उत्पन्न करने से इन दोनों ढांचे के लिए एक डाउनलोडर-स्विफ्ट.h फ़ाइल मिल जाएगी। इस प्रकार टकराव पैदा होता है। इससे बचने के लिए सबसे अच्छे अभ्यास क्या हैं?

Answer 1

ऐप्पल के इंजीनियरों के अनुसार <#Module Name#>-Swift.h हेडर एक मैक्रो का उपयोग करता है जो नामों को उलझन में डालता है ताकि विवादों से बचने के लिए (डब्ल्यूडब्ल्यूडीसी वीडियो Swift Interoperability In Depth देखें, 45 मिनट, 40 सेकंड से शुरू हो)। वे एक Document स्विफ्ट वर्ग का उदाहरण दिया: अपनी स्विफ्ट कोड के लिए

SWIFT_CLASS("_TtC5MyApp10Document") 
@interface Document : UIDocument 
// rest of the interface... 

, वर्ग, MyApp.Document के रूप में उपलब्ध हो जाएगा अगर MyApp मॉड्यूल यह में है तो, अगर आप एक ही के दो स्विफ्ट श्रेणियां होती हैं। विभिन्न मॉड्यूल से आने वाले नाम - कहते हैं, एक अपने खुद के और एक खुला स्रोत से अन्य है स्विफ्ट ढांचे SomeFramework - वे MyApp.Document और SomeFramework.Document के रूप में अपने स्विफ्ट कोड के लिए उपलब्ध हो जाएगा ...

Obj सी पक्ष पर, तथापि , इन दो वर्गों को एक ही व्याख्यात्मक दायरे में आयात करने से Duplicate interface definition for class 'Document' संकलक त्रुटि होती है। यह सिर्फ ओब्जे-सी है ... हालांकि, अधिकांश मामलों में, यह कोई मुद्दा नहीं होगा क्योंकि आप तब भी इन दोनों कक्षाओं को ऐप में आयात कर सकते हैं जब तक कि वे एक-दूसरे के क्षेत्र में अपराध न करें। दरअसल, आप अपने ऐप के उसी मॉड्यूल में कितनी बार MyApp.Document और SomeFramework.Document का उपयोग करना चाहते हैं? जैसे-जैसे हम तेजी से आगे बढ़ रहे हैं, मुझे यकीन नहीं है कि यह विशेष मुद्दा मल्टीकोर, वितरित, कार्यात्मक, हप्पीक, प्रत्याशित, पहनने योग्य, स्वायत्त, आदि जैसे कई आवश्यक मुद्दों की तुलना में एक विशेष रणनीति का वारंट करता है ...