[php] SPL Type Handling - плюсы/минусы

Покопал я поглубже это дело... Ну его нафиг. Не готов ещё PHP к типам данных :(

> стоит ли её внедрять в проекты?

Не такая уж это глобальная вещь. А внедрять конечно стоит, если разрабатываешь не простенькие класс(ы) или библиотеку, которую потом будут использовать другие разработчики.

внедрять обязательно, создавать на их основе свои типы данных

Кстати, какие выгоды сулит строгая типизация в скриптовом языке??? А вот проблем получить можно несоизмеримо. PHP - язык для своих целей. На нем не нужно писать ОС или системные утилиты или что-то ресурсоемкое. К слову о безопасности. Проблема безопасности тут больше я думаю в соблюдении некоторых правил. Нужно позаботится о некоторых узких местах в веб-приложении и все. Для этого очень большое количество фреймворков уже создано. Да и никакая типизация не спасет человека, если программирование начинается с написания кода. ИМХО строгая типизация в скриптовом языке - бесполезно.

Строгая типизация позволяет нормально описать абстрактную модель данных - это то, без чего применение ООП сводится к классам, содержащим схожие по смыслу методы. PHP - язык для своих целей, но диапазон этих целей гораздо шире, чем вы (судя по всему) себе представляете. В системах посложнее, чем сайт-визитка, между контроллером и моделями лежит слой бизнес-логики, именно с проектирования его интерфейсов, говоря упрощенно, начинается разработка программы. В пхп и так интерфейсы ущербны (нет возможности указать тип возвращаемого значения), но если и параметры не типизировать, то ничего хорошего не получится и программа превратится в это: http://www.linux.org.ru/forum/web-development/5875965

Я отлично представляю как выглядит архитектура фреймворка. Знаю содержимое нескольких. Знаю и что такое бизнес-модель,и умл. Много чего использовал и использую. Вы наверно не правильно поняли меня в другой теме. Говоря, что я не участвовал в командной разработке, я не имел ввиду что мне до 16 и что я не имею опыта разработки. И возвращаясь к теме, о «проектировании интерфейсов» в каком конкретно месте разработки у вас возник(ли/али) сложности? Возможно, если вы с нами поделитесь, мы вам поможем. Возможно и я внесу свои 5 копеек.

По поводу ссылки. Чтобы вы там себе не думали, а я уважаю, таких ребят как этот. Хотя бы только потому, что дело затеял не дурное. Если вы не поняли, то такой процесс называется - обучение, самообразование. На практике по матану (ну если вы учились в вузе), когда вам дают задачи и вы решаете их не правильно, преподователь не называет вас долбоебом. Или, если вы спрашиваете у человека совета обычно он не посылает вас нахуй, потому что вы дебил, раз это не знаете. А молодой человек, этот он молодец. Потому, что он сделает раз, потом переделает, потом книжку прочитает и будет результат.

Какой-то странный у нас с вами разговор получается:

- какие выгоды сулит строгая типизация в скриптовом языке???

- типизация позволяет ... абстрактную модель данных ... тря-ля-ля

- не надо мне тут ничего объяснять, мне не 16 лет, я много видел и много знаю!

Ничего удивительного, что вместо помощи людей на этом форуме зачастую подвергают унижениям и остракизму вплоть до доведения до суицида. По существу могу сказать следующее: нет, сложностей при проектировании интерфейсов не возникало, именно благодаря строгой типизации.

В свою очередь хочу узнать, какие конкретно проблемы возникли у вас при использовании строгой типизации:

А вот проблем получить можно несоизмеримо.

Строгая типизация нужна там, где нужна. Ни разу мне еще при проектировании веб приложения не понадобилось использовать ее. Всегда хватало того, что есть в пхп. Проблемы всегда были, как у нормального разработчика и они решались. Правда не в контексте веб прогрммирования. Строгая типизация для построения веб приложений не нужна.

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

Кстати сказать хочу отписаться по поводу последней реплики RE: «но если и параметры не типизировать, то ничего хорошего не получится и программа превратится в это: Страницы вида сайт/юзер . Так вот никакая типизация, даже сверх мега жесткая, не имеет отношение к разработке приложения. Можно и С и на С++ написать очень плохое приложение, несмотря на то, что там как раз типизация жесткая. Скорее всего вы пишите программы, те вы „кодер“, поэтому для вас это так важно. А разработчик программу разрабатывает и ему даже не очень обязательно знать строгая типизация там или нет. Собственно принять решение о том на каком языке будет написано приложение можно не с самого начала, а где-нибудь на начальном этапе проектирования. Конечно тут все зависит от модели проектирования, которую выбрали и можно конечно заранее договориться, но это совсем не обязательно.

Эко вас зацепило ) Нет, я не кодер, я технический руководитель одного интернет-проекта и занимаюсь (в том числе) проектированием архитектуры приложений, из которых этот проект состоит. Под разработкой я подразумевал не только написание кода, но и как раз проектирование структуры программы и компонентов бизнес-логики в том числе. Без строгой типизации вы просто не построите нормальную UML-диаграму, поскольку в описании интерфейсов на ней будут отсутствовать типы параметров методов и возвращаемых ими значений. Либо придется использовать для обмена данными между объектами (или статическими классами логики) примитивные типы и их массивы - это тоже очень плохо, поскольку абстрактная модель данных как таковая отсутствует (хотя это лучше, чем случай, описанный в том самом топике. Думаю, для его автора это - следующий шаг).
Еще раз отмечу, что строгая типизация - это очень важная часть, необходимая для проектирования нормальной ООП-программы даже на пхп. А то, что она вам не понадобилась, говорит лишь об уровне тех задач, которые вам приходилось решать. Либо о небольшом сроке поддержки написанных проектов. Возможно, строгие типы данных - это не всегда удобно, он рассчитывать на то, что «оно там само приведется к нужному типу» - безумие, любое неконтролируемое приведение типов - это потеря данных, рано или поздно это приведет к проблемам.

> Кстати, какие выгоды сулит строгая типизация в скриптовом языке???

Такие же, как в нескриптовом.

А вот проблем получить можно несоизмеримо.

Например?

>Строгая типизация для построения веб приложений не нужна.

Строгая типизация многократно упрощает рефакторинг.

> строгая типизация - это очень важная часть, необходимая для проектирования нормальной ООП-программы даже на пхп.

что вы называете строгой типизацией?

>Ни разу мне еще при проектировании веб приложения не понадобилось использовать ее.

Значит, приложения были небольшими. Или Вы не обращались к ним год спустя :) Или Вам не лень делать крюк в семь вёрст :)

Строгая типизация избавляет от массы ошибок и снижает вероятность поломать всё год спустя.

>А если вам не имется и все же хочется строгую типизацию, создайте свой ЯП.

А что, готовые популярные и массовые ЯП со строгой типизацией уже отменили? :D

Если обращаясь год спустя к приложению вероятность что-то поломать так высока, то это говорит как раз о том, что писал код - «кодер». Документацию еще никто не отменял, так же как и комментарии к коду. Здесь такие же претензии как у разработчиков на с к разработчикам на с++ по поводу документации.

Вроде бы нет, не отменяли. Все тот же питон и вроде бы руби. Так, что пхп ниче не нужно добавлять. Если охота язык использовать со строгой типизацией, то пожалуйста. Хотя я все таки считаю, что выбор языка при разработке не должен иметь первостепенное значение. Главное, чтобы все работало хорошо и отлажено.

Кстати, я тут надумал сделать свой mvc-фреймворк + fastcgi-сервер на C++/Qt4 ))

«Без строгой типизации вы просто не построите нормальную UML-диаграму, поскольку в описании интерфейсов на ней будут отсутствовать типы параметров методов и возвращаемых ими значений. ...» Для этого есть расширения умл: стереотипы,помеченные значения,ограничения.

>Если обращаясь год спустя к приложению вероятность что-то поломать так высока, то это говорит как раз о том, что писал код - «кодер»

Мсье - теоретег? :)

Не очень. На самом деле я и сам так грешу. Все так грешат, что документировать код хорошо - это сложно. Сам недавно пришел к тому, что сначала нужно писать не код, а рисовать как можно больше диаграмм, и более подробно описывать, то что делаешь.

>Все так грешат, что документировать код хорошо - это сложно
Нет, не сложно. Достаточно использовать phpDoc и какую-либо из систем непрерывной интеграции для автоматической сборки - и всегда будет актуальная документация по проекту. И изучать документацию проекта, где есть строгая типизация, проще и удобнее (на мой взгляд), поскольку про любой тип параметра можно изучить, перейдя по гиперссылке. А не так, что «ага, первый параметр этого метода - число, второй - массив... а что там в массиве надо передавать... блин в доке не написано, надо лезть в код» - это, кстати, нарушение инкапсуляции.
Но, скорее всего, выше правильно сказали - вы просто теоретик. Либо одинокий фрилансер, не имеющий представления о серьезных проектах. Об этом же говорит ваше заблуждение, что пхп - это «язык для своих целей, на котором нельзя писать что-то ресурсоемкое» и поэтому строгая типизация там не нужна. Расскажите это ребятам из flickr и facebook.

> Расскажите это ребятам из flickr и facebook.

про что именно рассказать - создание HL-проектов или строгую типизацию как важную часть проектирования нормальной ООП программы. ;)

Меня вот, что смущает... Если провести аналогию C++ и PHP, то получается, что код, написанный на PHP:

$str = new SplString('bla-bla');

«Равен» коду на C++:

String *str = new String('bla-bla');

Хотя в данном случае следовало бы так:

String str('bla-bla');

>А не так, что «ага, первый параметр этого метода - число, второй - массив...

Это ещё что... Я лет 8 назад насажал в некоторые места «умные» методы, которые сами разбирают свои аргументы. Ага, если первый параметр число, то это ID класса, если строка букв - то это имя класса, если URI-шного вида, то это URI ресурса. Чтобы одним методом всё грузить :D

До сих пор расхлёбываю.

И, ведь, в Thinking Forth же очень важным пунктом шло - «Не делайте умные [разбирающие контекст] слова. Делайте тупые слова. Это не усложнит разработку, но сильно упростит отладку и поддержку». 15 лет назад я этого правила не понимал и забил на него. Оказалось - очень верное :)