AX2012. Цель атрибутов в расширении наследования классов

[mazzy]

Цитата:

Сообщение от ta_and

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

Угу.

Цитата:

Сообщение от belugin

Чтобы при мердже кода не мержить свитч.

Ключевой вопрос: а почему "не мержить свитч" лучше?

Ведь use case все равно проверять, все равно придется копать все ветки кода, поскольку все равно останется угроза рефакторинга остальных веток кода. Все равно придется расширять test cases, все равно придется дописывать документацию, все равно придется обеспечивать совместимость.

Атрибут и свитч - это настолько небольшая часть работы в общем проекте. Но технология атрибутов получилась настолько отличной от остальной работы.

Так вот: а почему "не мержить свитч" лучше?

Цитата:

Сообщение от trud

Антон Кекс ... то собственно возникнет вопрос нафиг вы тогда вообще нужны, switch и так все знают.

Кекс экстремист своего рода )
Хоть и очень толковый. Но он судит людей по себе.

На самом деле все проще.
Как и остальные люди, специалисты в МС хотят сделать лучше, проще, быстрее. Просто "критерии лучшести" в МС сильно отличаются от остальных людей.

Можно много говорить на тему "почему отличаются". Это отдельная тема.

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

[belugin]

Цитата:

Сообщение от mazzy

Угу.
Ключевой вопрос: а почему "не мержить свитч" лучше?

Ведь use case все равно проверять, все равно придется копать все ветки кода, поскольку все равно останется угроза рефакторинга остальных веток кода. Все равно придется расширять test cases,
все равно придется дописывать документацию, все равно придется обеспечивать совместимость.

См. дальше дискуссия extensions vs overlayering. Скажу только, что можно скономить на легко автоматизируемых вещах время для трудноавтоматизируемых вещей.

[mazzy]

Цитата:

Сообщение от belugin

См. дальше дискуссия extensions vs overlayering.

)

Цитата:

Сообщение от belugin

Скажу только, что можно скономить на легко автоматизируемых вещах время для трудноавтоматизируемых вещей.

справедливости ради стоит отметить, что:

экономия предназначена только для инженеров МС, проявляется только внутри МС и в только на environment МС, в ходе достижения целей, которые существуют только внутри МС.

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

[ta_and]

Цитата:

Сообщение от mazzy

экономия предназначена только для инженеров МС, проявляется только внутри МС и в только на environment МС, в ходе достижения целей, которые существуют только внутри МС.

ВОТ! Точно и ясно высказанная цель, которую я не мог сформулировать.
Других целей я не вижу.

[dech]

Цитата:

Сообщение от ta_and

ВОТ! Точно и ясно высказанная цель, которую я не мог сформулировать.
Других целей я не вижу.

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

[mazzy]

Цитата:

Сообщение от dech

Цель МС давно известна - сделать разделение кода

Цель МС давно известна - заработать.

"Сделать разделение кода" не является (и не может являться) целью корпорации МС )))

[trud]

Цитата:

Сообщение от mazzy

Цель МС давно известна - заработать.

"Сделать разделение кода" не является (и не может являться) целью корпорации МС )))

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

[Vadik]

Цитата:

Сообщение от mazzy

Так вот: а почему "не мержить свитч" лучше?

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

P.S. а ответ на самом деле дал Максим еще вчера - расширение без изменения предка и оверлееринга

[mazzy]

Цитата:

Сообщение от Vadik

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

именно! именно от такого человека.
и вопрос вовсе не означает, что человек не знает ответа.
знание ответа вовсе не означает, что человек не надеется узнать что-то новое.

Цитата:

Сообщение от Vadik

P.S. а ответ на самом деле дал Максим еще вчера - расширение без изменения предка и оверлееринга

Прекрасно.

продолжим?
Так вот: а почему "расширение без изменения предка и оверлееринга" лучше?

[EVGL]

Цитата:

Сообщение от mazzy

продолжим?
Так вот: а почему "расширение без изменения предка и оверлееринга" лучше?

У меня есть встречный, не менее глубокий вопрос: по стене ползет, пятью ногами дрыгает. Кто это?
P.S. Сорри, должен был открыть для этого новую тему.

[mazzy]

Цитата:

Сообщение от EVGL

У меня есть встречный, не менее глубокий вопрос: по стене ползет, пятью ногами дрыгает. Кто это?

в общем, ушел от ответа.

впрочем, каждый выполнить технику Пять почему в качестве самостоятельного упражнения.
Результат моего поиска первопричины при помощи этой техники я изложил здесь.