Какое-то новое Pontoppidan OOП в AX7

[ax_mct]

У нас какое-то новое ООП которое я умудрился проспать. Возможно что даже это изобретение ожидающее патента.

Экземпляр родительского класса спокойно вызывает метод существующий только в потомке. В моей реальности компилятор такое пропустить не должен как и мой мозг. Со мной что-то не так?

https://blogs.msdn.microsoft.com/mfp...od-signatures/






https://blogs.msdn.microsoft.com/mfp...g-class-state/

[ExtensionOf(classStr(SysUserLogCleanup))]
final class mfpSysUserLogCleanup_Extension
{
    // Extending class state...
    private boolean mfpArchive;
    private DialogField mfpDialogArchive;
    
    // Adding new instance methods...
    private void mfpDialog(Dialog _dialog)
    {
        mfpDialogArchive = _dialog.addField(extendedtypestr(NoYesId), "Archive");
        mfpDialogArchive.value(mfpArchive);
    }
    private void mfpGetFromDialog()
    {
        mfpArchive = mfpDialogArchive.value();
    }


    // Wiring up event handlers...
    [PostHandlerFor(classStr(SysUserLogCleanup), methodStr(SysUserLogCleanup, dialog))]
    public static void mfpSysUserLogCleanup_Post_Dialog(XppPrePostArgs _args)
    {
        Dialog dialog = _args.getReturnValue();
        SysUserLogCleanup instance = _args.getThis();
        instance.mfpDialog(dialog);
    }


    [PostHandlerFor(classStr(SysUserLogCleanup), methodStr(SysUserLogCleanup, getFromDialog))]
    public static void mfpSysUserLogCleanup_Post_GetFromDialog(XppPrePostArgs _args)
    {
        SysUserLogCleanup instance = _args.getThis();  
        instance.mfpGetFromDialog();
    } 
}

[kashperuk]

Может у тебя просто более старая версия приложения?

Какой класс в примере "базовый", и какой метод существует только на "потомке", и каком именно?

[ax_mct]

Цитата:

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

Может у тебя просто более старая версия приложения?

Какой класс в примере "базовый", и какой метод существует только на "потомке", и каком именно?

В первом примере
Обьявление переменной в потомке:

class SalesLineType_NewType extends SalesLineType
{
	public boolean myExtraData;	
}

Использование:

SalesLineType salesLineType = salesLine.type(); // родительский тип
salesLineType.myExtraData = true; // обращение к члену потомка через экземпляр родительского типа

Должно быть

SalesLineType_NewType salesLineType = salesLine.type();

Не?

Пример 2
Обьявление метода в потомке:

SysUserLogCleanup_Extension extends SysUserLogCleanup
{
    private void mfpGetFromDialog()
    {
    } 
}

Использование:

SysUserLogCleanup instance = _args.getThis();  // родительский тип
instance.mfpGetFromDialog(); // вызов метода потомка через экземпляр родительского типа

При отсутствии данного метода в родительском классе (или в обязательном интерфейсе но это не суть)
другой потомок SysUserLogCleanup_AnotherExtension может и не иметь этот метод mfpGetFromDialog().
Для этого компилятор и существует.

В моей реальности это должно быть

SysUserLogCleanup_Extension instance = _args.getThis();

иначе компилятор не должен такое пропускать.

В связи с чем и вопрос я может какой патент пропустил?
Это не опечатка у него в двух примерах, это что-то другое.

[ax_mct]

O, я все проспал!

[ExtensionOf] != extends то есть это не наследование, а расширение базового класса.

То есть все потомки будут иметь этот член, так? Похоже что так.

[kashperuk]

Цитата:

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

O, я все проспал!

[ExtensionOf] != extends то есть это не наследование, а расширение базового класса.

То есть все потомки будут иметь этот член, так? Похоже что так.

Да, это совсем не потомок. Это как-бы "partial class", но не совсем.

[macklakov]

Цитата:

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

У нас какое-то новое ООП которое я умудрился проспать.

Есть такое дело. ООП уже не модно. Для микро-сервисов и прочего веба это излишне сложно. Поэтому в новомодном GO классов больше нет. Есть структуры, к которым можно цеплять методы-обработчики.

[belugin]

Цитата:

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

Да, это совсем не потомок. Это как-бы "partial class", но не совсем.

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


1) Прочитайте и поймите что такое extension method.
2) Генерализируйте это на остальные члены класса.

C# тоже движется в этом направлении.

Фактически, методы расширения - это синтаксический сахар для утилит (вместо StringUtils::convertToKOI8("test") пишем "test".convertToKOI8()).

Так же поля расширения это синтаксический сахар для какой-то более сложной конструкции (вместо GetExtensionOfType<MyInvoiceExtension>(Invoice).myField пишем Invoice.MyField)

[kashperuk]

Ну это раньше туда пихали именно "extension methods" в понимании C#
Сейчас это уже намного больше. Могут добавлять классу еще состояния, могут добавлять логику к существующим методам класса, могут вызывать protected методы класса, т.д.

extension methods как именно синтаксический сахар не интересно даже.

[belugin]

Цитата:

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

Могут добавлять классу еще состояния, могут добавлять логику к существующим методам класса,

Насколько я понял, это реализуется при помощи автогенерирования событий и связанных словарей расширений. Наверное не правильно называть это синтакическим сахаром. Тут две вещи - некий FW экстешненов, которые можно реализовать и на C# и поддержка его языком. Попробуй декомпилировать X++ сборку и увидишь код на C# который делает то же самое.

Цитата:

могут вызывать protected методы класса, т.д.

Вот это интересно как устроено (они точно могут наледоваться от кого-то кроме расширяемого класса?)

[MikeR]

Цитата:

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

Фактически, методы расширения - это синтаксический сахар для утилит (вместо StringUtils::convertToKOI8("test") пишем "test".convertToKOI8()).

Так же поля расширения это синтаксический сахар для какой-то более сложной конструкции (вместо GetExtensionOfType<MyInvoiceExtension>(Invoice).myField пишем Invoice.MyField)

Эта отрава я правильно понимаю из java сюда попала?

[belugin]

Цитата:

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

Эта отрава я правильно понимаю из java сюда попала?

Начальная идея (extension methods) C# остальное не знаю - местное наверное

[Logger]

Цитата:

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

Насколько я понял, это реализуется при помощи автогенерирования событий и связанных словарей расширений. Наверное не правильно называть это синтакическим сахаром. Тут две вещи - некий FW экстешненов, которые можно реализовать и на C# и поддержка его языком. Попробуй декомпилировать X++ сборку и увидишь код на C# который делает то же самое.

А вот интересно.
Раньше если добавляешь переменную в класс, то надо инкрементно компилировать, чтобы все наследники пересобрались. Иначе глючит.
Если добавляешь параметр в метод то смотришь по перекрестным ссылкам где он вызывается и где перекрыт в наследниках, тоже правишь и компилируешь эти места. Иначе глючит и может падать.

Теперь, есть ли какие-то подобные простые правила, что делать при работе с Extension ? Что минимально надо откомпилировать и проверить при добавлении расширений. Глобальную компиляцию не хочется делать на каждый чих.

[belugin]

Цитата:

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

Теперь, есть ли какие-то подобные простые правила, что делать при работе с Extension ? Что минимально надо откомпилировать и проверить при добавлении расширений. Глобальную компиляцию не хочется делать на каждый чих.

По идее если не используешь новое, то не надо ничего перекомпилировать кроме того модуля, где сам экстеншен - это ж стандартный .NET. Есть какие-то кеши которые надо флашить, наверное.

[kashperuk]

Цитата:

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

А вот интересно.
Раньше если добавляешь переменную в класс, то надо инкрементно компилировать, чтобы все наследники пересобрались. Иначе глючит.
Если добавляешь параметр в метод то смотришь по перекрестным ссылкам где он вызывается и где перекрыт в наследниках, тоже правишь и компилируешь эти места. Иначе глючит и может падать.

Теперь, есть ли какие-то подобные простые правила, что делать при работе с Extension ? Что минимально надо откомпилировать и проверить при добавлении расширений. Глобальную компиляцию не хочется делать на каждый чих.

By definition, нужно компилировать только ту модель, в которой ты добавляешь extension. Представь, что application code у тебя представлен просто dll'кой.
Хотя, конечно, проверить конкретно этот сценарий не помешало бы.

Добавить параметр в метод нельзя.. Собственно, о возможных способах решения пост mfp указанный выше.