когда я мог бы просто перегрузить существующую для PostgresQueryBuilder

насчет первой проблемы - это решаемо быстро

меня когда-нибудь это в конец достанет

и я пришлю им пуллреквест

без перугрузки жить можно, но с ней было б лучше

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

именованные конструкторы, разные имена методов типа эмуляции ее(add, addAll, addShit...)

именованные конструкторы, разные имена методов типа эмуляции ее(add, addAll, addShit...)

да не надо это

именованные конструкторы, разные имена методов типа эмуляции ее(add, addAll, addShit...)

вот я так и делаю

UpdateByIdAndUserId

выглядит глупо

зато читабельно

явно

Обновите телеграм и нажмите instant view по ссылке (пока только на мобилах) http://telegra.ph/%D0%97%D0%B0%D0%B2%D1%82%D1%80%D0%B0%D0%BA%D0%B0%D1%81%D1%82-%D0%B2-%D1%82%D0%B5%D0%BB%D0%B5%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B5-11-23

телеграм свой встроеный медиум запилил

> пришлось добавлять огород с другой функцией

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

зачем "обобщать" когда тебе наоборот нужно специализированное поведение?

точно так же методы updateByIdAndUserId вполне себе норм штука, просто потому что не надо гадать "по чем оно там что делает"

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

но в приведенном тобой примере с дистинктом я вообще не увидел необходимости в перегрузке методов

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

с перегрузкой проблема в том, что разработчик не будет ничего знать о контекстах. Максимум если добавить доку в описание метода. А когда у тебя 2 метода с разным поведением имеют два разных названия - это вполне себе норм тема

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

ну то есть перегрузка методов - это те же ифы но на уровне рантайма, неявно

Sergey Protko, [23 Nov 2016, 11:17]: так это и должна быть другая функция, у нее другая семантика, у нее другое поведение зачем "обобщать" когда тебе наоборот нужно специализированное поведение... так это одна и та же функция distinct

и в языке типа php, где проверка вызова происходит тоже в рантайме а не на этапе компиляции - профита от этого ровным счетом ноль

mysql/sqlite не умеет

а постгрес умеет

или тот же drop table cascade

сойдемся на том что eloquent говно, юзайте doctrine)

там разница в запросе в наличии слова cascade

и все

достаточно было бы одну переменную добавить в метод

$cascade = false

дефолтную

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

тебе ж никто не мешает

myfunction($value1, $value2) myfunction($value1, $value2, $value3 = false)

так можно?

да

а это с какой версии так можно?

со всех

я чот совсем пропустил этот момент

с версии 5.0 походу

ну или хз, но в 5.3 это точно было

Be conservative in what you send, be liberal in what you accept

есть такой принцип

Robustness principle

он как раз про это

если ты что-то расширяешь, ты можешь ослаблять предусловия, но не должен ослабвлять инварианты и пост условия

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

короч если проще - если не ломается обратная совместимость - все ок и можно

и правда работает

class A { public function myFunc($value1, $value2) { var_dump($value1); var_dump($value2); } } class B extends A { public function myFunc($value1, $value2, ...$value3) { var_dump($value1); var_dump($value2); var_dump($value3); } } $a = new A(); $a->myFunc(2,3); $b = new B(); $b->myFunc(2,3, 33,442,2323);

даж так не ругается

а я 7 лет думал, что ругаться будет и не делал так

эх

давайте лучше паттерн-матчинг

Implements же нету чтобы ругаться

Implements же нету чтобы ругаться

и с implements не будет ругаться.

у тебя ж интерфейс сохраняется. Он расширяется и позволяет принимать больше

а в чем проблема?

ну короч принцип подстановки Барбары Лискоу сохраняется, а потому все збс

вместо A можно передать B

надо написать статью про LSP

ERROR: S client not available

ушел писать

почти все

пхп не ругается, шторм ругается

и думаю, линтеры, тоже будут ругаться

ну по сути это бага линтеров, поскольку все должно быть ок

ну мол линтеры просто не понимают что это тоже самое что array $args = []

Значит надо открыть ишью в них

им надо явно прописать дефолтное значение что бы они не ныли

Попробовал сделать так же как и выше. Обработка успешная но ide ругается

что я делаю не так?

линтер шторма говорит что я молодец

Может дело в типе самом?

секу

не

все кейсы работают корректно

Еще вопрос

На вашем ide возможно обработчик php версии поновее?

эээм в смысле?

php 7.1

какая рахница если это работает с php 5.6

PhpStorm 2016.2.2 Build #PS-162.2380.11, built on October 24, 2016 Licensed to Sergey Protko Subscription is active until December 20, 2016 JRE: 1.8.0_112-release-287-b3 x86_64 JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o

все просто збс

Чуваки, можете сказать, какие профиты и грабли я получу с сервис локейтора, либо же депенденси инжекшин, при создании инверсии контроля? Или что мне лучше поможет? В сервис локейторе я смогу разрулить все через какой-то конфиг, где смогу переопределять, какие классы мне надо будет юзать, и заменять. В депенденси инжекшин, я просто буду закидывать объекты, у которых дожен будет например быть какой-то общий интерфейс.

зависит от того чего тебе нужно

по идеи

например, в Symfony

Service Locator внедряется через DI в приложение

у тебяж в любом случае (а может и не в любом) он должен существовать как объект

мне кажется будет совсем неудобно, если только Service Locator юзать

Чуваки, можете сказать, какие профиты и грабли я получу с сервис локейтора, либо же депенденси инжекшин, при создании инверсии контроля? Или что мне лучше поможет? В сервис локейторе я смогу разрулить все через какой-то конфиг, где смогу переопределять, какие классы мне надо будет юзать, и заменять. В депенденси инжекшин, я просто буду закидывать объекты, у которых дожен будет например быть какой-то общий интерфейс.

почитай у фаулера разбор полетов в плане минусов и плюсов. Плюсы - легко запилисть. Минусы - отсутствие статической информации о зависимостях