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]

Quote:

Originally Posted by gl00mie

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

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

[gl00mie]

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

[belugin]

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

[mazzy]

Quote:

Originally Posted by belugin

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

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

[belugin]

Quote:

Originally Posted by mazzy

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

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

[mazzy]

Quote:

Originally Posted by belugin

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

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

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

[belugin]

Quote:

Originally Posted by mazzy

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

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

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

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

[mazzy]

Quote:

Originally Posted by belugin

...но являются контрактами каких-то внутренних классов (чисто для внутренней реализации неймспейса)....

макс, да понимаю я что ты сказать хочешь.

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

internal - не нужен, дядя Вова.
http://coub.com/view/138x2

но если так хочется, и если уж пошли по пути public-полей. то и фиг с ними.

[belugin]

Quote:

Originally Posted by mazzy

макс, да понимаю я что ты сказать хочешь.

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

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

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

[mazzy]

Quote:

Originally Posted by belugin

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

))))

интерфейсы - это публичный контракт.
что не является публичным контрактом - не обязательно выражать через интерфейсы.

https://ru.wikipedia.org/wiki/%D0%98...BD%D0%B8%D0%B5)
http://habrahabr.ru/post/30444/
и так далее...


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

[belugin]

Quote:

Originally Posted by mazzy

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

Я не говорю, что это не так.

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

Например USB является публичным интерфейсом компьютера, а AGP является интерфейсом для его внутренней реализации, но публичным для видеокарты и материнской платы.

Quote:

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

Давай-ка напиши неймспейс на C# не выставляющий наружу ни одного класса с примером использования (еще раз - как ты получишь экземпляр чего-то полезного?)

[Stitch_MS]

Quote:

Originally Posted by gl00mie

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

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

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

[mazzy]

Quote:

Originally Posted by belugin

Давай-ка напиши неймспейс на C# не выставляющий наружу ни одного класса

макс, ты просишь меня доказать теорему несуществования?
бгггг.

если реально интересно поищи/почитай по ключевым словам "наследование нарушает инкапсуляцию"

а если просто похоливарить - то таки да, ты победил, конечно.
плюс можно почитать по ключевым словам "Инверсия презумпции"
например, http://los123.livejournal.com/210100.html

[belugin]

Quote:

Originally Posted by mazzy

макс, ты просишь меня доказать теорему несуществования?
бгггг.

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

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

Quote:

если реально интересно поищи/почитай по ключевым словам "наследование нарушает инкапсуляцию"

Тебе надо как-то связать этот тезис со всем остальным

[fed]

Quote:

Originally Posted by Stitch_MS

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

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

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

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

[George Nordic]

Quote:

Originally Posted by fed

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

Или рынок

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

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

[gl00mie]

Quote:

Originally Posted by fed

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

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

Quote:

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.

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

Quote:

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]

Quote:

Originally Posted by gl00mie

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

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

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

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