?

Должны. Но TurboPascal изначально процедурный язык.

subroutine(подпрограмма) была придумана в 47ом году!! И в паскале тоже были и функции и процедуры)

Ага. Только нам это рассказать забыли.

А про ООП даже упоминания не было.

программа выглядит гораздо лучше: $table = fetchAllRows(fetchDom()); printTable($table); function fetchDom() { //some //hel //with curl //and dom } function fetchAllRows($dom) { // some // how // traverse dom tree } function printTable($table) { // some how print you table }

программа выглядит гораздо лучше: $table = fetchAllRows(fetchDom()); printTable($table); function fetchDom() { //some //hel //with curl //and dom } function fetchAllRows($dom) { // some // how // traverse dom tree } function printTable($table) { // some how print you table }

Ага, приятно. А в ООП такое получится?

конечно, но начни с малого

Ага, приятно. А в ООП такое получится?

Мм, да

А то надо учиться красиво и модерново писать.

А то надо учиться красиво и модерново писать.

https://gist.github.com/mkusher/711bd46f0b62fbae851182e6fb3b1839

https://gist.github.com/mkusher/711bd46f0b62fbae851182e6fb3b1839

Прочитал при входе)

https://gist.github.com/mkusher/711bd46f0b62fbae851182e6fb3b1839

О, то что я искал

О, то что я искал

;)

https://github.com/sidkshatriya/dontbug

https://github.com/sidkshatriya/dontbug

Ага, уже записал себе) оченно нехватало.

@kostanakis что бы начат делать декомпозицию на объектах, стоит сначала научиться строить декомпозицию на функциях и осознать зачем вообще что-то надо делить на объекты. В чем профит и т.д. Тогда оно будет как-то более логично и последовательно идти. А то просто юзать потому что "так модно и без этого нельзя" - ну так себе идея.

@kostanakis что бы начат делать декомпозицию на объектах, стоит сначала научиться строить декомпозицию на функциях и осознать зачем вообще что-то надо делить на объекты. В чем профит и т.д. Тогда оно будет как-то более логично и последовательно идти. А то просто юзать потому что "так модно и без этого нельзя" - ну так себе идея.

Спасибо, записал

@kostanakis что бы начат делать декомпозицию на объектах, стоит сначала научиться строить декомпозицию на функциях и осознать зачем вообще что-то надо делить на объекты. В чем профит и т.д. Тогда оно будет как-то более логично и последовательно идти. А то просто юзать потому что "так модно и без этого нельзя" - ну так себе идея.

А вы часом не преподаете?

не, времени нет

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

https://www.youtube.com/watch?v=1RgXgZcj5nM

о нашел годноту

годнота, завтра буду смотреть)

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

а не. то другое было

ну где-то год назад и было выступление ))

вот почему потерял

Еще по теме апишек: https://www.youtube.com/watch?v=pspy1H6A3FM - оооочень харизматичный дядька

у него голос очень приятный)

https://confluence.jetbrains.com/display/PhpStorm/PhpStorm+Advanced+Metadata

воу, прикольная фича

а это разве не то что в ларавеле юзается?

а это разве не то что в ларавеле юзается?

нет

это новая возможность писать конфиги для метадаты в виде php-класса

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

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

overrid(\ServiceLocator::get(0), type(0)); типа как пхп, но не пхп

Никто не хочет мэппер объектов на данные и обратно написать модный какой?)

ты :))

Никто не хочет мэппер объектов на данные и обратно написать модный какой?)

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

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

а как же многострадальный ecommerce?

с ордерами без геттеров)

4drinks же есть)

@Enleur времени нет(

зато сколько пользы будет

@mkusher че?

@Enleur не ну согласен, но такое

@Enleur польза была бы если бы этим пользовались еще)

@mkusher че?

https://github.com/norzechowicz/mydrinks

ну исключи этот пункт и считай "пользование" чисто как стенд для демострации кода

https://github.com/norzechowicz/mydrinks

спс, надо поизучать

@Enleur ну может на след неделе будет время начну пилить "стэнд"

возможно можно тогда как-то тему ecommerce как-то обыграть?

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

tinder очередной? :D

@Enleur не не не))

спс, надо поизучать

но там с геттерами

@mkusher да черт с ними с геттерами)

типа того)

@mkusher хотя не, ладно

буду без геттеров

ERROR: S client not available

точнее как

геттеры максимум для сериализации

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

и смотреть как будет твое решение масштабироваться

agile и вся хуйня)

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

@fes0r а не будет ли лучше вместо геттеров отдавать DTO уже заполненные?

@Enleur тебя Кирилл покусал что ли?)

какой кирилл?

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

который @SerafimArts

>The introduction of DTOs doesn't guarantee a decoupling by no means. I've seen way too many projects where they where introduced for cargo-culting reasons, simply duplicated all fields of the entity backing them and by that just caused additional effort because every new field had to be added to the DTOs as well. But hey, decoupling! Not. ¯\_(ツ)_/¯ из того что @fes0r скидывал вчера) так что культ DTO тоже не стоит воспринимать через чур

который @SerafimArts

пардон)

ну мне нравится, что тайпхинтинг, но не нравится, что миллион объектов :(

ну чисто логически - если объект рендерится раз пять, и все пять раз нужны разные наборы полей, то пути три: 1) отдавать все поля объекта 2) отдавать массивы с разными наборами полей 3) пять DTO классов

крч первый и сторой - одно и то же)

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

ты же самтолько что сказал, что культ дто - бяка))

бяка это когда у тебя DTO получается такой же как сущность

еще и с логикой ))

а когда тебе из дерева сущностей нужно состряпать всего 1 DTO, то как-то проще все же юзать их)

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

но в большенстве случаев достаточно обьект туда-сюда отправлять)

дто с логикой - это вообще пирдуха

ну из логики в основном к примеру получить только ключи, или первый элемент из определенного поля

ну в сферическом мире в вакууме если ты хочешь сделать такую ДТОшку - то тебе надо бы разбить их на две/три/десять

ну первый кейс решается на принимающей стороне, а вот второй - пахнет новым классом

Anton если у тебя на все случаи жизни DTO будут собираться - это будет нарушать SRP так как есть две причины для изменения сущности

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

@fes0r сущность будет отдавать DTO, т.к. она знает о своем стейте