@ExileeD https://paste.ofcode.org/4y8bD9VLpAJZDpKrHrkhLE

и так по кругу

не влезло все

раз 15 прошло одно и тоже что по ссылке

комплируется же

по кругу?)

ltkfk rcnfnb bp ja ljrjd

https://confluence.atlassian.com/bitbucket/laravel-with-bitbucket-pipelines-913473967.html

Hello. Почему в __toString() нельзя бросать Excception ?

Hello. Почему в __toString() нельзя бросать Excception ?

https://stackoverflow.com/questions/2429642/why-its-impossible-to-throw-exception-from-tostring

"there is no way to ensure that an exception thrown during a cast to string would be handled correctly by the Zend Engine" блин. (

"there is no way to ensure that an exception thrown during a cast to string would be handled correctly by the Zend Engine" блин. (

Там в другом ответе ниже есть обходной путь

Вот только зачем?

Мне не нужен обходной путь. Просто хочу видеть весь трейс когда возникает ошибка.

Мне не нужен обходной путь. Просто хочу видеть весь трейс когда возникает ошибка.

Посмотри в том вопросе ниже

Посмотри в том вопросе ниже

я не хочу в каждом методе tostring писать trycatch)

Если в toString есть логика, которая может выбросить эксепшен, то чет код воняет

Если в toString есть логика, которая может выбросить эксепшен, то чет код воняет

why? К примеру: class TipOfTheDay(\DateTime $time) { public function __toString(){ return \to_camel_case( $this->db->fetchOne(' Select tip from tips where day = ? ', $this->time->format('y-m-d')) ); } }почему код плохой? Метод toString получается вообще костыль, так как мы должны думать о реализации методов которые мы вызываем.

Я б за такую херню тупо уволил. И, да, toString - своего рода костыль. Но это не значит, что надо такой мрак в нём творить

Я б за такую херню тупо уволил. И, да, toString - своего рода костыль. Но это не значит, что надо такой мрак в нём творить

Можно еще метровой стальной линейкой по рукам постучать, чтобы неповадно было

Можно еще метровой стальной линейкой по рукам постучать, чтобы неповадно было

Не, пускай другие стучат. Если человек додумался так сделать, стучать уже бесполезно)

Не, пускай другие стучат. Если человек додумался так сделать, стучать уже бесполезно)

Я бы не хотел, чтобы сотрудник, которого я уволил, на новом месте работы сказал, что это он у нас научился ?

Поэтому я и не пишу ничего в методе __toString и вообще его не юзаю. Хотя он должен привнести более удобное написания кода. Я хочу описать класс Tip и он будет представлять собой string. Как он будет ее генерировать - это не проблема представления. Кароче toString надо делать deprecated)

Должен быть отдельный класс, который порождает объекты Tip а Tip.__toString будет простым return $this->text;

Должен быть отдельный класс, который порождает объекты Tip а Tip.__toString будет простым return $this->text;

зачем и почему?

зачем и почему?

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

А toString это уровень представления

__toString это рабочий метод, для представления объекта в одну строку для какого-нибудь debugger. Вообще его спиздили с Джава, и как все что спижжено с Джава, не до конца проработано. Его просто не нужно использовать в своем бизнесс коде. Максимум, в каких-то дебаг либах, быть может. А то что ты в toString лезешь в БД - тут да, только уволить

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

Что такео логика представления? К примеру psr7 UriInterface::__toString - логика представления или нет?

Что такео логика представления? К примеру psr7 UriInterface::__toString - логика представления или нет?

Да, это представление в виде строки

__toString это рабочий метод, для представления объекта в одну строку для какого-нибудь debugger. Вообще его спиздили с Джава, и как все что спижжено с Джава, не до конца проработано. Его просто не нужно использовать в своем бизнесс коде. Максимум, в каких-то дебаг либах, быть может. А то что ты в toString лезешь в БД - тут да, только уволить

+1 согласен.

Да, это представление в виде строки

все методы которые возвращают ленту это "представление" ? можно ссылку чтобы где-то прочитать о "представление" или это вы сами придумали такую штуку ;)

__toString это рабочий метод, для представления объекта в одну строку для какого-нибудь debugger. Вообще его спиздили с Джава, и как все что спижжено с Джава, не до конца проработано. Его просто не нужно использовать в своем бизнесс коде. Максимум, в каких-то дебаг либах, быть может. А то что ты в toString лезешь в БД - тут да, только уволить

Для дебага в пых подвезли маг метод дебаг. Занятная штука

debugInfo имеешь ввиду, или что то новенькое?

все методы которые возвращают ленту это "представление" ? можно ссылку чтобы где-то прочитать о "представление" или это вы сами придумали такую штуку ;)

Гугли про MVC и про SRP

debugInfo имеешь ввиду, или что то новенькое?

Угу, оно

ну да. v - view) srp - в курсе. не понятно почему TipOfTheDay - представление. Получается мне всегда надо юзать dto - для представления данных и юзать factory для создания этих объектов. Все верно?

ну да. v - view) srp - в курсе. не понятно почему TipOfTheDay - представление. Получается мне всегда надо юзать dto - для представления данных и юзать factory для создания этих объектов. Все верно?

Не обязательно factory, это может быть DataProvider или репозиторий, а Tip может быть вполне себе Entity, со своей логикой

чем лучше дата провайдер и dto чем держать логику в объекте? Объект это и есть поведение, или я не прав?

чем лучше дата провайдер и dto чем держать логику в объекте? Объект это и есть поведение, или я не прав?

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

Он у тебя знает и как получить данные, и как работать с ними, и даже как представить их пользователю. Не многовато ли?

Он у тебя знает и как получить данные, и как работать с ними, и даже как представить их пользователю. Не многовато ли?

Ок. class RandomJoke{ public function getJoke(){ return array_rand([ 'a joke', 'b joke', 'c joke' ]); } }норм ?

Пока вроде ничего лишнего

class RandomJoke{ public function getJoke(){ return array_rand($this->db->fetchAll('select text from jokes limit 3 order by time')); } }Так норм?. Правильно ли я понимаю - вас напрягает форматирования текста (то есть представления)?

class RandomJoke{ public function getJoke(){ return array_rand($this->db->fetchAll('select text from jokes limit 3 order by time')); } }Так норм?. Правильно ли я понимаю - вас напрягает форматирования текста (то есть представления)?

в данном случае этот класс становится провайдером для Joke

class RandomJoke{ public function getJoke(){ return array_rand($this->db->fetchAll('select text from jokes limit 3 order by time')); } }Так норм?. Правильно ли я понимаю - вас напрягает форматирования текста (то есть представления)?

лучше так: class Jokes { public function random(): string { return array_rand(['foo', 'bar']); } }

мало ли тебе понадобится не рандомный

ну и в целом как коллекцию проще это воспринимать

или тебе понадобится 5 рандомных

лучше так: class Jokes { public function random(): string { return array_rand(['foo', 'bar']); } }

Jokes::todayJoke() Jokes::topJoke() Jokes::random() Jokes::randomFromGroup() ?

Jokes::todayJoke() Jokes::topJoke() Jokes::random() Jokes::randomFromGroup() ?

возможно стоит разбить на разные инттерфейсы

но это от задачи зависит и от того как методы юзаются

или тебе понадобится 5 рандомных

да. Список: new JokeFromList(new TodaysTopJokes()) new JokeFromList(new RandomJokes()) new JokeFromList(new Top10Jokes())

class RandomJokes implements JokeProvider { public function getJoke(): Joke { return array_rand([new Joke('foo'), new Joke('bar')]); } } class DailyJokes implements JokeProvider { public function __construct(\DateTimeInterface $today) { $this->today = $today; } public function getJoke(): Joke { return new Joke($this->db->fetchFromJokesTableByDate($this->today)); } } Если хочешь пользоваться методом __toString class Joke { public function __constuct(string $text) { $this->text = $text; } public function __toString() { return $this->text; } }

но это от задачи зависит и от того как методы юзаются

к примеру у меня сайт из шутками про рнр. Я показываю только рендомни шутки. Для чего мне дата провайдеры - если я могу реализовать JokeInterface::getText и не создавать dto ?

к примеру у меня сайт из шутками про рнр. Я показываю только рендомни шутки. Для чего мне дата провайдеры - если я могу реализовать JokeInterface::getText и не создавать dto ?

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

class RandomJokes implements JokeProvider { public function getJoke(): Joke { return array_rand([new Joke('foo'), new Joke('bar')]); } } class DailyJokes implements JokeProvider { public function __construct(\DateTimeInterface $today) { $this->today = $today; } public function getJoke(): Joke { return new Joke($this->db->fetchFromJokesTableByDate($this->today)); } } Если хочешь пользоваться методом __toString class Joke { public function __constuct(string $text) { $this->text = $text; } public function __toString() { return $this->text; } }

В таком варианте я пишу JokesList::all (TodayJokesList::all, new RandomizedJokesList(new TodayJokesList()) и не парюсь. Но иногда мне не нужно создават продавйдер. И я просто создаю обєкт.

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

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

к примеру у меня сайт из шутками про рнр. Я показываю только рендомни шутки. Для чего мне дата провайдеры - если я могу реализовать JokeInterface::getText и не создавать dto ?

1. Не JokeInterface а Jokes 2. не getText а get или random в твоем случае 3. В DTO прекрасно ложатся любые структуры данных, в случае php у тебя есть массивчики. 4. Сегодня тебе нужна только строка, завтра тебе понадобится выводить сколько эту шутку залайкало людей, потому лучше что бы данные которые возвращаются в представление были бы все же завернуты во что-то что бы позволить расширять все в будущем. Опять же массивчики неплохой выбор.

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

все так

1. Не JokeInterface а Jokes 2. не getText а get или random в твоем случае 3. В DTO прекрасно ложатся любые структуры данных, в случае php у тебя есть массивчики. 4. Сегодня тебе нужна только строка, завтра тебе понадобится выводить сколько эту шутку залайкало людей, потому лучше что бы данные которые возвращаются в представление были бы все же завернуты во что-то что бы позволить расширять все в будущем. Опять же массивчики неплохой выбор.

1. ок. 2. не ок. я не хочу держать в Jokes различные методы. лучше напишу метод first или сделаю Jokes::all():\Generator и буду елдить Joke 3. масив не типизированные 4. Есть резон. Спс

foreach(new TodayJokes() as $joke){...} TodayJokes:getIterator() )

1. ок. 2. не ок. я не хочу держать в Jokes различные методы. лучше напишу метод first или сделаю Jokes::all():\Generator и буду елдить Joke 3. масив не типизированные 4. Есть резон. Спс

2. не хочешь - не держи. 3. вопрос инструментов и отсутствия нативной возможности описать тип массива. С другой стотроны, динамические структурки это единственное преимущество php перед нормальными языками. Ну и штуки типа psalm умеют в array shapes.

2. не хочешь - не держи. 3. вопрос инструментов и отсутствия нативной возможности описать тип массива. С другой стотроны, динамические структурки это единственное преимущество php перед нормальными языками. Ну и штуки типа psalm умеют в array shapes.

странно почему шторм до сих пор не умеет

от того, что псалм могёт, жизнь, к сожалению, лучше не становится :(

ERROR: S client not available

от того, что псалм могёт, жизнь, к сожалению, лучше не становится :(

вот да

странно почему шторм до сих пор не умеет

1. psalm юзает php-parser, который четкий и понятный. шторм юзает свой парсер (потому что это IDE и 80% времени ему надо разбирать невалидный код), что сильно усложняет дела. 2. в phpstorm свой парсер докблоков 3. нет никаких стандартов определяющих как задавать типы для array shapes. Может быть в phpdocumentator добавят и тогда уже будут дела идти.

это как с дженериками. Сейчас в дженерики более-менее умеет только psalm и phan. Шторм все еще оперирует своими Foo[]|ArrayCollection

пока нет RFC в php с описанием как оно должно работать, пока нет стандарта который описывает как это все регламентируется в докблоках у всех будут свои реализации просто.

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

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

давай так, псалм пилит 1-2 человека, это типа не сурьезно. Но хоть что-то

p.s. если хочешь поблевать - посмотри исходники typescript-а

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

а ты готов перейти на имутабельность?

Например мне надо объект "Шутка" Я хочу увидеть все возможные способы его конструирования и выбрать для себя оптимальный - или написать новый. Если мы юзает всегда датапровйдер - ок. Ищем кто конструирует объекты и нет проблем. Но если в некоторых случаях мы напрямую в DTO забрасываем данные (например в контроллере) тогда уже трудно разобраться среди большого количества строк - как реально создать объект. и сложно выбрать подходящий. Поэтому и подумал что создавать объект который будет содержать алгоритм работы - норм.

а ты готов перейти на имутабельность?

ничё не помешает

Например мне надо объект "Шутка" Я хочу увидеть все возможные способы его конструирования и выбрать для себя оптимальный - или написать новый. Если мы юзает всегда датапровйдер - ок. Ищем кто конструирует объекты и нет проблем. Но если в некоторых случаях мы напрямую в DTO забрасываем данные (например в контроллере) тогда уже трудно разобраться среди большого количества строк - как реально создать объект. и сложно выбрать подходящий. Поэтому и подумал что создавать объект который будет содержать алгоритм работы - норм.

тебе может понравится концепция билдеров

$joke = Joke::builder() ->withAuthor($someAuthor) ->withText($someText) ->withSomeOtherStuff($stuff) ->build();

пробовал - не катит. Вы же не всегда будете писать билдеры. И получается что когда вам нужно объект определенного типа вам приходится искать реалзации этого типа + использование конструкторов.

Спасибо всем. Некоторые моменты для себя прояснил;)

пробовал - не катит. Вы же не всегда будете писать билдеры. И получается что когда вам нужно объект определенного типа вам приходится искать реалзации этого типа + использование конструкторов.

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

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

так это они и есть

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

и пример кода, где в __toString было $this->db->fetchOne

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

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

может, но только не тот объект, который эти данные в себе хранит

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

почему не может, вопрос абстракций выбранных

и пример кода, где в __toString было $this->db->fetchOne

Хотел что бы код вот так выглядел $joke = new RandomJoke(); echo $joke;- но из-за ограничений в рнр - так нельзя.

$joke = $joker->getJoke(); echo $joke;

$joker = new RandomJokeProvider();

если лишняя строчка кода мешает, то напиши так echo (new RandomJokeProvider())->getJoke();

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

(new RandomJokeProvider())() =)

(new RandomJokeProvider())() =)

https://i.gifer.com/5z3s.gif

а ты готов перейти на имутабельность?

Готов перейти на темную сторону?