أثناء استخدام discourse في تطبيق Ruby متعدد الخيوط وخادم (TruffleRuby/Puma)، يتم إنتاج أخطاء بسبب الاستخدام غير الآمن للـ hash في إعدادات العلامات وهذا النمط من التهيئة الكسولة يحتاج إلى تجنب التعيين مرتين:
3 إعجابات
هل يؤدي استدعاء بسيط لـ PostActionType.flag_settings في مُهيئ إلى حل المشكلة؟ (على سبيل المثال: فقط قم بالإدراج هنا: discourse/config/initializers/000-mini_sql.rb at 3e0cb8ea47ea27cb3b564ac10656884739e4d78c · discourse/discourse · GitHub مؤقتًا)
أعتقد أنه يمكننا مزامنة هذه الكتلة أيضًا. هل هناك أي علامات حمراء كبيرة أخرى تثيرها truffle؟
إعجابَين (2)
نعم، هذا يجب أن يعمل.
هل هناك أي سبب لتهيئته بشكل كسول؟
ستؤدي تهيئته بشكل غير كسول إلى تجنب أي مشكلة في المزامنة وسيكون الوصول إليه أسرع قليلاً وأبسط أيضًا.
إعجاب واحد (1)
بصراحة لست متأكدًا مما إذا كانت هذه التهيئة الكسولة منطقية على الإطلاق هنا أيضًا، فلدينا خطاف للمكونات الإضافية لاستبدال مجموعة الأعلام بالكامل، ولكن هذا سيحدث قبل المُهيئ.
@roman هل لديك أي مخاوف بشأن تهيئة استباقية هنا؟ أعتقد أن الإصلاح البسيط هو:
class << self
def flag_settings
...
end
end
flag_settings
أعتقد أن السبب الرئيسي لحدوث ذلك هو أن روبي لا تقدم نمطًا نظيفًا للمُهيئات الفئوية، لذا فهي تدفع المطورين نحو اختراع خاص بهم/استخدام الكسول.
إعجابَين (2)
يمكن القيام بذلك أيضًا، مما سيتجنب بشكل ملحوظ قراءة المتغير الداخلي مرتين ويجعله أكثر وضوحًا أنه تم تهيئته بشكل استباقي (يمكن أيضًا وضع المنطق في طريقة مساعدة initial_flag_settings للتنظيم بالطبع):
class << self
attr_reader :flag_settings
end
@flag_settings = FlagSettings.new
@flag_settings.add(
3,
:off_topic,
notify_type: true,
auto_action_type: true,
)
# ...
إعجابَين (2)
نعم، أعتقد أن التهيئة المبكرة ستكون آمنة هنا. كما أنه لا ينبغي أن يتعارض مع واجهة برمجة تطبيقات المكون الإضافي، والتي نادرًا ما يتم استخدامها.
3 إعجابات
إليك طلب سحب (PR):
4 إعجابات
تم إغلاق هذا الموضوع تلقائيًا بعد 4 أيام. لم يعد يُسمح بالردود الجديدة.