یعنی این چیزا رو توی PHP میبینم میخوام سرم رو بکوبم به دیوار!

[freeman99]

<?php

$a = '0e462097431906509019562988736854';
$b = '0e830400451993494058024219903391';

if( $a == $b ) echo 'Yes.';
else echo 'No!';

?>

فکر میکنید خروجیش چیه؟
جواب: Yes :متعجب:

آقا اینا دیوانه ان :لبخند:

الان یکی به من میتونه با زبان فصیح بگه منطق این رفتار چیه؟ :لبخندساده:
لطفا رفرنس و منبع انگلیسی و طولانی ندید، دوتا اسم که خودشون اختراع کردن روش گذاشتن نگید (مثل اون type juggling مسخره که قبلا سر یه مورد دیگه بحثش بود!)، خودتون چی فکر میکنید خودتون اگر خوندید فهمیدید نظرتون رو بگید که دلیلش چیه منطقش چیه به چه دردی میخوره چطوری کجا چنین چیزهای مفیده جز اینکه واسه برنامه نویسان دردسر و باگ درست کنه توی کدوم زبان دیگه شما چنین چیزهایی در این حد عجیب و غیرمنتظره دارید!

[prans.info]

چطور شد به این دوتا رشته رسیدی؟

[freeman99]

خودم نرسیدم، یاد نیست تصادفا از کجا رسیدم به یه تاپیک در stackoverflow.com که این موضوع توش با این نمونه کد مطرح شده بود: http://stackoverflow.com/questions/26741378/understanding-php-type-coercion

البته فقط این یکی نیست. از این موارد در PHP که سردرگمی ایجاد کرده زیاده و افراد مختلفی اومدن حتی تصادفا توی برنامشون با اینطور موارد مواجه شدن مطرح کردن.

اینم یه نمونش که درواقع شکل دیگری از همین مورده: http://stackoverflow.com/questions/22140204/why-md5240610708-is-equal-to-md5qnkcdzo

[freeman99]

باز مهندس شهرکی میاد حالا میخواد از PHP دفاع کنه!
هرچند درمورد اون بحث قبلی و type juggling حداقل در یک نکته و تاحدی بنظر خود مهندس هم رفتار PHP غیرمنتظره بود و مشکل داشت (که فکر کنم گفت اینو به منابع رسمیش هم گزارش کرد).

الان من میدونم چی میخواد بگه، میگه این رشته ها چون با عدد شروع میشه تبدیل به عدد کرده هر دو رو. البته هم همینطور و توی اون منبعی که اینو ازش برداشتم همینو نوشته بود و اسمش هم type coersion است. درسته مثلا یه چیزی به اسم type coersion توی زبانهای دیگری هم هست، ولی گول یکسان بودن اسم رو نخورید، چون رفتارها متفاوته و هیچ زبان دیگری مثل PHP اینقدر عجیب و غیرمنتظره عمل نمیکنه و عمرا دو تا رشته مختلف اینطور با هم یکسان تشخیص داده نمیشن!

بعد مهندس میاد میگه شما باید بجای == از === استفاده کنی، ولی اینم باز جواب این سوال نشد و بیشتر پاک کردن صورت مسئله است.
بالاخره منطق همون == چیه چون توی زبانهای دیگه هم که مشابه == و === پی اچ پی رو دارن گفتم که اینطور عمل نمیکنن!
بعدم با این وضعی که من از == میبینم اینقدر غیرقابل پیشبینی و خطرناکه استفاده ازش، یعنی مدام باید دقت خیلی زیادی داشته باشی تا منطق برنامت دچار باگ نشه، که کلا ترجیح میدی اصلا ازش استفاده نکنی و بذاری کنار! یعنی منکه متخصص امنیت هستم بهتون میگم که عملگر == با این وضع بسیار خطرناکه برای امنیت و حتی منی که متخصص امنیت هستم نمیتونم با احساس امنیت ازش استفاده کنم حتی اگر این مسائل و موارد رو میدونم و سعی میکنم حواسم باشه و در جاهایی که فکر میکنم مشکل ساز میشه ازش استفاده نکنم.

آقا به خدا من شاخ درآوردم نمیدونم اینا که PHP رو اینطوری طراحی کردن کیان چه غرضی مرضی دارن شاید یا اینقدر در این زمینه ناشی هستن یا خودسر و از خود راضی هستن چی هستن خلاصه چرا این کارها رو میکنن چه منطقی دارن چه هدفی دارن آخه از این کارها!

هیچ زبانی نمیاد دو متغییر دو طرف عملگر رو که هر دو یک نوع دارن (در اینجا رشته)، برای مقایسه تبدیل به نوع دیگری بکنه!

[freeman99]

بنظر من باید یه کمپینی چیزی برای این مسائلی که در PHP وجود داره راه انداخت! جدی میگم!
توی فکرم فعلا برم در همون stackoverflow و اینا یک تاپیک در مورد ضعفهای طراحی PHP و علتش بزنم.

[prans.info]

<?php
$a = '0e462097431906509019562988736854';
$b = '0e830400451993494058024219903391';
settype($a, "string");
settype($b, "string");
if( $a == $b ) echo 'Yes.';
else echo 'No!';

من فکر میکردم مشکل در تعریف متغیر هست (که درصد اون هم خیلی پایین بود) که ظاهرا اینطوری نیست و مربوط به عملگر == هست :متفکر:

[MMSHFE]

eshpilen اینجا رو ببین:

$a = '0e0';
$b = '0e1';
if( $a == $b ) echo 'Yes.';
else echo 'No!';
جواب باز هم Yes هست. میدونی چرا؟ سورس PHP رو بررسی کردم چون وقتی از == استفاده میکنی بطور پیشفرض میبره تو مود عددی مقایسه میکنه و اونجا، 0 ضربدر هر عددی بشه، حاصل باز هم صفر هست (0e0=0x10^0 و 0e1=0x10^1) و بخاطر همین میگه با هم برابر هستن ولی اگه فرضاً توی همین مود بجای 0 اول (قبل از e) عدد دیگه (مثلاً 1) بگذاری اونوقت میگه No

نمیخوام بگم این رفتار PHP درسته (چون اگه با settype هم نوع متغیرها رو دستی string بگذاریم، دیگه نباید تبدیل نوع کنه ولی باز هم اینکار رو انجام میده). فقط خواستم دلیلش رو بگم که چرا چنین رفتاری داره تا سرتو به دیوار نکوبی. تا اطلاع ثانوی همه جا از === استفاده کنید (مگه اینکه عمداً بخواین تبدیل نوع انجام بشه). توی فریمورکهای بزرگ (مثل Yii) هم همین کار انجام شده و همه جا با === تساوی دو مقدار چک میشه.

[freeman99]

کمپین «مرگ بر PHP» شروع شد: http://stackoverflow.com/questions/28936084/php-a-fractal-of-bad-design
هر روز یک مرگ بر PHP هر روز یک قدم برای نابودی استکبار جهانی :لبخند:

ببین یارو اومده چی گفته:

I wasn't aware PHP was designed. I thought it was just sort of implemented

ترجمه: «من اطلاع نداشتم که PHP طراحی شده بوده. فکر میکردم فقط یک طوری پیاده سازی شده است» :قهقهه:

اون یکی میگه: Because they didn't make any in the first place

ترجمه: «زیر آنها در وهلهء اول هیچ (طراحی ای) نکردند»

:لبخند:

[Veteran]

یعنی واقعا اشپیلن تازه به این موضوع پی بردی ؟ یا نه،باز بیکار شدی دنبال بحث میگردی ؟! :متفکر:

[MMSHFE]

یعنی واقعاً خدا هیچکسی رو بیکار نکنه. تو که اینقدر اهل تحقیق هستی لابد باید متوجه میشدی که نصف بیشتر این مسائل بخاطر گذشتن عدد موردنظر از محدوده PHP_INT_MAX هست. توی نسخه 64 بیتی من چنین مشکلاتی ندیدم و محدوده اعداد و نوع مقایسه هم توی نسخه های بعدی قرار شده عوض بشه. بهرحال هیچ زبانی بی عیب نیست و PHP هم کم و بیش باگهای ریز و درشت زیادی داره ولی امتیاز اصلی اون اینه که اینجور باگها سریع پیدا و رفع میشن. ضمناً توی اون لینک مشکلی که درمورد md5 گفته شده هم بخاطر همون دلیلی هست که توی پست قبلی گفتم. به هش این دو عبارت دقت کنید:

md5('240610708') // 0e462097431906509019562988736854
md5('QNKCDZO') // 0e830400451993494058024219903391
درواقع با مقایسه این دو هش، به همون مسئله قبلی میرسیم که هر دو، بعنوان عدد 0 با هم مقایسه میشن. برای همینه که Hash ها رو حتماً باید با === مقایسه کنید.

[Veteran]

یعنی منکه متخصص امنیت هستم
و حتی منی که متخصص امنیت هستم


:قهقهه::قهقهه::قهقهه:

[MMSHFE]

این جدول رو یه جا ذخیره کنید:

// "===" means that they are identical
// "==" means that they are equal
// "!=" means that they aren't equal.

false null array() 0 "0" 0x0 "0x0" "000" "0000"
false === == == == == == != != !=
null == === == == != == != != !=
array() == == === != != != != != !=
0 == == != === == === == == ==
"0" == != != == === == == == ==
0x0 == == != === == === == == ==
"0x0" != != != == == == === == ==
"000" != != != == == == == === ==
"0000" != != != == == == == == ===

[freeman99]

یعنی واقعاً خدا هیچکسی رو بیکار نکنه. تو که اینقدر اهل تحقیق هستی لابد باید متوجه میشدی که نصف بیشتر این مسائل بخاطر گذشتن عدد موردنظر از محدوده PHP_INT_MAX هست. توی نسخه 64 بیتی من چنین مشکلاتی ندیدم و محدوده اعداد و نوع مقایسه هم توی نسخه های بعدی قرار شده عوض بشه.
محدوده عدد کجا بود! اصولا اصل فلسفه اینکه دوتا رشته رو سرخود برمیداره برای مقایسه به عدد تبدیل میکنه مشکل داره. مثل اینکه شما بخوای آب بخوری بریزی توی قاشق سرریز کنه بعد بخوای قاشق بزرگتری بسازی یا بگی خب ملاقه رو واسه همین کارها ساختن دیگه :لبخند:
ما اصلا نمیخوایم وارد جزییات بیهوده قدمهای بشیم وقتی در قدم اول مشکل وجود داره. اصل کار، منطق اولیه، طراحی اولیه غلطه و به همین دلیل شما توی هیچ زبان دیگری مشابه چنین چیزهایی رو در این حد نمیبینید. واقعا تعجب میکنم درک و پذیرفتن این مسئله اینقدر سخته یعنی یا باز میخواید توجیه کنید و فکر میکنید طراحان PHP ممکن نیست خطاهای ناشیانه طراحی مرتکب شده باشن! البته برای من هم عجیبه که کسانی که اینقدر در توسعه PHP موفق بودن و طبیعتا برنامه نویسان قوی ای هستن چطور اینقدر در طراحی ضعیف عمل میکنن، ولی شواهد بنظر من بقدر کافی واضحه که در غلط بودن این طراحی ها شک خیلی کمتری دارم.

مورد قبلی هم یادته که اشکال این بود که در یک مقایسه PHP میامد و مقداری رو که بصورت صریح (literal) مشخص شده بود تبدیل به نوع طرف دیگر که بصورت غیرصریح بود میکرد. یعنی دقیقا عکس چیزی که ازنظر منطقی درست بنظر میرسه!


بهرحال هیچ زبانی بی عیب نیست و PHP هم کم و بیش باگهای ریز و درشت زیادی داره
شدت ناشیانه بودن خطاهای طراحی در PHP رو در هیچ زبانی هیچ روایتی تاحالا ندیدم! موضوع اینه. شدت ناشیانه بودن که برای یک زبان اینقدر پرکاربرد و مهمی واقعا عجیب و غیرقابل قبوله. اشتباه وقتی قابل قبوله که با سطح کلی کاربرد و اهمیت کلی اون زبان و سطحی که برای صلاحیت طراحانش قاعدتا لازم بنظر میاد هماهنگی کافی داشته باشه. ضمنا اینا خطاهای طراحی هستن و نه باگ. شاید باگ هم بتونیم بگیم ولی باگ در این مورد اصطلاح مبهم کننده و گمراه کننده ای است. باگ معمولا به چیزی میگن که ازش غفلت شده و ناآگاهانه بوده که برای همه متخصصان در اون سطح میتونه پیش بیاد، ولی اینطور خطاهای طراحی نشانهء ضعف جدی در تخصص طراحی زبان و مسائل درگیر در اون هستن. یعنی متوجه میشی که سوادشون در این زمینه مشکل داره و مسئله فقط غفلت و فراموشی انسانی عادی نمیتونه باشه، یا مشکل بهرصورت از یه جای دیگس. مثل اینکه اگر شما توی برنامهء من یه چیز خیلی ناشیانه ببینی که مشخصه که صرف خطای انسانی عادی نیست و ناشی از کم سوادی من بوده (یا شاید مثلا عجله من در کد نوشتن و صرفا سرهم کردن یه چیزی و جدی نگرفتن اون قضیه).



md5('240610708') // 0e462097431906509019562988736854
md5('QNKCDZO') // 0e830400451993494058024219903391
درواقع با مقایسه این دو هش، به همون مسئله قبلی میرسیم که هر دو، بعنوان عدد 0 با هم مقایسه میشن. برای همینه که Hash ها رو حتماً باید با === مقایسه کنید.
بله اینو که میدونم چون خودم سرچ کردم این هش ها رو و یکی از لینک هایی که گذاشتم هم دقیقا کد و نمایش این مسئله است.
دقیقا خطر این مسئله در همینطور موارد کاملا روشن میشه که یه چیزی به اهمیت امنیتی مقایسهء دو هش ممکنه به این شکل اشتباه عمل کنه. حالا شما هرچی بگو با === مقایسه کنیم، گفتم که این باعث نمیشه اون رفتار == درست تلقی بشه و شما صورت مسئله رو پاک کردید، چون در زبانهای دیگه با مشابه همون == هم خطری پیش نمیاد وقتی دوتا هش که هردو رشته هستن رو مقایسه میکنید، و انتظار منطقی غیر از این هم نیست. اینکه شما میگی از === استفاده کنیم به اصطلاح مثلا یک workaround است، نه توجیه بدون اشکال بودن رفتار ==.

[MMSHFE]

من نگفتم اون رفتار == درسته. میگم PHP از سالها قبل راه حلش رو داشته: ===

هنوز هم معتقدم رفتار == اشتباهه و نباید اینطوری کار کنه ولی مسئله اینه که این موضوع رو خیلی وقته حرفه ایهای این زبان فهمیدن و توی هیچ اسکریپت پیشرفته ای مقایسه ها با == انجام نمیشه مگه اینکه واقعاً تبدیل نوع رو لازم داشتن و مطالعه کردن که تبدیل نوع چطور داره انجام میشه. اینجاست که بیشتر به عمل این موضوع که «برتری در برنامه نویسه نه زبان برنامه نویسی» پی میبریم. اینجاست که متوجه میشیم چرا میگن اگه میخوای حرفه ای بشی، سورس کدهای حرفه ای رو مطالعه کن و اینجاست که میفهمیم مزیت اصلی Open Source بودن چیه (حتی اگه هیچوقت نخوایم کد نوشته شده رو تغییر بدیم).

طراحان PHP هم هیچ کدوم خدای برنامه نویسی نبودن. تازه در همین حدی هم که توی دنیا داره استفاده میشه، باز هم باید بهشون تبریک گفت که خطاهاشون در حدی نبوده که فاجعه به بار بیاد یا حداقل راههای دررو رو از قبل گذاشتن (مثل وجود همین === و ==! درکنار == و =! یا موارد مشابه دیگه). بهرحال تیم تولید PHP هم به مرور تغییر کرده و هم افراد حرفه ای تر واردش شدن و هم سواد افراد قبلی افزایش پیدا کرده و توی قابلیتهای جدید میبینیم که آنچنان مثل گذشته ناشیانه رفتار نمیشه.

بهرحال من شخصاً این روند رو بیشتر دوست دارم تا روال کاری مایکروسافت و امثال اون که سالهاست همچنان از همون سوراخهای قبلی گزیده میشن.

[freeman99]

این جدول رو یه جا ذخیره کنید:

// "===" means that they are identical
// "==" means that they are equal
// "!=" means that they aren't equal.

false null array() 0 "0" 0x0 "0x0" "000" "0000"
false === == == == == == != != !=
null == === == == != == != != !=
array() == == === != != != != != !=
0 == == != === == === == == ==
"0" == != != == === == == == ==
0x0 == == != === == === == == ==
"0x0" != != != == == == === == ==
"000" != != != == == == == === ==
"0000" != != != == == == == == ===

جان؟ یعنی خب که چی؟
یعنی هر رفتاری میخوان از خودشون تعریف کنن، یک میدان مین گذاری شده درست کنن توی زبان برنامه نویسی، بعد یک جدول تهیه کنن بگن همیشه هر قدم که میخواید بردارید این جدول رو چک کنید (یا خوب حفظ کرده باشید و دائما توی ذهنتون نسبت بهش حضور ذهن داشته باشید) و اینطوری خطر اینکه پا روی مین بذارید به صفر که نه، ولی به حداقل میرسه!! یه نقشه بدن بگن این نقشهء راه امن در میدان مین! در درجهء اول ما باید بپرسیم خب اصلا در وهلهء اول برای چی این میدان مین رو در مسیر ما درست ایجاد کردید؟ توجیهش چیه؟ سودش که بیشتر از ضرر و خطرش باشه چیه؟ منطقش چیه؟ چرا دیگران نکردن و اگر نکردن آیا اونا اشتباه کردن و شما به ما کمک کردید با این کار و این کارتون یه پیشرفت در تسهیل و بالا بردن کیفیت برنامه نویسی محسوب میشه؟
این منطق مسخره است!
اصولا چیزی که منطق درستی نداره یا منطقش ضروری نیست و در مقابل از نظر یادگیری هزینه داره و از نظر کاربردی بیش از اونکه سود داشته باشه ریسک و هزینه داره، طراحی درستی نیست.
درسته در زبانهای دیگر هم بعضی موارد کمی عجیب و یا چیزهایی که باید حفظ کرد و مد نظر داشت وجود دارن، ولی اونا منطقشون و ضرورت یا اهمیت و فایده هاشون قابل درک و قانع کننده است و کسی ایراد زیادی بهشون نداره، و هیچکدام اینقدر نیاز به دقت و حفظ کردن در چنین جزییات و در قدم به قدم عملیات های پایه که از دید منطقی و برنامه نویسی روشن و منطقی تلقی میشن ندارن. اون چیزی که برنامه نویسان اغلب هدفشون است و انتظار منطقی ای که از رفتار کدها میره، برنامه نویسان میتونن روش اتکا کنن و نیازی به جدول و نقشهء راه و این همه جزییات و دقت نداره! مثل اینکه وقتی به یکی میگی تشنمه برام آب بیار، داری توی لیوان بریزه بیاره، نه توی قاشق، نه توی ملاقه، و نه توی قابلمه! نهایت توی کاسه میریزه میاره که باوجود غیرمعمول بودن اما مشکل بزرگی نداره.

[MMSHFE]

نه عزیزم این جدول رو هم خودم برحسب تجربه به مرور درست کردم. همین هم توی Manual نیست. خواستم کمکی کرده باشم :چشمک: دوست نداری برو همچنان Procedural کد بنویس :لبخند:

[freeman99]

توی هیچ اسکریپت پیشرفته ای مقایسه ها با == انجام نمیشه
شاید اینکه میگی درست باشه، ولی این بازم رفتار متفاوت و غیرمنتظره == در PHP رو توجیه نمیکنه.
الان کار اینها مثل اینه که یک چاقو ساختن که هر دو لبهء اون تیزه، دستهء اونم خیلی کوتاهه و در استفاده ازش باید خیلی دقت داشته باشید که دستتون نلغزه و زخمی نشید. یعنی خیلی بیشتر از چاقوهای دیگر، و بدون اینکه دلیل منطقی کافی داشته باشه که چرا اصولا باید چنین چاقویی ساخته بشه و سودش در چیه آیا از مزیتش بیشتره.
حالا شما میگی خب واسه فلان کارها از چاقوهای دیگری یا اصلا از روش دیگری که چاقو توش نیست برای انجام استفاده کنید. این درست که کاری رو که میشه بدون چاقو هم تقریبا با همون راحتی انجام داد، بدون چاقو انجام بدیم که خطرش کمتر باشه، چون بهرحال حتی چاقوی معمولی هم خطر آسیب رو داره. بقول یارو کار از محکم کاری و احتیاط عیب نمیکنه.


برتری در برنامه نویسه نه زبان برنامه نویسی
برتری زبان برنامه نویسی هم اگر باشه به برنامه نویس کمک میکنه و طبیعتا حداقل کارش رو راحتتر میکنه و یکسری از باگها و خطاهای انسانی که حتی برترین و باتجربه ترین برنامه نویسان هم ممکنه مرتکب بشن کاهش پیدا میکنن.
بهرحال این بحث انحرافیه. ما داریم در مورد طراحی درست و غلط خود زبان بحث میکنیم. بله بعد از این همه غافلگیر شدن و تجربه و خسارت آدم متوجه میشه و با دقت و دانش خودش میتونه جبران کنه، ولی طراحی زبان خودش یه اصولی داره و تخصص خودش رو میخواد.


خطاهاشون در حدی نبوده که فاجعه به بار بیاد
مطمئنی؟
فاجعه یعنی چی مثلا؟
شاید خیلی از نفوذها و خیلی از خسارت ها بر سر همین موارد پیش آمده تاحالا. مسلما هزاران برنامه و سایت به همین دلیل دچار ضعف و ریسک هستن.
بیشتر از این میخواستن چه گندی ببار بیارن مثلا؟
آیا رجیستر گلوبالز موجب خسارت های امنیتی گسترده نبود؟ موجب اتلاف منابع و وقت و انرژی زیادی نبود؟


حداقل راههای دررو رو از قبل گذاشتن (مثل وجود همین === و ==! درکنار == و =! یا موارد مشابه دیگه
اینا رو گذاشتن باید میذاشتن شاهکاری نکردن چون در موارد روشن و منطقی تری و به دلایل دیگری لازم هستن و در زبانهای مشابه دیگر هم به همون دلایل وجود دارن. یجور میگی انگار وجود این آلترناتیوها ثابت میکنه که این افراد از تبعات این موارد خاص از طراحی خودشون کاملا آگاه بودن، در حالیکه اصلا اینطور نیست و چنین چیزی ثابت نمیشه چون حتی بدون این موارد هم باید این عملگرهای مکمل رو میذاشتن به دلیل کاربردهای روشن و متداول که در زبانهای دیگر هم هست و همه میدونن!


بهرحال تیم تولید PHP هم به مرور تغییر کرده و هم افراد حرفه ای تر واردش شدن و هم سواد افراد قبلی افزایش پیدا کرده و توی قابلیتهای جدید میبینیم که آنچنان مثل گذشته ناشیانه رفتار نمیشه.

امیدوارم اینطور باشه.


بهرحال من شخصاً این روند رو بیشتر دوست دارم تا روال کاری مایکروسافت و امثال اون که سالهاست همچنان از همون سوراخهای قبلی گزیده میشن.
بنظرم حتی بین پروژه های بازمتن هم PHP در این زمینه یک شاهکاره! اگر اولین نباشه ولی یکی از اولین هاست! (در میزان خطا و ناشی گری در این زمینه)
بهرحال ما این موارد رو مطرح میکنیم چون باید مطرح کنیم. اگر مطرح نکنیم سودی نداره که ضرر هم داره. با مطرح کردن هم خودمون در این امور واردتر و آگاه تر و مطمئن تر و ماهرتر میشیم و هم دیگران که طراحان PHP هم جزوشون هستن و این میتونه باعث بهتر شدن چیزها در آینده برای همه بشه و از تکرار اشتباهات جلوگیری بشه. منکه بارها گفتم با وجود این مسائل PHP رو در کل زبان واقعا مفید و دوست داشتنی ارزیابی میکنم. البته یک دلیلش اینکه آلترناتیو قابل قبول دیگری دقیقا در این حیطه وجود نداره، ولی بهرحال اینم که اشکال PHP نیست و بقول معروف بین بدتر (نبودن یک ابزار اینقدر fit برای این حیطهء خاص) و بد طبیعتا بد بهتره! یعنی وجود PHP از نبودنش بهتره.

[freeman99]

نه عزیزم این جدول رو هم خودم برحسب تجربه به مرور درست کردم. همین هم توی Manual نیست. خواستم کمکی کرده باشم :چشمک: دوست نداری برو همچنان Procedural کد بنویس :لبخند:
حالا این بحث برنامه نویسی Procedural چه ربطی داشت؟
برای من این کار اشکالی نداره چون من دارم واسه خودم با شرایط خودم برنامه مینویسم نه اینکه یک زبان برنامه نویسی معروف و محبوب طراحی و پیاده سازی کنم برای این همه کاربرد و آدم، و کار تجاری و سفارشی واسه کسی هم نمیکنم که مسئول کیفیت و عواقبش باشم بگید ربطی به پول گرفتن و مسئولیت قبول کردن و ادعا کردن و وجدان کاری داره. ضمنا من ادعایی ندارم و بارها گفتم هنوز در این زمینه در حال تجربه و پیشرفت به روش عملی بر اساس نیاز هستم و برنامم هم هنوز در حدی که یک برنامهء انتشاری نهایی برای استفاده عموم و پشتیبانی و توسعه جدی باید باشه نمیدونم. هم من و هم برنامم هنوز در حال تکامل هستیم در این زمینه. اینطوری که بر حسب و نیاز و تجربه عملی خودم پیش برم بهینه تر و مفیدتر میدونم. اول میخوام قابلیت هاش رو کامل و اصلاح کنم، بعدش اگر در جریان یا بعدا وقت شد و نیاز عملی دیدم بقیه ابعادش رو هم بهبود میدم که احتمالا شیء گرایی هم جزوشه.
خلاصه من فکر نمیکنم زیاد ربطی داشته باشه. تازه گیریم من هم خودسری و اشتباهات مشابهی با طراحان PHP که ازشون ایراد میگیرم دارم، این میشه مغلطهء «تو هم بدی». یعنی جواب منطق و واقعیت نیست، بلکه صرفا گمراه و پنهان کردن و گریز از صورت مسئلهء دیگری است. تازه من دارم خود مسئله رو از بعد فنی هم بررسی و تحلیل میکنم؛ نیامدم بگم از طراحان PHP طلبکارم! اصلا آقا قبول منم اشتباه دارم، منم مشکل دارم، ولی در این مورد حق با منه و واقعیته و میخوام بررسیش کنم چه اشکالی داره؟ لطفا در زمینهء بحث اصلی اگر نظر و مطلب درخوری دارید بفرمایید.

[MMSHFE]

هیچی شوخی بود. با اینهمه هوش و نبوغت چطور نفهمیدی؟!

[freeman99]

یعنی واقعا اشپیلن تازه به این موضوع پی بردی ؟ یا نه،باز بیکار شدی دنبال بحث میگردی ؟! :متفکر:

:قهقهه::قهقهه::قهقهه:
منظورت از این شکلک ها و حرفها رو متوجه نشدم! میشه دقیقتر توضیح بدی؟
این موضوع هم فکر نمیکنم حتی از برنامه نویسان با تجربه انتظار بره تمام ابعاد و جزییات و اشکال اون رو کاملا از قبل بدونن و از بر باشن و همیشه حضور ذهن داشته باشن. جزییات و اشکال این قضیه زیاده و منکه نتونستم همه رو از قبل کامل و دقیق بخونم و حفظ کنم (بخصوص که حفظ کردن چیزهایی که منطق و اصول منظم و هماهنگ و سازگار و قابل درکی ندارن خیلی سخت تره). توی نت هم این همه آدم میان که اکثرشون غافلگیر شدن و برنامشون طبق انتظار عمل نکرده و باگ پیدا کرده به این خاطر، همش تقصیر اونا نیست!
در همین فروم هم مطمئن باش خیلی از کاربران اولین باره خیلی از این موارد رو میبینن یا متوجه میشن (اونقدری که باید در برنامه نویسی PHP متوجه بشن و حواسشون جمع باشه). پس این میتونه بحث و اطلاع رسانی مفیدی باشه. ضمنا PHP با طراحی غلط خودش داره آموزش غلطی از منطق و تمهیدات برنامه نویسی به برنامه نویسان مبتدی میده که بحث ما برای اینم مفیده، وگرنه یک مبتدی ممکنه همین سهل انگاری ها و شیرین کاری ها و هوشمند بازیهای بیش از حد براش توی برنامه نویسی هم الگو بشه و بگه اگر من فلان کار رو میکنم خب در PHP هم فلان کار رو کردن پس اشکالی نداره و اینقدر نیاز به دقت و طراحی اصولی نیست و اصلا خیلی خوبه و از نظر اصول هیچ مشکلی نداره. طرف اگر این همه انتقاد و استدلال و نظرهای مخالف رو ببینه و بفهمه که حتما یا شاید طراحی PHP مشکل داشته باشه، چیزهای مفیدی یاد گرفته که در روش تحلیل و طراحی خودش در برنامه نویسی هم میتونه خیلی مفید باشه. مثلا اینکه بیش از حد نباید پشتک بالانس زد و شیرین کاری و سرخودبازی درآورد، درواقع در تاریخ برنامه نویسی بارها به شکلهای مختلف نمود داشته و ثابت شده و توی منابع هم آمده و افراد زیادی بهش اشاره کردن، ولی برای یک مبتدی خیلی راحته که در این زمینه ناآگاه باشه و اشتباه و افراط کنه (خیلی وقتا به خیال خودش شاهکار هم میکنه و کد نبوغ آمیز مینویسه).
اصلا توی دوره های برنامه نویسی PHP بنظر من باید یک بخش برای همین موارد کنار بذارن و اینطور نباشه طرف بعدا خودش تصادفا برخورد کنه و متوجه این چیزا بشه یا توی نت پیدا کنه و بخونه. چون واقعا این موارد غیرمنتظره و مهم هستن و باید جزیی ضروری از آموزش و سرفصل های زبان PHP تلقی بشن!

[freeman99]

هیچی شوخی بود. با اینهمه هوش و نبوغت چطور نفهمیدی؟!
خب شوخی باشه اشکالی نداره. بهرحال شوخی زیاد به درد کسی نمیخوره. من باید تمام تفاسیر و معنای احتمالی هم شما و هم خوانندگان دیگر رو درنظر بگیرم و چیزی که مفیدتره رفع ابهام کردن روشن و دقیق در این باب است.
متاسفانه بعضا از طرف شما و اکثرا از طرف دیگران در اینطور مباحث برخورد صحیح و سازنده ای نمیشه. مثل کاربر دیگر که مسخره میکنه و میگه علافی و این مباحث رو پیش پا افتاده و کم ارزش و بی فایده میدونه، ولی منکه خودم شخصا با این بحثها واقعا روشن تر و کاراتر میشم و برای دیگران هم اهمیت و کاربرد کافی درش میبینم.
برنامه نویسی فقط این نیست که دوتا کد و برنامه بنویسی و فقط شیء گرایی نیست، و زندگی هم فقط برنامه نویسی محض و مستقیم نیست، منجمله زندگی همهء برنامه نویسان. بهتره آدم ابهامات رو در زندگیش تاحد ممکن کاهش بده و حل کنه و هرچی از جوانب و موارد دیگر هم آگاهی داشته باشی میتونه بقدر کافی مهم و پرفایده باشه. منکه به تجربهء زندگی به این رسیدم و عقلم هم همیشه تایید کرده! شکی ندارم. ولی شاید بعضی ها اینقدر بینش ندارن در این زمینه ها. البته هم که طرز تفکر و زندگی خیلی ها کلا سطحیه و راضی هم هستن چون خودشون هم آدمهای سطحی هستن. از این آدمها انتظار نمیره آدمهای دقیق و باریک بین و متفاوتی مثل من رو درک کنن. ولی من دارم نتیجه و برتری این خصوصیات رو در زندگیم بطور مستمر تجربه میکنم.

[MMSHFE]

موفق باشی. فقط سعی کن این احساس درونی که داری رو زیاد اینطرف و اونطرف جار نزنی چون مصداق خودشیفتگی میشه. لزومی هم نداره بقیه رو آدمهای سطحی خطاب کنی چون ممکنه تعریفتون از سطح و عمق با هم فرق داشته باشه.

[sairon123]

سلام اقای شهرکی
من تحقیق کردم به تابع Strcmp برخوردم
اگه با این تابع مقایسه کنیم مشکل حل میشه و دیگه نیازی نیست از === استفاده کنیم

[sairon123]

تابعstrcmp () در php دو رشته را با هم مقایسه می کند و به حروف بزرگ و کوچک حساس میباشد
مقادیر بازگشتی تابع عبارتند از :


[*=right]بازگرداندن عدد 0 اگر دو رشته با هم مساوی باشند
[*=right]بازگرداندن عددی کوچک تراز 0 اگر رشته اول از رشته دوم کوچکتر باشد (-1)
[*=right]بازگرداندن عدد بزرگتر تراز 0 اگر رشته اول از رشته دوم بزرگتر باشد(1)



تابع strcasecmp( )
این تابع همانند strcmp می باشد ولی نسبت به حروف حساس نیست (تفاوتی بین حروف کوچک و بزرگ قائل نمی شود).

[prans.info]

سلام اقای شهرکی
من تحقیق کردم به تابع Strcmp برخوردم
اگه با این تابع مقایسه کنیم مشکل حل میشه و دیگه نیازی نیست از === استفاده کنیم

تابعstrcmp () در php دو رشته را با هم مقایسه می کند و به حروف بزرگ و کوچک حساس میباشد
مقادیر بازگشتی تابع عبارتند از :


[*=right]بازگرداندن عدد 0 اگر دو رشته با هم مساوی باشند
[*=right]بازگرداندن عددی کوچک تراز 0 اگر رشته اول از رشته دوم کوچکتر باشد (-1)
[*=right]بازگرداندن عدد بزرگتر تراز 0 اگر رشته اول از رشته دوم بزرگتر باشد(1)



تابع strcasecmp( )
این تابع همانند strcmp می باشد ولی نسبت به حروف حساس نیست (تفاوتی بین حروف کوچک و بزرگ قائل نمی شود).



اینا که نشدند راه حل درست و حسابی باید مشکل خود php حل بشه ، تا حل شدن هم من ترجیح میدم از === بجای strcmp استفاده کنم .
به هر حال ممنون از شما ...

[joker]

این موارد اکثرا مشکلات بی تجربه بودن برنامه نویسهای مبتدی هست که براشون به شکل باگ امنیتی جلوه میکنه. چیزی هم که زیاده برنامه نویس بی تجربه ،،،

اگه کاربرهای کااشف:لبخند: این باگ خطرانگیزناک امنیتی در سایت استک کمی با تجربه تر بودند این مسئله براشون یک مسئله کاملا توضیح داده شده بود. و نتیجه این عملگر نه تنها اصلا براشون تعجب برانگیز نبود بلکه کاملا عادی بود.
http://php.net/manual/en/language.operators.comparison.php

در هر حال اگه با دقت ( حتی بی دقت )داکیومنت php را خونده بودی میدیدی که همون اول به صراحت توضیح داده هر کدوم از این اپراتورکدها وظیفشون و طرز عملکردشون چیه و کجا و چطوری باید استفاده بشن.
تاحالا پیش خودت فکر نکردی این طراحهای php چقدر بیکار بودن که برای مقایسه دو نوع اپراتورکد مختلف نوشتن ؟ بیکارن لابد ، حوصلشون سر رفته بود گفتن بزار ی اپراتور کد دیگه هم برای قشنگی بسازیم :بامزه:
داکیومنتشم میزاریم که ملت نگاهش نکنن!
اینم برا قشنگی نوشتن که شما باگ کشف کنید


<?php
var_dump(0 == "a"); // 0 == 0 -> true
var_dump("1" == "01"); // 1 == 1 -> true
var_dump("10" == "1e1"); // 10 == 10 -> true
var_dump(100 == "1e2"); // 100 == 100 -> true

?>


شما در توسعه یک زبان که تعداد زیادی کاربر داره نمیتونی یهو بیای کلا خاصیتهای یک اپراتورکد پرکاربرد را عوض کنی ، چون عوارض و اشکالاتی که ممکنه در میلیونهانرم افزار بوجود بیاد پیشبینی نشده هست و بار مسئولیتش به عهده ارائه دهنده های نسخه های جدیدتر هست.
اونها که گتره ای عمل نمیکنند ، مسئولیت پذیر هستند و عاقل و با تجربه نه مبتدی و دم دمی مزاج :)


حالا ی تازه کار از روی عادت فقط بنویسه (==) دلیل بر بیسوادی طراحان این زبان قدرتمند نیست.

پیوست 0:
شما php کار نکن ، سردرد ناشی از ضربه به دیوار خوب میشه ایشالا ( اگه هنوز ضربه مغزی نشدی و حواست سرجاشه توروخدا هک مون نکنی :قهقهه: )

پیوست 1: این مسئله در حد یک وارنینگ به کدنویسهای این زبان هست برای رعایت قواعد مقایسه ها نه یک باگ خطرناک امنیتی غیر قابل حل و مرگبار . (خطرناکه حسن)

پیوست 2:
با توجه به اینکه توضیحات این عملگرها به صراحت قید شده احتمالا زبان انگلیسیتون خوب نبوده که بتونید داکیومنتشو بخونید پس کمی هم زبان یاد بگیرید برای آینده تون خوبه

پیوست 3:
این موارد تجربه و دقت برنامه نویس را میطلبه که بلاخره بشه یکجایی فرق کد تایپیست مبتدی تازه کار را با یک نفر برنامه نویس با تجربه تشخیص داد :چشمک:
و الی این روزها همه برنامه نویسن شدن.

پیوست 4:
کلا نمیخواستم جواب این تاپیک را بدم ولی وقتی دیدم نوشتی


آقا به خدا من شاخ درآوردم نمیدونم اینا که PHP رو اینطوری طراحی کردن کیان چه غرضی مرضی دارن

گفتم بیام توجیهت کنم که منبعد اول یک زبان را خوب یادبگیرید بعد به خودتون جرات بدین در مورد سطح سواد تولید کنندگانش تحقیق کنید و و در نهایت اگه مشکلی دیدید بهشون بگین "غرض دارن و مرض دارن " ، دیگه چه برسه به نظریه پردازی و ایراد گرفتن به ساختار.
این جور صحبت کردن در مورد افرادی که واقعا خدمت کردند به توسعه دنیای نرم افزار واقعا غرض ورزانه و بیمار گونه هست. و از این بابت براتون متاسفم.

[rahnema1]

سلام دوستان
حالا شرط تساوی را ول کنید این را چیکار می کنید؟:


<?php
$a = "0e6";
$b = "0e5";

if( $a > $b ) echo 'Yes!';
else echo 'No!';
?>

ظاهرا با strcmp حل میشه
یا یه ترفند دیگه مثلا متغیرها را این جور مقدار دهی کنیم


$a = "0e6$";
$b = "0e5$";

حالا جدای از این مورد یکی از نکاتی که به نظر من از نقاط ضعف جدی php هست اینه که سعس کرده شبیه زبان c باشه
مثلا ترتیب برآورد عملوندهای یک عملگر مشخص نیست دقیقا همون طور که در زبان c مشخص نیست
مثلا ما اگه داشته باشیم a+b معلوم نیست ابتدا عبارت a برآورد میشه یا عبارت b که همین مساله خودش منشا خطاها میشه که در زبان c بهش میگن undefined behavior
واسه همین در زبان c یه سری قواعد خاص درمورد ترتیب اجرای عملگر ها به نام sequence point مشخص شده که یک کاربر php لازمه از این پیچیدگی ها هم اطلاع داشته باشه
اخیرا اولین تلاشها برای نوشتن استاندارد php در github صورت گرفته و متن پیش نویس تهیه شده در اونجا گفته ترتیب اجرای عبارتها مشخص نیست البته فکر می کنم اینها همه ضعف در طراحی هست. الان با استفاده از ابزارهایی همچون bison میشه به راحتی آب خوردن یک مفسر زبان ایجاد کرد. اگه نیندیشیده و بدون طراحی عمیق این کار صورت بگیره میشه همین نتیجه php که متاسفانه undefined behavior از c به زبان اسکریپتی php سرایت کرده
اما شما زبانی مثل جاوا را ببینید که چه قدر دقیق طراحی و کار شده و کمی کتاب استاندارد زبان جاوا یا همون java specification مطالعه کنید متوجه می شید چه قدر دقت عمل در طراحی صورت گرفته.من فکر می کنم برای پیاده سازی عملگرها چند نفر نشستند ساعتها جلسه گذاشتند. تا مثلا این مطلب را طراحی و پیاده سازی کنند که ترتیب اجرای عبارتها از چپ به راسته نه مثل php که اصلا روی این موارد فکر نشده
حالا من به این دوستمون توصیه نمی کنم سرش را بکوبه به دیوار چون یک بار در بررسی و تست چند زبان به این نکته پی بردم و غیر از php بعضی زبانهای دیگه هم به این مشکل دچار هستند که اگه می خواستم کله خودم را واسه همینها به دیوار بکوبم دیگه چیزی ازم باقی نمونده بود. در عوض زبانهایی را دیدم که از این تست سربلند بیرون اومدن مثل جاوا ، جاوا اسکریپت، روبی ، پایتون، سی شارپ (دنباله رو جاوا) خیالم راحت شد. یکی یه جای اشتباهی مرتکب شده چرا ما کله خودمون را بکوبیم به دیوار؟ البته نباید از زحمات اینها هم غافل شد

[freeman99]

...
همه اینا که گفتی پاک کردن صورت مسئله و توجیه بود و مغلطه پرداختن به مخاطب، که اگر پست های قبلی رو میخوندی قبلا درمورد اینها توضیح کافی داده بودم و رفع ابهام شده بود.
مسئله طراحی یک زبانه که میتونه ضعیف یا حتی درحدی باشه یه چیزی که بگیم طراحی غلط. چیزی که ضرورت نداشته باشه، سودمندی کافی نداشته باشه، و در مقابل هزینه یادگیری رو بالا ببره، احتمال خطاهای انسانی رو بالا ببره، چیزی نیست جز طراحی غلط (حالا هرچی داکیومنت داشته باشه و خودشون کاملا نسبت به رفتارش آگاه بوده باشن بگن خب داکیومنت ها رو خوب بخونید، توصیه های ایمنی را جدی بگیرید!). و این رو حتی تاریخ خود PHP ثابت کرده. بطور مثال رجیستر گلوبالز طراحی غلطی بود که منجر به مشکلات امنیتی زیادی شد، گرچه بله برنامه نویس اگر آگاه بود و همواره دقت و از یک اصول خاصی پیروی میکرد دچار مشکل نمیشد، ولی این کار عملا سخت و مستعد خطا بود. آخرش خودشون دیدن رجیستر گلوبالز بیشتر از اونکه مفید باشه خسارت ببار میاره در عمل، بنابراین حذفش کردن (به مرور البته)، باوجودی که بقول شما تعداد زیادی برنامه نویس و برنامه در طول سالها روش اتکا داشتن.
حالا چیزی که شما طراحی بکنی بعد مجبور بشی حذفش کنی، بنظر شما اسمش چیه؟ تصمیم طراحی اشتباه نبوده؟ پس چی بوده؟
من یجایی دیدم چند نفر خارجی راجع به همین موضوعات بحث میکردن طرف میگفت «زبانی که یه زمانی متغییرهای کاربر رو همینطور میریخت توی فضای کد برنامه نویس...». این مسائل و بحثها در نت زیاده و راجع به PHP واضحا. چرا به زبانهای دیگه این اتهامات اینقدر زده نمیشه و اینقدر انتقاد و مشکل وجود نداره؟

[sairon123]

من نمیدونم چرا بعضی ها اینقدر دوست دارن زبان php رو خراب کنن ، شاید قصد دارن علم خودشون رو به رخ دیگران بکشن
خوب داداش گلم اگه مشکلی هست بهتر نیست راهنمایی کنید و به جای دعوا برای حل این مشکل راه حل بگید تا تازه کارهایی مثله بنده دچار مشکل نشن
خوب گیریم php مشکل داره آخرش که چی !!!!! آخر این بحث میخواین به کجا برسین!!!!!!!!
اینکه بیاین نویسندگان زبان php رو تخریب کنین و به اونها توهین کنید چیزی عوض نمیشه و چیزی گیرتون نمیاد
اگه واقعا خودتون رو برنامه نویس میدونین سعی کنید به جای اینکه این مباحث حاشیه ای رو مطرح کنید در کنار این مباحث آموزش هایی رو برای رفع این مشکل قرار بدین تا دوستان بتونن استفاده کنن

حالا لطفا بگین برای رفع این مشکل بهتره چیکار کنیم؟؟؟
از تابع strcmp استفاده کنیم یا از === استفاده کنیم؟؟؟

[mohamadali1374]

من نمیدونم چرا بعضی ها اینقدر دوست دارن زبان php رو خراب کنن ، شاید قصد دارن علم خودشون رو به رخ دیگران بکشن
خوب داداش گلم اگه مشکلی هست بهتر نیست راهنمایی کنید و به جای دعوا برای حل این مشکل راه حل بگید تا تازه کارهایی مثله بنده دچار مشکل نشن
خوب گیریم php مشکل داره آخرش که چی !!!!! آخر این بحث میخواین به کجا برسین!!!!!!!!
اینکه بیاین نویسندگان زبان php رو تخریب کنین و به اونها توهین کنید چیزی عوض نمیشه و چیزی گیرتون نمیاد
اگه واقعا خودتون رو برنامه نویس میدونین سعی کنید به جای اینکه این مباحث حاشیه ای رو مطرح کنید در کنار این مباحث آموزش هایی رو برای رفع این مشکل قرار بدین تا دوستان بتونن استفاده کنن

حالا لطفا بگین برای رفع این مشکل بهتره چیکار کنیم؟؟؟
از تابع strcmp استفاده کنیم یا از === استفاده کنیم؟؟؟

به نظر من هم مدیریت بخش هم باید اینجور تایپیک های بی محتوا رو حذف کنه
سوالی که در این تایپیک مطرح شده میتونست خیلی محترمانه مطرح بشه تا یه جواب درست و حسابی به اون داده بشه و اینکه تایپیک باعث ارتقا علمی افراد بشه نه اینکه فقط وقت کاربر ها رو بگیره!!

[***BiDaK***]

من نمیدونم چرا بعضی ها اینقدر دوست دارن زبان php رو خراب کنن ، شاید قصد دارن علم خودشون رو به رخ دیگران بکشن
خوب داداش گلم اگه مشکلی هست بهتر نیست راهنمایی کنید و به جای دعوا برای حل این مشکل راه حل بگید تا تازه کارهایی مثله بنده دچار مشکل نشن
خوب گیریم php مشکل داره آخرش که چی !!!!! آخر این بحث میخواین به کجا برسین!!!!!!!!
اینکه بیاین نویسندگان زبان php رو تخریب کنین و به اونها توهین کنید چیزی عوض نمیشه و چیزی گیرتون نمیاد
اگه واقعا خودتون رو برنامه نویس میدونین سعی کنید به جای اینکه این مباحث حاشیه ای رو مطرح کنید در کنار این مباحث آموزش هایی رو برای رفع این مشکل قرار بدین تا دوستان بتونن استفاده کنن

حالا لطفا بگین برای رفع این مشکل بهتره چیکار کنیم؟؟؟
از تابع strcmp استفاده کنیم یا از === استفاده کنیم؟؟؟
آخرش اینکه شما با یه چیز جدید آشنا شدی.
اگه پستارو هم خوب بخونی جواب سوالت توشون هست.


به نظر من هم مدیریت بخش هم باید اینجور تایپیک های بی محتوا رو حذف کنه
سوالی که در این تایپیک مطرح شده میتونست خیلی محترمانه مطرح بشه تا یه جواب درست و حسابی به اون داده بشه و اینکه تایپیک باعث ارتقا علمی افراد بشه نه اینکه فقط وقت کاربر ها رو بگیره!!
تاپیک همچین بی محتوا هم نیست. توو پست های دوستان مطالب مفید پیدا میشه. یبار دیگه با دقت بخون

[mohamadali1374]

تاپیک همچین بی محتوا هم نیست. توو پست های دوستان مطالب مفید پیدا میشه. یبار دیگه با دقت بخون
بله من هم نگفتم محتوا نداره ولی اگه سوال بی حاشیه پرسیده میشد این همه تایپیک بی محتوا اون هم بر سر موضوع تکراری "آیا php خوب است یا نه......:قهقهه:" ایجاد نمیشد و توی چند تایپیک به سوال پاسخ داده میشد(پاسخی که اگه یه ماه دیگه هم یه نفر این مشکل براش پیش میومد میتونست راحت مشکل خودش رو حل کنه نه اینکه تا بیاد مشکلش رو حل کنه هزار تا مشکل برای اصل php --که خوب است یانه--- براش پیش بیاد.)

[freeman99]

البته این تاپیک بحث در یک سطح و دیدگاه بالاتری هست. یک دیدگاه کلیت و نه اینکه بیایم سر جزییات فنی و اینکه مثلا workaround برای مشکلاتی که در طراحی PHP (مفروضا) وجود دارن ارائه بدیم.
بحث و سوال اصلی و چیزی که میخوایم بفهمیم اینه که چرا این چیزهای عجیب و طراحی های غلط (اگر ثابت شده بدونید/از استدلال ها و اسناد ارائه شده قانع شده باشید/بنظر شما هم همینطور باشه) اینقدر در PHP رخداد دارن از گذشته تا حالا. چرا طراحان PHP رفتار خودشون رو اصلاح نمیکنن باوجود این همه مشکل و بحث و فیدبک که در نت هست. آیا فکر میکنن کارشون هیچ اشکالی نداره؟ آیا آدمهای خودسری هستن؟ آیا غرور برشون داشته؟ آیا توان فنی لازم رو ندارن؟ (خب چرا از متخصص های این کاره کمک نمیگیرن یا حتی همین خود جامعه برنامه نویسان خوب PHP احتمالا میتونه بهتر پیشنهاد طراحی بده و کمک زیادی بکنه در این امر) چرا تاحالا مسئولانه عمل نکردن و به ملت جوابهای روشنی ندادن و استدلال و منطق خودشون رو مطرح نکردن و به بحث و تبادل نظر نذاشتن، چرا از منابع و متخصصان معتبر کمک نگرفتن؟ (مطمئن نیستم این کارها رو هیچ نکردن، ولی منکه چیز خاصی در این زمینه ها ندیدم تاحالا)
و چطور میشه این مسئله رو اصلاح کرد. اگر نمیشه اصلاح کرد و ما کنترلی بر امروز و آینده رفتار این طراحان و ساختار PHP نداریم به هیچ وجه، و هیچ فرد دیگری مثل ما یا متخصص تر و معتبرتر از ما، پس شاید باید فکرهای جدی تری بکنیم و تصمیمات سخت تری بگیریم. بخاطر خودمون و بخاطر همه و آینده.
در اون تاپیک که در stackoverflow زدم کسی پرسیده الان سوال این تاپیک چیه؟ (چون میدونید که stackoverflow سایت پرسش و پاسخ هست و حتما باید سوال مشخصی در موضوع تاپیک وجود داشته باشه - نمیشه فقط بیاید مطلب یا نظری بدید)
همین الان بهشون همین پاسخ رو دادم. و گفتم در نهایت ما میخوایم راجع به این مسئله روشن تر بشیم و بدونیم که چکار کنیم، چون بنظر میرسه عمل جدی تری نیازه. مثلا شاید باید به فکر سویچ کردن به زبان دیگری باشیم، چون PHP لجوجانه داره راه غلط خودش رو میره و اگر آیندهء خودش در خطر نباشه ولی آیندهء افراد خاص میتونه به این خاطر به خطر بیفته (من برنامه نویس که میخوام توی این زبان برنامه بنویسم و باید هزینه ها و ریسک های طراحی های ضعیف و اشتباه اون رو بپردازم).
ضمنا یه پیشنهاد دیگه هم دادم و اون اینکه چنانچه امیدی نیست که طراحان PHP رفتار خودشون رو اصلاح کنن دیگران خودشون یک fork جدید از PHP ایجاد کنن. به این شکل میتونیم استانداردها و طراحی های دیگری در زبان PHP رو شاهد باشیم. البته شاید PHP به این شکل در کوتاه مدت تضعیف بشه، ولی در میان مدت یا بلندمدت میتونه حتی به نفعش تموم بشه (البته تیم و طراحان فعلی PHP معلوم نیست اون موقع چی به سرشون اومده باشه، شاید دیگه بساطشون تقریبا جمع شده باشه!! شایدم سر این مسئله fork و دیدن اینکه چقدر جدیه و چاره ای ندارن و کار بهتر و عاقلانه همینه، حاضر به همکاری و اصلاح و اتحاد بشن، که در این صورت میتونم بگم در نهایت و در کل به نفع PHP و همگان خواهد بود)

بابا به خدا طراحی زبان خودش یه تخصصه، علمه، یکسری اصول و تجربه های شناخته شده داره.
طراحان و متخصصان و افراد با تجربه هم در این زمینه در دنیا منقرض نشدن و وجود دارن. منجمله طراحان زبانهای دیگه مثل پایتون، جاوا، رابی، پرل و خیلی دیگه.
من بودم میامدم از همهء اینا درخواست کمک و همکاری و بحث و تبادل نظر میکردم. شده حتی بهشون دستمزد میدادم تا راهنمایی کنن و یاد بدن و کمک کنن.
یعنی این کارها از جامعهء به این بزرگی PHP و شرکتهایی که درش مشغول فعالیت هستن، شرکتهایی که ازش استفاده میکنن و سود میبرن، شدنی نیست؟
اصلا چرا راه دور بریم، یه بحث و تبادل نظر از برترین و با تجربه ترین و باسوادترین برنامه نویسان همین جامعهء PHP راه بندازن احتمال زیاد میتونه خیلی مفید باشه و به خیلی اشکالات طراحی پی برده بشه.
کلا بازمتن یعنی همین. اصول و راه سعادت بازمتن اینه، نه چیز دیگه. اینکه چند نفر بشینن توی یه اتاق و مدتی بحث کنن و نهایت از منابع خیلی محدود و بسته ای کمی مشورت و فیدبک بگیرن و یه چیزی به این پرکاربردی و اهمیت رو بدون اینکه تخصص و صلاحیت اصولی و تجربهء واقعی درش داشته باشن طراحی کنن، که نشد کار!

[freeman99]

طراحان PHP به خیال خودشون میخوان کار برنامه نویس رو راحت کنن (البته بنده با این رفتارها بهشون کمی مشکوک شدم که شاید اصلا دلایل یا هدف دیگری در کاره!).
مثلا رجیستر گلوبالز هم دلیل وجودیش چی بود؟ راحتی برنامه نویسی.
ولی متاسفانه این کار رو به شکل بدون اصول و بدون درنظر گرفتن جنبه های دیگرش انجام دادن و در هوشمند کردن و شیرین کاری زبان برنامه نویسی بیش از حد افراط که بشه همینطور مشکلات پیش میان. زبان برنامه نویسی دیگه نباید تا این حد سرخود و غیرمنتظره عمل کنه. شما در هیچ زبان دیگری چنین چیزهایی اینقدر زیاد و در این حد وخیم نمیبینید.
در همین حد هوشمندی و انعطاف که زبانهای برنامه نویسی سطح بالای امروزی بطور معمول دارن، درحد متعارفی که اکثریت هستن، هنوز از گذشته تاحالا سرش بحث هست و مثلا بعضیا میگن مثلا weak typing یا نمیدونم dynamic typing و اینها از نظر امکان پنهان کردن خطاهای برنامه نویس و ایجاد باگ در برنامه مشکل دارن، حالا PHP اومده و از این حد هم بی پروا خیلی فراتر رفته و طراحی و منطق زبان برنامه نویسی رو داره شبیه پازل و میدان مین میکنه! برنامه نویسی که برنامه مینویسه باید روی برنامهء خودش تمرکز کنه، نه حل کردن پازل منطق های به اصطلاح فوق هوشمند و پیچیده و غیرمنتظرهء زبان برنامه نویسی و نیاز به دقت زیاد برای اینکه پاش روی مین نره!! هرچی هم جزییات لازم برای یادگیری و برنامه نوشتن در یک زبانی زیاد بشه، امتیاز منفیه. میگید برو عملگر === استفاده کن، strcmp استفاده کن، == رو برای اینا نساختن، ولی من واقعا نفهمیدم اصلا کاربرد == چیه، چون اینطور که من میبینم اصولا بطور کلی باید کنارش بذاریم (مگر در موارد خیلی محدود و مشخصی شاید). اینقدر منطق اینو سرخود پیچیده و غیرمنتظره کردن و هوشمندبازی و شیرین کاری درآوردن که کلا زدن عملگر رو چپرچلاق و بیهوده کردن! یبارکی حذفش کنن دیگه. یا بگن این واسه بازی و باگ درست کردنه یا کسانی که علاقه دارن Minesweeper بازی کنن :لبخند:

[golbafan]

نه عزیزم این جدول رو هم خودم برحسب تجربه به مرور درست کردم. همین هم توی Manual نیست. خواستم کمکی کرده باشم :چشمک: دوست نداری برو همچنان Procedural کد بنویس :لبخند:

منوال پی اچ پی در این رابطه:
http://au.php.net/manual/en/language.operators.comparison.php

وقتی شما حق تالیف رو رعایت نمیکنی دیگه از بقیه چه انتظاری میره؟
http://stackoverflow.com/questions/80646/how-do-the-php-equality-double-equals-and-identity-triple-equals-comp

129372

[freeman99]

حالا نگران نباشید نمیخوام سرم رو بکوبم به دیوار :لبخند:
میخواستم بگم میخوام سر شما رو بکوبم به دیوار که دیدم بده خب :قهقهه:
نه شوخی کردم :بامزه:
ای درد و بلای همتون بخوره تو سر Rasmus Lerdorf :قهقهه:

بابا توهین کجا بود فقط دارم بذله گویی میکنم :لبخندساده:
والا من با PHP و بروبچش هیچ دشمنی ندارم تازه خودم هم این زبان رو دوست دارم و دارم استفاده میکنم دیگه!
در کل هم بنظر من زبان PHP خوبه و خیلی مفید بوده (من عاشق یه چیزایی مثل آرایه های فوق العاده منعطف و همه کاره و قدرتمند اون هستم که توی زبانهای دیگه نیست). ولی این مشکلات دیگه دارن نگران کننده میشن و باید یه کسی چیزی بگه کاری بکنه بالاخره. از اون طرف هم چون بخش اعظم وب رو PHP گرفته بهتره مسئولانه تر عمل کنن، چون درسته که بازمتنه و مجانی و بقول معروف میگن دندون اسب پیشکشی رو نمیشمارن، ولی چیزی وقتی اینقدر پر استفاده و استاندارد شد و اهمیت پیدا کرد و عملا بقیهء آلترناتیوها رو محدود کرد مسئولیت هم میاره و حساب کن مثلا من الان بخوام برم به زبان دیگه سویچ کنم خب راحت نیست هزینه داره محدودیت میاره چون بیشتر هاستهای معمولی و اشتراکی ها و قیمت های مناسب PHP هستن، و کاربرد زبانهای دیگه در زمینهء وب از PHP فاصله داره اگر برم به سمت اونا شاید بازار کارم هم محدود بشه (گرچه من هنوز کار تجاری نمیکنم؛ ولی مثال میزنم حالا).

اینقدر این چیزایی که در PHP میبینم بنظر من عجیب و غیرقابل توجیه است که یه وقتا شک میکنم، مثلا جایی میخوندم طرف گفته بود یکسری باگها رو عمدا توی PHP گذاشتن که بعد خودشون استفاده کنن واسه نفوذ و هک و این حرفا. من خودم از مخالفان و منتقدان تئوریهای توطئه هستم، ولی این مسائل رو که میبینم خودم الان یه وقتا فکر میکنم شک میکنم میگم نکنه واقعا همچین چیزهایی از کجا معلوم شاید هم واقعا درکار و عمدی باشه :متفکر:. شاید اینکه شرکت و تشکیلات توسعه دهندهء اصلی PHP هم اسرائیلی هستن یجوری این شک رو بیشتر میکنه! هر روز هم که از برنامه های جاسوسی امثال NSA و موساد گند و خبرش درمیاد آدم به ذهنش میاد که شاید همه اینا دستشون توی یه کاسه باشه!

[golbafan]

مثلا جایی میخوندم طرف گفته بود یکسری باگها رو عمدا توی PHP گذاشتن که بعد خودشون استفاده کنن واسه نفوذ و هک و این حرفا

به اون بنده خدا بگید که این زبون اپن سورسه !
خسته است میفهمی خسته!

و البته نظر من اینه که در حد سواد امثال من و نیاز های فعلی دنیای وبنویسی، php باگ ندارد...

[freeman99]

به اون بنده خدا بگید که این زبون اپن سورسه !
خب اپن سورس باشه!
همهء باگها که لزوما خیلی واضح نیستن و زود تشخیص داده نمیشن. تا یه باگی توسط دیگران کشف بشه و تا پچ بشه و بعضی هاستها هم دیر آپدیت/پچ میکنن یا اصلا نمیکنن تا مدتها، اون آسیب پذیری وجود داره. شاید همون زمان محدود و همون تعداد برای هدفشون کافی باشه.
تازه خیلی از باگها ممکنه تا مدتها شناسایی نشن که این در محصولات بازمتن هم رخ میده و مثلا توی کتابخانهء OpenSSL برای سالها باگ خطرناکی بود که چند وقت پیش تازه گندش درآمد. همچنین توی BASH بود به گمانم. و خیلی مثالهای دیگه.
البته نمیشه ثابت کرد که این باگها عمدی هستن، ولی در دنیای امروز احتمال همه چیز میره. همونطور که حداقل 12 سال NSA داشته چه برنامه های جاسوسی پیشرفته ای رو توسعه میداده و در خاموشی استفاده میکرده. برنامه هایی که حتی میرن توی هارد و هارد رو فرمت بکنی هرکار بکنی از بین نمیرن، ولی کسی خبر نداشته و تازه بعد از سالها تصادفی هم کشف کردن اینا رو. البته هدفهای این حمله ها هدفهای خاص و انتخاب شده و محدودی هستن. کار سازمانهای امنیتی مثل هکرهای معمولی نیست که سر و صدا راه بندازن یا در مقیاس وسیع همینطور به هرکی میرسن حمله کنن (طبیعتا اونطوری احتمال افشا شدن هم خیلی بالاتر میره).

[golbafan]

خب اپن سورس باشه!
همهء باگها که لزوما خیلی واضح نیستن و زود تشخیص داده نمیشن. تا یه باگی توسط دیگران کشف بشه و تا پچ بشه و بعضی هاستها هم دیر آپدیت/پچ میکنن یا اصلا نمیکنن تا مدتها، اون آسیب پذیری وجود داره. شاید همون زمان محدود و همون تعداد برای هدفشون کافی باشه.

حد اقل این بهتر از زبان های سورس بسته هست!

در ثانی میدونید چقدر سایت الان در دنیا با php تولید شده...؟؟؟ اوووووه

[golbafan]

برنامه هایی که حتی میرن توی هارد و هارد رو فرمت بکنی هرکار بکنی از بین نمیرن

میشه بیشتر توضیح بدید؟؟؟
هارد که نمیتونه خودش برنامه رو چک کنه...
شما با این حرف کلا سیستم عامل رو نادیده گرفتید
بر فرض که برنامه بعد از فرمت در هارد بمونه...
وقتی سیستم عامل نصب کردی چطوری باید اون فایل اجرا بشه؟؟؟
مگر اینکه خودش سیستم عامل باشه...

با اینحال میشه هارد رو wipe کرد...

[freeman99]

میشه بیشتر توضیح بدید؟؟؟
هارد که نمیتونه خودش برنامه رو چک کنه...
شما با این حرف کلا سیستم عامل رو نادیده گرفتید
بر فرض که برنامه بعد از فرمت در هارد بمونه...
وقتی سیستم عامل نصب کردی چطوری باید اون فایل اجرا بشه؟؟؟
مگر اینکه خودش سیستم عامل باشه...

با اینحال میشه هارد رو wipe کرد...
حتی wipe و حتی روشهایی با استانداردهایی که برای سازمانهای نظامی و امنیتی طراحی شدن در این مورد موثر نیستن.
چون این برنامه firmware هارد رو بازنویسی میکنه و یک بخش پنهان و دیسک مجازی اختصاصی خودش روی هارد دیسک ایجاد میکنه. بیشتر و دقیقتر از این نمیدونم ولی مثلا لابد هر بار هم از طریق همین firmware مجددا اجرا میشه و مستقل از سیستم عامل و فرایند بوت رایانه است. خلاصه چیز خفنیه. احتمالا از یک ضعفی چیزی در مکانیزم محافظت و بازنویسی firmware هارد دیسک یا جای دیگه برای نفوذ اولیه استفاده میکنه. بهرحال الان دنیا اینطوری شده. مثلا من قبل ترش هم در یکی از این سایتهای معتبر امنیتی درمورد نفوذ از طریق باگهای داخل خود سخت افزارها مثل کارت شبکه مطلب خونده بودم. الان خود اجزای سخت افزاری تهدید هستن چون داخلشون برنامه و تشکیلات خاص خودشون رو دارن و بنوعی هوشمند هستن و بنظرم حتی قابلیت برنامه نویسی و اجرای برنامه های خاص خودشون (یا شاید در مواردی هم همین برنامه هایی که با زبانها و کامپایلرهای استاندارد مثل سی نوشته بشن) روی اونا وجود داره.
این تاپیکو ببین: http://barnamenevis.org/showthread.php?486700-%D9%BE%DB%8C%D8%B4%D8%B1%D9%81%D8%AA%D9%87%E2%80%8 C%D8%AA%D8%B1%DB%8C%D9%86-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D8%AC%D8%A7%D8%B3%D9%88%D8%B3%DB%8C-%D8%B3%D8%A7%DB%8C%D8%A8%D8%B1%DB%8C-%D8%AA%D8%A7%D8%B1%DB%8C%D8%AE-%DA%A9%D8%B4%D9%81-%D8%B4%D8%AF
منبع حرفایی که من زدم اینه: http://arstechnica.com/security/2015/02/how-omnipotent-hackers-tied-to-the-nsa-hid-for-14-years-and-were-found-at-last/

[golbafan]

مرسی جالب بود...

خیلی خوب مینویسی (حوصله بخرج میدی)

من جای شما باشم میرم نویسنده میشم. :لبخند:

[احسان!]

نمیدونم چرا کلا freeman99 (http://barnamenevis.org/member.php?229578-freeman99) (اشپیلن یا هرچی!) و MMSHFE (http://barnamenevis.org/member.php?55504-MMSHFE) علاقه ی زیادی به بحث و درگیری با همدیگه دارن.

[golbafan]

نمیدونم چرا کلا freeman99 (http://barnamenevis.org/member.php?229578-freeman99) (اشپیلن یا هرچی!) و MMSHFE (http://barnamenevis.org/member.php?55504-MMSHFE) علاقه ی زیادی به بحث و درگیری با همدیگه دارن.

این نشون میده که اینا دوستای قدیمی هستن...

[MMSHFE]

وقتی شما حق تالیف رو رعایت نمیکنی دیگه از بقیه چه انتظاری میره؟
http://stackoverflow.com/questions/80646/how-do-the-php-equality-double-equals-and-identity-triple-equals-comp

دوست عزیز، من خودم برحسب تجربه شخصیم و با جستجو از اینطرف و اونطرف و جمع کردن یکسری اطلاعات که بخشی از اون هم از منابعی مثل همین لینکی که گذاشتین بدست اومده، یکسری Cheetsheet برای کارهای خودم درست کردم و حقیقتاً موقعی که پست رو گذاشتم، لینک منبعش یادم نبود که بخوام بگذارم و ازطرفی جدولی که دارم خیلی کاملتره ولی فقط همین بخشش مربوط به عملگرهای مقایسه ای بود که گذاشتم. شما به بزرگی خودتون ببخشین.

[MMSHFE]

این نشون میده که اینا دوستای قدیمی هستن...

چه جورم! یک درصد فکر کن من و این اژدها رفیق باشیم :چشمک:
حمیدرضا تحویل بگیر

[golbafan]

چه جورم! یک درصد فکر کن من و این اژدها رفیق باشیم :چشمک:
حمیدرضا تحویل بگیر

اگر با من نبودش هیچ میلی
چرا ظرف مرا بشکست لیلی

[freeman99]

چه جورم! یک درصد فکر کن من و این اژدها رفیق باشیم :چشمک:
حمیدرضا تحویل بگیر
مهندس یعنی حال دادی گفتی اژدها :لبخندساده:
جون تو یاد بروسلی افتادم!
اژدها وارد میشود... :لبخند:

عجب مرد کبیری بود.
ابرمرد بود.
منم میخوام ابرمرد باشم.
از عادی بودن حال نمیکنم.
اصلا آدم عادی خیلی درپیته خب. حالمو بد میکنه.
ولی داغم تازه شد. یعنی یه هدف مادرزادی واسه آدمی مث من رزمی بود... ولی وقت نشد. یعنی این زندگی رفتم دنبال علم و فناوری. خب یجورایی جبر بود. ولی هیچوقت رزمی از یادم نمیره. یعنی امروز با بچه خواهرم رفته بودیم پارک همینطور درخت و پرچین و تپه مپه ها رو نگا میکردم میگفتم جون میده بپری بدوی لگد بزنی خودتو بکوبی به اینور و اونور، همچین بدنت قوی و محکم میشه ها... خفن!

استعداد انحراف و آفتاپیک رو حال میکنی؟ :لبخند:
یعنی یه کلمه یه چیزی بگو ش من میرم شوش و برمیگردم، اصلا نگی هم باز هرجا دلم بخواد میرم برمیگردم :لبخند:

[engmmrj]

مهندس یعنی حال دادی گفتی اژدها :لبخندساده:
جون تو یاد بروسلی افتادم!
اژدها وارد میشود... :لبخند:

عجب مرد کبیری بود.
ابرمرد بود.
منم میخوام ابرمرد باشم.
از عادی بودن حال نمیکنم.
اصلا آدم عادی خیلی درپیته خب. حالمو بد میکنه.
ولی داغم تازه شد. یعنی یه هدف مادرزادی واسه آدمی مث من رزمی بود... ولی وقت نشد. یعنی این زندگی رفتم دنبال علم و فناوری. خب یجورایی جبر بود. ولی هیچوقت رزمی از یادم نمیره. یعنی امروز با بچه خواهرم رفته بودیم پارک همینطور درخت و پرچین و تپه مپه ها رو نگا میکردم میگفتم جون میده بپری بدوی لگد بزنی خودتو بکوبی به اینور و اونور، همچین بدنت قوی و محکم میشه ها... خفن!

استعداد انحراف و آفتاپیک رو حال میکنی؟ :لبخند:
یعنی یه کلمه یه چیزی بگو ش من میرم شوش و برمیگردم، اصلا نگی هم باز هرجا دلم بخواد میرم برمیگردم :لبخند:
هه ُ هر چقدرم بزرگ بشی بازم یک روز سرتو میزاری زمین میمری ! مثل بروسلی
پس سعی کن وقت میمری همه نگن اژده ها پر حرف مرد !

[freeman99]

هه ُ هر چقدرم بزرگ بشی بازم یک روز سرتو میزاری زمین میمری ! مثل بروسلی
پس سعی کن وقت میمری همه نگن اژده ها پر حرف مرد !
بنظر من مسئله ای که الان واقعیت داره و اولویت اول و واضحتره، مسئلهء دشوارتر، زندگی کردن. حل مسئلهء زندگی برای من از مرگ مهمتر و واقعی تر و سخت تره. تاحالا هم بنظر خودم خوب تونستم از پس حل این مشکل، یعنی بالا بردن کیفیت زندگیم، معقول کردنش، بربیام. یعنی بهتر از اکثریت دیگر مردم. یکی از چیزهای پایه هم که برای داشتن یک زندگی خردمندانه و خوب بهش رسیدم اینه که نظر مردم به خودی خودش مهم نیست. چه موقع حیات و چه بعد از مرگ. نباید برای دیگران زندگی کرد!


وقت میمری همه نگن اژده ها پر حرف مرد
خیالی نیست، اینقدر بگن که خسته شن :قهقهه:

[rezaonline.net]

@freeman99 (http://barnamenevis.org/member.php?229578-freeman99) :
اون آواتار بمب اتمت رو بذار :لبخند:

[MMSHFE]

تاپیک به دلیل خارج شدن از مسیر اصلی، قفل شد.