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

[belugin]

Цитата:

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

Именно!
Внутри оно работает с именами классов. Ключ ТУПО преобразуется к именам. В текущей реализации Platform 7 ключ не имеет никакой семантики. Скрипач (отдельный ключ) не обязателен.

_baseClass это имя базового класса а не ключа. Ключ, должен идентифицировать потомка этого базового класса.

Цитата:

да-да. именно во множественном числе.

Угу потому что выбранный тобой метод нужен в случае если требуется ровно один класс. Соответственно он требует у стратегии найти классы и если их больне одного то ругается. Если надо несколько, то getClassInstanceListFromSysAttribute

[mazzy]

Цитата:

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

_baseClass это имя базового класса а не ключа. Ключ, должен идентифицировать потомка этого базового класса.

Угу-угу.
и это не отменяет "Ключ ТУПО преобразуется к именам. В текущей реализации Platform 7 ключ не имеет никакой семантики."

Цитата:

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

Угу потому что выбранный тобой метод нужен в случае если требуется ровно один класс. Соответственно он требует у стратегии найти классы и если их больне одного то ругается. Если надо несколько, то getClassInstanceListFromSysAttribute

Макс, ты снова рассказываешь что это работает. Спасибо тебе за это.
Я же снова и снова возвращаюсь к трудоемкости и к исходному вопросу "Какая цель создания экземпляров классов через расширенные атрибуты? Чем не устраивает старый дедовский способ construct?"

Макс, мы верим, что это работает.
Некоторые читатели даже знают как это работает.
А некоторые читатели даже давно используют.

Мы уже поняли, что МС хочет сделать свои классы read only.
И хочет вынести фазу инстанцирования куда-то в сторонку.
Ок, должен возникнуть класс-запускач. Но ведь можно было не ломать систему конструкторов, а реализовать их в отдельном семействе классов. Также есть масса других способов.
Ок, должен возникнуть контроль созданных, но не прошедших инициализацию объектов.

Я говорил о том, что за уникальностью атрибутов фреймворк не следит - ответственность лежит на программисте (причем не на МС-программисте).
Я говорил о том, что в фреймворке далеко не везде идет работа с неуникальными атрибутами и классами - гораздо чаще фреймворк будет выкидывать исключение в runtime. И это тоже проблема программиста (причем не МС-программиста).

Вообще фреймворк очень многое переводит в рантайм, делая аксапты очередной php-фреймворк. Может быть, некоторые будут очень рады. Но эти некоторые тут же потребуют и другие инструменты, обязательно присущие рантаймовым фреймворкам. Без обязательных инструментов этот фреймворк полная фигня, которая не стоит денег, которые за него просят.

Я хочу донести мысль, что задачу "сделать классы read only" можно было решать разными способами. Но МС выбрал способ, который минимизирует трудозатраты только тех, кто создает новую функциональность. Полностью проигнорировав интересы остальных... Лично я очень хотел бы, чтобы учитывались интересы всех заинтересованных сторон.