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

но jquery мощнее js это точно)0

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

Вай нот?

после нормального языка на пхп не захочется возврощатьс

я

уныло будет

это я типо наверное ответил на вопрос выше

Spring vs Symfony = who win?

тут принято считать что все говно )

говно vs моча

doctrine в spring есть?

и участь наша страдать )

фесор сказал пхп > джава

doctrine в spring есть?

hibernate

doctrine в spring есть?

хибернэйт

и спринг > симфони

doctrine в spring есть?

И ты ещё судишь про нормальные языки ))))090

аа по другому называется

просто столько языков, php, js, golang, python и еще kotlin(spring) учить, слишком много языков

просто столько языков, php, js, golang, python и еще kotlin(spring) учить, слишком много языков

зачем нада?

просто столько языков, php, js, golang, python и еще kotlin(spring) учить, слишком много языков

так много, а деньги зарабатывают на Wordpress

так много, а деньги зарабатывают на Wordpress

+

ну так получилось, писал на php, js, потом пришлось python немного писать, потом все надоело хотел найти работу на гошке, но у нас вакансий тупо нет по ней ...

а Котлин на работе

не знаю, вордпресс делать ваще уныло было бы, даже не взялся бы

короче хочется получше, но чтоб не учить, но получше )

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

@Enleur поведай за спринг в котлине и симфу )

пхп я то знаю уже, симфони норм заходит, а теперь стек поменяли давай на коте(spring) ну ппц

php, js, python, golang, kotlin, а я еще Rust хотел потом взять, повеситься можно же.

/link@yetanotherstatsbot

https://b.yasb.exileed.com/telegram/chat/1001091570538

Всем привет, кто-нибудь пробовал Symfony и Spring(java), оба фрейморка? ---- и какое мнение после использования обоих фрейморков?

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

@murtukov я смотрел, я запутался в ней быстро где что, у симфони все по порядку, даже видео курсы не нужны, просто читай по порядку все.

кароче нафиг этот spring (kotlin) я думаю, жизнь себе испортишь только ...

я уже писал об этом тут. Есть много преимуществ у геттеров и сеттеров

будь добр напиши мне в личку список

вообще блин надо перестать лениться и хотя бы собрать в один файлик все мнения

будь добр напиши мне в личку список

Не хочу я быть добрым

Не хочу я быть добрым

если что я не отрицаю что геттерам и сеттерам есть место, вопрос в контексте их использования. Если на основе геттера принимается решение, если сеттер должен вызываться всегда в паре с другим методом - то есть нюансы. Если сеттер вызывается в одиночистве (setStatus какой) и если геттеры юзаются только что бы вывести данные - то все хорошо и вопрос исключительно в нейминге.

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

если что я не отрицаю что геттерам и сеттерам есть место, вопрос в контексте их использования. Если на основе геттера принимается решение, если сеттер должен вызываться всегда в паре с другим методом - то есть нюансы. Если сеттер вызывается в одиночистве (setStatus какой) и если геттеры юзаются только что бы вывести данные - то все хорошо и вопрос исключительно в нейминге.

Если у сеттеров нет побочных эфектов?

Если у сеттеров нет побочных эфектов?

ммм.... это как?

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

либо есть проблема с определением побочных эффектов

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

неправильно выразился

Сеттер должен делать только устанавливать значение , не модифицируя его

{ $this->puk = $kek; }

и все

ну это тогда вопрос к определению сеттера)

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

сеттер и мутатор

ну вот мне больше нравится разделять методы на те которые делают сайд эффекты (команды) и те которые их не делают (запросы)

в этом плане сеттер может восприниматься как тупая команда

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

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

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

а то сеттер и тип контролирует и еще может модифицировать то что кнам приходит.

Это из практики

он модифицирует если ты запихиваешь объекты либо пишешь сигнатуру по ссылке

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

он модифицирует если ты запихиваешь объекты либо пишешь сигнатуру по ссылке

че?

т.е. не всегда но варик есть

вывод - юзай сеттеры с простыми типами

хаха

ERROR: S client not available

setEmail(string $email): void { $this->email = strtolower($email); }

вот про это он видать

да

вывод - юзай сеттеры с простыми типами

как я люблю запах primitive obsession под вечер

щаща погоди

давай разберем пример этот

ну стоит там внутри strtolower - ок

о чем это может сказать тебе

ммм.... с точки зрения клиентского кода это не мое дело

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

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

public readonly $foo: Foo = null; вот так вот если бы можно было бы делать в пыхе

сча секу

соц опрос сделаю

соц опрос сделаю

дак ты можешь делать так class Foo{ __construct($bar){ $this->bar=$bar; } public function getBar(){ return $this-bar; } }

блин

я чотанажал и все пропало

сорян не тебе реплаил )

public readonly $foo: Foo = null; вот так вот если бы можно было бы делать в пыхе

кароч пример ридонли обжекта сверху

кароч пример ридонли обжекта сверху

Ну это понятно, но нахуя?

так делать

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

чем плохо, то что буков больше?

чем плохо, то что буков больше?

в getBar можно всякой хуйни еще написать (так и делают)

А я например не ожидаю такого

https://gist.github.com/fesor/c02162883181276e3f7eda8c657d352f

во

т.е. косяки разрабов ты спихиваешь на недостатки языка

5 вариантов одного и того же метода

какой из них сеттер а какой "не очень"

типа если бы можно было делать как ты предлжил то все бы так и делали. имхо - не взлетит )

т.е. косяки разрабов ты спихиваешь на недостатки языка

да