Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
Получается какая-то типизация ради типизации :)
Почему-то думал, что одна из причин для выбора PHP как раз отсутствие типизации
Type hinting может использоваться только для массивов и объектов.
Какой приведенного кода,
function teststring(string $string) { echo $string; }
teststring( 'string2' );
Если он вызывает ошибку? Я передаю строку, а интерпретатор хочет объект класс string.
Или нужно дополнительно написать классы string, integer и float…
Какой приведенного кода,
function teststring(string $string) { echo $string; }
teststring( 'string2' );
Если он вызывает ошибку? Я передаю строку, а интерпретатор хочет объект класс string.
Или нужно дополнительно написать классы string, integer и float…
вот именно для того, что бы не использовать только для array и для объектов и написан этот пост, а Вы даже не удосужились прочесть ЧТО в нем написано…
А разве можно такое в продакшн-коде использовать?
вобщем-то — вполне, но сразу оговорюсь — на реальных проектах я это решение не использовал, а проверял только на нескольких скриптах с небольшим объемом кода и БЛ
Мне просто не понятно где это можно использовать. Как проверка пользовательского ввода? Не получится, потому что все от пользователя — строка. Родные функции php зачастую возвращают разные типы данных в разных условиях.
Да и потом особенность PHP в отсутсвии типизации простых типов. Это же фича, а не баг. А вы относитесь к этому как к багу.
Да и потом особенность PHP в отсутсвии типизации простых типов. Это же фича, а не баг. А вы относитесь к этому как к багу.
в РНР6 появится опциональная поддержка питизации скалярных типов данных
Значит у нас есть еще 2 года, чтобы насладиться ее отсутствием. :)
У меня ощущение, что если нужна строгая типизация, то нужно сменить язык, например на Java
У меня ощущение, что если нужна строгая типизация, то нужно сменить язык, например на Java
Как раз недавно писал на эту тему: Scala.habrahabr.ru/blog/30538/ радует, что и PHP присоединяется к компании.
Как раз недавно писал на эту тему: Scala.habrahabr.ru/blog/30538/ радует, что и PHP присоединяется к компании.
Это используется, как написал автор, чтобы PHP падал при попытке подать ему не то, что должно быть, только и всего. Это просто для программиста авто-проверка своего кода.
Использовать можно, но не стоит из-за того, что количество таких проверок даже в средне-сложном движке может дойти до сотен, при этом каждые 50 проверок съедают примерно 1мс. Поэтому не стоит.
Бред какой то. Как связана типизация языка с командной разработкой? Может быть очень опосредованно только. Внедрение в язык, сама идеология которого подразумевает вольное обращение с типами данных, строгую типизацию, Вы фактически внедряете в телегу пятое колесо, причем стоящее под углом 90 градусов к 4-ем остальным. Высококвалифицированным разработчикам на PHP Ваша типизация не нужна, мало того она им вредит, так как заставляет в ряде алгоритмов вводить новые сущности, в случае, когда можно обойтись без них, получив более наглядный и эффективный код. С низкоквалифицированными разработчиками же вопрос решается жесткими стандартами кодирования и формализацией задач.
Бред. Или принимайте язык таким, какой он есть, или используйте другой.
Я сам сторонник максимальной типизации, но не вижу здесь ничего полезного.
В маленьких проектах это бесполезно, а в больших получим неприемлемый оверхед на какую-то сомнительную фичу.
Это если не считать переподготовки специалистов — нельзя вот так сразу начать фигачить строго типизированный код, здесь образ мышления менять надо…
Я сам сторонник максимальной типизации, но не вижу здесь ничего полезного.
В маленьких проектах это бесполезно, а в больших получим неприемлемый оверхед на какую-то сомнительную фичу.
Это если не считать переподготовки специалистов — нельзя вот так сразу начать фигачить строго типизированный код, здесь образ мышления менять надо…
Ну во-первых не стоит называть бредом все с чем ВЫ не согласны.
во-вторых — касательно производительности. Только что специально проверил — на каждую проверку мы убиваем 0.002 секунды (это на моем ноутбуке. на сервере думаю меньше), так что кое-где, но данный подход может иметь место. Более того, кто мешает сделать перед продакшном что-то типа:
во-вторых — касательно производительности. Только что специально проверил — на каждую проверку мы убиваем 0.002 секунды (это на моем ноутбуке. на сервере думаю меньше), так что кое-где, но данный подход может иметь место. Более того, кто мешает сделать перед продакшном что-то типа:
preg_replace( '/[\(,]\s+(string|integer|float|resource)/i', '', $file );
<code>
по всем файлам?Беру бред назад, хотя если бы считал это бредом, не писал бы комментарий, думал что это очевидно…
>> Более того, кто мешает сделать перед продакшном что-то типа:
preg_replace( '/[\(,]\s+(string|integer|float|resource)/i', '', $file );
>> Более того, кто мешает сделать перед продакшном что-то типа:
preg_replace( '/[\(,]\s+(string|integer|float|resource)/i', '', $file );
по всем файлам?
Ну это сильно зависит от модели обновления кода на сервере, да и весомая часть полезности теряется.
Более того, без встроенной в язык типизации переменных и возвращаемых значений вряд ли можно надеяться на достаточную формализацию кода.
Еще можно залезть в исходники PHP и пропатчить все там, но это будет совсем другой язык.
Но все равно есть ограничение, которое обойти не удастся. Как правило, строгая типизация требует отдельного процесса - компиляции. В динамических же языках типа PHP все происходит в рантайме. Например, в C++ в рантайме нет типов как таковых - энное количество байт в памяти может быть чем угодно - целым, float, строкой, объектом какого-то типа, пользовательским псевдотипом... За типами следит компилятор, которого в динамических языках нет (как такового). Так что приемлемой "красивости" все равно достичь не удастся.
PHP всегда был строго типизированным. Не следует это путать с динамической типизацией. Эти понятия ортогональны.
Извините, но:
«Строгая типизация подразумевает выполнение следующих обязательных условий:
1. Каждое значение, переменная, параметр и возвращаемое значение функции на этапе проектирования программы безусловно привязывается к определённому типу данных, который не может быть изменён во время выполнения программы (т. н. статическая типизация).
2. Допускается присваивание переменной только значения, имеющего строго тот же тип данных, что и переменная, те же ограничения действуют в отношении передачи параметров и возврата результатов функций.
3. Каждая операция требует параметров строго определённых типов.
4. Неявное преобразование типов не допускается (то есть транслятор воспринимает любую попытку использовать значение не того типа, который был описан для переменной, параметра, функции или операции, как синтаксическую ошибку).»
неужели в РНР эти условия выполняютя? о_О
«Строгая типизация подразумевает выполнение следующих обязательных условий:
1. Каждое значение, переменная, параметр и возвращаемое значение функции на этапе проектирования программы безусловно привязывается к определённому типу данных, который не может быть изменён во время выполнения программы (т. н. статическая типизация).
2. Допускается присваивание переменной только значения, имеющего строго тот же тип данных, что и переменная, те же ограничения действуют в отношении передачи параметров и возврата результатов функций.
3. Каждая операция требует параметров строго определённых типов.
4. Неявное преобразование типов не допускается (то есть транслятор воспринимает любую попытку использовать значение не того типа, который был описан для переменной, параметра, функции или операции, как синтаксическую ошибку).»
неужели в РНР эти условия выполняютя? о_О
а как насчет дефолтного значения? например:
вылетает эксепшен, что по дефолту может быть только null, так как типизированный параметр — объект или массив (типа ;)).
function myFunc( int $arg = 1) {
…
}
вылетает эксепшен, что по дефолту может быть только null, так как типизированный параметр — объект или массив (типа ;)).
Вам сюда: оригинал решения :)
ну занятная штука. интересно было посмотреть, интересный метод, использовать не собираюсь, но автору метода респект, задача так сказать с точки зрения самой задачи весьма занятная и интересно решена.
А неужели так отвратительно использовать is_* — функции совместно с каким-нибудь InvalidArgumentException? Зачем усложнять?
пишу много и долго на пхп5, обхожусь без этого на раз-два, особой необходимости в этом нет.
Тема давняя, но напишу.
Такая строгая типизация работает только для передачи аргументов в функцию.
В коде возможно присвоение любого типа данных.
Например:
function test(integer $i) {
$i = veryStrongCalculation();
return $i; //функция может вернуть любой тип
}
Это пример, написанный сходу.
В реальной программе такая типизация не сможет контролировать ошибочные преобразования.
Т.е. не будет контроля того, для чего строгая типизация вообще придумывалась. Точнее контроль будет очень локальным и частичным, но будет давать опасные предположения о типе переменной. В итоге, вам всё равно надо будет проверять тип, чтобы быть в нём уверенным.
Лучше вот так
www.php.net/manual/ru/class.splstring.php
Такая строгая типизация работает только для передачи аргументов в функцию.
В коде возможно присвоение любого типа данных.
Например:
function test(integer $i) {
$i = veryStrongCalculation();
return $i; //функция может вернуть любой тип
}
Это пример, написанный сходу.
В реальной программе такая типизация не сможет контролировать ошибочные преобразования.
Т.е. не будет контроля того, для чего строгая типизация вообще придумывалась. Точнее контроль будет очень локальным и частичным, но будет давать опасные предположения о типе переменной. В итоге, вам всё равно надо будет проверять тип, чтобы быть в нём уверенным.
Лучше вот так
www.php.net/manual/ru/class.splstring.php
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем PHP строго типизированным