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

[oip]

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

[Андре]

Цитата:

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

Вы исходите из того, что синаксис и идеология статичны, а это далеко не так. Мне тяжело привести примеры из мира Аксапта, так как средства разработки в нем представляют собой достаточно статичную картину, но если взглянуть на тот же .Net, с которым (согласно "теории о волнах") Аксапта когда то дожна интегрироваться, - то там чуть другая картина. Тот же MS за последний год реализовал, либо оказал поддержку ряду проектов, про которые, когда то Гейтс и прочие говорили, что это туфта и этому не место в промышленной разработке: LINQ, F#, Nemerle и прочие.

Цитата:

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

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

Что же касается моего примера, то честно говоря, вооюще не понимаю, в чем проблема . C каких это пор наследование не вписывается к концепцию Аксапты?

[Андре]

oip

А этот код ты считаешь тоже нечитабельным http://www.axaptapedia.com/SYS_ExpressionQueryBuilder ?

[oip]

Цитата:

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

oip

А этот код ты считаешь тоже нечитабельным http://www.axaptapedia.com/SYS_ExpressionQueryBuilder ?

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

[Андре]

Цитата:

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

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

[oip]

Цитата:

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

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

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

Цитата:

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

И еще - попробуй поставить себя на место человека, не видевшего Аксапту - какой код ему будет понятнее?

Какая-то подмена понятий идет. Теплое меняем на мягкое.

[Андре]

Цитата:

не обернется потерями материальными из-за дополнительной сложности в поддержке такого кода

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

[belugin]

1. С прикладным кодом разбираться труднее и больше
2. Маленькая понятная системная штучка может уменьшить объем прикладного кода и с ним станет проще разбираться

[oip]

Цитата:

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

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

Не любое.

Когда видишь слова типа "все", "любое" и.т.п. жди логической ошибки. (c) Маззи

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

Цитата:

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

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

Вопрос только в целесообразности этого развития.

Цитата:

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

2. Маленькая понятная системная штучка может уменьшить объем прикладного кода и с ним станет проще разбираться

По твоему мнению проще.

Сделайте этот класс стандартом через майкрософт. Если М$ его официально включит в систему, если его все на всех проектах будут использовать - я что, против? А вот если каждый у себя на проекте будет использовать какую-то местную удобную по вашему мнению (а мнение других спросили, тех кто после вас поддерживать, дорабатывать, апгрейдить систему будет? Почему вы считаете, что если что-то удобно вам, то оно будет удобно всем остальным?) приблуду такого рода, то будет хаос. Появляется какое-то программирование ради программирования.

[belugin]

Можно спросить у Andre наколько быстро он разобрался с билдером...

[oip]

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

Цитата:

The code is very fat and contains lots of duplications

Это что, проблема? Это что, проблема для бизнеса? Нет вроде. Тогда что?

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

[Андре]

Цитата:

Можно спросить у Andre наколько быстро он разобрался с билдером...

3-4 минуты - ровно столько, сколько мне понадобилось прочитать wiki - страничку. Это очень важно, поэтому я повторюсь - для того, чтобы разобраться как работает эта конструкция мне не надо смотреть ее реализацию. Мне она интуитивно понятна.

Цитата:

Пусть это и ускорит чуть-чуть кодирование.

Она ускорит чтение исходников. Ты меня почти убедил, что это относится не ко всем, но для меня это так.

В общем-то belugin здесь очень правильно написал:

Цитата:

1. С прикладным кодом разбираться труднее и больше
2. Маленькая понятная системная штучка может уменьшить объем прикладного кода и с ним станет проще разбираться

Время потраченное на понимание QueryBulder ничтожно по сравнению со временем, которое требуется на то, чтобы понять некоторые сложные алгоритмы, заложенные в системы (то же закрытие склада, книжки покупок/продаж, сопоставление платежей с оплатами). Оно настролько ничтожно (для меня), что про него не стоит даже говорить - я себе чай долбше завариваю.
С другой стороны, у меня есть уверенность, что если бы разработчики Аксапты стремились бы к подобным конструкциям (лаконичным и выразительным), то вышеназванные алгоритмы были бы понятнее и доступнее.

Почему никто не возмущается, что во всех сложных алгоритмах используются map и container, посмотреть содержимое которых под отладчиком не реально? Зато всех возмущает самодельные обертки над ними, которые позволят избавиться от подобных проблем.

Цитата:

Это что, проблема? Это что, проблема для бизнеса?

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

[belugin]

[QUOTE=oip;155392]Я вот бОльшую времени трачу не на удар молотом, а на поиск того места, куда надо ударить.
[QUOTE]

Мне кажется, если код меньше, то его читать проще. например, код на встроенном SQL читается лучше по сравнению с QBDS за счет того, что там меньше дублирования впрочем, как и другой текст

Цитата:

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

Какие?

Цитата:

Это что, проблема? Это что, проблема для бизнеса? Нет вроде. Тогда что?

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

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

Цитата:

Я о самом подходе таком. Я не спорю, что какие-то улучшения делать можно. Но надо уметь вовремя остановиться.

Именно. Вопрос, где именно это "вовремя"

Цитата:

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

[belugin]

Цитата:

Почему никто не возмущается, что во всех сложных алгоритмах используются map и container, посмотреть содержимое которых под отладчиком не реально?

Реально!

[Андре]

Как?

[miklenew]

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

[Андре]

Цитата:

Может создать опрос нужны ли такого рода изменения программеру?

Зачем? На планы разработки MBS это никак не повлияет и поделка, так и останется поделкой.

[sukhanchik]

Выступлю на строне Андре, хотя его конструкция с Args режет мне глаза.
К сожалению нет четких критериев и границ - где нужно останавливаться, а где нет.
Но посмотреть содержимое мапов и контейнеров (а также объектов Set и List) - можно только в простом случае (в стандарте). А если там торчит курсор/класс/контейнер - то можно вешаться.
Есть MapViewer - который позволяет посмотреть объект Map. Это тоже наработка, но для ЧТЕНИЯ кода.
Есть (например) возможность "бить молотом" через шаблоны.

Я считаю, что все разработческие утилиты - можно разделить на утилиты для ЧТЕНИЯ кода и для ПИСАНИЯ кода.
Вот утилиты для ПИСАНИЯ кода - в общем-то (на мой взгляд) - не нужны и может даже вредны - с т.з. привыкания к Аксапте (а также лишнего кода)

А вот утилиты для ЧТЕНИЯ кода - думаю - что будут полезны. Да, это лишний код. Но это окупается (если ими пользуются несколько человек) - при чтении кода (меньше времени тратится на чтение - соотв меньше акционер экономит на оплате).

Но, к сожалению, все эти критерии - чисто субъективные - человека - который принимает решение.

[Russland]

Проблема в том, что в данном случае "инициатива" исходит снизу. Если бы штучки SYS_ExpressionQueryBuilder и им подобные инициировал бы сам Майкрософт все бы говорили: "Wow! Какой прогресс! Все на овладение новым инструментом!". А так, к сожалению, у сообщества остаётся ощущение

Цитата:

придумования велосипеда с уже имеющегося велосипеда.

А жаль.

[belugin]

Цитата:

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

Как?

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