Вернуть this из класса

[_scorp_]

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

[Lucky13]

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

[Андре]

Цитата:

Это наверное так же как использование шаблонов в проектах на C++ - язык повзоляет, но использовать не рекомендуется

Кем не рекомендуется ?

[Lucky13]

Руководителями проектов. Я имею в виду не запрещение использования шаблонов вообще, а использование сложных конструкций с использованием шаблонов. Мне приходилось с таким сталкиваться.

[belugin]

Цитата:

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

Надо просто знать меру.. ... остановиться. По моему мнению, КвериБилдер эту грань уже пересек.

А в чем эта мера? Это мера чего? И почему он ее пересек? По какому параметру он "слишком"?

[oip]

Ну я же сказал, что я не знаю, в чем эта мера конкретно состоит. Я пока не могу сформулировать даже сколько-нибудь четкие критерии. И параметра по которому "слишком" - не знаю. А пересек он просто по моему мнению. Поэтому я по возможности не буду его использовать.

[belugin]

ok. Сущсвуют ли по твоему мнению такие условия, когда примемение EQB приемлемо?

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

EQB прост для изучения - это всего лишь результат применения паттерна ExpressionBuilder по отношению к аксаптовскому Query. Несколько минут, если уже знаешь то и другое, зато сэкономит время и объем внимаения, т.к. под ногами не будет болтатьсся всякие fetchMode(0) и прочие дубли

[mazzy]

Цитата:

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

EQB прост для изучения - это всего лишь результат применения паттерна

Могу ошибаться, но мне кажется, что:
1. при построении перекрестных ссылок у Аксапты может пехать крыша
2. query лучше строить не в коде, а в AOT, а в коде инстанцировать одной строкой query = new Query(querystr(mySuperQuery))

[oip]

Цитата:

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

ok. Сущсвуют ли по твоему мнению такие условия, когда примемение EQB приемлемо?

Не знаю. Пока я думаю, что разве что в учебных целях, но не на реальном проекте внедрения. Ну или в каких-то сторонних приблудах типа Табакса.

Цитата:

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

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

Вот пусть и изучает бизнес-сущности, а не способ кодирования. Не важно, изолирован модуль или нет. Абсолютно не важно.

Цитата:

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

т.к. под ногами не будет болтатьсся всякие fetchMode(0) и прочие дубли

Мне эти фетчмоды не мешают, я к ним уже привык.

[belugin]

Цитата:

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

Могу ошибаться, но мне кажется, что:
1. при построении перекрестных ссылок у Аксапты может пехать крыша
2. query лучше строить не в коде, а в AOT, а в коде инстанцировать одной строкой query = new Query(querystr(mySuperQuery))

1. Не поедет - это такой же код как и другой
2. Query плохо читаемо: для того, чтобы узнать, какие есть условия на поля надо активно возить мышкой и нажимать на плюсики. Даже для того, что убедится, что оно не отсортировано. Т.е. визуализация Query содержит много лишних деталей, но при жтом нужные детали запрятаны глубоко.

Сорри, при наведении на датасурс часть структуры показывается...

[mazzy]

Цитата:

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

1. Не поедет - это такой же код как и другой

Не совсем. Уровней вложености много.

Цитата:

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

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

В том то и дело.
В АОТ структура запроса отделена от кода. Следовательно:
1. заниматься оптимизацией и улучшизмами можно отдельно от кода (может отдельный человек)
2. апгрейд сильно упрощается, поскольку самым трудоемким является апгрейд кода. А количество кода при использовании Query из АОТ сильно уменьшается.

Но что-то я ушел от темы.

В общем, я согласен, что паттерн ExpressionBuilder позволяет сделать интересный код.
Но у него все ж таки есть недостатки, связанные с глубиной.
1. как я уже говорил могут поехать перекрестные ссылки
2. по-моему, нельзя будет поставить точку останова на конкретный метод (дебаггер остановится на первом вызове, а затем в дебаггере нужно будет заходить в каждый парм-метод)
3. возникают очень тонкие и неявные побочные явления, связанные с порядком вызова методов и их аргументов
4. не дай бог какому-нибудь из методов вернуть значение Null.
5. непонятно как возвращать параметры

В общем, все равно весь код в подобном стиле написать не получится.
Значит будет дикая смесь нотаций: традиционной и через-точку.

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

[Андре]

В общем то я понимаю, что эта ветка ничего не реит и каждый останется при своем мнении, но дабы не заканчивать на такой пессиместичной ноте:

Цитата:

1. как я уже говорил могут поехать перекрестные ссылки

Честно говоря пока не замечал, хотя часто пользуюсь.

Цитата:

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

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

Цитата:

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

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

Цитата:

4. не дай бог какому-нибудь из методов вернуть значение Null.

С чего это? Если ты вызвал метод, то экземпляр класса существует, а следовательно return this что-то вернет.

Цитата:

5. непонятно как возвращать параметры

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

Цитата:

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

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

[belugin]

Цитата:

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

Не совсем. Уровней вложености много.

Надо проверить....

Цитата:

1. заниматься оптимизацией и улучшизмами можно отдельно от кода (может отдельный человек)

В принципе, да, есть примеры в реальности? Как фиксируется интерфейс Query (то есть то, что нельзя менять при такой оптимизации - состав полей, порядок записей)

Цитата:

2. апгрейд сильно упрощается, поскольку самым трудоемким является апгрейд кода. А количество кода при использовании Query из АОТ сильно уменьшается.

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

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

Цитата:

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

Согласен.

Цитата:

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

Вот тут не очень понятно, можено пример? Вроде порядок вызова четко определен.

Цитата:

4. не дай бог какому-нибудь из методов вернуть значение Null.

Каким образом return this может превратиться в Null

Цитата:

5. непонятно как возвращать параметры

Так как builder нацелен на создание Query, у него все сделано для того, чтоб эта задача решалась максимально просто и лаконично. Возврат параметров просто будет методами с более длинными названиями. Либо через Query

Цитата:

В общем, все равно весь код в подобном стиле написать не получится.
Значит будет дикая смесь нотаций: традиционной и через-точку.

Ну не согласен что смесь - скорее кровавая Мери - водка отдельно, томатный сок отдельно.

[macklakov]

Цитата:

Сообщение от Андре

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

Согласен, что функциональное программирование увлекает красотой концепции. Это практически чистая математика, его хочется использовать. Но я считаю, что на данный момент не стоит привносить этот стиль в Axapta по следующим причинам:
1) Сами функциональщики признают, что их стиль написания часто делает программы нечитабельными.
К примеру, не сложно написать полноценный интерпретатор в одну строку. Прочитать сложнее.
2) Сама суть функционального стиля заключена в рекурсии. В Axapta есть технологическое ограничение на число вложенных вызовов, т.е. использование рекурсии невозможно
3) Основные причины возобновления интереса к функциональным языкам это:
- удобство работы с текстами
- практически идеальное распараллеливание вычислений
- дешевая оперативная память, позволяющая полностью "развернуть" граф и т.о. получить хорошую скорость работы
Для axapta ни один из этих критериев не применим
4) Очень тяжело дебажить такой код

[belugin]

Кстати, самый объектно-ориантированный язык smalltalk тоже прижерживается такой нотации - там метод возвращает this, если не сказано обратное

[EVGL]

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

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

Вообще, Microsoft не любит горизонтальных решений от партнеров. Я в нашей компании стараюсь держать неизбежный горизонтальный слой в разумных пределах и не раздуваю его сверх меры. А все эти приблуды - типичные горизонтальные решения, которые неизвестно кто поддерживает и неизвестно как долго собирается поддерживать.

Так что, мой совет: "Руки прочь!"

[belugin]

понятно . А что у вас в горизонтальном слое и как вы определяете, где мера?

[EVGL]

Функционал типа Workflow или интеграциии проектов с Microsoft Project. Буду рад выбросить его, как только появится что-то похожее в новой версии. А мера такая: если сходная фича запрашивается более чем 2-3 клиентами, имеет смысл встроить ее в BUS-слой. Еще пример: складской учет НЗП.

[mazzy]

Цитата:

Сообщение от Андре

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

А чем легче, чем при традиционном?

Цитата:

Сообщение от Андре

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

отвечю чуть ниже

Цитата:

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

Вот тут не очень понятно, можено пример? Вроде порядок вызова четко определен.

parm1(someComplexType _var)
{
    // модифицируется и проверяется _var
    return this;
}
parm2(someComplexType _var)
{
    // модифицируется и проверяется _var
    return this;
}

classvar.parm1(func1(var1)).parm2(func2(var1));

в каком порядке будут вызваны parm1, parm2, func1, func2?
Если вдобавок внутри происходит модификация переменных, то...

Не помню у кого, но видел в подписи выражение типа (i=1;i+=(i++)+(i++);cout<<i);
запись через точку порождает примерно такие же головоломки

Цитата:

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

Каким образом return this может превратиться в Null

Во всей Аксапте принято возвращать null или пустую запись, если что-то не получилось.

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

Цитата:

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

Так как builder нацелен на создание Query, у него все сделано для того, чтоб эта задача решалась максимально просто и лаконично.

А... дык, это только для создания query...

[Владимир Максимов]

Цитата:

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

>>>В худшем, Вы получите пародоксальное (не предсказуемое) поведение Axapta.

Каким образом?

Извиняюсь за задержку с ответом, но иногда и работать надо

В данном случае, я неудачно построил фразу.

Смысл в том, что с точки зрения Axata поведение будет логичным и предсказуемым, а вот с точки зрения человека, привыкшего к другой идеологии программирования - не ожидАемым. Он получит не то, что ожидал, исходя из своих предположений и опыта программирования в других средах.

Простой пример:

static void Test(Args _args)
{
    print true || true && false;
    print true || (true && false);
    pause;
}

Во многих средах программирования операция "И" имеет приоритет над операцией "ИЛИ". Поэтому, вполне естесственно желание сэкономить на скобках. Результат - неожиданный. А все потому, что у Axapta нет приоритета между "И" и "ИЛИ". Они равноправны.

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