А ещё ну очень громоздко.

я мигрил год назад с 2.1 на 2.5, долго плевался

verbosity/code overhead большой, я бы сказал

Мигрирование версий вообще забей

и дебажить то еще удовольствие

ок, понятно

Тут ещё недавно смешная шутка была

даже супердев мод не спасает

а так да, наброс защитан :)

да не набрасывал я

ок, понятно

самый жесткий кейс, у клиента в браузере глюкан, и че с этим делать?

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

а так норм фрейворк :) но шаг влево шаг вправо и полетели костыли и грабли

самый жесткий кейс, у клиента в браузере глюкан, и че с этим делать?

Когда в 60 хроме поведение пары встроенных функций (getAbsoluteLeft/Top()) поправили для соответствия стандартам, а GWT в реализациях генераторов browser-specific кода рассчитывал на косую реализацию этого в хроме, при обновлении хрома МНОГО чего полетело, гм, пушным зверьком

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

Они это уже поправили, конечно

Но для этого надо обновляться

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

но я еще счатсливчик у меня поверх GXT был

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

А тут ещё надо вспомнить, что компилятор (транспилятор, точнее) там Н Е Т О Р О П Л И В Ы Й

И память любит

до супердев мода еще более менее был

но мэвен без 1гб хипа не хотел в дебаг моде взлетать :)

до супердев мода еще более менее был

У меня в проекте сейчас прописано Xmx=2048m, с гигом падает OOM при сборке.

Не на то сообщение реплай, но ты понел

карчое если если есть выбор с ГВТ пилить или без, всегда выбирать без :)

потом хрен на что мигранешь с него

Типа того. К этому привыкнуть можно, конечно. Но не нужно.

и у самого уже профдеформация будет :)

Так вот те кто за конструктор инжекшн, подскажите, как мокать темплейт, который создается внутри консруткора? Рефлексия или сеттер заэкспозать?

консруткор

Так вот те кто за конструктор инжекшн, подскажите, как мокать темплейт, который создается внутри консруткора? Рефлексия или сеттер заэкспозать?

Внутри конструктора только присваивания по хорошему должны быть. Может темплейт в спринг контекст положить и уже внедрять в твой класс?

Уже построенный в смысле

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

а еще тест к этому классу не написал :)

Отхуячь и перепиши

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

я пока не проникся элегантностью этого решения

всеравно 1 дб пул шарится, какая разница, новый темплейт или переиспользованый? Оо

Так вот те кто за конструктор инжекшн, подскажите, как мокать темплейт, который создается внутри консруткора? Рефлексия или сеттер заэкспозать?

если DI юзаешь то в конструкторе ничего не создавай

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

скорее всего уже лепили костыли

Отхуячь и перепиши

Поддерживаю

лан спасибо что выслушали :) пойду костыли на костыли писать :)

ООП нужен) но не всего его могут, я считаю. Товарищ Бугаенко это заметил и пытается ткнуть палкой всех, кто думают что понимает ОО, а на самом деле его не понимают. Многие помоему вообще смешивают теплое и мягкое, говорят об ОО а сами в процедурном стиле проблемы описывают. Вобщем мешанина полная. Вот вы о доме говорите, ну если вообще не знать ничего о нем, типа дом и дом себе это тип House без полей и без методов. Если буду уточнения (типа дом то коричневый, а в твоем типе пусто - вот ты лоханулся), мы добавляем состояние - color и чтоб не нарушать инкапсуляцию не делаем акссеоры (привет Котлин). Тогда вопрос - зачем это состояние вообще? А ответ: для того, чтобы Дом знал (именно Дом, да) о том, какого он цвета. И тут опять выясняется, что в отчеты о недвижимости надо бы добавить инфу о всех домах. Вот мы и добавляем в House метод report(...) а аргументов передаем какой-нить sink куда House запишем свое представление. И так далее. Скажут нам что в доме есть окна - ок, добавим еще одно поле hasWindows, а если потом придут и скажут что в доке 3 окна - добавим windowCount, а если в трейтий раз придут и скажут что нет, давай у каждого окна будут свои характерситики - все выкосим, сделает list<Window>. Т.е сила ОО в том, что состояние сокрыто всегда, тогда у нас дизайн консистентный и мы можем реально итератривно вносить измнения при этом мыслить удобными объектами.

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

а тут уже ЭПИЧЕСКОЕ неуважение к ООП и спрингу

Давайте без Бугаенок, пожалуйста

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

работать шоле?

Упаси боже

а тут уже ЭПИЧЕСКОЕ неуважение к ООП и спрингу

как будто что-то плохое

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

@apocarteres чтоб не нарушать инкапсуляцию не делаем акссеоры (привет Котлин) это не котлин, а скала — он оттуда содрал 1 в 1

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

ахаха +1

на самом деле, я рад, что вышел Котлин

кароче, красивый ОО это не так просто, в мире где ОО называют не совсем ОО

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

я сам быдлокодер еще тот, но постоянно стараюсь упростить и улчушить свой ОО код в частности

А потом такой дом разрастается до хулиард методов и строчек кода

А потом такой дом разрастается до хулиард методов и строчек кода

нет. не разрастатеся, сколько бы он не рос

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

И все это методы дома

а ооп Егора разве не почти-фп ?

ERROR: S client not available

И все это методы дома

делегирование, композиция, выделение новых сущностей. я тебе 100% говорю можно любой тип в пределах желаемых N строк описывать

в 99% случаев если у тебя за N строк выходит тип - ты его сильно перегрузил ответственностями

А потом такой дом разрастается до хулиард методов и строчек кода

Декомпозировать его к хуям.

Если твой дом разрастается, значит ты не умеешь в ООП.

И паттерны проектирования.☝️

А вот твой функциональный дом будет монструозным набором функций. Довольно сложно представить себе, как что-то структурное может описываться функциями.

Неужели нету такого опен сорс проекта где все по феньшую ООП

Чтобы код посмотреть

Где код блиать

Давайте для начала все сойдутся, как выглядит фен-шуй ООП

А потом обсудим

Если твой дом разрастается, значит ты не умеешь в ООП.

какие все умные, лол

:D

А вот твой функциональный дом будет монструозным набором функций. Довольно сложно представить себе, как что-то структурное может описываться функциями.

ой все

Давайте без Бугаенок, пожалуйста

Даже если не упоминать Егора, есть такие понятия как cohesion и coupling. Нытье о том что ООП дно потому что "классы на 10к строк унаследованные друг от друга" проистекает как раз из того что 10К классы с наследованием нихрена не cohesive, и как правило охрененнно coupled.

Даже если не упоминать Егора, есть такие понятия как cohesion и coupling. Нытье о том что ООП дно потому что "классы на 10к строк унаследованные друг от друга" проистекает как раз из того что 10К классы с наследованием нихрена не cohesive, и как правило охрененнно coupled.

Это да, без вопросов

не факт что ФП верися дома будет уступать в maintainability OO версии того же дома

bricks.reduce(toHouse()) :)

Это да, без вопросов

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

не факт что ФП верися дома будет уступать в maintainability OO версии того же дома

Зависит от того, против какого волка этот дом строится.

Подходишь ты такой к столу в своём функциональном доме. А на нём — монада. И что ты будешь делать?

поглажу ее)

Резонный вопрос

Подходишь ты такой к столу в своём функциональном доме. А на нём — монада. И что ты будешь делать?

Забиндишь обед к столу и получишь обеденный стол?)

Подходишь ты такой к столу в своём функциональном доме. А на нём — монада. И что ты будешь делать?

заходишь в хату, а там на полу монада лежит

поглажу ее)

Тогда ты функтор.

обожаю этот иммутабельный юмор

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