mfp: X++ in AX7: Internal keyword

[Blog bot]

Источник: http://blogs.msdn.com/b/mfp/archive/...-internal.aspx
==============


internal is a new keyword in X++. It has the same semantics as in C#.

When you mark a class or method as internal, then it can only be accessed from within the model where it is defined.

internal class MyInternalClass
{
internal void myInternalMethod()
{
}
}

Notice, you can define internal methods on public classes too.




THIS POST APPLIES TO MICROSOFT DYNAMICS AX7 TECHICAL PREVIEW; IS PROVIDED AS-IS AND CONFERS NO RIGHTS.




==============
Источник: http://blogs.msdn.com/b/mfp/archive/...-internal.aspx

[gl00mie]

Прелестно... особенно с учетом того, что обновления стандартного приложения AX 2012 R3 поставляются мелкими моделями. Способ поставки обновлений изменится, или это - фича сугубо для ISV?

[macklakov]

Цитата:

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

Прелестно... особенно с учетом того, что обновления стандартного приложения AX 2012 R3 поставляются мелкими моделями. Способ поставки обновлений изменится, или это - фича сугубо для ISV?

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

[Stitch_MS]

Цитата:

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

...что обновления стандартного приложения AX 2012 R3 поставляются мелкими моделями. Способ поставки обновлений изменится, или это - фича сугубо для ISV?

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

Т.е. хотя Peter Villadsen не рекомендует использование pre- и post-event handlers, я считаю, что лучше использовать их где только можно, хотя бы на методах, параметры и назначение которых вряд ли изменится в будущем, типа системных xRecord.validateField.

[fed]

Цитата:

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

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

Вообще побывав на Convergence, я все время вспоминал старую шутку насчет "Как мало вы в сущности знаете о добрых феях". Микрософт, похоже что считает что:
1. Партнеры забирают 70-90% бюджета проекта, при этом нихера не делают. В конце концов - ведь внедрение - это только галочки расставить и может печатные формы подправить.
2. Если установить все в облаке - и саму аксапту и их микрософтовский чудо-конфигуратор в LCS -то нужда в партнерах почти отпадет и Микрософт сможет срубить больше бабла на лицензиях.
3. Поскольку обновления буду устанавливаться автоматически, то аксапта не будет иметь номера версии, и все клиенты всегда будут работать на последнем хотфиксе. Ну накрайняк - слегка заплатят каким-нить фрилансерам за апгрейд печатных форм.
.....
5. Profit!

В общем - как мало, в сущности, микрософт знает о добых феях....

P.S. Это я к тому что бесполезно рассуждать о стратегии Микрософта. Это броуновское движение. Вот попробуют они поработать с их новым подходом к рынку и придется им корректировать представления...

[George Nordic]

Цитата:

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

Вот попробуют они поработать с их новым подходом к рынку и придется им корректировать представления...

Или рынок

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

С Уважением,
Георгий

[gl00mie]

Цитата:

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

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

Мне кажется, не все так наивны, как минимум, среди тех, кто уже занимается поддержкой всяких облачных сервисов. К примеру, Eric Brechner (автор Hard Code) еще в 2010-м году писал в There's no place like production:

Цитата:

My current team has separate environments for development, check-in testing, scenario testing, stress testing, cross-division integration, partner integration, certification, and production. That’s eight different environments — and we’re planning to build out a preproduction environment next year.
What kind of fools build out and maintain useless environments? The kind who got burned building enterprise software. Large businesses rely on enterprise software — it’s got to work or they won’t buy it. Once they buy it, they own it. You don’t get to fix enterprise software anytime you want. That’s right, not even with security patches.
Remember, enterprise paychecks depend on having the software run smoothly. Software changes represent risk to an enterprise business. If the software doesn’t work, work well, and continue working well, enterprises businesses aren’t buying it. And they’ll tell you when they are darn well ready to accept a patch.
An entire generation of Microsoft engineers learned the hard way that you can’t release software until the code is fully tested. There are no “retries” in enterprise software.

Но там же он рассуждает о том, что в случае с сервисами всё иначе, и нужно выкатывать изменения в рабочую среду, но просто не для всех клиентов сразу

Цитата:

Let’s recap. There’s no place like production. You need a development environment to run a small set of automated check-in tests, a test environment to run preliminary acceptance and stress testing to help avoid catastrophic failures, and production. Anything more is superfluous.
There’s no place like production. The problem becomes configuring production to permit the testing and certifying of prerelease code. The solution is called “continuous deployment.” The concept is simple: deploy multiple builds to production, and use custom routing to direct traffic as desired. It’s like a source control system for regulating services instead of source files.

Т.е. с одной стороны, есть понимание, что корпоративное ПО - это особенная сфера разработки, где нельзя просто так взять и выкатить без спроса свой хотфикс, а с другой стороны, в случае сервисов еще 5 лет назад планировалось использовать совсем другой подход. Надеюсь, здравый смысл в случае с Аксаптой победит

[mazzy]

Цитата:

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

Мне кажется, не все так наивны
...есть понимание, что корпоративное ПО - это особенная
...здравый смысл

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

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

а вот с этим как-то... посмотрим.

[macklakov]

Цитата:

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

выкатить без спроса свой хотфикс, а с другой стороны, в случае сервисов еще 5 лет назад планировалось использовать совсем другой подход.

Подход будет все тот же. Клиента, при покупке, заставят подписать disclaimer, по которому вендор не несет ответственности за убытки понесенные в результате глючного update. Если же клиент прикоснется к исходникам, а он прикоснется, куда деваться, то гарантии совсем лишат. И, как всегда, клиент будет делать интегральное тестирование за свой счет.

[macklakov]

Цитата:

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

их микрософтовский чудо-конфигуратор в LCS -то нужда в партнерах почти отпадет и Микрософт сможет срубить больше бабла на лицензиях.

Ага, как раз иду на проект, на котором MS обещался все забабахать с помощью LCS за 3 месяца. 6 месяцев назад, на собеседовании, я сказал что в сказки не верю, чем очень обидел тогдашнюю program manager. До запуска все те же 3 месяца...

[macklakov]

P.S. реально я знаю о ситуации на этом проекте лишь со слов PM. Возможно это были ее личные завышенные ожидания.

[Link]

Цитата:

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

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

Т.е. хотя Peter Villadsen не рекомендует использование pre- и post-event handlers, я считаю, что лучше использовать их где только можно, хотя бы на методах, параметры и назначение которых вряд ли изменится в будущем, типа системных xRecord.validateField.

Мой текущий клиент пользуется в разработке таким подходом. При любой возможности на стандартных и партнерских классах и таблицах для модификаций используют event handlers. Но имхо затраты на разработку выше затрат на апгрейд.
К тому же в 7ке для этого нужно использовать extension methods.

[gl00mie]

Дело не в том, что можно изменить стандартный код, если понадобится, а в том, что заметная часть изменений в языке X++, о которых пишет mfp, делается в угоду сблжения языка с C# без явной потребности в изменениях со стороны X++. А судя по обсуждениям 7-ки, новой мантрой в разработке как раз становится "не ходите, дети, в Аф.. не меняйте стандартный код на своем слое разработки - всё пишите сбоку, как если бы у вас не было исходников".
Может быть, приложение из монолитного пытаются сделать более модульным, может быть, в следующей версии появятся пространства имен или что-то в этом духе, или часть кода перестанут поставлять в исходниках, и ради этого сейчас готовят почву, вводя необходимые языковые возможности. Тогда логичнее было бы явно обозначить вектор развития, а потом уже рассказывать про частные изменения в языке. Но читая про все эти новшества, на сакраментальный вопрос "Что там есть для меня?" я не могу найти сколь-нибудь позитивного ответа. В общем, как по мне, все нынешние изменения Microsoft делает для себя, а не на пользу клиентам/партнерам/ISV, отсюда и некоторый мой скепсис. Вот в 2012-й введение моделей, а также возможности подписывать их и самостоятельно генерировать для них лицензионные коды очень помогло тем же ISV.

[belugin]

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

[mazzy]

Цитата:

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

отделить публичный API от особенностей реализации

Вообще говоря, для этих целей используют interface.
и в аксапте оно есть.

[belugin]

Цитата:

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

Вообще говоря, для этих целей используют interface.
и в аксапте оно есть.

1) Интерфейсы могут быть внутренними по отношению к модулю
2) Попробуй написать публичное API на одних интерфейсах (подсказка - как получить экземпляр )

[mazzy]

Цитата:

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

1) Интерфейсы могут быть внутренними по отношению к модулю

тогда их не надо оформлять как интерфейсы, а сразу класс )

интерфейсы - это и есть публичный контракт.
и никаких поробностей реализации.

[belugin]

Цитата:

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

тогда их не надо оформлять как интерфейсы, а сразу класс )

интерфейсы - это и есть публичный контракт.
и никаких поробностей реализации.

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

и 3) Как без internal предотвратить неумышленное использование особенностей реализации с учетом того, что (2) для того, чтобы создать экземпляр интерфейса все равно нужен класс.

[Raven Melancholic]

Раз пошла такая пьянка, то неплохо было бы ввести Partial, например, для форм. В AOT создаем форму, а весь код, кроме системного, выносится в отдельный класс.

[belugin]

Цитата:

Сообщение от Raven Melancholic

Раз пошла такая пьянка, то неплохо было бы ввести Partial, например, для форм. В AOT создаем форму, а весь код, кроме системного, выносится в отдельный класс.

Примерно так и есть только немного по другому - на диске у нас файл XML, а в VS - редактор для формы и текстовый редактор для кода. То есть код формы отделяется на уровне IDE от дизайнера.