То что в PHP не сложилось с культурой кода и вызывает такие темы. Вернее из-за того что интерпретатор мало что контролирует. Это все больше начинает быть похожим на какую-то религию со своими заповедями:
1. Все «крутые программисты» пишут на PHP как на Java
2. Пишите так как сказал X, а если нет, значит вы мудак и попадете в ад
Мне нравиться ООП. Я всего лишь доношу то что ваши мысли по поводу сеттеров, геттеров и анти-паттэрнов не верные в контексте PHP. Но все же хочу услышать вразумительный ответ на вопрос что задал.
Что вам дает сеттер в PHP если вы не можете контролировать все типы данных?
Т.е. вы предлагаете например со скалярными типами работать через обертки и type hinting или как?
$port = new Int(8080); ->setPort(Int $port);
Вы пропагандируете доктрину, основываясь на одной парадигме программирования. А конкретно ООП. Но поскольку PHP сам по себе это гибрид и то что вы считаете якобы «качеством кода» которое можно применить в PHP это ничто иное как туфта, уж извините за резкость. Так как в PHP есть псевдо ООП и нет возможностей чтобы реализовать чистое ООП. Да что там, даже type hinting не полный, так как нельзя контролировать типы в полной мере. Так что рассуждения о сеттерах геттерах и анти-паттэрнах это доктрина которую вы себе решили лучшей, не обдумывая в каком окружении вы работаете. Если вы считаете что например решение задавать свойства через геттеры в гибридном языке это истина, то я даже не знаю как вы это собрались делать в языке с динамической типизацией. $port = new Int(8080); ->setPort($port); Так что ли?
P.S. Замыкания по сути тоже инициализация, только объекта класса Closure. Безусловно неким количеством памяти можно пожертвовать на это но зачем? Я просто выгоды не вижу. Да получается статика, но явная статика ты полностью уверен что метод возвращает нужный тип/класс.
А вообще задача решает все. Но ИМХО в 98% DI в PHP вообще не нужен и постоянно брать его за основу для «больших» проектов можно только по очень большой приверженности к нему.
Я использую Lazy initialization, Proxy, Registry, причем от третьего иногда отказываюсь. DI я использовал и у меня появлялись постоянно преграды в рефакторинге, а когда нужно быстро сделать прототип проекта это занимает очень много время в Lazy initialization или Proxy мне приходится переписать всего один метод в случае изменений и поверьте с головой хватает, причем все вещи сделаны явно и производительность не страдает совсем(!).
>> то все очень даже удобно
Это ваше субъективное мнение. Не только я лично отказываюсь от этой ОRМ в частности из-за этого. Считаю полнейшим бредом добавлять возможности на основе комментариев (строк) в язык. Если это считать как ничего страшного то можно дойти до того что будут реализовывать декораторы в манере python только с помощью строк.
Насчет DI тут кому как нравиться, у меня руки не отвалятся написать явный реестр явно инициализированных объектов, а не городить обертку ради очень сомнительной выгоды в динамическом языке. Вы можете ссылать на какой то абстрактный «большой» проект, но лучше если бы вы реально написали какой плюс от DI на реальном примере.
Как то дурно это все пахнет. Какой то неявный Registry, что наводит на мысли что магия это зло, если это не возможность языка. Это как с аннотациями, когда начинают парсить аннотации с комментариев в скриптах, блевать хочется.
Причем тут инклуды вообще?! С вашей логикой можно сказать что и MVC это инклуды, а что разве нет? Те же инклуды только происходят в определенном порядке. Идя по вашей логике можно сказать что http это вообще набор слов и чисел, что будет верно но далеко от истины. Как вы приплели сюда к трэйтам стандартные голые включения php кода я не знаю. Вы пишите кроме пхп на каком то языке где есть трэйты? Как можно судить даже не попробовав, у меня это в голове не укладывается.
>> А сколько информации нужно будет загрузить в мозг новичку в вашем проекте
Так давайте вообще ООП c php выкинем, а то у бедного новичка мозг кипятится.
>> одно требование — понятность
Я может вам глаза приоткрою но пхп чуть ли не худший язык чтобы понимать что-то глядя на исходный код. Так как в большистве случаев без проверки var_dump вы даже не знаете какой тип имеет переменная или возвращает метод. А поскольку многие пхпшники не знают что такое тестирование баг и php код как брат с сестрой.
>> Пока их не много — они помещаются у вас в голове(все пять)
В голове абсолютно ничего держать не надо, если код покрыт тестами. Если вам нравиться держать все в голове это ваше право, если же у вас есть архитектура, есть тесты или например TDD, то вы не сможете по крупному наговнокодить. Поэтому говнокод только в голове.
* Весь говнокод в голове. Никакая парадигма не спасет от этого.
* Нужны почти всегда если написать в MVC и DRY. При наличии типажей и примесей можно делать очень тонкие контроллеры. Вот например вам не нужно в каждом контролере аутентификация или сессии или мэйлер. Так почему бы не подключить когда они нужна user Session, Auth, Mailer;(конечно можно через глобальный реестр делать вызов их, но тут как кому нравиться) Или реализовать фильтры как цепочка вызовов use CSRFFilter, DoSFilter; Т.е. теперь не нужно лепить кучу статических методов чтоб может когда-то инициализировать какое то свойство. Вот в чем вся и прелесть.
Альтернатива рано или поздно появляется, если этот продукт востребованный. Никто не упустит откусить кусок пирога. Дело другое насколько этот продукт хорош, если есть хороший продукт и рынок, инвестиции ждать не придется. Поэтому ИМХО вы ооочень сильно драматизируете.
Вы уж матерый Сишник извините, но сишные либы пишутся очень долго(по несколько лет), пока они становятся стабильными. Если сравнить написать стабильную либу на Си и на Джава, то в второе с первого раза будет и стабильнее и нааамного быстрее(в разработке).
Монополия это не дуло пистолета, как говорится — не нравиться используйте альтернативу. В чем проблема? Или проблема в том что альтернатива хреновенькая? Google Chrome(Chromium) это отличный браузер. Google делает отличные продукты, поэтому люди их используют или вы не согласны? Я думаю тут каждый второй с хабра Reader-ом пользуется, и другими сервисами. Вот все так боятся монополии, ну так альтернативу предложите, что за ментальность такая ныть постоянно?
Я не знаю почему столько сомнений у Вас, но я думаю язык будет намного понятнее большинству программистов знакомых с классовым ООП. Это что касается новичков. Ну так уж сложилось что большинство знают именно классовое ООП и оно намного больше используется, а если еще программист когда либо работал или хотя бы знакомился с статической типизацией то изучение Dart займет от 1 дня до недели, чтоб писать не плохо. И вот скажите в чем тут беда? Я думаю что наоборот это замечательно, так как я отношусь к JS скажем так не холодно не жарко и пишу на нем только из необходимости. Ну если не приживется Бог с ним, но альтернатива то чем плохо? А вот как раз гневные посты против Dart, попахивают некими теплыми чувствами к JS. Если в Dart добавят еще сахар как в Scala то это будет отличный язык ИМХО.
1. Это не язык поверх JS. Это отдельный язык на данный момент использующий трансляцию в JS. Это не значит что это всегда так будет.
2. Не конфликтовать наверно может гарантировать область видимости, вы то сами как думаете? Вы же не ставите вопрос, «кто мне гарантирует в каждой браузере document.querySelector», логично что производитель браузера и гарантирует либо либа какая-то либо что вы сами себе гарантируете.
3. «Запуск jQuery на Dart… Т.е. рождение костыля» — может я открою для вас тайну но реализация DOM не имеет никакого отношения какой язык используется. Это API. Поэтому jquery вообще тут не причем.
Вас под дулом пистолета никто не заставляет использовать этот язык. Это язык даже без версии пока. Поэтому в продакшине адекватные люди врядли счас его будут использовать.
>> Все его штучки в том или ином виде давным давно есть
А что вы хотели написать do Chuck Norris и программа готова? Вот и напишите спецификацию, устройте презентацию крупным компаниям, сможете доказать эффективность вашего сферического коня, может получите грант. А просто говорить о какой супер абстрагированном языке все могут.
1. Все «крутые программисты» пишут на PHP как на Java
2. Пишите так как сказал X, а если нет, значит вы мудак и попадете в ад
Что вам дает сеттер в PHP если вы не можете контролировать все типы данных?
Т.е. вы предлагаете например со скалярными типами работать через обертки и type hinting или как?
$port = new Int(8080); ->setPort(Int $port);
А вообще задача решает все. Но ИМХО в 98% DI в PHP вообще не нужен и постоянно брать его за основу для «больших» проектов можно только по очень большой приверженности к нему.
Это ваше субъективное мнение. Не только я лично отказываюсь от этой ОRМ в частности из-за этого. Считаю полнейшим бредом добавлять возможности на основе комментариев (строк) в язык. Если это считать как ничего страшного то можно дойти до того что будут реализовывать декораторы в манере python только с помощью строк.
Насчет DI тут кому как нравиться, у меня руки не отвалятся написать явный реестр явно инициализированных объектов, а не городить обертку ради очень сомнительной выгоды в динамическом языке. Вы можете ссылать на какой то абстрактный «большой» проект, но лучше если бы вы реально написали какой плюс от DI на реальном примере.
>> А сколько информации нужно будет загрузить в мозг новичку в вашем проекте
Так давайте вообще ООП c php выкинем, а то у бедного новичка мозг кипятится.
>> одно требование — понятность
Я может вам глаза приоткрою но пхп чуть ли не худший язык чтобы понимать что-то глядя на исходный код. Так как в большистве случаев без проверки var_dump вы даже не знаете какой тип имеет переменная или возвращает метод. А поскольку многие пхпшники не знают что такое тестирование баг и php код как брат с сестрой.
>> Пока их не много — они помещаются у вас в голове(все пять)
В голове абсолютно ничего держать не надо, если код покрыт тестами. Если вам нравиться держать все в голове это ваше право, если же у вас есть архитектура, есть тесты или например TDD, то вы не сможете по крупному наговнокодить. Поэтому говнокод только в голове.
* Нужны почти всегда если написать в MVC и DRY. При наличии типажей и примесей можно делать очень тонкие контроллеры. Вот например вам не нужно в каждом контролере аутентификация или сессии или мэйлер. Так почему бы не подключить когда они нужна user Session, Auth, Mailer;(конечно можно через глобальный реестр делать вызов их, но тут как кому нравиться) Или реализовать фильтры как цепочка вызовов use CSRFFilter, DoSFilter; Т.е. теперь не нужно лепить кучу статических методов чтоб может когда-то инициализировать какое то свойство. Вот в чем вся и прелесть.
2. Не конфликтовать наверно может гарантировать область видимости, вы то сами как думаете? Вы же не ставите вопрос, «кто мне гарантирует в каждой браузере document.querySelector», логично что производитель браузера и гарантирует либо либа какая-то либо что вы сами себе гарантируете.
3. «Запуск jQuery на Dart… Т.е. рождение костыля» — может я открою для вас тайну но реализация DOM не имеет никакого отношения какой язык используется. Это API. Поэтому jquery вообще тут не причем.
Вас под дулом пистолета никто не заставляет использовать этот язык. Это язык даже без версии пока. Поэтому в продакшине адекватные люди врядли счас его будут использовать.
А что вы хотели написать do Chuck Norris и программа готова? Вот и напишите спецификацию, устройте презентацию крупным компаниям, сможете доказать эффективность вашего сферического коня, может получите грант. А просто говорить о какой супер абстрагированном языке все могут.