PDA

View Full Version : PHP 6



alips66
دوشنبه 02 اسفند 1389, 14:42 عصر
دوستان کسسی از تاریخ عرضه PHP 6 خبر داره ؟
چه مزیتی نسبت به PHP 5 داره؟

eshpilen
دوشنبه 02 اسفند 1389, 18:17 عصر
قول داده بودن از یونیکد پشتیبانی Native داشته باشه؛ و این مهمه!
فکر میکنم نقص مهم دیگر PHP نداشتن امکانات مالتی تردینگ باشه. اطلاع ندارم در PHP6 چنین چیزی رو اضافه میکنن یا نه.

mtchabok
دوشنبه 02 اسفند 1389, 22:06 عصر
من الان هر چی گشتم تاریخی برای عرضه وجود نداشت ...
ولی به یه چیزای جالبی رسیدم که اصلا از وجودشون اطلاعی نداشتم ... شما هم یه سرچی بکنین در این مورد ... روشهای خیلی جالبی در نسخه های جدید وجود داره که من تازه دیدم و از این به بعد ازشون استفاده میکنم ... البته یه خورده ذوق زده شدم ... :کف: آخه چیزای جدید یاد گرفتم ...

amir001
دوشنبه 02 اسفند 1389, 23:21 عصر
فکر میکنم یکی از اشکالاتش هم در شیء گرایی اون هست که در دسترسی به خواص یک شیء باید از پیکان استفاده کرد در حالی که نقطه خیلی زیباتر و راحت تر هست. دلیلش هم این بوده که قبلا نقطه رزرو شده بوده برای کانکت رشته. نمیدونم در این مورد تغییری داره یا نه.

مشکل دیگه که من دیدم این بود که $this نوشتنش در خود کلاس الزامی هست در حالی که در بقیه زبانها با نبودن this هم مشکلی پیش نمیاد و در صورت ذکر نکردن اون پیش فرض متغیر یا متد عضو در نظر گرفته میشه.

کسی در این موارد چیزی پیدا نکرده؟؟



قول داده بودن از یونیکد پشتیبانی Native داشته باشه؛ و این مهمه!


میشه خواهش کنم در این مورد بیشتر توضیح بدید؟؟ یونیکد الان در php به چه شکل هست ؟؟

eshpilen
سه شنبه 03 اسفند 1389, 01:05 صبح
یونیکد الان Native نیست. یعنی PHP خودش بر اساس یونیکد نیست و مفهوم یونیکد بصورت داخلی و خودکار در ساختارها و توابع اون شناخته نمیشه، بلکه همه چیز رو بصورت کاراکترهای تک بایتی میبینه.
بطور مثال شما طول یک رشتهء فارسی رو با تابع strlen خود PHP بگیرید یک مقدار نادرست به شما میده. چون بصورت بایت به بایت شمارش میکنه درحالیکه کاراکترهای فارسی بصورت UTF-8 هرکدام بیش از یک بایت هستن.
همینطور در رگولار اکسپرشن ها مشکلات و پیچیدگی و ناسازگاری قابل توجهی برای کار با یونیکد وجود داشته و داره، چون بطور مثال شما نمیتونید در اونها کاراکترهای یونیکد رو بصورت مستقیم با کد عددی معرفی کنید. مشکلات در این زمینه ظریف و متعدد هستن که بنده باهاشون قبلا برخورد داشتم. ممکنه رگولار اکسپرشنی مثلا برای فارسی بنویسید که درست بنظر میاد، اما در حقیقت اشکال داره. ضمنا طراحی رگولار اکسپرشن برای بعضی کارها نیاز به دانش و مهارت خاص دربارهء یونیکد و انکدینگ هایی مثل UTF-8 داره. باید کلی مقاله بخونید و با جزییات سطح بایت UTF-8 کار کنید تا بتونید این کاربردها رو پیاده سازی کنید. بنده یه پروژه ای که داشتم باید یک رگولار اکسپرشن برای ولیدیت سمت سرور درست میکردم که کلی بابتش مقاله خوندم و تست انجام دادم، و یک رگولار اکسپرشن جداگانه برای سمت کلاینت و جاوااسکریپت باید طراحی میکردم که جاوااسکریپت بخوبی از یونیکد پشتیبانی میکنه.

البته توابعی مثل mb_strlen وجود دارن، اما اینا بیشتر وصله و پینه و محدود و موردی هستن تا علاج اصولی و کامل درد.

eshpilen
سه شنبه 03 اسفند 1389, 01:36 صبح
دلیلش هم این بوده که قبلا نقطه رزرو شده بوده برای کانکت رشته. نمیدونم در این مورد تغییری داره یا نه.
من فکر میکردم بخاطر این بوده که اتصال رشته در برنامه نویسی وب خیلی زیاد بکار میره و بنابراین روش راحتتر از نظر تایپ رو برای اتصال رشته ها استفاده کردن.
ولی اینی که شما میگی احتمالا درسته.



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

UnnamE
سه شنبه 03 اسفند 1389, 02:45 صبح
مشکل دیگه که من دیدم این بود که $this نوشتنش در خود کلاس الزامی هست.........

مثلا الان

class << self
def authenticate(email, submitted_password)
user = find_by_email(email)
(user && user.has_password?(submitted_password)) ? user : nil
end

def authenticate_with_salt(id, cookie_salt)
user = find_by_id(id)
(user && user.salt == cookie_salt) ? user : nil
end
end

يه جورايي جادو....