Private, Protected, Public or Internal

[sukhanchik]

Цитата:

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

Увы. Есть такое понятие как карма и поддержка.

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

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

[belugin]

Цитата:

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

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

Какие-то точки расширения были продуманы, какие-то нет. Какие-то были лишние. Регулярное добавление свидетельствует только о том, что либо не все были продуманы заранее либо появися новый функционал.

[Logger]

Цитата:

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

а однажды даже написать event handler к навигационному методу на таблице (это которого не видно в aot, но он там всё-таки есть после активации определенного свойства на table relation-е), потому-что по-другому ну никак.

Как интересно! А вы не могли бы описать подробнее ?

[Logger]

Цитата:

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

Они могут себе попросить точку расширения, которой им не хватает.

Не могут. Вернее могут, но это слишком дорого и трудозатратно. Т.е. по факту не могут. И на практике ищут обходные пути. Об этом многократно говорилось.
Пожалуй я соглашусь с Евгением (DSPIC), что если по умолчанию ставить везде protected вместо private, то всем будет намного легче.

[Logger]

Цитата:

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

классическая аксапта до CIL использует очень древнуюю виртуальную машину Java

Что, правда ? Мне казалось что Дамгаарды просто посмотрели на Java 1.0 и сделали по мотивам, но все сами. Как же оно было на самом деле?

[fed]

Цитата:

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

Что, правда ? Мне казалось что Дамгаарды просто посмотрели на Java 1.0 и сделали по мотивам, но все сами. Как же оно было на самом деле?

Я тоже много раз читал рассуждения mazzy по поводу того что Аксапта использует древнюю явовскую VM, но никогда не читал что-то подобного в воспоминаниях участников процесса или даже архивных внутренних документах MS. При этом схожесть с явой в старой аксапте - она тоже достаточно относительная. Я бы скорее назвал X++ версии 2.5 "Visual Basic с явовским синтаксисом". Все-таки многие очень фундаментальные явовские идеи - типа интерфейсов, появились в языке только где-то в DAX2009 (хотя да - interface был reserved word со времен версии 2.1).

[belugin]

Цитата:

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

Точки расширения они делают регулярно. Деятели...

Тут такая логическая цепочка: регулярные обновления => совместимость => органичение объема API.

При регулярных обновлениях надо быть обратно совместимым потому, что иначе расширения будут отваливаться. Теперь рассмотрим, что будет, если просто везде стаить public.

Вот, допустим кто-то написал

public void foo(string bar)
{
   ...- 
}

Теперь нам надо сделать дополнительный параметр.

public void foo(string bar, int baz)

- так делать нельзя. Расширение может вызывать этот метод и оно перестанет компилироваться и работать.

public void foo(string bar, int baz = 0)

Тут расширение из предыдущей фразы будет работать, но
1. Может быть расширение которое обернуло этот код и не прокидывает новый параметр
2. Если параметр baz логически обязательный, то все скомпилируется и сработает но неправильно. Фактически, это означает, что логически обязательный параметр вообще никак нельзя добавить без потери обратной совместимости.

public void foo(string bar)
{
     this.fooWithBaz(bar, 0);
}
public void fooWithBaz(string bar, int baz)

Так можно, но нельзя перестать вызывать foо в том месте, где он изначально вызывался, потому, что расширение может подписаться на вызовы foo или обернуть и тогда оно тихо перестанет работать.

Еще можно сделать disposable context - фактически передавать дополнительные данные через статический метод, но будут пролемы с рекурсией.

Можно изначально передавать параметры завернутые в parameter object.

A самое главное, от логически обязательного параметра не спасает ничего.

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

[fed]

Цитата:

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

Они могут себе попросить точку расширения, которой им не хватает.
Мы регулярно их делаем.

Могу поделиться опытом: Запросили точку расширения 19 мая. Получили ее в версии 10.0.21, которая в сентябре попала в general availability. Поскольку фича была непринципиальна - мы могли позволить себе подождать.
Но в целом соглашусь с другими ораторами: Запрос точки расширения могут себе позволить только ISV. В проектных условиях - cut and paste - наше все...

[belugin]

Цитата:

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

Я тоже много раз читал рассуждения mazzy по поводу того что Аксапта использует древнюю явовскую VM, но никогда не читал что-то подобного в воспоминаниях участников процесса или даже архивных внутренних документах MS.

Маззи явно не отделяет свои гипотезы от того, что ему точно известно.

В Ax<=2012 своя ВМ и свой рантайм. Это можно даже по внешним свойствам догадаться. Оно ведет себя не как ява, а как динамический рантайм со статическим проверщиком типа тайпскрипт.

final - оно ж прежде всего логическая вещь, а не для перформанса.

[belugin]

Кстати, конкретно от модуля ER есть API которые бы вы хотели, но не просили официально?

[Stitch_MS]

Цитата:

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

Как интересно! А вы не могли бы описать подробнее ?

Нужно было использовать запись ERFormatMappingTable, но не ту, что ER модуль предлагает. Детали не спрашивайте, у меня у самого вопросы к консультанту, но задачу нужно было решить. Поскольку модуль закрыт, пришлось прицепиться к навигационному методу solution, чтобы подставить нужную запись ERFormatMappingTable, из которой уже в стандартном коде будет найдена соответствующая ERSolutionTable через ERFormatMappingTable.solution().

[ExtensionOf(tableStr(ERFormatMappingTable))]
final class ERFormatMappingTableNNN_Extension
{
    [PreHandlerFor(tableStr(ERFormatMappingTable), tableMethodStr(ERFormatMappingTable, solution))]
    public static void ERFormatMappingTable_Pre_solution(XppPrePostArgs args)
    {
        NNNEuSalesListReportingEngineContext context = NNNEuSalesListReportingEngineContext::current();

        if (context != null && context.generatingReport && context.reportFormatMappingId != 0)
        {
            ERFormatMappingTable erFormatMappingTable = ERFormatMappingTable::find(context.reportFormatMappingId);

            ERFormatMappingTable callerERFormatMappingTable = args.getThis() as ERFormatMappingTable;

            callerERFormatMappingTable.data(erFormatMappingTable);
        }
    }

}

[axm2017]

Цитата:

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

Кстати, конкретно от модуля ER есть API которые бы вы хотели, но не просили официально?

Хотелки (как разраба):
а) возможность создавать свою среду разработки. Не уверен что сейчас это возможно без финтов. +

б) возможность встроить свои форматы (как Excel и ко) Вроде писали что можно но не тестил. + но- по идее конечно могу выгрузить в формате xml или json и далее уже все сделать но выглядеть это будет колхозно.

в) возможность связать явно маппинг и формат +++

[axm2017]

Цитата:

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

Ну в Вашем случае получается, что есть последователи вашего закрытого кода. А это "в корне меняет ситуацию"...

Разные случаи есть. Типичный случай когда человек не сильно погруженный в функционал полез менять что то в доступных методах. Ограничение позволяет ему выбрать правильное место по мысли автора кода.

[VORP]

Цитата:

Какие-то точки расширения были продуманы, какие-то нет. Какие-то были лишние

В новом модуле CreditManagement (Управление кредитными лимитами, CredMan) вообще вся функциональность сделана internal, то есть даже копи-паст не очень поможет(если только скопировать всю модель).

[belugin]

Цитата:

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

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

Мне тогда трудно использовать эту информацию. Хотелось бы знать, зачем, чего не хватило в стандартном функционале.

P.S. Вот тут "as XXX" лучше убрать имхо. Если что-то не так, то лучше получить invalidcastexception и знать в чем именно дело, чем nullreferenceexception и гадать то ли пришел null то ли не тот тип.

            ERFormatMappingTable callerERFormatMappingTable = args.getThis() as ERFormatMappingTable;

            callerERFormatMappingTable.data(erFormatMappingTable);

Да и короче будет

[belugin]

Цитата:

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

а) возможность создавать свою среду разработки. Не уверен что сейчас это возможно без финтов. +

Это вряд ли - получается надо открыть все-все а потом это поддерживать.

Цитата:

б) возможность встроить свои форматы (как Excel и ко) Вроде писали что можно но не тестил. + но- по идее конечно могу выгрузить в формате xml или json и далее уже все сделать но выглядеть это будет колхозно.

Это можно завести как запрос на точку расширения, только с бизнес мотивацией. Желательно с описанием примера.

Цитата:

в) возможность связать явно маппинг и формат +++

Мы кажется это обсуждали уже, но я забыл зачем именно это нужно и по-быстрому не нашел.

[Stitch_MS]

Цитата:

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

В новом модуле CreditManagement (Управление кредитными лимитами, CredMan) вообще вся функциональность сделана internal, то есть даже копи-паст не очень поможет(если только скопировать всю модель).

О, это вообще песня. Чтобы эта приблуда заработала в Intercompany без копи-пасты, пришлось жестоко изобретать.

Например, через reflection в нужные моменты временно активировать кредит-чекпоинты для типа proforma confirmation в настройках, а потом постить этот документ для original SO, чтобы сработал кредит-чек и, если надо, заблокировал его.

Или, скажем, при нажатии Release to warehouse в intercompany SO, переходить в original SO, запускать кредит-чек для чекпоинта Release to warehouse, и если там получался кредит-холд, перебрасывать этот кредит-холд в IC SO. Так чтобы в итоге задолженность конечного покупателя не дала отпустить товар на склад в другой компании.

[trud]

Цитата:

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

Грубо говоря - мне дали задачу, я написал класс, в котором 20 методов private и 10 методов public / protected. Если я обычный программист - я не думаю о последователях - ибо их нет, а расставлять точки расширения наобум - это бестолковая задача. А вот если я программист MS - я обязан дополнительно подумать об (условно) 5 точках расширения, которые я должен заложить в свой код.

Этож не так работает, у программистов МС тоже есть свои сроки и задачи. Т.е. там где партнер использует рефлекшн, они просто ставят internal.
Потом возникает вопрос частоты обновлений, тут на помощь приходит микросервисная архитектура. Делается микросервис(идельно - работающий только на Тир2, что отсекает большую часть разработчиков из репортинга багов ), который уже отдельная команда пилит по своему расписанию.
Т.е. архитектура системы подстраивается под структуру огранизации разрабатывающей ПО, вроде такой закон даже есть
Вообще модификаторы идеально были сделаны в начальной версии АХ, т.е. private не запрещал вызов метода, а выдавал ошибку BP. Это как бы на порядок лучше использование Reflection.

[imir]

Ладно со старыми методами, там private по-умолчанию переехал из 12-й, это можно объяснить (не)злым умыслом. Но в новых модулях, кторые пишутся с нуля.. смотрим написанный недавно с нуля Asset leasing:

- все классы помечены internal final class AssetLease*
Все методы:
-все что можно private
- там где нельзя поставить private по смыслу - internal
- нельзя ни то, ни другое - [Hookable(false)]

ну т.е. не то что точки не заложены, а модуль целиком и полностью с особой паранойей закрыт изначально.

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

[Stitch_MS]

Цитата:

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

Допускаю, что это задумано для того, чтобы репортили баги вместо заплаток

А ещё это освобождает вендора от неприятных раздумий типа «а не breaking ли change я сейчас пилю?»