🧩 जेनेरिक्स के साथ Go में एक्सप्रेशन प्रॉब्लम की पड़ताल 🔗

प्रोग्रामिंग भाषा डिज़ाइन में “एक्सप्रेशन प्रॉब्लम” (Expression Problem) एक क्लासिक चुनौती है। इस पोस्ट में, हम Featherweight Go शोधपत्र में प्रस्तुत विचारों का संदर्भ लेते हुए और Go के वर्तमान कार्यान्वयन की सीमाओं की जांच करते हुए, यह पता लगाएंगे कि जेनेरिक्स (generics) का उपयोग करके Go में इसे हल करने की दिशा में कैसे आगे बढ़ा जाए।

📑 विषय-सूची 🔗

❓ एक्सप्रेशन प्रॉब्लम क्या है? 🔗

इस चुनौती को समझने के लिए, यह देखना मददगार होगा कि Featherweight Go शोधपत्र इसे कैसे परिभाषित करता है:

“लक्ष्य एक डेटा टाइप को केसों (cases) के रूप में परिभाषित करना है, जहाँ कोई मौजूदा कोड को दोबारा कंपाइल किए बिना और स्टैटिक टाइप सुरक्षा को बनाए रखते हुए, डेटा टाइप में नए केस और डेटा टाइप पर नए फ़ंक्शन जोड़ सके।”

शोधपत्र इसे समझने में मदद करने के लिए एक उत्कृष्ट उदाहरण प्रदान करता है:

“क्या कोई भाषा एक्सप्रेशन प्रॉब्लम को हल कर सकती है, यह उसकी अभिव्यक्ति की क्षमता का एक प्रमुख संकेतक है। कोई व्यक्ति केसों (cases) को एक तालिका में पंक्तियों (rows) के रूप में और फ़ंक्शनों को स्तंभों (columns) के रूप में सोच सकता है। एक फंक्शनल भाषा में, पंक्तियाँ निश्चित होती हैं (डेटाटाइप घोषणा में केस) लेकिन नए स्तंभ (फ़ंक्शन) जोड़ना आसान होता है। एक ऑब्जेक्ट-ओरिएंटेड भाषा में, स्तंभ निश्चित होते हैं (क्लास घोषणा में मेथड्स) लेकिन नई पंक्तियाँ (सबक्लास) जोड़ना आसान होता है। हम पंक्तियों या स्तंभों दोनों को जोड़ना आसान बनाना चाहते हैं।”

संक्षेप में: एक सच्चा समाधान हमें मौजूदा सोर्स कोड को संशोधित किए बिना आसानी से अपने कोड में नए डेटा वेरिएंट (पंक्तियाँ) और नए ऑपरेशन्स/व्यवहार (स्तंभ) जोड़ने की अनुमति देता है।

🚧 आधुनिक Go में सीमा (Limitation) 🔗

मूल Featherweight Go ड्राफ्ट में प्रस्तावित समाधान एक ऐसे फीचर पर निर्भर करता है जो अंतिम Go 1.18 जेनेरिक्स रिलीज़ में शामिल नहीं हो पाया।

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

// Hypothetical (Not valid Go): 
// Constraining the method receiver directly
func (e Plus[T Evaler]) Eval() int
func (e Plus[T Stringer]) String() string

हालाँकि, Go के जेनेरिक्स कार्यान्वयन के लिए आवश्यक है कि मेथड रिसीवर की टाइप बाधाएं स्ट्रक्ट की टाइप परिभाषा से पूरी तरह मेल खाएं। आप प्रत्येक मेथड के आधार पर नई बाधा आवश्यकताएं (जैसे Evaler या Stringer) नहीं जोड़ सकते हैं।

🛠️ एक व्यावहारिक वैकल्पिक समाधान (Workaround) 🔗

चूँकि हम मेथड स्तर पर टाइप पैरामीटर्स को सीमित नहीं कर सकते हैं, इसलिए हम उन्हें स्ट्रक्ट स्तर पर सीमित करने के लिए मजबूर हैं।

नीचे एक अनुकूलित कोड उदाहरण दिया गया है जो Go 1.18+ जेनेरिक्स के साथ पूरी तरह से काम करता है। हालाँकि, ध्यान दें कि हम पहले से ही एक संयुक्त Expr इंटरफ़ेस परिभाषित करने के लिए मजबूर हैं। चूँकि हर बार जब हम कोई नया ऑपरेशन जोड़ना चाहते हैं तो हमें इस इंटरफ़ेस को संशोधित करना पड़ता है, इसलिए यह एक्सप्रेशन प्रॉब्लम का सच्चा समाधान नहीं है, बल्कि शोधपत्र से अनुकूलित एक व्यावहारिक विकल्प है:

package main

import (
	"fmt"
)

// 1. Define our Base Data Type
type Num struct {
	value int
}

// 2. Define our Operations (Columns)
type Evaler interface {
	Eval() int
}

type Stringer interface {
	String() string
}

// Implement the operations for our base type
func (e Num) Eval() int {
	return e.value
}

func (e Num) String() string {
	return fmt.Sprintf("%d", e.value)
}

// 3. The Compromise: We must pre-define a combined interface.
// If we want to add a new operation later, we are forced to edit this interface,
// violating the core rule of the Expression Problem.
type Expr interface {
	Evaler
	Stringer
}

// 4. Define a Generic Data Type (Row)
// Because Go doesn't allow method-level constraints, we must constrain T to Expr here.
type Plus[T Expr] struct {
	left  T
	right T
}

func (e Plus[T]) Eval() int {
	return e.left.Eval() + e.right.Eval()
}

func (e Plus[T]) String() string {
	return fmt.Sprintf("(%s+%s)", e.left.String(), e.right.String())
}

// 5. Execution
func main() {
	var e Expr = Plus[Expr]{left: Num{1}, right: Num{2}}
	
	fmt.Println(e.Eval())   // Output: 3
	fmt.Println(e.String()) // Output: (1+2)
}

🏁 निष्कर्ष 🔗

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