Клуб анонимных оверлейщиков

[Logger]

Прикольно.
Только там не описали как обращаться к переменным класса.
Вот так можно ?

class BaseClass1
{
    str   memberVar;  // axforum
    str method1(int arg) {
        memberVar+="; "+int2str(arg); // axforum
    
    }
}

[ExtensionOf(ClassStr(BaseClass1))]
class BaseClass1_Extension
{
    str method1(int arg) {
        // Part 1
        info(memberVar);  // axforum
        var s = next method1(arg + 4);
        info(memberVar);  // axforum
        // Part 2
        return s;
    }
}

Чем-то это напомнило классы SysReportRun и SysSetupFormRun
Вернулись к корням ?

[trud]

думаю да

Цитата:

can also access other public and protected methods and variables of the class.

переменные класса то по умолчанию protected

[mazzy]

неужели таки сделают extension method как у нормальных людей.
http://kotlinlang.org/docs/reference/extensions.html

[ax_mct]

Цитата:

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

неужели таки сделают extension method как у нормальных людей.
http://kotlinlang.org/docs/reference/extensions.html

У Котлин это без необходимости наследования, а вот по
https://roadmap.dynamics.com/?i=296a...3a1#collapse13
непонятно наследование это или нет. К примеру если у базового класса есть абстрактные методы, то что?

Но главное как подметили это обязательность или нет вызова базового метода. Потому как обертка вокруг и полная подмена - очень разные вещи.

Вот скучная статья если кому интересно.
http://wiki.c2.com/?CompositionInsteadOfInheritance

[skuull]

Цитата:

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

У Котлин это без необходимости наследования, а вот по
https://roadmap.dynamics.com/?i=296a...3a1#collapse13
непонятно наследование это или нет. К примеру если у базового класса есть абстрактные методы, то что?

Но главное как подметили это обязательность или нет вызова базового метода. Потому как обертка вокруг и полная подмена - очень разные вещи.

Это не наследование. И наследовать extension тоже нельзя, там даже проверка была что он всегда final, но в примере походу как всегда накосячили.

Про next говорят, что его выкинуть нельзя.

[ax_mct]

Цитата:

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

Это не наследование. И наследовать extension тоже нельзя, там даже проверка была что он всегда final, но в примере походу как всегда накосячили.

Про next говорят, что его выкинуть нельзя.

Если next() как super()/base() вызов базового метода выкинуть нельзя то это тогда просто синтаксический сахар.
В том же xppPrePostArgs через getThis() и parm() я точно так же могу иметь доступ к переменным класса, если конечно он нормально спроектирован.
В чем прибыток то?

[kashperuk]

Цитата:

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

Если next() как super()/base() вызов базового метода выкинуть нельзя то это тогда просто синтаксический сахар.
В том же xppPrePostArgs через getThis() и parm() я точно так же могу иметь доступ к переменным класса, если конечно он нормально спроектирован.
В чем прибыток то?

Во многом, да.

Разница в доступе к protected methods / protected class fields

[kashperuk]

Dave Froslie очень адекватный чувак, и нормально в техническом плане, так что это вы зря.
Он курирует партнерами с которыми мы ближе работаем, и extensibility requests по Finance, Project, GAB, etc. То есть с точки зрения именно application

Йорис - энтузиаст, поэтому больше интересовался возможностями платформы, конечно же.
Он бывший MVP - вот его блог http://daxmusings.codecrib.com/

Поэтому могло так показаться на конференции, что Дейв не шарил. Это не так

[ax_mct]

Цитата:

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

Во многом, да.

Разница в доступе к protected methods / protected class fields

И еще наверно в целостности выполнения так как при подписке нет предсказуемости последовательности вызова подписчиков. Тут кстати возникает вопрос как будут жить вместе несколько врапперов между собой и порядок вызова между ними и их самих с подписными пре и пост.
Вроде отдельная тема появилась - пойду почитаю...

[ax_mct]

Цитата:

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

Dave Froslie очень адекватный чувак, и нормально в техническом плане, так что это вы зря.
Он курирует партнерами с которыми мы ближе работаем, и extensibility requests по Finance, Project, GAB, etc. То есть с точки зрения именно application
...
Поэтому могло так показаться на конференции, что Дейв не шарил. Это не так

Поскольку блокирование кода и уход от основы АХ - перекрытия слоев само по себе - неадекват, от которого вообще никто не выигрывает - то и ищем мы этих самых мифических технарей-неадекватов в Майкрософте. Ну и поскольку он из угла тестеров то я не исключаю что все текущие проблемы экосистемы из-за того что для Дейва автоматические тесты и покрытие ими - приоритет. Он при этом может быть и адекватом только с противоположными интересами и искренним непониманием проблем сложившейся экосистемы. Если не он то кто тогда сошел с ума?

[ax_mct]

Тихо и с косами стоят...
А у меня вопрос.
При overlaying конфликты кода и как результат логики - налицо, а при extension модели расширений конфликта кода нет и как результат конфликта логики не видно.
При seemless updates со стороны MS в production клиента встаёт вопрос о совместимости существующих расширений и этих апдейтов. Это реальная проблема или я опять занимаюсь от скуки scaremongering?

[skuull]

Цитата:

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

Тихо и с косами стоят...
А у меня вопрос.
При overlaying конфликты кода и как результат логики - налицо, а при extension модели расширений конфликта кода нет и как результат конфликта логики не видно.
При seemless updates со стороны MS в production клиента встаёт вопрос о совместимости существующих расширений и этих апдейтов. Это реальная проблема или я опять занимаюсь от скуки scaremongering?

Ну если и занимаетесь то точно не один. Вот начинание https://github.com/Adacta/source-dependency где человек хочет знать, что метод который он расширял поменялся и не плохо было бы его посмотреть. Присоеденяйтесь, внесите лепту делом, а не словом

[ax_mct]

Цитата:

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

Ну если и занимаетесь то точно не один. Вот начинание https://github.com/Adacta/source-dependency где человек хочет знать, что метод который он расширял поменялся и не плохо было бы его посмотреть. Присоеденяйтесь, внесите лепту делом, а не словом

Дельно человек предлагает. Но как это будет выглядеть я не понимаю. Seamless servicing and continuous updates как я понимаю это прямиком в production.

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

Насчет лепты не готов. Мне кредит за дом платить надо, а не песочные замки строить вместе с играющими в песочнице

[skuull]

Цитата:

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

Дельно человек предлагает. Но как это будет выглядеть я не понимаю. Seamless servicing and continuous updates как я понимаю это прямиком в production.

Есть слухи, что рано или поздно, но скорее рано, platform обновления будут ставиться раз в месяц сами по себе, как на винду. По поводу application suite даже слухов нет. Т.е. будете сами их ставить на дев, сами этим или каким другим образом смотреть, что ваши чудо расширения не развалились и сами их потом деплоить. А в связи с тем, что МС очень сильно хочет, чтобы мы их ставили, нам бы какой-то инструмент в помощь.
Хотелось бы еще заметить, что титаник задраен не до конца, даты задраивания модели Currency я нигде не видел.

[ax_mct]

Цитата:

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

Есть слухи, что рано или поздно, но скорее рано, platform обновления будут ставиться раз в месяц сами по себе, как на винду. По поводу application suite даже слухов нет. Т.е. будете сами их ставить на дев, сами этим или каким другим образом смотреть, что ваши чудо расширения не развалились и сами их потом деплоить. А в связи с тем, что МС очень сильно хочет, чтобы мы их ставили, нам бы какой-то инструмент в помощь.
Хотелось бы еще заметить, что титаник задраен не до конца, даты задраивания модели Currency я нигде не видел.

Довольно непросто понять что есть platform, а что application suite. Туповатому мне.

Application stack and server architecture
https://docs.microsoft.com/en-us/dyn...r-architecture

New extensibility support in the July 2017 Update
https://blogs.msdn.microsoft.com/mfp...y-2017-update/

Цитата:

Refactoring of the *TableType and *LineType classes, so insert/update/delete events on the backing tables can be used as extension points.

То есть я понимаю все это так что обновления и изменения в *TableType and *LineType классах будут идти автоматически и прямо в Production. Я правильно понимаю?

[EVGL]

Цитата:

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

То есть я понимаю все это так что обновления и изменения в *TableType and *LineType классах будут идти автоматически и прямо в Production. Я правильно понимаю?

Нет. Банально идет речь о том, что на методы SalesTableType.update() и SalesLineType.update() повесили атрибут [Hookable] или отрефакторили там, чтобы можно было вклиниваться в исполнение кода.

[ax_mct]

Цитата:

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

Нет. Банально идет речь о том, что на методы SalesTableType.update() и SalesLineType.update() повесили атрибут [Hookable] или отрефакторили там, чтобы можно было вклиниваться в исполнение кода.

Это, да, в контексте "что именно сделали в данных классах" для возможности их расширения не меняя "базовый" код.

Но зачем? Затем чтобы можно было автоматически и без спроса менять этот "базовый" код в Production.
То есть, код SalesLineType.update() может меняться автоматически и без спроса в Production. Это так или нет? В этом вопрос.

[Vadik]

Нет. Не может

[fed]

Цитата:

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

Есть слухи, что рано или поздно, но скорее рано, platform обновления будут ставиться раз в месяц сами по себе, как на винду.

Во многих индустриях (в частности в фармацевтике), обязательно использование стандартизированых систем управления качеством. И большая часть систем качества требует верификации устанавливаемого программного обеспечения. Не буду притворятся что я очень хорошо процесс верификации понимаю, но одно из его требований состоит в том, что любое обновление, перед развертыванием, должно либо тестироваться самим клиентом, либо каким-то независимой тестирующей организацией. Поэтому никакой автоматической установки обновлений в фармацевтике нет и быть не может. Аналогичный подход применяется и в других индустриях где системы управления качеством достаточно стандартизированы.
И разговоры об автоматическом обновлении чего либо просто демонстрируют как в MS на самом деле плохо понимают свой рынок...

[kashperuk]

Цитата:

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

То есть я понимаю все это так что обновления и изменения в *TableType and *LineType классах будут идти автоматически и прямо в Production. Я правильно понимаю?

Раньше в salesLine.update(), к примеру, super() не вызывался. Вместо этого вызывался salesLineType.update(), который внутри делал record.doUpdate()

После рефакторинга super() будет вызываться в salesLine.update(), а весь код вокруг него который был в salesLineType вынесен в различные методы.

Тем самым достигается несколько вещей:
- Теперь можно будет подписаться на вызов onInserted, onUpdated, onUpdating, etc. на SalesLine - раньше это было невозможно, так как event тригеррится в super()
- Теперь можно будет с помощью CoC или pre/post-method handlers добавлять требуемую партнерскую логику, которая должна выполняться во время обновления строки заказа.