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

[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. непонятно как возвращать параметры

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

Согласен.

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

[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]

Цитата:

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

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

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

     parm1, parm2, func1, func2?

Если бы не было return this, to все было то же самое. кроме повторения названия переменных.

func1, parm1, func2, parm2.

Цитата:

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

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

не.. тут зависимости видны явно.

Разве есть разница между

query.proc1(func1(x));
query.proc2(func2(x));

и

query.proc1(func1(x))
        .proc2(func2(x));

Цитата:

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

Тоже исключение.

Цитата:

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

Именно! Этою билдер - оно и в названии отражено.

[mazzy]

Цитата:

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

     parm1, parm2, func1, func2?

Если бы не было return this, to все было то же самое. кроме повторения названия переменных.

func1, parm1, func2, parm2.

Не факт
порядок скорее зависит от конкретной реализации интерпретатора/компилятора. Это значит, что для 2.5, 3.0, 4.0, 5.0, а может быть и для каждого сервис-пака, надо проверять отдельно

[belugin]

Цитата:

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

Не факт
порядок скорее зависит от конкретной реализации интерпретатора/компилятора. Это значит, что для 2.5, 3.0, 4.0, 5.0, а может быть и для каждого сервис-пака, надо проверять отдельно

Если внимательно посмотреть на код то вфзов parm1 требует вызова func1 => func1 вызовется раньше parm1. вызов parm2 требует вызова parm1, func2.

=> порядок вызова такой func1 (parm1 | func2) parm2

то есть единственная неопределенность - что раньше вызовется parm1 или func2.

Если func2 не будет иметь побочных эффектов то смысл кода не изменится.