mfp: X++ the most extensible language on the planet!

[belugin]

Цитата:

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

Если взять все объекты (или группы объектов с одинаковым префиксом) из АОТ и так же расположить по кругу, а потом нарисовать связи в соответствии с перекрестными ссылками, то должна получиться сходная картина.

Надо попробовать. Только я бы не рисовал по кругу, а кластеризовал бы. Вопрос, хорошо это или плохо - такая связанность.

Цитата:

Персонал действительно выполняет функцию ERP системы, но не там, где ее нет (она везде есть, пусть даже в виде скоросшивателя, никто не держит все проводки в голове), а где ее функциональности не хватает. Если полностью заменить персонал и оборудование, включая директора и калькулятор, но оставить скоросшиватель, новый персонал вполне сможет продолжить с работу в этой системе.

Ну это вопрос. Мне кажется внутри персонала должен быть код application foundation - бухгалтерия и прочее. И вряд ли совсем все подробности описаны в документах.

Цитата:

Что касается интерфейсов между отделами. Я бы сказал, это довольно условно. Однажды попросили меня дать права доступа к оплате кредитной картой простому складскому рабочему. Я, конечно, поинтересовался у консультанта, не попутал ли он чего, ведь рабочий на складе обычно переставляет ящики. На что мне ответили, что в их бизнес-сценарии рабочий на складе должен брать в руки ящик только после того, как поступит оплата кредитной картой.

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

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

[ax_mct]

Цитата:

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

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

А что даст и кому?

[belugin]

Цитата:

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

А что даст и кому?

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

[ax_mct]

Цитата:

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

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

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

Те же Netsuite, SalesForce предоставляют API к транформаторной будке и это намного честнее. В чем крутизна хитро-изогнутых инструментов X++ если нельзя ими лазить - непонятно.

Поэтому лучше бы MFP посыпал голову пеплом. Мальчишки-живодеры.

Я кстати написал там у него вежливый но саркастичный комментарий два дня назад, но полагаю что его не пропустят. Например я задал вопрос как много сейчас программистов X++ v.7-8 во всем мире вне стен Microsoft. И пожалел что пока еще нет лямбд и шаблонов на уровне языка.

[belugin]

Цитата:

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

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

Зависит от того, что значит "изменять функциональность". В разрешенных местах можно вроде. Драйвера поддерживаются в рамках одного поколения API.

Цитата:

Те же Netsuite, SalesForce предоставляют API к транформаторной будке и это намного честнее.

Это что значит?

Цитата:

В чем крутизна хитро-изогнутых инструментов X++ если нельзя ими лазить - непонятно.

Как это нельзя? Можно но не всюду. Невозможно сделать обратно совместимое API, где можно вообще все.

Нет ли мест, где изменения особо никому не нужны? Типа менять поведение бухгалтерской проводки как сущности нельзя, но менять процессы порождающие проводки можно?

[ax_mct]

Цитата:

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

Зависит от того, что значит "изменять функциональность". В разрешенных местах можно вроде. Драйвера поддерживаются в рамках одного поколения API.
..
Это что значит?
..
Как это нельзя? Можно но не всюду. Невозможно сделать обратно совместимое API, где можно вообще все.

Нет ли мест, где изменения особо никому не нужны? Типа менять поведение бухгалтерской проводки как сущности нельзя, но менять процессы порождающие проводки можно?

API означает более или менее неизменный интерфейс и определяет границы дозволенного.

Самый расширяемый язык X++ (читай D365FO) не имеет таких интерфейсов, а предлагает сверлить и подвешиваться где только сможешь.
При этом нигде не говорится о концепции и границах дозволенного. Все рассматривается только со стороны технических возможности.

Опытные программисты AX по инерции используют те же границы дозволенного к которым они привыкли. Клиенты по инерции рассматривают как ту же платформу разработки которая переехала в web. И данная инерция движения и мысли провоцируется и поощряется вот такими вот статьями.

Новые программисты, скорее всего c .NET, вообще не имеют опыта чтобы понимать что можно, а что нельзя. И понимание у них скорее всего такое что можно все если дают такие широкие возможности.

Но это же не так. Дымовая завеса с этим X++. Нельзя программировать так как было как раньше. Не с технической стороны, а с точки зрения функционала.
И кто об этом и где говорит?

Цитата:

менять процессы порождающие проводки можно

Уверены? По идее все от зависит от нюансов. Что-то можно, а что-то нельзя, но кто это будет оценивать и на какой стадии?

[belugin]

Цитата:

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

API означает более или менее неизменный интерфейс и определяет границы дозволенного.

Самый расширяемый язык X++ (читай D365FO) не имеет таких интерфейсов, а предлагает сверлить и подвешиваться где только сможешь.
При этом нигде не говорится о концепции и границах дозволенного. Все рассматривается только со стороны технических возможности.

Я думаю на эту тему в терминах design-by-contract, ковариантности, контравариантности и обратной совместимости.

Цитата:

Уверены? По идее все от зависит от нюансов. Что-то можно, а что-то нельзя, но кто это будет оценивать и на какой стадии?

Я имею ввиду гипотетичекскую альтернативную реальность в которой разделяем приложение разделено на две части - в одном модули которые можно легко обновить на новую версию с продуманным интерфейсом расширения, а в другой - "скрипты", которые можно править, но при этом новая версия не является обратно совместимой. То есть возможен ли некий компромисс. Условно говоря, как в линуксе - можно написать приложение, используя API, а можно поменять исходный код ОС. Или как в игровых движках (тут я не специалист но вроде там так) ядро .из основных понятий и скрипты (насколько я знаю, там даже другие языки для них используют чем для ядра - типа lua).