Rails/autoloading and reloading constants

يوثق هذا الدليل طريقة عمل التحميل التلقائي وإعادة تحميل الثوابت. بعد قراءة هذا الدليل، ستتعلم:

• الجوانب الرئيسية لثوابت لغة روبي.
• ماهية autoload_paths وكيفية عمل التحميل الحثيث (eager loading) في الإنتاج.
• كيفية عمل التحميل التلقائي للثابت.
• ماهية need_dependency.
• كيفية عمل إعادة التحميل للثابت.
• حلول للتحميل التلقائي المشترك.

المقدمة

تسمح لغة ريلز بكتابة تطبيقات كما لو حملت الشيفرة الخاص بها مسبقًا.

في أصناف برنامج روبي عادي، تحتاج إلى تحميل جميع اعتماديته (dependencies):

require 'application_controller'
require 'post'
 
class PostsController < ApplicationController
  def index
    @posts = Post.all
  end
end

سرعان ما ترى غريزتنا الروبية بعض التكرار هنا: إذا عُرِّفَت الأصناف في ملفات مطابقة لاسمها، ألا يمكن أن يتم التحميل التلقائي بطريقة ما؟ يمكن حفظ مسح الملف (scanning the file) من أجل الاعتماديات، وهو أمر غير مُجدٍ.

علاوة على ذلك، يحمل Kernel.require الملفات مرة واحدة، ولكن التطوير يكون أكثر سلاسة إذا تحدثت الشيفرة عند تغييرها دون إعادة تشغيل الخادم. سيكون من الجيد أن تكون قادرًا على استخدام Kernel.load في التطوير، و Kernel.require في الإنتاج.

في الواقع، تتوفر هذه الميزات بواسطة ريلز، إذ يكفي أن نكتب فقط:

class PostsController < ApplicationController
  def index
    @posts = Post.all
  end
end

يوثق هذا الدليل كيفية عمل ذلك.

إنه خارج نطاق هذا الدليل توثيق ثوابت لغة روبي، لكننا مع ذلك سنسلط الضوء على بعض المواضيع الرئيسية. حقا استيعاب المقاطع التالية له دور فعال لفهم التحميل التلقائي وإعادة التحميل للثوابت.

منشط الثوابت

بينما الثوابت ليست ذات أهمية في معظم لغات البرمجة، إلا أنها موضوع ثري في لغة روبي.

هذا الأمر يقع خارج نطاق هذا الدليل لتوثيق ثوابت لغة روبي، لكننا مع ذلك سنسلط الضوء على بعض المواضيع الرئيسية. فهم الأقسام التالية بشكل جيد هو أداة مفيدة لفهم التحميل التلقائي وإعادة التحميل للثوابت.

التشعب

يمكن تشعيب تعريفات صنف ووحدة لإنشاء مجالات أسماء:

module XML
  class SAXParser
    # (1)
  end
end

إن التشعب (nesting) في أي مكان معطى هو مجموعة الأصناف المتداخلة المضمنة (enclosing nested class) وكائنات الوحدة الخارجية. يمكن فحص التشعب في أي مكان مع Module.nesting. على سبيل المثال، في المثال السابق، يكون التداخل في (1) هو:

[XML::SAXParser, XML]

من المهم أن نفهم أن التشعب يتكون من كائنات الصنف والوحدة، ولا علاقة له بالثوابت المستخدمة في الوصول إليهم، كما أنه لا علاقة له بأسمائها.

على سبيل المثال، في حين أن هذا التعريف هو مماثل لهذا التعريف السابق:

class XML::SAXParser
  # (2)
end

التشعب في (2) مختلف:

[XML::SAXParser]

لا تنتمي XML إليها.

يمكننا أن نرى في هذا المثال أن اسم الصنف أو الوحدة التي تنتمي إلى تشعب معين لا يرتبط بالضرورة مع مجالات الأسماء الموجودة في المكان.

أكثر من ذلك، فهي مستقلة تمامًا. خذ على سبيل المثال:

module X
  module Y
  end
end
 
module A
  module B
  end
end
 
module X::Y
  module A::B
    # (3)
  end
end

يتكون التشعب في (3) من كائنات وحدتين:

[A::B, X::Y]

لذلك، لا تنتهي فقط في A، والتي لا تنتمي حتى إلى التشعب، ولكنها تحتوي أيضًا على X::Y، وهي مستقلة عن A::B.

التشعب عبارة عن حزمة داخلية يحتفظ بها المترجم، وتُعدل وفقًا للقواعد التالية:

• كائن الصنف الذي يتبع الكلمة المفتاحية class يُضَاف عندما ينفذ جسمه، وينتشر (pop) بعد ذلك.
• كائن الوحدة الذي يتبع الكلمة المفتاحية module يُضَاف عندما ينفذ جسمه، وينشر بعد ذلك.
• الصنف المنفرد (singleton class) الذي يُفتتَح مع class << object يضاف، ثم ينتشر لاحقًا.
• عندما يستدعى instance_eval مع سلسلة نصية تمثِّل الوسيط، يُضَاف الصنف المفرد للمتلقي إلى تداخل الشيفرة المقيمة. عندما يستدعى class_eval أو module_eval باستخدام سلسلة وسيطة، يضاف المستقبل إلى تداخل الشيفرة المقيمة.
• التداخل في المستوى الأعلى من الشيفرة التي فسرت بواسطة Kernel.load يُعدُّ فارغًا، إلا إذا تلقى استدعاء load قيمة صحيحة كوسيط ثانية، وفي هذه الحالة تضاف وحدة مجهولة أُنشئت حديثًا بواسطة روبي.

من المثير للاهتمام ملاحظة أن الكتل لا تعدل المكدس. وعلى وجه الخصوص، فإن الكتل التي قد مُرِّرت إلى Class.new و Module.new لا تجلب الصنف أو الوحدة التي يجري تعريفها والتي أضيفت إلى تشعبها. هذا هو أحد الاختلافات بين تحديد الأصناف والوحدات بطريقة أو بأخرى.

تعريفات الصنف والوحدة هي مهام ثابتة

لنفترض أن الشيفرة البسيطة التالية تنشئ صنفًا (بدلًا من إعادة فتحه):

class C
End

ينشئ روبي الثابت C في Object ويخزن في هذا الثابت على أنه كائن صنف. اسم نسخة الصنف هي "C"، سلسلة نصية، سميت بعد الثابت.

إليك أيضًا الشيفرة التالية:

class Project < ApplicationRecord
End

ينفذ مهمة ثابتة تعادل:

Project = Class.new(ApplicationRecord)

بما في ذلك تحديد اسم الصنف على أنَّه تأثير جانبي:

Project.name # => "Project"

المهمة الثابتة لها قاعدة خاصة لتحقيق ذلك: إذا كان الكائن الذي تعين هو صنف أو وحدة غير معروفة، تعين روبي اسم الكائن إلى اسم الثابت.

تنبيه: من الآن فصاعدًا، ما يحدث للثابت والنسخة لا يهم. على سبيل المثال، يمكن حذف الثابت، أو يمكن تعيين كائن الصنف إلى ثابت مختلف، أو يمكن تخزينه بدون ثابت بعد الآن، ...إلخ. بمجرد تعيين الاسم، لا يتغير.

بالمثل، يجري إنشاء وحدة باستخدام الكلمة المفتاحية module بالشكل التالي:

module Admin
End

تنفيذ مهمة ثابتة تعادل:

Admin = Module.new

بما في ذلك تحديد الاسم على أنَّه تأثير جانبي:

Admin.name # => "Admin"

تحذير: سياق التنفيذ لكتلة مُررت إلى Class.new أو Module.new لا يكافئ تمامًا أحد تعريفات الجسم باستخدام الكلمتين المفتاحيتين class و module. لكن كل من التعابير ينتج عنها نفس المهمة الثابتة.

وهكذا، عندما يقول أحدهم بشكل غير رسمي "الصنف String" ، فهذا يعني بالفعل: كائن الصنف المخزن في الثابت المسمى "String" في كائن الصنف المخزن في الثابت Object. إن String هي ثابت روبي عادي وكل شيء يتعلق بالثوابت مثل خوارزميات الاستبيان ينطبق عليها.

وبالمثل، في وحدة التحكم:

class PostsController < ApplicationController
  def index
    @posts = Post.all
  end
end

لا يعد Post صياغة لصنف. بدلًا من ذلك، Post هو ثابت روبي عادي. إذا كان كل شيء جيد، يقيم الثابت إلى كائن يستجيب إلى all.

هذا هو السبب في أننا نتحدث عن التحميل التلقائي للثابت (constant autoloading)، إذ ريلز لديها القدرة على تحميل الثوابت مباشرةً وتلقائيًّا.

تخزين الثوابت في الوحدات

الثوابت تنتمي إلى وحدات بالمعنى الحرفي. تحتوي الأصناف والوحدات على جدول للثوابت. فكر في الأمر كأنه جدول Hash.

دعونا نحلل مثالًا لفهم ما يعنيه ذلك حقًا. في حين أن الإساءات الشائعة للغة مثل "الصنف String" صحيحة، فإن العرض سيكون دقيقًا هنا لأغراض تعليمية.

لنأخذ بعين الاعتبار تعريف الوحدة التالية:

module Colors
  RED = '0xff0000'
end

أولاً، عند معالجة الكلمة المفتاحية module، ينشئ المترجم قيمة جديدة في جدول الثوابت لكائن الصنف المخزن في الثابت Object. يقترن المدخل بالاسم "Colors" إلى كائن الوحدة التي أُنشئت حديثًا. علاوة على ذلك، يعين المترجم اسم كائن الوحدة الجديد ليكون السلسلة النصية "Colors".

لاحقًا، عندما يُفسر نص تعريف الوحدة، يُنشأ قيمة جديد في جدول الثوابت لكائن الوحدة المخزن في الثابت Colors. تعين تلك القيمة الاسم "RED" إلى السلسلة "0xff0000".

على وجه الخصوص، لا يرتبط Color::RED كليًّا بأي ثابت RED آخر قد يوجد في أي كائن صنف أو وحدة أخرى. إذا كان هناك أي منها، سيكون لديها قيم منفصلة في جداول الثوابت الخاصة بها.

يجب إعطاء اهتمام خاص في الفقرات السابقة للتمييز بين كائنات الصنف والوحدات والأسماء الثابتة وكائنات القيمة المرتبطة بها في جداول الثوابت.

خوارزميات الاستبيان (Resolution Algorithms)

خوارزمية الاستبيان للثوابت النسبية

في أي مكان في الشيفرة، دعنا نعرّف cref ليكون العنصر الأول من التشعب إذا لم يكن فارغًا، أو Object خلاف ذلك.

دون الحصول على الكثير من التفاصيل، فإن خوارزمية الاستبيان لمراجع الثابت النسبي تسير على النحو التالي:

• إذا لم يكن التشعب فارغًا، فسيُبحث عن الثابت في عناصره بالترتيب. يُتجاهل أسلاف تلك العناصر.
• إذا لم يُعثر عليه، ستصعد الخوارزمية عبر سلسلة أسلاف cref.
• إذا لم يُعثر عليه وكانت cref وحدةً، فسيُبحَث عن الثابت في Object.
• إذا لم يُعثر عليه، يستدعى const_missing على cref. التنفيذ الافتراضي للتابع const_missing يرمي الاستثناء NameError ولكن يمكن تجاوزه.

لا يحاكي التحميل التلقائي لريلز هذه الخوارزمية، ولكن نقطة البداية هي اسم الثابت الذي سيُحمل تلقائيًا، و cref. اطلع على قسم المراجع النسبية للمزيد من التفاصيل.

خوارزمية الاستبيان للثوابت المؤهلة

الثوابت المؤهلة (qualified constants) تبدو كالتالي:

Billing::Invoice

يتكون Billing::Invoice من اثنين من الثوابت: Billing وهو نسبي ويُستبيَن باستخدام خوارزمية القسم السابق.

تنبيه: من شأن النقطتان البارزة أن تجعل الجزء الأول مطلقًا وليس نسبيًا: ::Billing::Invoice. من شأن ذلك أن يجبر Billing على الظهور كثابت عالي المستوى فقط.

Invoice على الجانب الآخر مؤهل من قبل Billing وسنرى استبيانه وقراره فيما يلي. لنحدد الأب ليكون هذا العنصر المؤهل للصنف أو الوحدة، أي Billing في المثال أعلاه. الخوارزمية للثوابت المؤهلة تسير بالشكل التالي:

• يُبحّث عن الثابت في الأب وأسلافه. في الإصدار 2.5 من ريلز وما بعده، يتخطى Object إذا كان موجودًا بين الأسلاف وستستمر عملية التحقق من Kernel و BasicObject.
• إذا فشل البحث، يستدعى const_missing في الأب. التنفيذ الافتراضي const_missing يرمي الاستثناء NameError ولكن يمكن تجاوزه.

تنبيه: ما قبل الإصدار 2.5 من ريلز، يقيم String::Hash إلى Hash والمترجم يصدر تحذيرًا: "toplevel constant Hash referenced by String::Hash" (ثابت Hash ذو مستوى أعلى أشير إليه بواسطة String::Hash). بدءًا من الإصدار 2.5، يرمي String::Hash الاستثناء NameError عند تخطي Object.

كما ترى، هذه الخوارزمية أبسط من تلك الثوابت النسبية. على وجه الخصوص، لا يلعب التشعب أي دور هنا، والوحدات ليست حالة خاصة؛ إذا لم تكن لديها هي أو أسلافها الثوابت، لن يُتحقق من Object.

لا يحاكي التحميل التلقائي لريلز هذه الخوارزمية، ولكن نقطة البداية هي اسم الثابت الذي سيحمل تلقائيًا، والأب. اطلع على قسم المراجع الؤهلة للمزيد من التفاصيل.

مفردات اللغة

مجالات أسماء الأب

بالنظر إلى سلسلة نصية ذات مسار ثابت، نحدد مجال اسم الأب الخاص بها لتكون السلسلة التي تنتج عن إزالة الجزء الموجود في أقصى اليمين.

على سبيل المثال ، مجال الاسم للأب من السلسلة "A::B::C" هو السلسلة "A::B"، ومجال الاسم للأب من "A::B" هو "A"، ومجال الاسم للأب من "A " هو "".

تفسير مجال اسم الأب عند التفكير في الأصناف والوحدات أمر صعب رغم ذلك. لنفترض أن الوحدة M تحمل الاسم "A::B":

• قد لا يعكس مجال الاسم للأب، الذي هو "A"، التشعب في موضع محدد.
• قد لا يكون الثابت A موجودًا بعد الآن، إذ يكون بعض التعليمات البرمجية قد أزالته من الكائن.
• إذا كان A موجودًا، فقد لا يكون الصنف أو الوحدة التي كانت في الأصل في A موجودة بعد الآن. على سبيل المثال، إذا كانت هناك مهمة ثابتة أخرى بعد إزالة الثابت، فسيكون هناك كائن مختلف بشكل عام.
• في مثل هذه الحالة، يمكن أن يحدث أن يعاد تعيين A إلى صنف جديدة أو وحدة تسمى أيضا "A"!
• في السيناريوهات السابقة، لم يعد من الممكن الوصول إلى M خلال A::B ولكن كائن الوحدة نفسه يمكن أن يبقى على قيد الحياة في مكان ما وسيبقى اسمه "A::B".

تكمن فكرة وجود مجال اسم أب هي عند جوهر خوارزميات التحميل التلقائي والمساعدة على شرح وفهم دوافعها بشكل حدسي، ولكن كما ترى أن الاستعارة تتسرب بسهولة. إذا أخذنا في الاعتبار حالة حدية يجب التفكير فيها، فضع في حسبانك دائمًا أنه عبر "مجال اسم الأب"، الدليل يعني بالضبط اشتقاق سلسلة نصية محددة.

آلية التحميل

تقوم ريلز بالتحميل الآلي للملفات مع Kernel.load عندما تكون قيمة الضبط config.cache_classes هي false، وهو الافتراضي في وضع التطوير، ومع Kernel.require خلاف ذلك، وهو الافتراضي في وضع الإنتاج.

يسمح Kernel.load لريلز بتنفيذ الملفات أكثر من مرة إذا كانت إعادة التحميل للثابت مُفعلة.

يستخدم هذا الدليل الكلمة «تحميل» (load) بحرية للإشارة إلى ترجمة ملف معين، لكن الآلية الفعلية يمكن أن تكون عبر Kernel.load أو Kernel.require اعتمادًا على تلك الراية.

إتاحة التحميل التلقائي

يكون ريلز دائمًا قادرًا على التحميل التلقائي بشرط توفر بيئة التشغيل الخاصة به. على سبيل المثال، الأمر runner التالية يعيد التحميل:

$ bin/rails runner 'p User.column_names'
["id", "email", "created_at", "updated_at"]

وحدة تحكم تتحمل تلقائيًّا، ومجموعة الاختبار تتحمل تلقائيًّا، وبالطبع التطبيق يتحمل تلقائيًّا أيضًا.

بشكل افتراضي، تحمل ريلز بشكل حثيث (eager loads) ملفات التطبيق عند تشغيله في وضع الإنتاج، لذلك لا يحدث معظم التحميل التلقائي هنا الذي يجري في التطوير. ولكن قد لا يزال يُطلَق التحميل التلقائي أثناء التحميل الحثيث.

على سبيل المثال، إعطاء:

class BeachHouse < House
End

إذا كان House لا يزال غير معروف عندما يُحمَّل app/models/beach_house.rb بشكل حثيث، تحمله تلقائيًا.

autoload_paths و eager_load_paths

كما تعلم، عندما تُعطَى require اسم ملف نسبي:

require 'erb'

تبحث روبي عن الملف في المجلدات المدرجة في ‎$LOAD_PATH. هذا هو، تكرر روبي على كافة المجلدات الخاصة به وتتحقق من كل واحد منها من وجود ملف يسمى "erb.rb" أو "erb.so" أو "erb.o" أو "erb.dll". إذا وجدت أي منها، يحملها المترجم وينهي عملية البحث. وإلا، فإنه يحاول مرة أخرى في المجلد التالي من القائمة. إذا نفدت القائمة، فسيُمرمَى الاستثناء LoadError.

سنغطي كيفية عمل التحميل التلقائي للثابت بمزيد من التفاصيل في وقت لاحق، لكن الفكرة هي أنه عندما يكون ثابتًا مثل Post مكتوبًا ومفقودًا، فإذا كان هناك ملفًا باسم post.rb على سبيل المثال في app/models، فسيجده ريلز، ويقيمه، ويحدد Post على أنه تأثير جانبي.

حسنًا، لدى ريلز مجموعة من المجلدات المشابهة لـ ‎$LOAD_PATH للبحث فيها عن post.rb. يطلق على هذه المجموعة الاسم autoload_paths وتتضمن افتراضيًا ما يلي:

• جميع المجلدات الفرعية للــ app في التطبيق والمحركات الموجودة في وقت الإقلاع. على سبيل المثال، app/controllers. لا تحتاج إلى أن تكون الافتراضية، فكل المجلدات المخصصة مثل app/workers تنتمي تلقائيًا إلى autoload_paths.
• أي مجلدات موجودة ذات مستوى ثان تسمى app/*/concerns  في التطبيق والمحركات.
• المجلد test/mailers/previews.

إن eager_load_paths هو في البداية مسارات التطبيق (app) أعلاه.

تعتمد كيفية التحميل التلقائي للملفات على إعدادات تهيئة eager_load و cache_classes التي تختلف عادةً في أوضاع التطوير والإنتاج والاختبار:

• في التطوير، تريد بدء التشغيل بسرعة مع تحميل تدريجي لشيفرة التطبيق. لذا، يجب يجب تعطيل التحميل الحثيث عبر تعيين eager_load إلى القيمة "false"، وسيحمل ريلز تلقائيًا الملفات حسب الحاجة (انظر قسم خوارزميات التحميل التلقائي أدناه) ثم يعيد تحميلها عند تغييرها (راجع قسم إعادة التحميل للثوابت أدناه).
• في الإنتاج، ومع ذلك تريد التناسق وسلامة الصفحات ويمكن قبول وقت أطول للإقلاع. لذا، يتعين eager_load إلى القيمة true، وبعد ذلك أثناء الإقلاع (قبل أن يكون التطبيق جاهزًا لاستقبال الطلبات) تحمل ريلز كافة الملفات الموجودة في eager_load_paths ثم توقف التحميل التلقائي (ملحوظة: قد تكون هناك حاجة إلى التحميل التلقائي أثناء التحميل الحثيث). لا يعد التحميل التلقائي بعد التشغيل أمرًا جيدًا، نظرًا لأن التحميل التلقائي يمكن أن يتسبب في حدوث مشكلات في سلامة الصفحات.
• في الاختبار، لسرعة التنفيذ (من الاختبارات الفردية) eager_load يكون false، لذلك يتبع ريلز سلوك التطوير نفسه.

ما هو موضح أعلاه هي الإعدادات الافتراضية مع تطبيق ريلز أنشأ حديثًا. هناك طرق متعددة يمكن تهيئتها بشكل مختلف (راجع توثيق ضبط تطبيقات ريلز). ولكن استخدام autoload_paths من تلقاء نفسها في الماضي (قبل الإصدار 5) قد يضبط المطورون autoload_paths للإضافة مواقع إضافية (على سبيل المثال lib الذي اعتاد أن يكون قائمة مسار autoload منذ سنوات، ولكن لم يعد كذلك). ومع ذلك، فإن هذا غير محبط الآن لمعظم الأغراض، حيث من المحتمل أن يؤدي إلى أخطاء في الإنتاج فقط. من الممكن إضافة مواقع جديدة إلى كل من config.eager_load_paths و config.autoload_paths ولكن استخدم ذلك على مسؤوليتك الخاصة.

انظر أيضًا قسم التحميل التلقائي في بيئة الاختبار.

الضبط config.autoload_paths غير قابل للتغيير من ملفات الضبط الخاصة بالبيئة.

يمكن فحص قيمة autoload_paths. في تطبيق أنشأ للتو:

$ bin/rails r 'puts ActiveSupport::Dependencies.autoload_paths'
.../app/assets
.../app/channels
.../app/controllers
.../app/controllers/concerns
.../app/helpers
.../app/jobs
.../app/mailers
.../app/models
.../app/models/concerns
.../activestorage/app/assets
.../activestorage/app/controllers
.../activestorage/app/javascript
.../activestorage/app/jobs
.../activestorage/app/models
.../actioncable/app/assets
.../actionview/app/assets
.../test/mailers/previews

تنبيه: يحسب autoload_paths ويخزن مؤقتًا أثناء عملية التهيئة. يجب إعادة تشغيل التطبيق لتطبيق أي تغييرات في بنية المجلد.

خوارزميات التحميل التلقائي

المراجع النسبية

قد يظهر مرجع ثابت نسبي في عدة أماكن، على سبيل المثال، في

class PostsController < ApplicationController

 def index

   @posts = Post.all

 end

End

كل المراجع الثلاثة الثابتة نسبية.

الثوابت بعد الكلمات الأساسية class و module

ينفّذ روبي بحثًا عن الثابت الذي يتبع الكلمة المفتاحية class او module لأنه يحتاج إلى معرفة ما إذا كان سينشأ الصنف أو الوحدة النمطية أو سيُعيد فتحها.

إذا لم يُعرف الثابت عند هذه النقطة لا يعتبر ثابت مفقود، لا يُثار التحميل التلقائي.

لذا، في المثال السابق، إذا لم يحدد الوظيفة PostController عند ترجمة الملف، لن يُشغل Rails autoloading، سيعمل Ruby على تعريف وحدة التحكم فقط.

ثوابت المستوى الأعلى

على العكس من ذلك، إذا كان ApplicationController غير معروف، فسيعتبر الثابت مفقودًا وسيقوم Rails بمحاولة تحميل تلقائية.

لتحميل ApplicationController، يتكرر Rails على autoload_paths. أولاً تحقق من وجود app/assets/application_controller.rb. إذا لم يحدث ذلك، وهو ما يحدث عادةً، فسيستمر في البحث عن app/controllers/application_controller.rb.

إذا كان الملف يعرّف التطبيق الثابت، فإن كل شيء على ما يرام، وإلا فسيرفع LoadError:

unable to autoload constant ApplicationController, expected

<full path to application_controller.rb> to define it (LoadError)

ملاحظة: لا يتطلب Rails قيمة الثوابت التي تُحمل تلقائيًا لتكون صنف أو كائن وحدة نمطية. على سبيل المثال، إذا كان تطبيق الملف / models / max_clients.rb يعرّف MAX_CLIENTS = 100 autoloading MAX_CLIENTS يعمل بشكل جيد.

مجالات الأسماء

يبدو التحميل التلقائي لـ ApplicationController مباشرة تحت دلائل autoload_paths لأن التداخل في تلك البقعة فارغ.

يختلف وضع Post، ويكون التشعب في هذا الخط هو [PostsController] ويأتي تشغيل الدعم لمساحات الإسم.

الفكرة الأساسية هي أن تعطى

module Admin

 class BaseController < ApplicationController

   @@all_roles = Role.all

 end

End

للتحميل التلقائي لـ Role الذي سيفحص إذا تعرف في مجالات الأسماء الحالية أو المحلية، في وقت واحد. لذا، من الناحية المفاهيمية، نرغب في محاولة التحميل التلقائي لأي منها

Admin::BaseController::Role

Admin::Role

Role

بهذا الترتيب. هذه هي الفكرة. للقيام بذلك، يبحث Rails في autoload_paths على التوالي لأسماء الملفات مثل هذه:

admin/base_controller/role.rb

admin/role.rb

Role.rb

بعض عمليات البحث عن الأدلة الإضافية التي سنغطيها قريبًا.

'Constant::Name'.underscore يعطي المسار النسبي بدون امتداد لاسم الملف حيث من المتوقع أن يُحدد Constant :: Name.

دعنا نرى كيف يحمل Rails تلقائيًا الثابت Post في postsController أعلاه بافتراض أن التطبيق يحتوي على نموذج Post محدد في app/models/post.rb.

أولاً يتحقق من posts_controller / post.rb في autoload_paths:

app/assets/posts_controller/post.rb

app/controllers/posts_controller/post.rb

app/helpers/posts_controller/post.rb

...

test/mailers/previews/posts_controller/post.rb

نظرًا لاستنفاد البحث دون نجاح، يجري بحث مشابه عن الدليل، سنرى السبب في القسم التالي:

app/assets/posts_controller/post

app/controllers/posts_controller/post

app/helpers/posts_controller/post

...

test/mailers/previews/posts_controller/post

إذا فشلت كل هذه المحاولات، فسيبدأ Rails عملية البحث مرة أخرى في مجال الاسم الأصل. في هذه الحالة، يبقى المستوى الأعلى فقط:

app/assets/post.rb

app/controllers/post.rb

app/helpers/post.rb

app/mailers/post.rb

app/models/post.rb

إذا عُثر على ملف مطابق في app/models/post.rb. يتوقف البحث هناك ويُحمل الملف. إذا كان الملف يعرف بالفعل Post اذا كل شيء على ما يرام، وإلا يرفع LoadError.

مراجع مؤهلة

عند فقدان ثابت مؤهل لا يبحث Rails عنه في مجالات الأسماء الأصل. ولكن هناك تحذير: عندما يفتقد ثابت، لا تستطيع Rails معرفة ما إذا كان المشغل مرجعًا نسبيًا أو مرجعًا مؤهلاً.

على سبيل المثال، انظر

module Admin

 User

End

و

Admin::User

إذا كان User  مفقودًا، ففي كلتا الحالتين يعرف Rails أن ثابتًا يسمى "User" مفقود في وحدة تسمى "Admin".

إذا كان هناك User رفيع المستوى روبي سوف يحلها في المثال السابق، لكن لن يكون في الأخير. بشكل عام، لا تحاكي Rails خوارزميات روبي لإحلال الثوابت، ولكنها في هذه الحالة تحاول استخدام الكشف عن الأشياء التالية:

" إذا كان أي من مجالات الأسماء الأصل للصنف أو الوحدة النمطية يحتوي على ثابت مفقود، يفترض Rails أن المرجع هو نسبي. خلاف ذلك مؤهل. "

على سبيل المثال، إذا كان هذا الرمز يشغل التحميل التلقائي:

Admin::User

والثابت User موجود بالفعل في Object، ليس من الممكن أن الوضع:

module Admin

 User

End

لأنه بخلاف ذلك، كان روبي قد حل User ولم يكن قد شُغل أي تحميل ذاتي في المقام الأول. وبالتالي، يفترض Rails مرجع مؤهلاً ويعتبر ملف admin / user.rb والدليل admin/user أن تكون الخيارات صالحة فقط.

من الناحية العملية، يعمل هذا بشكل جيد طالما أن التداخل يطابق كافة مساحات أسماء الأصل على التوالي وتعرف الثوابت التي تجعل القاعدة تنطبق في ذلك الوقت.

ومع ذلك، يحدث التحميل التلقائي عند الطلب. إذا لم يُحمل User ذي المستوى الأعلى عن طريق الصدفة، يفترض Rails مرجعًا نسبيًا بموجب العقد.

إن تسمية التضارب من هذا النوع أمر نادر في الممارسة، ولكن إذا حدث ذلك، فإن required_dependency يوفر حلاً من خلال التأكد من أن الثابت المطلوب لتحفيز الكشف عن مجريات الأمور محدد في المكان المتضارب.

الوحدات التلقائية

عندما تعمل وحدة نمطية مثل مجال اسم، لا يتطلب Rails التطبيق لتعريف ملف له، الدليل المتطابق لمجال الاسم كافٍ.

لنفترض أن التطبيق يحتوي على مكتب خلفي يُخزن وحدات التحكم فيه في app/controllers/admin.

إذا لم تُحمل وحدة Admin حتى الآن عند إصابة Admin::UsersController، فإن Rails يحتاج أولاً إلى تحميل الثابت Admin أولاً.

إذا كان autoload_paths يحتوي على ملف يسمى admin.rb Rails سيُحمل هذا الملف، ولكن إذا لم يكن هناك مثل هذا الملف وعُثر على دليل يسمى admin، يُنشأ Rails وحدة فارغة ويُعينه إلى الثابت Admin أثناء الطيران.

الإجراء العام

تم ذكر فقدان المراجع النسبية في cref حيث سُجلت، وتم ذكر فقدان المراجع المؤهلة في الأصل (راجع خوارزمية الاستبيان للثوابت النسبية في بداية هذا الدليل لتعريف cref، و خوارزمية الاستبيان للثوابت المؤهلة لتعريف الأصل).

يكون الإجراء للتحميل التلقائي للثابت  C في الموقف التعسفي كما يلي:

if the class or module in which C is missing is Object

 let ns = <nowiki>''</nowiki>

else

 let M = the class or module in which C is missing

 if M is anonymous

   let ns = <nowiki>''</nowiki>

 else

   let ns = M.name

 end

end

loop do

 # ابحث عن ملف عادي.

 for dir in autoload_paths

   if the file "#{dir}/#{ns.underscore}/c.rb" exists

     load/require "#{dir}/#{ns.underscore}/c.rb"

     if C is now defined

       return

     else

       raise LoadError

     end

   end

 end

 # ابحث عن وحدة تلقائية.

 for dir in autoload_paths

   if the directory "#{dir}/#{ns.underscore}/c" exists

     if ns is an empty string

       let C = Module.new in Object and return

     else

       let C = Module.new in ns.constantize and return

     end

   end

 end

 if ns is empty

   #وصلنا إلى المستوى الأعلى دون العثور على الثابت.

   raise NameError

 else

   if C exists in any of the parent namespaces

     # الثوابت المؤهلة الإرشادية.

     raise NameError

   else

     # حاول مرة أخرى في مساحة الاسم الأصل.

     let ns = the parent namespace of ns and retry

   end

 end

End

Require_dependency

يُشغل التحميل التلقائي عند الطلب ولذلك قد يكون التعليمات البرمجية التي تستخدم ثابت معين محددة بالفعل أو قد يؤدي إلى التحميل التلقائي. يعتمد ذلك على مسار التنفيذ وقد يختلف بين عمليات التنفيذ.

ومع ذلك، هناك أوقات تريد فيها التأكد من معرفة ثابت معين عندما يصل التنفيذ إلى رمز ما. يوفر require_dependency طريقة لتحميل ملف باستخدام آلية التحميل الحالية، وتتبع الثوابت المحددة في هذا الملف كما لو تُحملت تلقائيًا لإعادة تحميلها حسب الحاجة.

نادراً ما نحتاج إلى require_dependency، ولكن نرى بعض حالات الاستخدام في Autoloading و STI وعندما لا يُشغل الثوابت.

ملاحظة: على عكس autoloading، لا تتوقع require_dependency أن يحدد الملف أي ثابت معين. قد يكون استغلال هذا السلوك ممارسة سيئة بالرغم من ذلك، يجب أن تتطابق الملفات والمسارات الثابتة.

إعادة التحميل للثوابت

عندما يكون config.cache_classes false، فإن Rails قادرة على إعادة تحميل الثوابت ذاتية التحميل.

على سبيل المثال، إذا كنت في جلسة عمل وحدة التحكم وقمت بتحرير بعض الملفات من وراء الكواليس، فيمكن إعادة تحميل الشيفرة مع reload! أمر:

> reload!

عند تشغيل التطبيق، يُعاد تحميل الشفرة عندما يتغير شيء ذي صلة بهذا المنطق. من أجل القيام بذلك، تراقب Rails عدد من الأشياء:

• config/routes.rb.
• مواقع محلية.
• ملفات روبي تحت autoload_paths.
• db / schema.rb و db / structure.sql.

إذا تغير أي شيء هناك، فهناك برنامج وسيط يكتشفها ويعيد تحميل الشفرة.

Autoloading بتتبع التحميل التلقائي الثوابت. تُنفذ إعادة التحميل عن طريق إزالتها جميعًا من الأصناف والوحدات الخاصة بها باستخدام Module # remove_const. بهذه الطريقة، عندما يُشغل الشيفرة، ستكون هذه الثوابت غير معروفة مرة أخرى، ويُعاد تحميل الملفات عند الطلب.

هذه عملية كل شيء أو لا شيء، Rails لا يحاول إعادة تحميل سوى ما تغيرت لأن التبعيات بين الطبقات يجعل ذلك صعب حقا. بدلا من ذلك، يُمسح كل شيء.

Module#autoload غير متضمنة

Module#autoload يوفر طريقة كسولة لتحميل الثوابت التي تتكامل تمامًا مع خوارزميات البحث لثوابت روبي، وواجهة برمجة التطبيقات الثابتة الديناميكية، إلخ. إنها شفافة تمامًا.

تستخدم Rails الداخلية استخدام واسع النطاق لتأجيل أكبر قدر ممكن من العمل من عملية التمهيد. ولكن التحميل التلقائي للثوابت لايُنفذ في Rails مع Module#autoload.

أحد التطبيقات الممكنة استناداً إلى Module#autoload سيكون السير إلى شجرة التطبيق وإصدار استدعاءات autoload تُعين أسماء الملفات الموجودة إلى اسمها الثابت التقليدي.

هناك عدد من الأسباب التي تمنع Rails من استخدام هذا التنفيذ.

على سبيل المثال، لا يستطيع Module#autoload  إلا تحميل الملفات باستخدام require، لذا لن تكون عملية إعادة التحميل ممكنة. ليس ذلك فحسب، بل يستخدم require الداخلي الذي لا Kernel#require.

ثم، فإنه لا يوفر أية طريقة لإزالة التعريفات في حالة حذف ملف. في حالة إزالة الثابت باستخدام Module#remove_const لا يُشغل autoload مرة أخرى. كما أنه لا يدعم الأسماء المؤهلة، لذلك يجب ترجمة الملفات ذات مجالات الأسماء أثناء سير الشجرة لتثبيت استدعاءات autoload الخاصة، لكن هذه الملفات قد تحتوي على مراجع ثابتة لم تُكون بعد.

سيكون التنفيذ الذي يعتمد على Module#autoload رائعًا لكن، كما ترى، على الأقل اعتبارًا من اليوم غير ممكن. تُنفذ التحميل التلقائي في Rails مع  Module#const_missing وهذا هو السبب في أنه يحتوي على العقد الخاص به، موثقة في هذا الدليل.

Gotchas المشترك

التشعب والثوابت المؤهلة

دعونا ننظر:

module Admin

 class UsersController < ApplicationController

   def index

     @users = User.all

   end

 end

End

و

class Admin::UsersController < ApplicationController

 def index

   @users = User.all

 end

End

لحل User روبي يتحقق من Admin في الحالة السابقة، لكنه لا يوجد في الأخير لأنه لا ينتمي إلى التداخل (راجع التشعب و خوارزميات الاستبيان).

لسوء الحظ، لا تعرف التحميل التلقائي ل Rails التشعب في المكان الذي كان فيه الثابت مفقودًا، وبالتالي لا يكون قادرًا على التصرف كما يفعل روبي. على وجه الخصوص، سيحصل على التحميل التلقائي Admin::User في كلتا الحالتين.

على الرغم من أن الثوابت المؤهلة التي تحتوي على كلمات أساسية class و module قد تعمل تقنيًا مع التحميل التلقائي في بعض الحالات، فمن الأفضل استخدام الثوابت النسبية بدلاً من ذلك:

module Admin

 class UsersController < ApplicationController

   def index

     @users = User.all

   end

 end

End

التحميل التلقائي و STI

وراثة جدول فردي (STI) هي إحدى ميزات السجل النشط التي تمكّن من تخزين تسلسل هرمي للنماذج في جدول واحد. واجهة برمجة التطبيقات (API) لهذه النماذج تدرك التسلسل الهرمي وتلخص بعض الاحتياجات العامة. على سبيل المثال ، بالنظر إلى هذه الأصناف:

<nowiki>#</nowiki> app/models/polygon.rb

class Polygon < ApplicationRecord

end

<nowiki>#</nowiki> app/models/triangle.rb

class Triangle < Polygon

end

<nowiki>#</nowiki> app/models/rectangle.rb

class Rectangle < Polygon

End

ينشئ Triangle.create صفًا يمثل المثلث، وينشئ Rectangle.create صف يمثل مستطيلاً. إذا كان المعرف هو الرقم التعريفي لسجل موجود، فإن (Polygon.find (id ترجع كائن من النوع الصحيح.

التوابع التي تعمل على مجموعات هي أيضا على بينة من التسلسل الهرمي. على سبيل المثال، ترجع Polygon.all كافة سجلات الجدول، لأن كافة المستطيلات والمثلثات عبارة عن مضلعات. يعتني السجل النشط بإعادة نسخ من فئتها المتطابقة في مجموعة النتائج.

والتحميل التلقائي أنواع حسب الحاجة. على سبيل المثال، إذا كان Polygon.first مستطيلاً ولم يُحمل Rectangle بعد، السجل النشط يُحمله تلقائيًا وينشئ السجل بشكل صحيح.

كل شيء جيد، ولكن إذا أردنا العمل على بعض الأصناف الفرعية، بدلاً من تنفيذ استعلامات تستند إلى صنف الجذر، فستصبح الأشياء مثيرة للاهتمام.

أثناء العمل مع Polygon، لا تحتاج إلى أن تكون على دراية بجميع أحفادها، لأن أي شيء في الجدول يكون مضلعًا بحكم التعريف، ولكن عند العمل مع الأصناف الفرعية يجب أن يكون السجل النشط قادراً على تعداد الأنواع التي يبحث عنها. دعونا نرى مثال.

يُحمل Rectangle.all المستطيلات فقط عن طريق إضافة قيد نوع إلى الاستعلام:

SELECT "polygons".* FROM "polygons"

WHERE "polygons"."type" IN ("Rectangle")

دعونا نقدم الآن صنف فرعية من Rectangle:

# app/models/square.rb

class Square < Rectangle

End

Rectangle.all يجب الآن إرجاع المستطيلات والمربعات:

SELECT "polygons".* FROM "polygons"

WHERE "polygons"."type" IN ("Rectangle", "Square")

ولكن هناك تحذير هنا: كيف يعرف السجل النشط أن صنف Square موجودة على الإطلاق؟

حتى إذا كان ملف app/models/square.rb موجودًا ويحدد صنف Square، إذا لم يستخدم أي رمز بعد ذلك، فإن Rectangle.all يصدر الاستعلام.

SELECT "polygons".* FROM "polygons"

WHERE "polygons"."type" IN ("Rectangle")

هذا ليس خطأ، ويشمل الاستعلام جميع الأحفاد المعروفة من Rectangle.

طريقة للتأكد من أن هذا يعمل بشكل صحيح بغض النظر عن ترتيب التنفيذ هو يدوياً تحميل الأصناف الفرعية المباشرة في أسفل الملف الذي يعرّف كل صنف متوسطة:

<nowiki>#</nowiki> app/models/rectangle.rb

class Rectangle < Polygon

end

require_dependency 'square'

يجب أن يحدث هذا لكل صنف وسيطة (غير جذر وغير ورقة). لا يقوم نطاق الجذر بتوسيع نطاق البحث حسب النوع، وبالتالي لا يلزم بالضرورة معرفة كل أحفاده.

التحميل التلقائي والطلب

لا يجب مطلقًا طلب الملفات التي تحدد الثوابت التي ستُحمل تلقائيًا:

require 'user' # DO NOT DO THIS

class UsersController < ApplicationController

 ...

End

هناك نوعان من gotchas محتملة هنا في وضع التطوير:

1- إذا تحمل User تلقائيًا قبل الوصول إلى require، فسيشغل app/models/user.rb مرة أخرى نظرًا لأن التحميل لا يُحدّث $ LOADED_FEATURES.

2- إذا كانت require  قيد التشغيل أولًا، فإن Rails لا يضع علامة على User كتحميل تلقائي لثابت ولا يُعاد تحميل التغييرات على app/models/user.rb.

فقط اتبع التدفق واستخدم التحميل التلقائي للثابت دائما، أبدا لا تخلط بين التحميل التلقائي و require. كحل أخير، إذا كان بعض الملفات يحتاج إلى تحميل ملف معين استخدم require_dependency للعب لطيف مع التحميل التلقائي للثابت. نادرًا ما يكون هذا الخيار مطلوبًا في الممارسة.

وبالطبع، فإن استخدام ما يتطلب من ملفات حُملت تلقائيًا لتحميل مكتبات عادية تابعة لجهات خارجية أمر جيد، و Rails قادرة على تمييز ثوابتها، ولا يُوضع علامة عليها بأنها تحميل تلقائي.

التحميل التلقائي و المهيأت   

خذ بعين الاعتبار هذه المهمة في config / initializers / set_auth_service.rb:

AUTH_SERVICE = if Rails.env.production?

 RealAuthService

else

 MockedAuthService

End

قد يكون الغرض من هذا الإعداد أن يستخدم التطبيق الصنف التي تتوافق مع البيئة عبر AUTH_SERVICE. في وضع التطوير يحصل على التحميل التلقائي MockedAuthService عند تشغيل المُهيئ. لنفترض أننا نقوم ببعض الطلبات، ونغير تنفيذها، ونضغط على التطبيق مرة أخرى. لدهشتنا لا تنعكس التغييرات. لماذا ا؟

كما رأينا سابقاً، يزيل Rails التحميل التلقائي للثوابت، ولكن يخزن AUTH_SERVICE كائن الصنف الأصلي. تالفة، غير قابلة للوصول باستخدام الثابت الأصلي  ولكن وظيفية تماما.

يلخص الشيفرة التالي الحالة:

class C

 def quack

   'quack!'

 end

end

X = C

Object.instance_eval { remove_const(:C) }

X.new.quack # => quack!

X.name      # => C

C           # => uninitialized constant C (NameError)

وبسبب ذلك، ليست فكرة جيدة التحميل التلقائي للثوابت عند تهيئة التطبيق.

في الحالة أعلاه، يمكننا تنفيذ نقطة وصول ديناميكية:

<nowiki>#</nowiki> app/models/auth_service.rb

class AuthService

 if Rails.env.production?

   def self.instance

     RealAuthService

   end

 else

   def self.instance

     MockedAuthService

   end

 end

End

واستخدم التطبيق AuthService.instance بدلاً من ذلك. ستُحمل AuthService عند الطلب وتكون autoload-friendly.

required_dependency و المُهيآت

كما رأينا من قبل، need_dependency تحميل الملفات بطريقة autoloading-friendly. ومع ذلك، عادةً ما لا يكون مثل هذا الاستدعاء منطقيًا في المُهيئ.

يمكن للمرء أن يفكر في إجراء بعض استدعاءات relay_dependency في المُهيئ للتأكد من تحميل ثوابت معينة مقدما، على سبيل المثال كمحاولة لمعالجة gotcha مع STIs.

المشكلة هي، في وضع التطوير يمسح التحميل التلقائي للثوابت إذا كان هناك أي تغيير ذات الصلة في نظام الملفات. إذا حدث ذلك، فنحن في نفس الموقف الذي أراد المبتدئ تجنبه!

الإستدعاء إلى require_dependency يجب أن تكون مكتوبة بشكل استراتيجي في مواقع التحميل التلقائي.

عندما لا تكون الثوابت مفقودة

المراجع النسبية

دعونا ننظر في جهاز محاكاة الطيران. التطبيق يحتوي على نموذج رحلة افتراضي:

<nowiki>#</nowiki> app/models/flight_model.rb

class FlightModel

End

يمكن تجاوزها من قبل كل طائرة، على سبيل المثال:

<nowiki>#</nowiki> app/models/bell_x1/flight_model.rb

module BellX1

 class FlightModel < FlightModel

 end

end

<nowiki>#</nowiki> app/models/bell_x1/aircraft.rb

module BellX1

 class Aircraft

   def initialize

     @flight_model = FlightModel.new

   end

 end

End

يريد المُهيئ إنشاء BellX1 :: FlightModel وتداخل يحتوي على BellX1، التي تبدو جيدة. ولكن إذا تحمل نموذج الطيران الافتراضي ولم يُثبت نموذج Bell-X1، فسيكون بمقدور المترجم حل ملف FlightModel ذي المستوى الأعلى وبالتالي لا يُشغل ميزة التحميل التلقائي لـ BellX1 :: FlightModel.

يعتمد هذا الرمز على مسار التنفيذ.

يمكن في الغالب حل هذا النوع من الغموض باستخدام ثوابت مؤهلة:

module BellX1

 class Plane

   def flight_model

     @flight_model ||= BellX1::FlightModel.new

   end

 end

End

أيضا، require_dependency هو الحل:

require_dependency 'bell_x1/flight_model'

module BellX1

 class Plane

   def flight_model

     @flight_model ||= FlightModel.new

   end

 end

End

مراجع مؤهلة

ملاحظة: هذه gotcha ممكن فقط في روبي <2.5.

معطى

<nowiki>#</nowiki> app/models/hotel.rb

class Hotel

end

<nowiki>#</nowiki> app/models/image.rb

class Image

end

<nowiki>#</nowiki> app/models/hotel/image.rb

class Hotel

 class Image < Image

 end

End

التعبير Hotel :: Image غامض لأنه يعتمد على مسار التنفيذ.

كما رأينا من قبل، يبحث روبي عن الثابت في Hotel وأسلافه. إذا تحمل app/models/image.rb ولكن app/models/hotel/image.rb لا، لم يعثر روبي على Image في Hotel، لكنه في Object:

$ bin/rails r 'Image; p Hotel::Image' 2>/dev/null

Image # NOT Hotel::Image!

يجب أن يكون رمز تقييم Hotel :: Image للتأكد من تحميل app/models/hotel/image.rb، ربما مع require_dependency.

في هذه الحالات، يصدر المترجم تحذيرًا على الرغم من:

warning: toplevel constant Image referenced by Hotel::Image

يمكن ملاحظة هذا الاستبيان الثابت المذهل مع أي صنف مؤهلة:

2.1.5 :001 > String::Array

(irb):1: warning: toplevel constant Array referenced by String::Array

=> Array

ملاحظة: للعثور على هذا gotcha  يجب أن تكون مجال الاسم المؤهلة صنف، الكائن ليس سلف من الوحدات.

التحميل التلقائي داخل أصناف Singleton

لنفترض أن لدينا تعريفات الصنف هذه:

<nowiki>#</nowiki> app/models/hotel/services.rb

module Hotel

 class Services

 end

end

<nowiki>#</nowiki> app/models/hotel/geo_location.rb

module Hotel

 class GeoLocation

   class << self

     Services

   end

 end

End

إذا كان Hotel::Services معروفة في وقت تحميل app/models/hotel/geo_location.rb، تُحل الـ Services بواسطة Ruby لأن الفندق ينتمي إلى التشعب عندما تُفتح صنف singleton من Hotel :: GeoLocation.

ولكن إذا كان Hotel::Services غير معروفة، تكون Rails غير قادرة على التحميل التلقائي، ويرفع التطبيق NameError.

السبب في ذلك هو أن تشغيل التحميل التلقائي لصنف singleton، هو مجهول، وكما رأينا من قبل، Rails فقط تتحقق من مجال الاسم الأعلى في حالة الحافة.

الحل السهل لهذا التحذير هو تأهيل الثابت:

module Hotel

 class GeoLocation

   class << self

     Hotel::Services

   end

 end

End

التحميل التلقائي في BasicObject

لا تملك أحفاد Direct من BasicObject كائن بين أسلافهم ولا يمكن حل ثوابت المستوى الأعلى:

class C < BasicObject

 String # NameError: uninitialized constant C::String

end

عندما يشارك التحميل التلقائي تلك المؤامرة لديها تطور. دعونا ننظر:

class C < BasicObject

 def user

   User # WRONG

 end

End

نظرًا لأن Rails يتحقق من مجال الاسم ذات المستوى الأعلى، يحصل User على التحميل التلقائي بشكل جيد في المرة الأولى التي يستدعى فيها التابع User. تحصل على الاستثناء فقط إذا كان الثابت User معروفًا عند هذه النقطة، خاصة في ثاني استدعاء للـ Use:

c = C.new

c.user # surprisingly fine, User

c.user # NameError: uninitialized constant C::User

لأنه يكتشف أن مجال الاسم الأصل تحتوي على الثابت (انظر مراجع مؤهلة).

كما هو الحال مع روبي الصافي، داخل جسم السلف المباشر من BasicObject، استخدم دائمًا المسارات الثابتة المطلقة:

class C < BasicObject

 ::String # RIGHT

 def user

   ::User # RIGHT

 end

End

التحميل التلقائي في بيئة الاختبار

عند تهيئة بيئة الاختبار للتحميل التلقائي، يمكنك التفكير في عدة عوامل.

على سبيل المثال، قد يكون من المفيد تشغيل اختباراتك باستخدام إعداد مماثل للإنتاج (config.eager_load = true, config.cache_classes = true) من أجل اكتشاف أي مشاكل قبل أن تصل إلى الإنتاج (وهذا تعويض عن عدم وجود تعادل dev-prod ). ومع ذلك فإن هذا سيبطئ وقت الإقلاع للاختبارات الفردية على جهاز dev (وهو غير متوافق على الفور مع الإنطلاقة انظر أدناه). لذا فإن أحد الاحتمالات هو القيام بذلك على جهاز CI فقط (والذي يجب أن يعمل دون الإنطلاقة).

على جهاز التطوير يمكنك بعد ذلك تشغيل الاختبارات الخاصة بك مع أي شيء أسرع (بشكل مثالي config.eager_load = false).

باستخدام أداة التحميل المسبق من Spring (المضمنة في تطبيقات rails الجديدة)، ستحتفظ بشكل مثالي بـ config.eager_load = false وفقًا للتطوير. في بعض الأحيان قد ينتهي بك الأمر مع تكوين مختلط (config.eager_load = true ، config.cache_classes = true AND config.enable_dependency_loading = true)، راجع قضية Spring. ومع ذلك، قد يكون من الأسهل الحفاظ على نفس التكوين مثل التطوير، اكتشف - حل كل سبب يؤدي الى فشل التحميل التلقائي  (ربما عن طريق نتائج اختبار CI الخاص بك).

من حين لآخر قد تحتاج إلى eager_load صراحة باستخدام Rails.application.eager_load! في إعداد اختباراتك - قد يحدث هذا إذا كانت اختباراتك تنطوي على تعدد مؤشرات.