потому что интерфейс создания объекта не является частью интерфейса объекта?

в нормальных языках :)

итак: - конструктор нарушает LSP почти всегда... это никого не интересует? - вызывать его как метод не имеет смысла, но он доступен как метод... это типа ок? - жизненный цыкл обьекта - это что-то новое, неизученное в ООП - есть отличный способ обойтись без конструктора-метода, например как в Scala

не нарушает конструктор лсп, вызвать его как метод можно наверное в пыхе, но в пыхе много чего можно. Жизненный цикл объекта что-то новое в ооп? о.о

ссылки в студию! иначе несчитово

ссылки чего?

на жизненный цикл обьекта

а то я как-то давно варюсь в этой каше, но не встречал еще нормальных статтей о жизненном цыкле обьекта

на жизненный цикл обьекта

https://en.wikipedia.org/wiki/Object_lifetime

ну эту и я видел, но вот и всё

что все?

ну сложно найти ответы по поводу хорошо это или плохо, как с этим жить, почему в некоторых языках так, а не иначе

"хорошо это или плохо" это надо в детских книжках смотреть

там про хорошо и плохо в основном

"хорошо это или плохо" это надо в детских книжках смотреть

с такими рекомендациями только в детском садике и преподавать, а не в этом чатике сидеть

хватит его кормить с этими конструкторами...)

ну сложно найти ответы по поводу хорошо это или плохо, как с этим жить, почему в некоторых языках так, а не иначе

ну тут надо в историю вникать.... ресерчить) сам понимаешь) ну и по поводу хорошо или плохо - Эскобар

Пабло?

нет

не стоит их использовать. Во всяком случае в новых проектах. Трейты вполне себе могут быть неплохим инструментом для рефакторинга как временная мера но не более того. Ключевое слово - временная мера. еще один пример разумного использования трейтов - дефолтная реализация интерфейсов. Пример - EntityManagerInterface из доктрины. Если ты хочешь предоставить возможность разработчику удобно делать декораторы - трейт который делает проброс всех вызовов этого интерфейса в некий wrappedInstance это более чем нормально.

Macroable в ларавел, который позволяет дергать нестатически объявленные методы статически

Macroable в ларавел, который позволяет дергать нестатически объявленные методы статически

звучит как что-то очень плохое

Как то даже неприлично

звучит как что-то очень плохое

С точки зрения дизайна - да, с точки зрения юзабилити - весьма удобно

Вот это кстати погано вообще

С точки зрения дизайна - да, с точки зрения юзабилити - весьма удобно

мне надо это увидеть что бы делать выводы

Приводит к ситуации когда вокруг происходит полнейшая чертовщина, но всем норм потому что удобно

Рубистайл

Model::find(1); Под капотом там резолв модели из контейнера с зависимостями и враппер на калл статик который проксирует статику в обычный метод

рубистайл с аннотациями типов и здравым смыслом по идее удобно))) а вот попытка перенести руби стайл в php я вижу обреченной на "успех" изначально

Model::find(1); Под капотом там резолв модели из контейнера с зависимостями и враппер на калл статик который проксирует статику в обычный метод

а ты об этом... а нафига там трейты?

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

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

звучит очень плохо)

Но удобно :)

https://github.com/illuminate/support/blob/master/Traits/Macroable.php

эдакий гибрид сервис локаторов и недомиксинов....

Но удобно :)

все относительно)))

p.s. ты не думай, я тоже такими штуками обмазывался.... лет 5 назад

И дело привычки, согласен :)

ну то есть я могу сравнивать подходы)

Ну мне после симфы многое тоже в ларе глаз режет, но любые фичи девелопятся быстро и удобно, и пока меня это устраивает

Ну мне после симфы многое тоже в ларе глаз режет, но любые фичи девелопятся быстро и удобно, и пока меня это устраивает

что если я скажу что симфони тоже говно (ну местами, некоторые вещи как и в ларе норм)

да и потом.... причем тут симфони, ты там тоже можешь говном обмазываться подобным образом))

просто это не из коробки и сложнее)

просто это не из коробки и сложнее)

+

пока у тебя нет нужды влазить во внутренности фреймворка - лара вполне себе хороший DSL

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

но только не лезь в ядро!)

но только не лезь в ядро!)

истину глаголишь :) там такой треш

симфони, правда, еще хуже

ой врядли

ой, уж я то знаю, колупаю симфу каждый день

симфони выигрывает только в одном аспекте: модули и конфигурация

https://phpclub.ru/talk/threads/%D0%9D%D0%B5%D0%B4%D0%BE%D0%9E%D0%9E%D0%9F-%D0%BE%D1%82-laravel-%D1%87%D0%B0%D1%81%D1%82%D1%8C-2.83993/ вот такое там врядли встретишь я думаю

тайпклассы с приоритетами)

ну в симфе не хуже бывает

эт да

из сегодняшнего: симфони использует некий phpunit-bridge, который внутри себя при запуске (вместо пхпюнита, типа ./bin/simple-phpunit) по прошитому намертво урлу выкачивает с гитхаба пхпюнит, ложит его в определённую папочку и запускает его

Если не симфа/ларавел, то что?

пока ничего нет

Ыыы - те же грабли, но в профиль

зенд - там тоже по особенному

Если не симфа/ларавел, то что?

ну я не думаю что когда-либо появится какой-то эдакий фреймворк который "ну вот все ребята, теперь все будут довольны".

это будет уже пост-фреймворковый мир

я думал они хотят сделать опять набор прекрасных, "но других" компонентов, с которых ты можешь собрать свой фреймворк, но там тоже грусть под капотом

зенд - там тоже по особенному

Точно. Только из-за того, что «особенный» и не хочется юзать

ну я не думаю что когда-либо появится какой-то эдакий фреймворк который "ну вот все ребята, теперь все будут довольны".

))Оурэл бы написал...

это будет уже пост-фреймворковый мир

+1))

да не будет идеального фреймворка. такого чтобы и блог за 30 минут и ынтерпрайз писать

лебедь рак и щука

да не будет идеального фреймворка. такого чтобы и блог за 30 минут и ынтерпрайз писать

ну логично, совершенно ж разные задачи

а зачем вам фреймворк?

да не будет идеального фреймворка. такого чтобы и блог за 30 минут и ынтерпрайз писать

Энтерпрайз за 30 минут для чайников )

я пробовал начинать писать самый лучший фреймворк на пхп, несколько раз начинал

ну то есть ..... проблема то не в том что там "ларавель говно" или "симфони ниоч" а в том что есть огромное комьюнити людей которые знают один инструмент и его применяют везде

но я всегда упирался в непобедимую проблему, угадайте какую)

а зачем вам фреймворк?

Чтоб с великом не заморачиваться

но я всегда упирался в непобедимую проблему, угадайте какую)

Поиск лучшего

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

Чтоб с великом не заморачиваться

дык взял psr7/11 и поехала на компонентах

Поиск лучшего

не, не так глобально, я реалист

не, не так глобально, я реалист

Все мы реалисты)))в чатах

но я всегда упирался в непобедимую проблему, угадайте какую)

ты просто не можешь сделать лучше :D

не увеличивая сложность :)

ты просто не можешь сделать лучше :D

скорее всего да, но в чем причина?

скорее всего да, но в чем причина?

вероятно яп

вероятно яп

в точку!

ты просто не можешь сделать лучше :D

Типа без jquery работаешь?))

+ уровень разработчиков

как бы я не пытался улучшить то, что есть - в итоге говно получается)

вопрос что есть лучше и лучше ли будет, когда будет правильнее но сложнее ?

вряд ли

я наблюдаю следующую проблему. Есть господин А, и господин Б. Первый начал делать штуки. Штуки прикольные но местами не оч. Господин Б ваял бэйзкампоклоны пачками и захотелось ему упростить поточную разработку. И взял он компоненты господина А и завернул сверху в свои штуки что бы было удобнее чисто под него. Народ разделился на два лагеря и начали хаять друг друга вместо колоборации и сотрудничества (хотя оно есть конечно, в самом ядре, но очень странное). А потом появляется еще какой-нибудь вася пупкин и говорит "херня это ваше MVC - вот вам ADR, а еще вот вам моя собственная ORM... и DBAL, и вообще вот мои крутые компоненты"..... И каждый в целом делает одно и то же и примерно одинаково херово.... Ну и еще из 1000 человек может быть у одного будет какая-нибудь дельная мысль.... и то не факт что он что-то реализует. Ну короч.... сегрегация комьюнити на почве фреймворков, разжигание межфреймворковой розни, стогнация комьюнити.

и главное - все будут гнать линию "норм симфони для маленьких проектов" или "норм ларавель для больших проектов"

и в итоге вместо специализации мы опять идем к обобщению подходов и как следствие к еще большому количеству проблем

при этом почти никто думать не хочет, а от того все еще печальнее

я все таки вижу проблему в другом: никто не подходит к созданию фреймворка с правильного конца

я все таки вижу проблему в другом: никто не подходит к созданию фреймворка с правильного конца

?