DeniZone: The future of X++

[Logger]

Кстати, интересно, зачем им потребовалось наследование таблиц ?
Решили отказаться от мапов ?

[sukhanchik]

Цитата:

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

Кстати, интересно, зачем им потребовалось наследование таблиц ?
Решили отказаться от мапов ?

Ну мапы-то "накодили не они" . А может сделают что-то более сильное (верю в светлое будущее). Мапы в общем-то тоже.... наследование, притянутое за уши.

[mifi]

Цитата:

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

Ну мапы-то "накодили не они" . А может сделают что-то более сильное (верю в светлое будущее). Мапы в общем-то тоже.... наследование, притянутое за уши.

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

[db]

Цитата:

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

Кстати, интересно, зачем им потребовалось наследование таблиц ?
Решили отказаться от мапов ?

Пока не увидим как это реализовано (какой интерфейс к этой табличной иерархии и как она отображается в бд) можно только гадать

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

все строго имхо

дополнение:
кстати есть уже достаточно древняя и очень классная книга Фаулера и компании
"Архитектура корпоративных программных приложений"
Вопросы табличного наследования там в том числе рассмотрены

[kashperuk]

Цитата:

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

Пока не увидим как это реализовано (какой интерфейс к этой табличной иерархии и как она отображается в бд) можно только гадать

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

все строго имхо

Я думаю, что это довольно близко описывает замысел. Хотя, это мое имхо тоже

[Logger]

Интересно, а формы они наследовать не планируют ?
Я как-то разрабатывал в системе где это было. Имеет право на жизнь.

[mifi]

Цитата:

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

Интересно, а формы они наследовать не планируют ?
Я как-то разрабатывал в системе где это было. Имеет право на жизнь.

Я тоже. И система называлась Borland Delphi.
Помню, когда переходил с Delphi на MorphX, очень не хватало этого самого наследования визуальных форм. Но, поскольку в Core AX дельфистов всегда было немного, то эта идея вряд ли когда-нибудь превратится в фичу AX, увы

[belugin]

Цитата:

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

Интересно, а формы они наследовать не планируют ?
.

Если винмательно почитать тут:
sjakalax: DAXCONF - Patterns in building client forms & usability

то можно кое что узнать о реюзе дизайна в формах

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