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

[Андре]

(С маленькой надеждой в голосе) Может кто-нибудь знает красивый способ вернуть экземпляр класса (this) из метода этого же экземпляра класса?

То есть вместо такого:

var.parm1(...);
var.parm2(...);
var.parm3(...);
var.parm4(...);
var.doIt();

хочется писать так:

var.parm1(...).parm2(...).parm3(...).parm4(...).doIt();

[gl00mie]

Цитата:

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

(С маленькой надеждой в голосе) Может кто-нибудь знает красивый способ вернуть экземпляр класса (this) из метода этого же экземпляра класса? хочется писать так:

var.parm1(...).parm2(...).parm3(...).parm4(...).doIt();

А вот так не прокатывает?

class Smth
{
}
Smth parm(...)
{
    // ...
    return this;
}

[Андре]

Если бы все было так просто - не спрашивал.
Ругается на return this;
В декларации метода в качестве возвращаемого типа указан сам класс.

[Андре]

Аааа.....сорри, прошу прощения.
Это косяки местного приложения.

[leva]

Странно, у меня не ругается. Проверил - работает на AX3 SP1

[kashperuk]

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

[Андре]

Хм... а я сделал оболочку над Args().

[Андре]

То есть, вместо подобного:

    Args   args;
    ;
    args = new Args();
    args.name(formStr(reportURLedgerTurnoverSetup));
    args.parmEnumType(enumnum(reportUReportType));
    args.parmEnum(reportUserReport.ReportType);
    args.parm(reportUserReport.ReportName);
    formRun = classFactory.formRunClass(args);

Можно писать так:

formRun = new my_Args().name(formStr(reportURLedgerTurnoverSetup))
                           .parmEnumType(enumnum(reportUReportType))
                           .parmEnum(reportUserReport.ReportType)
                           .parm(reportUserReport.ReportName)
                           .formRun();

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

[miklenew]

Цитата:

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

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

За что любил, люблю и буду любить Axapt-у, за то что есть хоть какие-то правила групповой разработки. За то что прежде чем написать что-то программисты писавшие её думали, а какого этим будет пользоваться другим, как это код будет читаться. Вам то может превычней. Потому что натация короче. А какого просматривать код, тем кто после прийдёт?
Осуждать не люблю просто прошу задуматься хоть на секунду, стоит ли ломать такие привычные вещи, как ввод параметров в класс Args. Тем более опыта то у вас намного больше. Но честно лучше уж такие превычные вещи оставлять такими какие они есть.

[Silence]

Цитата:

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

За что любил, люблю и буду любить Axapt-у, за то что есть хоть какие-то правила групповой разработки. За то что прежде чем написать что-то программисты писавшие её думали, а какого этим будет пользоваться другим, как это код будет читаться. Вам то может превычней. Потому что натация короче. А какого просматривать код, тем кто после прийдёт?
Осуждать не люблю просто прошу задуматься хоть на секунду, стоит ли ломать такие привычные вещи, как ввод параметров в класс Args. Тем более опыта то у вас намного больше. Но честно лучше уж такие превычные вещи оставлять такими какие они есть.

Аха, изменим мир к лучшему!!! Только все как писали, так и будут писать. (Т.е. что бы самим было удобно)

[Андре]

Цитата:

За что любил, люблю и буду любить Axapt-у, за то что есть хоть какие-то правила групповой разработки.

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

Цитата:

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

Хм.... мой код читается проще, чем конструкция Args() придуманная разработчиками. Это просто мое утверждение, но если ты обоснуешь свою позицию, я попробую привести аргументы в защиту моей конструкции

Цитата:

Вам то может превычней. Потому что натация короче.

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

[belugin]

Цитата:

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

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

Ну есть Best Practice Check - правда тормозной....

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

Цитата:

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

Вам то может превычней. Потому что натация короче.

Цитата:

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

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

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

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

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

[macklakov]

Цитата:

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

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

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

[Андре]

Цитата:

Только все как писали, так и будут писать. (Т.е. что бы самим было удобно)

Нет, просто проектирование приложений и требования к оформлению исходного кода - есть разные вещи и смешивать их не стоит

[Андре]

Цитата:

Ну есть Best Practice Check - правда тормозной....

Он ловит не все. Самые плохие вещи (например, int i1, i2,i3....) он не ловит.
Кстати, а где можно посмотреть QueryBuilder?

[belugin]

что за QueryBuilder?

[Андре]

Цитата:

kashperuk: Белугин так реализовывал QueryBuilder - методы которые обычно находятся на QueryBuildDataSource возвращали его же, что позволяло вызывать несколько методов подряд на том же queryBuildDataSource.

[belugin]

SYS ExpressionQueryBuilder — Axaptapedia

[belugin]

Ктати Best Practice Check - расширяемая штука