[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Будущее PHP
Страницы: 1, 2, 3, 4, 5, 6
YVSIK
Цитата (MiksIr @ 1.11.2013 - 18:06)
Так что не понимаю, что вы переживаете.

ну сказано же)) что целые сайты об этом пекуться ВДРУГ стали)) biggrin.gif biggrin.gif biggrin.gif
что-же делать)) что-же теперь делать ОТ нас удаляют так любимай PHP

пора прорубь искать или веревку ) laugh.gif laugh.gif

подведу итог: будет замена тогда и поспорим а пока замены нет и надо эту тему мусировать. есть только жалкое подобие, оно таво конечно сложновато для понимания , но мы оегких путей не ищем , нам потрудней задачки подавай biggrin.gif biggrin.gif biggrin.gif

_____________
«Гнусное свойство карликовых умов приписывать
________________!свое духовное убожество другим!»
___
О) как-же он прав=>__________________ © Оноре де Бальзак.

отличный хост(рекомендую !! )
My MVC-CMV
Rand
Я вообще не против развития ООП в PHP, но всё это идет так меееедленно... Получается как-бы ни рыба ни мясо. И на ООП я не могу развернуться, так как хотелось бы, и на процедурке есть множество неудобств. Вот сделалии в некоторых фреймворках анотации, как это сейчас работает: скудность синтаксиса восполняют своими инструкциями в doc-блоках, а потом исходники каждый раз парсятся токенайзером. По такому же принципу указываются типы параметров для процедур XML-RPC сервера в ZF2 - смотрел профайлером, функция парсящая блоки вызывается >1000 раз. Многое можно решить кешированием, но костыльность подхода меня категорически не устраивает!
redreem
YVSIK
с чего ты взял, что имеют место стадные миграции? поставь перед собой задачи, погугли возможные решения и выбери что по душе. мне вот nodejs нравится. я его потихонько покапываю. думаю скоро начну оформлять уже в ченить продуктивное. при этом мне плевать что говорят об этом. я проанализировал и у меня есть свое мнение. а холивары - второе имя всем форумам. smile.gif
Rand
Цитата (MiksIr @ 1.11.2013 - 21:28)
Тебе строгой типизации не хватает что-ли, не пойму?
Строгая типизация не нужна, но если бы была возможность делать так:
public function foo(string $str, int $num) {}
Я бы уже порадовался =) Не понимаю, почему можно проверять на array и на тип объекта, а на скалярные типы нельзя, какая-то куцая реализация.
Rand
И да - перегрузка, вот что мне действительно не хватает! smile.gif
Invis1ble
Rand
Уже давно ведь хотели ввести type hinting для скалярных типов, но там возникли какие-то проблемы технического плана, емнип. Не так давно поднималась эта тема на форуме и кто-то даже раскопал костыль для реализации этой плюшки.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

redreem
я против строгой типизации.
Rand
Цитата (MiksIr @ 1.11.2013 - 21:28)
Спасает, правда __toString, просто приходится писать (string) почаще, прозрачная замена не работает, увы. Как и (int)$object. Вот это - недостатки.
Согласен.
Цитата (MiksIr @ 1.11.2013 - 21:58)
Именованные параметры при передаче в функции
Вот это хочу =)
Цитата (MiksIr)
foo(123, "123") вызовет фатал, а это противоречит общей концепции языка
Может это и нарушает концепцию, но мне иногда хотелось бы, чтобы пользовательский код приводил тип самостоятельно, а функция об этом не заботилась (иногда действительно надо, чтобы int был именно int, а 123asd - должно вызывать подозрения в правильности работы программы). Сейчас валится Warning, видимо по той же причине. Ссылку прочту, спасибо.

Invis1ble
Я всё таки оптимист, и надеюсь, что с выходом ZE3 всё наладится ))
GET
MiksIr
Цитата
3. Нормальные функции empty/isset


Можете проккоментировать, что значит нормальные? Чем они отличаются от аналогов в 5.3?

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
GET
MiksIr
Спасибо.

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2025 Invision Power Services, Inc.