Ruby/refinements

= التحسينات =  إن ميّزة الأصناف المفتوحة في لغة روبي تسمح لك بإعادة تعريف أو إضافة وظائف إلى أصناف معرّفة مسبقًا. وهذا ما يسمى بـ "ترقيع القرد" أو monkey patch. المشكلة هنا أن تعديلات من هذا النوع تكون مرئيّة على المستوى العام global وبالتالي جميع مستخدمي الصنف المرقّع قادرون على رؤية هذه التغييرات، ممّا قد يسبّب تأثيرات جانبيّة غير محسوبة أو حتى عطب في البرامج. تأتي التحسينات هنا لتقلّل أثر ترقيع القرد على مستخدمي الصنف الآخرين، إذ تقدّم طريقة لتوسيع الصنف محليًّا. وإليك مثال على تحسين بسيط:

class C
 def foo
   puts "C#foo"
 end
end
module M
 refine C do
   def foo
     puts "C#foo in M"
   end
 end
end 

في البداية يُعرّف الصنف C، ثم يُجرى له تحسينًا باستخدام Module#refine. وبما أنّ التحسينات تعدّل أصنافًا فقط ولا تعدّل كينونات فيجب أن يكون المعامل الممرر لها صنفًا. يقوم Module#refine بعدئذ بإنشاء كينونة ليست ذات اسم anonymous  وإنّما تحوي التعديلات أو التحسينات المطبّقة على هذا الصنف (في مثالنا الصنف C). واستخدام self أو Module#module_eval سيشير إلى هذه الكينونة الجديدة. أمّا تفعيل هذا التحسين فيكون باستخدام using:

using M
c = C.new
c.foo # تطبع "C#foo in M"

النطاق

يمكنك تفعيل التحسينات في المستوى الأعلى من البرنامج، أو ضمن الأصناف والكينونات، لكن لا يمكنك حصرها ضمن نطاق تابع معيّن، إذ أنها تبقى مفعّلة حتى نهاية تعريف الصنف أو الكينونة الحاليّة، و في حال تفعيلها في المستوى الأعلى من البرنامج تبقى مفعّلة حتى نهاية الملف الحالي. كما بإمكانك تفعيل التحسينات في سلسلة أوامر ممرّرة إلى Kernel#eval، وحينها تبقى فعالة حتى نهاية هذه السلسلة. تبدأ صلاحية التحسينات ضمن نطاق معيّن عند استدعاء using، وبالتالي فإنّ أيّ سطر برمجيّ يسبق هذا الاستدعاء لن يكون للتحسينات أثر عليه.  وحين ينتقل التحكّم إلى خارج النّطاق يُلغى تفعيل التحسينات تلقائيًّا، وهذا يعني أنّك إن قمت بطلب أو تحميل ملفّ، أو أجريت استدعاءً لتابع معرّف خارج النّطاق الحاليّ، فسيلغى تفعيل التحسينات تلقائيًّا:

class C
end
module M
 refine C do
   def foo
     puts "C#foo in M"
   end
 end
end
def call_foo(x)
 x.foo
end
using M
x = C.new
x.foo       # يطبع "C#foo in M"
call_foo(x) #=> يسبب NoMethodError

إذا عُرّف تابع في نطاق كانت فيه التحسينات مفعّلة، فستبقى هذه التحسينات على حالة تفعيلها عند استدعاء هذا التابع، إليك المثال التالي الذي يمتدّ على ملفّات عدّة: c.rb:

class C
end
m.rb:
require "c"
module M
 refine C do
   def foo
     puts "C#foo in M"
   end
 end
end

m_user.rb:

require "m"
using M
class MUser
 def call_foo(x)
   x.foo
 end
end

main.rb:

require "m_user"
x = C.new
m_user = MUser.new
m_user.call_foo(x) # يطبع "C#foo in M"
x.foo              #=> يسبب NoMethodError

بما أنّ التحسين M فعال في الملف m_user.rb حيث تعريف التابع MUser#call_foo فسيبقى هذا التحسين فعالًا عندما يُستدعى التابع call_foo في الملف main.rb وبما أنّ using هو تابع، فستفعّل التحسينات فقط عند استدعائه، وإليك أمثلة حيث يكون التحسين M مفعلًا أو غير مفعّل. في ملف:

# غير فعال هنا
using M
# فعال هنا
class Foo
 # فعال هنا
 def foo
   # فعال هنا
 end
 # فعال هنا
end
# فعال هنا

في صنف:

# غير فعال هنا
class Foo
 # غير فعال هنا
 def foo
   # غير فعال هنا
 end
 using M
 # فعال هنا
 def bar
   # فعال هنا
 end
 # فعال هنا
end
# غير فعال هنا

لاحظ أنّ التحسينات M لا تفعّل تلقائيًّا في حال أُعيد فتح الصنف لاحقًا. في eval:

# غير فعال هنا
eval <<EOF
 # غير فعال هنا
 using M
 # فعال هنا
EOF
# غير فعال هنا
عند عدم تحقّق التنفيذ:
# غير فعال هنا
if false
 using M
end
# غير فعال هنا

عند تعريف عدة تحسينات في نفس الكينونة داخل عدّة كتل برمجيّة محسِّنة، فكلّ التحسينات في هذه الكينونة تصبح فعالة عند استدعاء تابع محسَّن (أيّ من توابع to_json في المثال أدناه) :

module ToJSON
 refine Integer do
   def to_json
     to_s
   end
 end
 refine Array do
   def to_json
     "[" + map { |i| i.to_json }.join(",") + "]"
   end
 end
 refine Hash do
   def to_json
     "{" + map { |k, v| k.to_s.dump + ":" + v.to_json }.join(",") + "}"
   end
 end
end
using ToJSON
p [{1=>2}, {3=>4}].to_json # "[{\"1\":2},{\"3\":4}]" تطبع

البحث عن التوابع

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

• إذا وُجدت تحسينات فعالة للصنف C فيتمّ البحث بعكس ترتيب تفعيلها:
  • يبدأ بالكينونات المضمّنة باستخدام prepend في تحسينات الصنف C
  • ثمّ تحسينات الصنف
  • ثم الكينونات  المضمّنة باستخدام include في تحسينات الصنف C
• ثم الكينونات المضمّنة في الصنف باستخدام prepend
• ثم الصنف نفسه
• ثم الكينونات المضمّنة في الصنف باستخدام include

وإذا لم يجد المفسّر أيّ تابع مطابق في أيّ مرحلة من هذه المراحل فإنّ عملية البحث تكرّر بنفس الترتيب لكن مع الصنف الأب للصنف C. لاحظ أنّ أولوية التوابع في الصنف الابن أعلى من التحسينات في الصنف الأب، فعلى سبيل المثال لو عرّفنا التابع / في تحسين للصنف Numeric فإنّ العملية 1/2 تستدعي التابع المقابل في الصنف Integer بسبب كون الأخير صنفًا فرعيًا عن Numeric فيسبقه في عمليّة البحث، وبما أنّ التابع موجود في الصنف الابن فسيتوقف البحث بمجرّد العثور على هذا التابع فيه. وبالمقابل لو عرّفنا التابع foo في الصنف Numeric ضمن تحسين ما، فإنّ كتابة 1.foo ستستدعي هذا التابع من الصنف Numeric لكونه غير معرّف في الصنف Integer.

super

إليك الترتيب الذي يسير وفقه المفسر عند استدعاء super:

• الكينونات المضمّنة في الصنف الحاليّ، مع ملاحظة أنّ الصنف الحاليّ يمكن أن يكون تحسينًا.
• في حال كان الصنف الحاليّ تحسينًا فإنّ عملية البحث تسير وفق الترتيب المذكور في الفقرة السابقة "البحث عن التوابع"
• وفق حال كان للصنف الحاليّ أب مباشر فستسير عمليّة البحث كما في الفقرة السابقة وإنّما على الصنف الأب.

لاحظ أنّ استدعاء super في تابع ضمن تحسين صنفٍ ما سيستدعي هذا التابع من الصنف الذي يُحسَّن، حتى ولو سبق ذلك تفعيل تحسين آخر ضمن نفس السياق. == الاستدعاء غير المباشر للتوابع ==  إذا استدعي تابع بشكل غير مباشر كما هو الحال عند استخدام Kernel#send أو Kernel#method أو Kernel#respond_to? فحينها لا تُعطى التحسينات أولويّة أثناء عمليّة البحث. إلّا أنّ هذا السّلوك قد يتغيّر في المستقبل. == وراثة التحسينات باستخدام Module#include ==  إذا ضُمّنت الكينونة X في الكينونة Y فإنّ الثانية ترث التحسينات المطبّقة في الأولى. ففي المثال التالي ترث C تحسينات من A و B:

module A
 refine X do ... end
 refine Y do ... end
end
module B
 refine Z do ... end
end
module C
 include A
 include B
end
using C
# التحسينات من A و B فعالة هنا.

وتحسينات الأبناء لها أولوية أعلى من تحسينات الآباء.

مزيد من المعلومات

انظر صفحة التوثيق الخاصة بالقواعد الحاليّة لاستخدام التحسينات، قد تجد فيها المزيد من التفاصيل.