ماهو سبب وجود Case Sensitive في السي شارب ؟

وعليكم السلام ورحمة الله وبركاته

فؤائد استخدام ال Case Sensitive

1 - زيادة عدد اسماء المتغيرات المتاح خصوصا انه فى الماضى كان عدد الحروف المتاح لاسم المتغير قليل جدا كما ان قواعد تسمية المتغيرات صارمة

وهذا يتيح للمبرمج استخدام نفس الاسم (مع تغير الحالة) للتعبير عن معنى مختلف

2 - اسرع بالنسبة للمترجم حتى لايكون هناك ضرورة للتحويل من الحروف الكبيرة الى الصغيرة او العكس عند التعامل مع اسماء المتغيرات

فى رايى المتواضع هذه اسباب تتماشى مع الماضى وانا مع ان تكون اللغة Not-Case Sensitive

وعندما صممت السوبرنوفا جعلت المتغيرات Not-Case Sensitive ولكنى تماديت بعدم وضع قيود على اسم المتغير لا من حيث الرموز او الطول

مما جعلنى اشترط وضع اسماء المتغيرات بين علامة [ وعلامة ] واستخدام هذه العلامات فى حد ذاتها مشكلة وعبء على المبرمج ولكن يمكن حله

من خلال بيئة التطوير.

الذى اراه نحن فى عصر مختلف ويجب فى تصميم اللغات ان يتم مراعاة ان هناك بيئة تطوير يمكن ان تحل مشاكل

بمعنى نصمم اللغة بحيث نحل المشاكل التى لايمكن حلها من خلال بيئة التطوير (الا بصعوبة شديدة) ولامشكلة من اضافة مشاكل طالما مجبرين من جانب

ويمكن حل هذه المشاكل من جانب بيئة التطوير

اعلم ان هناك مبرمجين لايستخدمون بيئة التطوير اساسا وتصميم اللغة على اساس بيئة التطوير بالنسبة لهم جنون

ولكن طريقة التصميم التى اقصدها لاتستهدف هذه النوعية اساسا (اغلبها مبرمجين ASM و C ) يكفيهم Notepad لكتابة الكود المنخفض المستوى

الامر الذى تقصده اخى سنان للاسف موجود فى لغات اخرى لم اكن اتوقع بها ذلك

ماذا تقول فى لغة Python وهى التى توصف فى الكثير من المنتديات بانها ال Basic فى هذا العصر

هى لغة رائعة بلا شك (وانا استخدمها بشكل عملى فى انجاز بعض الامور ) ولكن اتعجب فيها للخصائص التالية

1 - Case Sensitive

2 - تعريف ال function قبل استخدامها

3 - استخدام ال tab بدون جمل مثل endif او endwhile او endfor يجعلنى فى مشكلة حول تحديد نوع ال control structure فى الخوارزميات الكبيرة

طبعا حل هذه المشكلة ممكن عن طريق عمل comments فى نهاية كل control structure

لكنه حل غير كامل لان الشائع عدم فعل ذلك مما يجعلك امام شفيرات مصدرية كتبها الاخرين بدون استخدام ال comment الذى يوضح النوع

طبعا يمكن عن طريق اداة خارجية قراءة السورس كود واضافة هذه ال comments له لكن كنت اتمنى لو كانت اللغة توفر ذلك بشكل قياسى

امر اخر غير ال case-sensitive

العنصر الاول فى المصفوفة الذى يكون الرقم 0

كل هذه الامور فى اللغات تجعل الشخص يشعر بانه ال Abstraction الذى توفره اللغة متاثر بالالة Machine على مستوى الامور البسيطة التى يمكن تجنبها

من الجميل فى لغات xbase مثل Clipper و VFP و Harbour ان هذه اللغات

1 - Not Case Sensitive

2 - لاتحتاج لتعريف الاجراء قبل استخدامه ( يمكن ان يكون فى اى مكان فى البرنامج) وتستخدمه بشكل مباشر

3 - العنصر الاول فى المصفوفة هو رقم 1

وهناك الكثير من الامور الاخرى التى لايتسع المجال لها

كل مايمكننى قوله انها لغات صممت من اجل البساطة

لكن الان نحن لسنا فى عصر هذه اللغات نحن فى عصر ال Java و لغات ال .NET و ال ++C

بالنسبة للمستقبل والله اعلم به .... اراه فى ال Visual Programming Langauges

التى ستريحنا من جميع هذه الامور اساسا

كمثال متطور اقترح الاطلاع على Tersus وهو Visual Programming Langauge حديثة ومتطورة لتطبيقات الويب والموبايل

http://www.tersus.com/

وهو free-open source

طبعا ماذكرته اراء خاصة قد يتفق معها البعض ووارد جدا ان يختلف معها الاخرين

كل شخص يختار مايناسبه حسب رؤيته

والله الموفق

شكرا لك محمود على ردك المفصل ...

وضحت انت نقاط كثيره .. ومهمة ..

لكن في مسالة ان المصفوفة تبدأ بالرقم ( 0 ) فانا لست معك ..لانني لا اعتبرها مشكلة بحد ذاتها

لا اعتقد بان هنالك فرق بين 0 او 1 من ناحية البداية .. فهذه كلها فهرسة ..

لكن بالنسبة لحالة الاحرف والفائدتين التي ذكرتها انت هي من العهد الماضي .. عهد الرام 8كيلو والسرعة المتواضعه ..

اما الان لا يوجد من يهتم بها على حد علمي ..

اي ان السرعة لا اعتقد انها ستتاثر بمسألة تحويل الكبير الى صغير او العكس .. فمثلا وكمثال شائع جدا بيئة الفيجول بيسك بصورة عامة تقوم بالتحويل اثناء كتابة الكود Design Time ..

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

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

وضع #C كلغة من عائلة لغات الC يجعلها الى حد كبير مرغمة على ابقاء بعض الخصائص الأساسية لهذه اللغة مثل الCase Sensitivity و Semi Colon و غيرها من الخصائص التي تجعل اللغة تنتمي لهذه العائلة, و تشترك في هذا كل هذه اللغات

#C

Java

Javascript

D

كما أن الCase Sensitivity تحافظ على مقروئية الكود بشكل كبير, فلا يمكنك أن تكتب اسم المتغير بعشرين طريقة مختلفة في البرنامج, مما قد يجعل الكود "ملخبط"

و عليكم السلام,

كون اللغة case-sensitive أم لا هو قرار لا يؤثر في اللغة بأي شكل من الأشكال برأيي, لأنه يتبع تفضيل منشأ اللغة نفسها. حتى من ناحية سرعة الـ Implementation فإن ذلك لا يذكر, مجرد insensitive comparison في مرحلة الـ Lexical Parsing!

أما كون المصفوفة تبدأ من صفر أم من واحد, فإن القرار مهم. في البداية كان الجميع يعتقد أن هذا الأمر يتبع تفضيل صاحب اللغة, و لكن Dijkstra له رأي آخر: Why numbering should start at zero

السلام عليكم جميعا ..

يعطيكم العافية يااارب..

أذكر عندما كنت بالجامعة كنا نأخذ محاضرات للغة C# فسألت الأستاذ سؤالا احتار هو في اجابته .. وهو نفس سؤال الأخ ..

فأجابني جوابين :

1- للزيادة في عدد المتغيرات الممكنة ...

2-لترتيب الكود وتسهيل قرائته ..

في ذلك الوقت لم أقتنع كثيرا بأجابة الأستاذ حقيقة .

ولكن عندما بدأت بكتابة البرامج والأكواد بنفسي وجدت أن Case-sensitive لها دور كبير في ترتيب وسهولة قراؤة الكود ..

يسلمو جميعا ..

motamayez كتب:

كما أن الCase Sensitivity تحافظ على مقروئية الكود بشكل كبير, فلا يمكنك أن تكتب اسم المتغير بعشرين طريقة مختلفة في البرنامج, مما قد يجعل الكود "ملخبط"

لكن

EmpName

empName

empname

EMPName

.

.

.

.

.

كيف يمكن التمييز بينها ؟؟؟

اذا كان الرد هو باستخدام اسم واحد فقط للمتغير والباقي لا داعي له .. هنا ساقول اذا لماذا وجدت هذه المسألة اصلا في حين ان الافضل ان اختار اسما واحدا ؟؟

الم يصبح الكود الاعلى "ملخبط" ؟

اقتباس

EmpName

empName

empname

EMPName

الأربعة شكلهم مزعج انا افضل اني اقرا طوال البرنامج emp_name :D بدلا من الكاتب الحيران طوال الوقت

كذلك نظام التشغيل لو نظرت فلو عندك عدة ملفات file غير FilE غير FILE فهيعتبرهم مختلفين لأنهم فعلا مختلفين بغض النظر هل فعلا انت بتنشئ ملفات بالشكل دا او لأ!؟

اقتباس

ماذا تقول فى لغة Python وهى التى توصف فى الكثير من المنتديات بانها ال Basic فى هذا العصر

هى لغة رائعة بلا شك (وانا استخدمها بشكل عملى فى انجاز بعض الامور ) ولكن اتعجب فيها للخصائص التالية

1 - Case Sensitive

2 - تعريف ال function قبل استخدامها

3 - استخدام ال tab بدون جمل مثل endif او endwhile او endfor يجعلنى فى مشكلة حول تحديد نوع ال control structure فى الخوارزميات الكبيرة

طبعا حل هذه المشكلة ممكن عن طريق عمل comments فى نهاية كل control structure

لكنه حل غير كامل لان الشائع عدم فعل ذلك مما يجعلك امام شفيرات مصدرية كتبها الاخرين بدون استخدام ال comment الذى يوضح النوع

طبعا يمكن عن طريق اداة خارجية قراءة السورس كود واضافة هذه ال comments له لكن كنت اتمنى لو كانت اللغة توفر ذلك بشكل قياسى

1- لايوجد داعي للعجب للحساسية من الأحرف! فسي وسي++ وجافا كذلك مش شئ غريب!

2- وهل المفترض ان يستخدم شئ قبل تعريفه!؟

3- قطعا لا .. التنظيم بإستخدام ال indentations رائع جدا و"بيفرض" درجة وضوح كبيرة في الكود (بعكس الناس اللي يفرق معها { وتلاقي الكود متاهات!!)وهو الأقرب لطبيعة الإنسان

اقتباس

- لايوجد داعي للعجب للحساسية من الأحرف! فسي وسي++ وجافا كذلك مش شئ غريب!

نعم صحيح مش شىء غريب على لغات البرمجة

لكنى تعجبت لان Python تدرج ضمن اللغات السهلة التى لاتربك من يتعلمها بدون خلفية سابقة عن البرمجة

فسطر واحد يكفى لعمل برنامج hello world بدون الحاجة لتعريف function او class

والشخص العادي الذى ليس له خلفية سابقة عن البرمجة يصدمه شىء مثل Case-Sensitive

اقتباس

2- وهل المفترض ان يستخدم شئ قبل تعريفه!؟

هذا هو الطبيعى :) عند قراءة الكود :)

نحن نبدا فى قراءة التطبيقات بقراءة اول دالة رئيسة فى التطبيق

والتى بدورها تستدعى دوال اخرى

هذه الدوال تكون معرفة فى الاسفل (فى نفس الملف) او فى ملفات اخرى

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

ولان تعريف الدالة قبل استخدامها يعتبر فعلا مشكلة

قامت لغة C بتقديم حل نسبى لها من خلال عمل ال Function prototype فقط قبل استخدام الدالة

فى حين تكون الدالة فعليا مع الكود الخاص بها فى اى مكان (فوق ... تحت .... وراء الجدار .... تحت الطاولة ... مش مشكلة :) )

فى لغات مثل Clipper و Harbour و VFP التى تنتمى لعائلة xBase .... ضع الدالة فى اى مكان واستخدمها مباشرة لايوجد مشكلة

المترجم يقوم بالمرور على الشفيرة المصدرية والتعرف على الدوال الموجودة بها قبل ان يصدر تحذير باستخدام دالة غير موجودة

لكن اللغات التى لاتدعم ذلك يكون هدفها اساسا اداء المترجم Performance

اقتباس

- قطعا لا .. التنظيم بإستخدام ال indentations رائع جدا و"بيفرض" درجة وضوح كبيرة في الكود (بعكس الناس اللي يفرق معها { وتلاقي الكود متاهات!!)وهو الأقرب لطبيعة الإنسان

انا مع ال indentations لتنظيم الكود ... وليس هذا ما اعترض عليه

ما اعترض عليه هو حذف نهاية ال Block التى تحدد نوعه مثل EndIF او EndFor او EndWhile

ان استخدام الاثنين معا هو الذى يسهل تنظيم الكود وقراءته واستيعابه

لكن ال indentation فقط يعطى عبء عند استيعاب الخوارزميات الكبيرة والمعقدة التى تشتمل الكثير من جمل التحكم والكثير من العمليات بداخلها

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

والله الموفق

اقتباس

الأربعة شكلهم مزعج انا افضل اني اقرا طوال البرنامج emp_name بدلا من الكاتب الحيران طوال الوقت

جميل جدا .. هذا يحل المشكلة بالنسبة للاشخاص الذين يعتبروها مشكلة ..

ولكن ايضا ماذا ستفعل الان ...

Emp_Name

Emp_name

emp_Name

.

.

.

----------------------------

اقتباس

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

@محمود ...

انت دخلت مع من ؟؟

احمد يوسف = بايثون ( خبير )

خالد الشايع = سي++ ( خبير )

محمود فايد = عضو مميز ( فقط )

سنان محمد صالح = عضو شرف ( احمر اللون + فقط )

:lol: :lol:

اقتباس

ولان تعريف الدالة قبل استخدامها يعتبر فعلا مشكلة

قامت لغة C بتقديم حل نسبى لها من خلال عمل ال Function prototype فقط قبل استخدام الدالة

شخصيا افضل ان اكتب كل الدوال وانتهي منها قبل كتابة main .. وبعد الانتها ء من الدوال ارجع واضيف ما اريد اضافته ..

وكل شخص له اسلوبه ..

اقتباس

@محمود ...

انت دخلت مع من ؟؟

احمد يوسف = بايثون ( خبير )

خالد الشايع = سي++ ( خبير )

محمود فايد = عضو مميز ( فقط )

سنان محمد صالح = عضو شرف ( احمر اللون + فقط )

من الجميل اختلاف الخبرات ووجهات النظر وهنا تكمن الفائدة :)

والله الموفق

السهولة لاعلاقة لها بالحساسية تجاه الأحرف من قريب أو من بعيد ولكن تعني مدى وضوح الكود وقابليته للقراءة

بايثون حددت لنا مجموعة من الأساليب في الكتابة للوصول لأعلى وضوح ومقروئية في pep-8

http://www.python.org/dev/peps/pep-0008/

اقتباس

هذا هو الطبيعى :) عند قراءة الكود :)

إذا انت تتكلم عن القراءة وليست الإستخدام فتتبع مسار البرنامج من خلال القراءة غير كتابته فلايوجد منطق بإستخدام كود لايوجد (شئ غير منطقي!!)

اقتباس

لكن اللغات التى لاتدعم ذلك يكون هدفها اساسا اداء المترجم Performance

إستغناء بايثون ولغات اخرى عنها لم يحسن الأداء

اقتباس

انا مع ال indentations لتنظيم الكود ... وليس هذا ما اعترض عليه

ما اعترض عليه هو حذف نهاية ال Block التى تحدد نوعه مثل EndIF او EndFor او EndWhile

ان استخدام الاثنين معا هو الذى يسهل تنظيم الكود وقراءته واستيعابه

ممكن نتجادل كثيرا ولكن لايوجد رأي يرجح .. فمثلا أرى ان طبيعة الإنسان تميل لل indentations للتنظيم (وللblocks) ولاحاجة ل } ولا إلى كلمات ختامية ك ENDWHILE او ENDFOR

اقتباس

جميل جدا .. هذا يحل المشكلة بالنسبة للاشخاص الذين يعتبروها مشكلة ..

ولكن ايضا ماذا ستفعل الان ...

Emp_Name

Emp_name

emp_Name

أي واحد طالما هيفضل "متثبت" طوال الكود!! يمكن لوقابلت واحد بيغير شكل اسم المتغير طوال البرنامج اروح اطير رقبته :D

*في لغات بتستخدم الحروف الكبيرة للثوابت!

ادي كود خيالي بسيط للمبتدأين :D

MY_VAR1=1
FOr I iN rANge(MY_var1, My_2ndVAR()) dO
	bEGIN 
		puTStrLn("I:", I) 
	END

dEFINE FUNCTION putMAnyLines(ARr<StRiNG> LINes) do
	BEGIN
		foreACH(lINE IN lineS) do
			beGIN
				pUTstRLn(LINE)
			END
	enD

ملاحظة my_2NDvaR المفترض انه دالة ستعرف لاحقا :D

اقتباس

يمكن لوقابلت واحد بيغير شكل اسم المتغير طوال البرنامج اروح اطير رقبته

احمد على هذا الكود الذي ارفقته انت .. انا اللي حا اطير رقبتك :mad:

احتاج لمرجعين حتى افهم الدالة ..

هذا هو احد اشكال الـ Readability .. فهي مشكلة كبيرة بالنسبة لاي كود مكتوب يحتاج مبرمج اخر لقرائته ..

السلام عليكم.

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

مثال: عندما كنت أتعلم لغة Python بالتجربة قبل قراءة الكثير، توقعت أن تكون كلمة true عبارة عن كلمة محجوزة، و لكنها كانت عبارة عن ثابت، و الثوابت تبدأ بحرف كبير أو capital في Python و لغات أخرى.. بينما في Ruby، كلمة true التي يبدو أنها كلمة محجوزة في اللغة تكتب بالأحرف الصغيرة، و لا يمكن أن تكتب True!

النقطة هي لماذا قد أريد أن يكون لدي ثابت باسم True، و متغير باسم true، و ثابت آخر باسم TRUE، و ما شابه ذلك، هذه هي اللامقروئية بعينها! الأمر ليس في كتابة true و TrUe و جميع الأشكال المختلفة للكلمة، و إنما على الأقل true و True و TRUE!!!

شكرًا.

هههههههههههههههه شفت بقى المعاناة اللي اقصدها :D

مش لوكنا ضربنا المثال من الأول كان بانت القصة :P

اقتباس

مثال: عندما كنت أتعلم لغة Python بالتجربة قبل قراءة الكثير، توقعت أن تكون كلمة true عبارة عن كلمة محجوزة، و لكنها كانت عبارة عن ثابت، و الثوابت تبدأ بحرف كبير أو capital في Python

هذا غير صحيح هوريك مثال صغير

>>> True, False = False, True
>>> if True: "Hello"
... 
>>> if False: "Hello"
... 
'Hello'

حد عمره شاف if False بتتنفذ ياجدعان :D ?

في بايثون القضية مختلفة قليلا لكونها لاتدعم الثوابت أصلا ولكن المتفق عليه أن المبرمج عندما يقرأ الكود هناك عدة أشياء متعارف عليها مثلا المتغير بأحرف كبيرة فالقصد منه هو التعبير عن ثوابت وإذا مسبوق ب _ فالمقصود أنه private ولكنه في الواقع متاح للجميع!!

اقتباس

النقطة هي لماذا قد أريد أن يكون لدي ثابت باسم True، و متغير باسم true، و ثابت آخر باسم TRUE، و ما شابه ذلك، هذه هي اللامقروئية بعينها! الأمر ليس في كتابة true و TrUe و جميع الأشكال المختلفة للكلمة، و إنما على الأقل true و True و TRUE!!!

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

السلام عليكم.

لست متعمقًا في Python، و لا أعرف حتى أبسط الأساسيات! لذلك من الطبيعي ألا أفهم ما هذا الكود؟! كيف تمكنت من أن تسند قيمة لـTrue و False، أيًا كانتا، كلمات محجوزة أو متغيرات أو ثوابت! عندما جربت الكود لم يعمل: و اتضح لي من الخطأ الظاهر أن True و False عبارة عن كلمات محجوزة فعلًا (keywords)، إذن ما سبب الحرف T و لم ليس t؟

استفدت منك كثيرًا أخي الكريم، لم أكن لأصدق بسهولة أن لغة بحجم Python ليس فيها دعم للثوابت! و هذا بالضبط ما فعلته في لغة منشئ المواقع، الثوابت فائدتها بالنسبة لي أنها auto-global فقط، لذلك وفرت متغيرات auto-global عبر علامة مميزة تسبق اسم المتغير، و لا يوجد ثوابت في اللغة، لأنها طبقة تعقيد لا داع لها - بالنسبة لي!

نقطة أخرى، بالنسبة لـTrue و true و TRUE، لا أقصد أن يتم استخدام الثلاثة في كود واحد، و لكن واحد فقط، حسب ما يناسب طريقة المبرمج! هناك أمور أعتقد أن على اللغة تركها للمبرمج. عمومًا، إن كانت اللغة لمنع التداخل أو الأكواد الغريبة أو حتى بلا سبب، كانت حساسة لحالة الأحرف، أو لم تكن، فإنه في رأيي ليس ذلك الشيء الكبير، طالما أن هذا أمر معروف و ثابت في اللغة.

شكرًا.

اقتباس

وإذا مسبوق ب _ فالمقصود أنه private ولكنه في الواقع متاح للجميع!!

يعني python ما فيها private ؟

أتذكر VB6 ، كانوا ينسخون محتويات كلاس أب إلى كلاس إبن ، ويقولون : VB6 تدعم الوراثة ،

مع فارق التشبيه وعظيم الاحترام لبايثون .

=

بالنسبة لحساسية الأحرف، في الغالب اللغات البشعة في السينتاكس و التي تحمل درجة من الغباء هي التي تتجاهلها ،PL/SQL و BASIC مثال .

اقتباس

مع فارق التشبيه وعظيم الاحترام لبايثون

لاحظ انك تهين معشر مبرمجي البيسك عموما .. عبدالله ...

جذاري ..

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

بعد python 3 تحولت لكلمات محجوزة ولكن انا اتحدث عن قبلها بحكم إستخدامي اليومي وحياك الله

اقتباس

يعني python ما فيها private ؟ Posted Image

لا لايتوفر لنا private في بايثون :D

/index.php?showtopic=199648&view=findpost&p=992412

private مفيدة ، لو أردت تطبيق design pattern معين مثل singleton ، لا أتصور طريقة إلا بها !

يعني الهدف من private أن تقلل نسبة الوقوع في الخطأ ، بحماية بياناتك .. تتحكم بقيمة كل متغير ، مثل : student.age = -12 ، مشكلة .

أظن خرجنا عن الموضوع ، آسف :-/ .

اقتباس

أظن خرجنا عن الموضوع ، آسف :-/ .

بالعكس .. هذه معلومة توصلنا لها من شخص متمرس على بايثون .. ولو سبب النقاش الرئيسي لما توضحت لنا معلومات حولها ..

----------------------

الواقع ان مبرمجين بايثون بيمشوا بال convention مش بالفرض فلاقيمة عندهم لكلمة private حتى عندما تتدخل بايثون لتغير الإسم فيمكن تعديها فعامة التصور العام للمبرمج هو إستخدام كل الأكواد الظاهرة (التي لاتحوى _ في بدايتها )

هناك أساليب اخرى مع الكود مثلا عمل ال properties و ال getters/setters للتحكم في ال fields

http://programming-fr34ks.net/wiki/index.php/PythonGuide/OOP_Basics

ولكنها في كل الأحوال ليست بالمشكلة الكبيرة

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

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

الهدف من شيء مثل الـstrong-typing، ليس تعقيد الأمور و تقييدها دون داع، و إنما في رأيي هو لكي يعمل الكود الصحيح و لا يعمل الغير صحيح، فعندما لا تكون اللغة strong-typed لا يمكنك أن تفسر سبب خروج "22" من "2" + "2"، بأنهما نصين، لا تتوقع من اللغة أن تفهم هل هذين رقمان أخطأت و عرضتهما على شكل نصين، أم هما نصان فعلًا و لا دخل لك في كونهما شبيهين بالأرقام، و بالطبع الاعتماد على نوع العنصر الأول في العمليات هو أمر غير مفيد إطلاقًا، و تغيير العلامة من نوع إلى نوع ليس حلًا عمليًا خصوصًا إذا كنت تريد لغة مرنة تتيح المقارنات و العمليات الحسابية بين مصفوفتين مثلًا، أو بين نصين، و بالتأكيد ليس من المتوقع أو الصحيح أن يتم الجمع بين نص و رقم، أو بين مصفوفة و نص - و يجب أن يصدر خطأ في حالة كهذه و عدم الاعتماد على "تخمين" اللغة!

ولكن..

عندما جربت الكود التالي في Python:

"".join([1,2])

للجمع بين عناصر قائمة (أو أيًا كان اسمها)، وجدت خطأً لعلي لم أتوقعه، الخطأ يفيد بعدم توقع اللغة للنوع int في العنصر 0 من القائمة، و لكن عندما جربت الكود المقابل في لغة Ruby، عمل الكود بنجاح، و أخرج لي النص "12"، رغم أن اللغتين strong-typed، و شبيهتين في أشياء عديدة!

أرى أن طريقة Ruby أفضل، بما أنه معروف أن join تعيد نصًا دائمًا، إذن فالتحويل الآلي هنا قد لا يضر، و لكن في مكان آخر قد يضر بالطبع، إن كان نوع النتيجة يختلف بنوع المدخلات!

في آرائكم أي الطريقتين أبسط (علمًا بأني لا أقصد "أسهل")؟ و أيهما أدق و أصح، و يتعامل بالشكل السليم مع الـtype safety؟

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

شكرًا.

ذكرتني بعادة بيرل السيئة في السماح بالجمع بين النص والحرف والتحويل التلقائي وهذا يخالف فلسفة بايثون من حيث Explicit is better than implicit فالكود المنطقي المقروء للمبرمج هو التالي

>>> ",".join(str(x) for x in [1, 2])
'1,2'

او ربما

>>> ",".join(map(str, [1,2]))

اما السماح ب أشياء مثل

"1".2

ونجد الناتج "12" فهذا قمة الغرابة :S

او ناتج جمع يكون 3!!؟

فالبساطة أخي الفاضل لاتعني السهولة على قدر ماتعني شدة الوضوح! واتمنى ان سنان يعذرنا عن الخروج عن الموضوع :)