сопроводительную документацию или документ по интеграции сюда не поместить конечно

я не об этом

вопрос документации это тоже очень большой вопрос

но условно говорю об этом https://pastebin.com/BZNBbzh4

потому лучше исходить из целей

а не делать доку ради доки

какой вариант предпочтительней)

какой вариант предпочтительней)

тот где инстанс PDO инджектится

с точки зрения трудозарат он одинаковый, да в случае с vo и dto и builder трудо затрат по больше но не так что прямо уж очень)

тот где инстанс PDO инджектится

согласен

@KuvshinovEE хотел бы подвести некоторые итоги. 1. По документации. VO так же само будут описаны docblock. И документирование кода так же один из типов сопровождающей документации. В аспекте документирования я могу заметить, что ее будет значительно больше по объему, но не по смысловой нагрузке. 2. Ты говорил, что подсчет экономической эффективности не дело программиста. Но следует участь тот факт, что твоя оценка трудозатрат и будет довольно значительно влиять на итоговую оценку экономической эффективности.

короч "славься information hiding" и на этом в целом дискуссию можно закрывать

@KuvshinovEE хотел бы подвести некоторые итоги. 1. По документации. VO так же само будут описаны docblock. И документирование кода так же один из типов сопровождающей документации. В аспекте документирования я могу заметить, что ее будет значительно больше по объему, но не по смысловой нагрузке. 2. Ты говорил, что подсчет экономической эффективности не дело программиста. Но следует участь тот факт, что твоя оценка трудозатрат и будет довольно значительно влиять на итоговую оценку экономической эффективности.

1. VO и вся концепция Whole Value, это часть декомпозиции системы. То есть если у тебя все ок с декомпозицией, все ок с information hiding, у тебя код будет самодокументрируемым. А в docblock у класса/метода можно доп детали дать если надо. 2. cost benifits анализ строится на всей имеющейся информации, в том числе на оценке сложности которую может дать разработчик. Это скорее гадание и т.д. и за финальные решения программист уже не отвечает.

@KuvshinovEE хотел бы подвести некоторые итоги. 1. По документации. VO так же само будут описаны docblock. И документирование кода так же один из типов сопровождающей документации. В аспекте документирования я могу заметить, что ее будет значительно больше по объему, но не по смысловой нагрузке. 2. Ты говорил, что подсчет экономической эффективности не дело программиста. Но следует участь тот факт, что твоя оценка трудозатрат и будет довольно значительно влиять на итоговую оценку экономической эффективности.

если ты берешь пример сложного массива с большим количеством ключей и рядом такойже dto то объем одинаковый примерно

к слову да, кода с VO не сильно больше

(его больше потому что надо структуру описать но это копейки и окупается легко и быстро)

именно

пример с pdo не очень, но это для наглядности, там действительно лучше сразу готовый pdo передавать )

а так - заюзаешь массив, сэкономишь 5 минут. и потом потеряешь день

а так - заюзаешь массив, сэкономишь 5 минут. и потом потеряешь день

вот +++

люди про "потом" просто не думают

быстрее сдать и забыть

у меня сейчас проект где мы работаем

у меня сейчас проект где мы работаем

ух ты

люди стараются делать лучше но кругом массивы

кругом

и возвращают массивы

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

если людям так удобно - то пусть. Думаю массивы это не самая большая ваша проблема на данный момент

да согласен не главная проблема

но например они не очень понимают зачем dip и как юзать di

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

это надо делать, массивы вжух и коммитим

но например они не очень понимают зачем dip и как юзать di

ну как и большинство

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

и тд но это наше локальное нытье)

я просто сейчас решил стримить конкретные проблемы

и как можно решать

люди про "потом" просто не думают

Я согласен, что есть ситуации в которых стоит описать объектами. Но должен заметить, что это "потом" практически не наступает и стоит не забывать об обыденном YANGI

Я согласен, что есть ситуации в которых стоит описать объектами. Но должен заметить, что это "потом" практически не наступает и стоит не забывать об обыденном YANGI

YAGNI про фичи, про более сложные штуки

Еще раз подтверждаю, что есть ситуации в которых действительно стоит описать объектно.

Еще раз подтверждаю, что есть ситуации в которых действительно стоит описать объектно.

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

так?

оцени трудозатраты

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

Должен не согласиться и причины я выше написал.

причем любая ide генерирует код вместо тебя

да это bullshit code по сути

скажем на структуру вида: class DatabaseConfiguration { public $host; public $port; public $username; // ../ }

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

а самое главное тут можно про каждую опицию написать и тд если есть какие нюансы

это позволит другому человеку или ТЕБЕ через месяц передавать корректно параметры

не заглядывая в реализацию

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

а теперь еще добавим сюда возможные опечатки в массивах

например сonnectionName

первая буква русская "с"

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

['сonnectionName' => 'ololo']

отсутствие тайпхинта проблема посерьезнее автокомплита

+

Стоп. Я не сказал, что подход объектами уступает подходу с массивами. Я привел доводы из-за того, что внутри чата формировалось исключительное мнение, что подход с объектами лучше. Я подвожу к тому, что не во всех ситуациях стоит использовать исключительно объекты. Каждый из подходов имеет свои +/-.

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

Стоп. Я не сказал, что подход объектами уступает подходу с массивами. Я привел доводы из-за того, что внутри чата формировалось исключительное мнение, что подход с объектами лучше. Я подвожу к тому, что не во всех ситуациях стоит использовать исключительно объекты. Каждый из подходов имеет свои +/-.

согласен)

Я лично, сочел это не объективным.

массивы для массивов

я же писал, массивы не плохо, массивы для массивов

@struzik узбагойся)

@struzik узбагойся)

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

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

Я прочел парочку твоих последних сообщений и не увидел плюсы массивов перед объектами. Можешь пояснить? Лично я вижу только минусы.

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

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

Привет. Я тут заранее спрашивал, можно ли опубликовать анонс мероприятия и получил разрешение. Так что публикую, без воды, только факты. Тапками не кидайте, не все еще стали матерыми волками программирования, когда-то и мы были джунами и клепали сайтики на CMS-ках. Впервые в Минске 11-12 ноября пройдет международная конференция MODXpo 2017 (проводится раз в 2 года и до этого была в Далласе, Утрехте, Кёльне и Мюнхене). Понятно, что будет о MODX и по смежным темам. Сайт тут - https://2017.modxpo.eu/ Билеты тут - https://modxpo.modx.by/#tickets, Подробный анонс - https://modx.pro/news/12793-modxpo-2017-will-be-held-in-minsk-11-november-12/ Для спонсоров - https://modx.pro/news/13503-to-become-a-sponsor-of-modxpo-2017-in-minsk/ Так как мы в телеграме, то и канал с новостями - @modxpo Спасибо! Ну и приходите, кто может.

Стоп. Я не сказал, что подход объектами уступает подходу с массивами. Я привел доводы из-за того, что внутри чата формировалось исключительное мнение, что подход с объектами лучше. Я подвожу к тому, что не во всех ситуациях стоит использовать исключительно объекты. Каждый из подходов имеет свои +/-.

подход с объектами лучше всегда. Другой вопрос что есть такое понятие как tradable quality и если ты вообще хз какая у тебя будет структура - массивы удобнее так как они тебя не ограничивают. Но когда у тебя структура стабилизировалась - будь добр оформить нормальную структуру данных явно.

и вот последним люди часто грешат (да что там. я сам так делаю часто))

+++

людям которые пишут на всяких там java/kotlin проще - у них просто должна быть структура

под каждым словом Сергея подписываюсь

https://kotlinlang.org/docs/reference/data-classes.html

подход с объектами лучше всегда. Другой вопрос что есть такое понятие как tradable quality и если ты вообще хз какая у тебя будет структура - массивы удобнее так как они тебя не ограничивают. Но когда у тебя структура стабилизировалась - будь добр оформить нормальную структуру данных явно.

на время стабилизации можно делать $obj->non_exists_value = bla;

людям которые пишут на всяких там java/kotlin проще - у них просто должна быть структура

в java можно творить ужас на Map<String, Object>

вот как можно не юзать такую лепоту?

но там за это по рукам настучат)

на время стабилизации можно делать $obj->non_exists_value = bla;

в целом сейчас да, сейчас есть тулы вроде phpstan которым можно сказать "вот это поле - оно только ro"

в java можно сделать public Magic(Map<String, Object> params)

и кастовать типы внутри

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

а вот в рубях/питоне - норм)

везде можно сделать гавно с этим наверно, главное желание

всем привет) возможно не в тему. как можно в mercurial сделать pull от имени другого пользователя? что то типу hg pull -u

салют! немного не по теме можно ли на s3 залить файл (изображение) безе expired in? или, подскажите, пожалуйста, как правильно построить механизм мне нужно: 1. заливать юзер контент на s3 2. получать ссылку 3. сторить в БД сейчас такая, штука, что линк полученный на файл стает не валидным через время указанное в expired

укажи там следующее столетие

укажи там следующее столетие

лимит есть кажется

прикинул походу не нужно в базе сторить линк на файл а только его имя (key) и уже генерить линк когда отдаю юзеру но накладненько как-то получается так с базы достал линк и все готово а так еще обрабатывать инфу нужно..

прикинул походу не нужно в базе сторить линк на файл а только его имя (key) и уже генерить линк когда отдаю юзеру но накладненько как-то получается так с базы достал линк и все готово а так еще обрабатывать инфу нужно..

ничего накладного в генерации линка не вижу. это обычная практика

это очень смешно, прогая на php экономить на генерации линка

это очень смешно, прогая на php экономить на генерации линка

ну мы же не знаем как он там у него генерируется, может быть там для этого 15 минут хеши высчитываются)

прежде временная оптимизация, .... (с.) Кнут

прикинул походу не нужно в базе сторить линк на файл а только его имя (key) и уже генерить линк когда отдаю юзеру но накладненько как-то получается так с базы достал линк и все готово а так еще обрабатывать инфу нужно..

накладненько будет как раз таки хранить) в долгосрочной перспективе

прикинул походу не нужно в базе сторить линк на файл а только его имя (key) и уже генерить линк когда отдаю юзеру но накладненько как-то получается так с базы достал линк и все готово а так еще обрабатывать инфу нужно..

А доставание из базы тоже не бесплатное, если что