[geany][plugin][C++][clang] Плагин-генератор сеттеров и геттеров для C++ в Geany

за геттеры и сеттеры надо убивать анальной сковородой!

впрочем чего ещё ожидать от человека, использующего Geany.

> за геттеры и сеттеры надо убивать анальной сковородой!

обоснуй

Генерация геттеров/сеттеров подразумевает проектирование «от реализации к интерфейсу», а не наоборот. А это есть прямое нарушение инкапсуляции.

В местных срачах многократно обсасывалось с отсылками к статье Голуба.

>обоснуй

Not again: http://www.linux.org.ru/forum/development/6013294

емнип в прошлом году было хлеще

Не, я понимаю, что местные «аналитики» увидели слово «геттер»/«сеттер» и больше ничего не надо для ср^Wобсуждения.

Но вот сам факт написания плагина для парсинга C++ при помощи clang и дальнейших нетривиальных модификаций кода вызывает одобрение, ТС - молодец :)

> Генерация геттеров/сеттеров подразумевает проектирование «от реализации к интерфейсу», а не наоборот. А это есть прямое нарушение инкапсуляции

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

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

> с отсылками к статье Голуба.

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

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

«Реальный процесс написания кода», «хорошая практика», и это говорит студент, пищущий аж 3 программы на С++?

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

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

Qt - нормальная библиотека?

Сразу несколько вопросов.

«Реальный процесс написания кода», «хорошая практика», и это говорит студент, пищущий аж 3 программы на С++?

Откуда вызывающе неверная информация?

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

Почему написание это не написание путем непосредственного нажимания кнопок пальцами? А обдумывание никто не отменял.

Неидеальная и ненормальная, разные вещи. Qt - вполне нормальная библиотека

> Qt - вполне нормальная библиотека

дык и я о том же, даже не нормальная - а де факто лучшая, с геттерами во все поля, а теоретики пока являются лучшими в написании статей и доказыванию правоты на форумах, suum cuique

Теоретики на форумах не нужны. Только сорят обрывками безполезных фраз и троллят. Для статей нужны, там хоть концепция полностью раскрывается.

>Реальный процесс написания кода поздоровее такой неуместной теориотизации

Да, да, вот так и получается всякий enterprise bullshit

генерация геттеров и сеттеров на первых фазах - хорошая практика

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

Хорошая практика - это движение от интерфейса, описывающего поведение объекта, к его реализации. Только в этом случае пользовательский по отношению к объекту код будет рассматривать его с поведенческой точки зрения и не будет опираться на детали реализации. При этом оба метода могут выглядить одинаково - как обычный сгенерированный сеттер, но суть не в том, что внутри, а в их восприятии. И именно поэтому генерация сеттеров/геттеров для имеющихся полей - зло

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

Вот не пойму нафига для всех то полей геттеры и сеттеры делать? Большинство же из них должны вообще не быть доступны извне, чем меньше их тем лучше!

о да )

дзен Qt таков, что обертка вокруг объекта продиктована соседними объектами, а не его внутренней структурой.
ребята работают от интерфейса к реализации, и потому получается code less deploy more.

Точно. Через анал.