LINUX.ORG.RU

Ответ на: комментарий от SaBo

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

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

valich ★★★ ()
Ответ на: комментарий от heisenberg

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

jeep ()
Ответ на: комментарий от jeep

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

heisenberg ★★ ()
Ответ на: комментарий от heisenberg

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

jeep ()
Ответ на: комментарий от heisenberg

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

jeep ()
Ответ на: комментарий от jeep

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

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

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


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



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

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

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

heisenberg ★★ ()
Ответ на: комментарий от heisenberg

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

jeep ()
Ответ на: комментарий от heisenberg

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

jeep ()
Ответ на: комментарий от heisenberg

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

jeep ()
Ответ на: комментарий от jeep

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

heisenberg ★★ ()
Ответ на: комментарий от jeep

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

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

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

Например?

tailgunner ★★★★★ ()
Ответ на: комментарий от jeep

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

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

kifer ()
Ответ на: комментарий от heisenberg

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

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

Lucky ★★ ()
Ответ на: комментарий от jeep

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от jeep

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

jeep ()
Ответ на: комментарий от KRoN73

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

jeep ()
Ответ на: комментарий от KRoN73

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

anonymous ()
Ответ на: комментарий от heisenberg

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

jeep ()
Ответ на: комментарий от jeep

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

jeep ()
Ответ на: комментарий от jeep

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

heisenberg ★★ ()
Ответ на: комментарий от heisenberg

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

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

Lucky ★★ ()

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

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

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

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

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

String str('bla-bla');

SaBo ★★ ()
Ответ на: комментарий от heisenberg

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

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

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

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

KRoN73 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.