Как стать автором
Обновить

Комментарии 43

Получается какая-то типизация ради типизации :)
в общем-то «да». Мне строгая типизация нужна исключительно для командной разработки, когда типы принимаемых аргументов совершенно очевидны
Почему-то думал, что одна из причин для выбора PHP как раз отсутствие типизации
у меня выбор PHP был из-за богатого набора встроенных функций и тесного переплетения с веб технологиями…
Это одна из причин по которой PHP-приложения — бесспорные лидеры по количеству дыр.
Type hinting может использоваться только для массивов и объектов.

Какой приведенного кода,

function teststring(string $string) { echo $string; }
teststring( 'string2' );

Если он вызывает ошибку? Я передаю строку, а интерпретатор хочет объект класс string.
Или нужно дополнительно написать классы string, integer и float…
вот именно для того, что бы не использовать только для array и для объектов и написан этот пост, а Вы даже не удосужились прочесть ЧТО в нем написано…
Хуже того, я даже нашел 5 минут времени чтобы запустить ваш пример.
Может я чего то не допонял, но в чем же здесь смысл?

Fatal error: Argument 1 passed to teststring() must be an object of class string

Мне теперь все строки в объектную оберку завернуть?
Вы это о чем?
О том что на php 5.1.х это не работает (на локальной машине у меня такой)
на 5.2.х — без вопросов.
в РНР5.1 и нативные type hint'ы не работают :)
Сходите еще раз в мануал по вашей ссылке.

>> Type Hints can only be of the object and array (since PHP 5.1) type.
А разве можно такое в продакшн-коде использовать?
вобщем-то — вполне, но сразу оговорюсь — на реальных проектах я это решение не использовал, а проверял только на нескольких скриптах с небольшим объемом кода и БЛ
Мне просто не понятно где это можно использовать. Как проверка пользовательского ввода? Не получится, потому что все от пользователя — строка. Родные функции php зачастую возвращают разные типы данных в разных условиях.

Да и потом особенность PHP в отсутсвии типизации простых типов. Это же фича, а не баг. А вы относитесь к этому как к багу.
в РНР6 появится опциональная поддержка питизации скалярных типов данных
Значит у нас есть еще 2 года, чтобы насладиться ее отсутствием. :)
У меня ощущение, что если нужна строгая типизация, то нужно сменить язык, например на Java
поймите — мой выбор РНР был абсолютно не из-за отсутствия строгой типизации :)
Как раз недавно писал на эту тему: Scala.habrahabr.ru/blog/30538/ радует, что и PHP присоединяется к компании.
Как раз недавно писал на эту тему: Scala.habrahabr.ru/blog/30538/ радует, что и PHP присоединяется к компании.
Это используется, как написал автор, чтобы PHP падал при попытке подать ему не то, что должно быть, только и всего. Это просто для программиста авто-проверка своего кода.
То есть это надо понимать как тест-кейсы?
Почти что. Это надо понимать так, что функция parseUrl(1) упадёт не потому что поняла, что урл левый а потому что передали ей не строку.
Проверка на разумное соответствие :)
Использовать можно, но не стоит из-за того, что количество таких проверок даже в средне-сложном движке может дойти до сотен, при этом каждые 50 проверок съедают примерно 1мс. Поэтому не стоит.
Я, собственно к этому и вел.
Бред какой то. Как связана типизация языка с командной разработкой? Может быть очень опосредованно только. Внедрение в язык, сама идеология которого подразумевает вольное обращение с типами данных, строгую типизацию, Вы фактически внедряете в телегу пятое колесо, причем стоящее под углом 90 градусов к 4-ем остальным. Высококвалифицированным разработчикам на PHP Ваша типизация не нужна, мало того она им вредит, так как заставляет в ряде алгоритмов вводить новые сущности, в случае, когда можно обойтись без них, получив более наглядный и эффективный код. С низкоквалифицированными разработчиками же вопрос решается жесткими стандартами кодирования и формализацией задач.
Именно. Проблема PHP не в том, что в языке отсуствует типизация, а в том, что PHP автоматически пытается преобразовывать типы данных. Приведённое решение отчасти помагает — но всё равно только отчасти и очень дорогой ценой…
Бред. Или принимайте язык таким, какой он есть, или используйте другой.

Я сам сторонник максимальной типизации, но не вижу здесь ничего полезного.

В маленьких проектах это бесполезно, а в больших получим неприемлемый оверхед на какую-то сомнительную фичу.

Это если не считать переподготовки специалистов — нельзя вот так сразу начать фигачить строго типизированный код, здесь образ мышления менять надо…
Ну во-первых не стоит называть бредом все с чем ВЫ не согласны.
во-вторых — касательно производительности. Только что специально проверил — на каждую проверку мы убиваем 0.002 секунды (это на моем ноутбуке. на сервере думаю меньше), так что кое-где, но данный подход может иметь место. Более того, кто мешает сделать перед продакшном что-то типа:
preg_replace( '/[\(,]\s+(string|integer|float|resource)/i', '', $file ); <code> по всем файлам?
Беру бред назад, хотя если бы считал это бредом, не писал бы комментарий, думал что это очевидно…

>> Более того, кто мешает сделать перед продакшном что-то типа:
preg_replace( '/[\(,]\s+(string|integer|float|resource)/i', '', $file ); по всем файлам? Ну это сильно зависит от модели обновления кода на сервере, да и весомая часть полезности теряется. Более того, без встроенной в язык типизации переменных и возвращаемых значений вряд ли можно надеяться на достаточную формализацию кода. Еще можно залезть в исходники PHP и пропатчить все там, но это будет совсем другой язык. Но все равно есть ограничение, которое обойти не удастся. Как правило, строгая типизация требует отдельного процесса - компиляции. В динамических же языках типа PHP все происходит в рантайме. Например, в C++ в рантайме нет типов как таковых - энное количество байт в памяти может быть чем угодно - целым, float, строкой, объектом какого-то типа, пользовательским псевдотипом... За типами следит компилятор, которого в динамических языках нет (как такового). Так что приемлемой "красивости" все равно достичь не удастся.
То есть возможность строгой типизации — это либо внедрение этапа компиляции (на котором компилятор сразу должен знать все про все модули), либо хранение в памяти типа данных и его проверка в рантайме (при каждом чихе) — то есть в большинстве случаев неприемлемый оверхед.
PHP всегда был строго типизированным. Не следует это путать с динамической типизацией. Эти понятия ортогональны.
Извините, но:

«Строгая типизация подразумевает выполнение следующих обязательных условий:

1. Каждое значение, переменная, параметр и возвращаемое значение функции на этапе проектирования программы безусловно привязывается к определённому типу данных, который не может быть изменён во время выполнения программы (т. н. статическая типизация).
2. Допускается присваивание переменной только значения, имеющего строго тот же тип данных, что и переменная, те же ограничения действуют в отношении передачи параметров и возврата результатов функций.
3. Каждая операция требует параметров строго определённых типов.
4. Неявное преобразование типов не допускается (то есть транслятор воспринимает любую попытку использовать значение не того типа, который был описан для переменной, параметра, функции или операции, как синтаксическую ошибку).»

неужели в РНР эти условия выполняютя? о_О
Вы правы. Разобрался по английской википедии. PHP — слаботипизированный язык. Ортогональными понятиями являются: статическая/динамическая типизация, строгая/слабая типизация, safely/unsafely typed system. Для PHP, похоже, так: динамическая, слабая, unsafely.
а как насчет дефолтного значения? например:
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
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории