Автобоксинг в Джава вчера и сегодня (только для джавистов).

Сергей-4030>> Те места, где ее можно применять "правильно" - раз-два и обчелся. Не стоит городить огород.
Murkt> Только используются эти места очень часто. Хотя бы те же "нестандартные" Numeric-типы (или они называются Number? не помню точно), типа BigInteger. Или StringBuffer/StringBuilder. В том же Питоне, в котором использование всех доступных возможностей "сделать красиво" (syntax hacking) считается тру и pythonic, перегрузка операторов используется только там, где она действительно имеет смысл. В стандартной библиотеке, в сторонних, вообще в любом коде, который я встречал - не видел ни разу чтоб перегрузка операторов использовалась в местах, в которых она выглядит неуместно.

А какие вы считаете уместными, кроме "стандартных" над всякими обертками "первичных" типов?

Сергей-4030>>> Те места, где ее можно применять "правильно" - раз-два и обчелся. Не стоит городить огород.
Murkt>> Только используются эти места очень часто. Хотя бы те же "нестандартные" Numeric-типы (или они называются Number? не помню точно), типа BigInteger. Или StringBuffer/StringBuilder. В том же Питоне, в котором использование всех доступных возможностей "сделать красиво" (syntax hacking) считается тру и pythonic, перегрузка операторов используется только там, где она действительно имеет смысл. В стандартной библиотеке, в сторонних, вообще в любом коде, который я встречал - не видел ни разу чтоб перегрузка операторов использовалась в местах, в которых она выглядит неуместно.
Сергей-4030> А какие вы считаете уместными, кроме "стандартных" над всякими обертками "первичных" типов?
Не надо бить мне морду!

Ну вот я указал некоторые. BigInteger - это ведь не обёртка над стандартным типом. Decimal - то же самое (не уверен, как он в джаве называется). Могу вот ещё нелогичность указать - "первичного" типа string нет, но конкатенация String'а в Джаве работает, а конкатенация чего угодно другого не работает. А ведь было бы удобно использовать + для создания StringBuffer/StringBuilder. Списки те же - тоже конкатенция. А плюс не работает. Матрицы складывать, вычитать, умножать (я имею в виду математические матрицы, то есть специально созданные для этого классы). В тех же множествах - and, or, xor. В питоне есть ещё хороший оператор in.

1. >>> a = set([1, 2, 3])
2. >>> b = set([2, 3, 4])
3. >>> a | b
4. set([1, 2, 3, 4])
5. >>> a ^ b
6. set([1, 4])
7. >>> a & b
8. set([2, 3])
9. >>> 1 in a & b
10. False
11. >>> 1 in a | b
12. True

Murkt> Ну вот я указал некоторые. BigInteger - это ведь не обёртка над стандартным типом. Decimal - то же самое (не уверен, как он в джаве называется). Могу вот ещё нелогичность указать - "первичного" типа string нет, но конкатенация String'а в Джаве работает, а конкатенация чего угодно другого не работает. А ведь было бы удобно использовать + для создания StringBuffer/StringBuilder. Списки те же - тоже конкатенция. А плюс не работает. Матрицы складывать, вычитать, умножать (я имею в виду математические матрицы, то есть специально созданные для этого классы). В тех же множествах - and, or, xor. В питоне есть ещё хороший оператор in.

Я не настаиваю на абсолютной истине моего восприятия, но по-моему, почти все ваши примеры ложатся на "оберточный" образец. Кроме матриц. Но! Матрицы - довольно особый случай. Они не характерны для большинства приложений. И "стандартные" операции так-таки не очень хорошо ложатся для матриц. Если a и b - матрицы, то что такое a+b, a*b? Это зависит от реализации. Выгода здесь будет только если разработчик цельный день этими матрицами занимается и у него уже в памяти выжжены каленым железом "правильные" смыслы для этих операций. А если кто-то другой придет со стороны, или просто из другой части проекта, или сам человек написал два года назад и забыл? Вот так и рождаются кошмары. И это еще при более-менее разумном применении переопределения операторов. А уж когда начинаются всякие кошмары типа

Person p; Account accs[];

accs

+=time("Feb/1/00")-time("Jan/1/00");

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

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

Murkt>> Ну вот я указал некоторые. BigInteger - это ведь не обёртка над стандартным типом. Decimal - то же самое (не уверен, как он в джаве называется). Могу вот ещё нелогичность указать - "первичного" типа string нет, но конкатенация String'а в Джаве работает, а конкатенация чего угодно другого не работает. А ведь было бы удобно использовать + для создания StringBuffer/StringBuilder. Списки те же - тоже конкатенция. А плюс не работает. Матрицы складывать, вычитать, умножать (я имею в виду математические матрицы, то есть специально созданные для этого классы). В тех же множествах - and, or, xor. В питоне есть ещё хороший оператор in.
Сергей-4030> Я не настаиваю на абсолютной истине моего восприятия, но по-моему, почти все ваши примеры ложатся на "оберточный" образец.
Вот только в Джаве даже они не работают.

Сергей-4030> Кроме матриц. Но! Матрицы - довольно особый случай. Они не характерны для большинства приложений. И "стандартные" операции так-таки не очень хорошо ложатся для матриц. Если a и b - матрицы, то что такое a+b, a*b? Это зависит от реализации.
От какой такой реализации? Это математика. Сложение и умножение матриц - это чётко определённые операции, которые ни от чего не зависят, и не должны. Сложение, отнимание, умножение векторов сюда же.

Сергей-4030> А уж когда начинаются всякие кошмары типа
Сергей-4030> Person p; Account accs[];
Сергей-4030> accs

+=time("Feb/1/00")-time("Jan/1/00");
Сергей-4030> имея в виду - записать человеку рабочее время за месяц - вот тут туши свет. А бывает и хуже.
Сергей-4030> Конечно, можно возразить, что надо просто правильное администрирование, правильное разделение полномочий, хороший дизайн и проч - да, в принципе, ценой увеличения затрат на дизайн и администрирование, наверное, можно получить какие-то плюсы. Но вот перевесит ли выгода от этих плюсов те самые затраты на дизайн/админинстрирование - совершенно, совершенно неизвестно.
Нет, я не буду говорить что нужно правильное администрирование. Просто без переопределения операторов код получается не лучше, не понятнее, только более громоздкий (а значит, и более сложный для понимания при прочих равных):
accs[p].add(time("Feb/1/00").subtract(time("Jan/1/00")));

Кстати, насчёт дат. Если в Питоне отнять дату от даты - получится "временная разница" (timedelta). Складывать даты нельзя. Но таймдельты можно и складывать, и отнимать (и умножать/делить на число). От даты тоже таймдельту можно отнимать, и можно прибавлять. Разумный дизайн? Безусловно. Отличался бы он чем-то от "безоператорного" варианта? Отнюдь, в безоператорном варианте было бы точно то же самое. Только писать нужно было бы больше.

Murkt> В одном языке он или то, или другое.

Пока нет смены приоритетов - по-другому и никак

Murkt> Если он в одном месте XOR, а в другом - возведение в степень, то это личная мозговая травма писателя

Как на счёт плюса, который в одном случае сложение, в другом - контактенация в той же Java? Или "%", который в Питоне для строк указывает не на остаток от деления, а на наполнение по шаблону?

Murkt> Отличался бы он чем-то от "безоператорного" варианта? Отнюдь, в безоператорном варианте было бы точно то же самое. Только писать нужно было бы больше.

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

Person person;
Account acc = Accounts.locate(person);
TimeCards tc = calculateWorkTime(new date("01/01/00"),new date("02/01/00"));
acc.credit(calculatePay(tc));

отличается НЕ только тем, что "писать нужно больше". Вернее, формально - да, только этим. А вот практически - этот код понятен любому разработчику, даже если он не знает ничего про то, как считаются рабочие дни, как производится оплата и т.п. Он более-менее самодокументирован. А вот пример с "операторным подходом" этого преимущества совершенно лишен. Что на практике приведет элементарно к большему количеству ошибок и НАМНОГО более затратной поддержке такого кода.

Murkt> Это доведение до абсурда - во-первых, строки друг на друга не умножаются; а во-вторых умножение всегда должно быть выше приоритетом, чем сложение

Умножение и сложение - это простой случай. Скажем, определяешь "~" для нечёткого сравнения строк с возвращение fuzzy результата. Приоритет надо задать? Надо, потому что "по умолчанию" бинарного "~" в большинстве языков нет, а там, где есть - обычно он высокоприоритетный, а нам приоритет низкий нужен

Murkt>> В одном языке он или то, или другое.
Balancer> Пока нет смены приоритетов - по-другому и никак
Число подвергается и XOR'у, и возведению в степень. Даже со сменой приоритетов ты не можешь заставить делать 2 ^ 5 то XOR, то возведение в степень.

Murkt>> Если он в одном месте XOR, а в другом - возведение в степень, то это личная мозговая травма писателя
Balancer> Как на счёт плюса, который в одном случае сложение, в другом - контактенация в той же Java?
Строки нельзя складывать "поэлементно".

Balancer> Или "%", который в Питоне для строк указывает не на остаток от деления, а на наполнение по шаблону?
Строки нельзя делить, хоть с остатком, хоть без. Поэтому спутать подстановку и деление невозможно. А число подвергается и XOR'у, и возведению в степень, и их спутать очень легко, если в одном месте оно одно, а в другом - другое.

Murkt> Число подвергается и XOR'у, и возведению в степень. Даже со сменой приоритетов ты не можешь заставить делать 2 ^ 5 то XOR, то возведение в степень.

Ладно, это пример не самый удачный. Просто при вводе своих операторов, хочешь не хочешь - приоритет задавать надо. Пусть возведение в степень будет фортрановское, "**", от необходимости задать приоритет никуда не деться.

Murkt> Строки нельзя делить, хоть с остатком, хоть без. Поэтому спутать подстановку и деление невозможно.

Ну да. "a = x % t" - это остаток от деления или подстановка? Или опять возвращаемся к венгерской нотации?

Murkt>> Отличался бы он чем-то от "безоператорного" варианта? Отнюдь, в безоператорном варианте было бы точно то же самое. Только писать нужно было бы больше.
Сергей-4030> Отличается безусловно. Тем, что определения операторов однозначны. Такой вариант:
Сергей-4030> Person person;
Сергей-4030> Account acc = Accounts.locate(person);
Сергей-4030> TimeCards tc = calculateWorkTime(new date("01/01/00"),new date("02/01/00"));
Сергей-4030> acc.credit(calculatePay(tc));
Сергей-4030> отличается НЕ только тем, что "писать нужно больше". Вернее, формально - да, только этим. А вот практически - этот код понятен любому разработчику, даже если он не знает ничего про то, как считаются рабочие дни, как производится оплата и т.п. Он более-менее самодокументирован. А вот пример с "операторным подходом" этого преимущества совершенно лишен. Что на практике приведет элементарно к большему количеству ошибок и НАМНОГО более затратной поддержке такого кода.

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

Murkt> А вот такой вариант - да, отличается не только тем что нужно писать больше.

Так это типично. То есть, в конечном итоге, да, есть определенное количество классов, для которых удобно сделать перезагрузку операторов. И объектов этих классов (BigInteger и т.п) в программе может быть много. Но тем не менее вводить только для этих случаев механизм, который потенциально опасен во всех других случаях - не выглядит на 100% здравой идеей. Никто, разумеется, не сможет строго доказать, что так лучше. Как и, скажем, goto. Но согласитесь, что на ваши доводы "за" так-таки существуют вполне весомые доводы "против". Истина в данном случае исключительно в практике.

Murkt>> Это доведение до абсурда - во-первых, строки друг на друга не умножаются; а во-вторых умножение всегда должно быть выше приоритетом, чем сложение
Balancer> Умножение и сложение - это простой случай. Скажем, определяешь "~" для нечёткого сравнения строк с возвращение fuzzy результата. Приоритет надо задать? Надо, потому что "по умолчанию" бинарного "~" в большинстве языков нет

Murkt>> Число подвергается и XOR'у, и возведению в степень. Даже со сменой приоритетов ты не можешь заставить делать 2 ^ 5 то XOR, то возведение в степень.
Balancer> Ладно, это пример не самый удачный. Просто при вводе своих операторов, хочешь не хочешь - приоритет задавать надо. Пусть возведение в степень будет фортрановское, "**", от необходимости задать приоритет никуда не деться.

Это всё введение новых операторов, я уже говорил что это не в ту степь. Безусловно, что при введении новых операторов нужно им уметь задавать приоритет, железный ящик телепатией пока не владеет.

Balancer> а там, где есть - обычно он высокоприоритетный, а нам приоритет низкий нужен
'beg' or 8 ~ 7 or 'bag' ~ 'bug'. or - среднеприоритетный, числовой ~ - высокоприоритетный, строковый ~ - низкоприоритетный. Компилятор схавает. Что будет думать человек?

Murkt> 'beg' or 8 ~ 7 or 'bag' ~ 'bug'. or - среднеприоритетный, числовой ~ - высокоприоритетный, строковый ~ - низкоприоритетный. Компилятор схавает. Что будет думать человек?

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

Murkt>> А вот такой вариант - да, отличается не только тем что нужно писать больше.
Сергей-4030> Так это типично. То есть, в конечном итоге, да, есть определенное количество классов, для которых удобно сделать перезагрузку операторов. И объектов этих классов (BigInteger и т.п) в программе может быть много. Но тем не менее вводить только для этих случаев механизм, который потенциально опасен во всех других случаях - не выглядит на 100% здравой идеей. Никто, разумеется, не сможет строго доказать, что так лучше. Как и, скажем, goto. Но согласитесь, что на ваши доводы "за" так-таки существуют вполне весомые доводы "против".
В Питоне очень много механизмов, которые потенциально опасны в кривых руках, однако ж всё хорошо Для множества фич языков программирования есть как доводы "за", так и "против". И те, и те - весомые.

Сергей-4030> Истина в данном случае исключительно в практике.
Отнюдь. Истина для каждого своя

Murkt>> 'beg' or 8 ~ 7 or 'bag' ~ 'bug'. or - среднеприоритетный, числовой ~ - высокоприоритетный, строковый ~ - низкоприоритетный. Компилятор схавает. Что будет думать человек?
Сергей-4030> Во-во. Например, новый программист, только пришедший. Пусть даже самой что ни есть высокой квалификации. Будет в доки лезть по такой мелочи. А если совсем неопытный - то и вовсе заколебется разбираться.
Угум. Я вот по-быстренькому написал иллюстрацию. Только в Питоне ~ - унарный, я воспользовался //. Написал чуток комментариев для тех, кто Питона не знает, чтоб понятнее было.

1. >>> class mystr(str):
2. ...     def __floordiv__(a, b): # в Питоне // маппится на __floordiv__
3. ...         total = 0
4. ...         for c1, c2 in zip(a, b): # zip('bag', 'bug') == [('b', 'b'), ('a', 'u'), ('g', 'g')]
5. ...             if c1 == c2:
6. ...                 total += 1
7. ...         return total * 3 >= len(a) * 2
8. ...
9. >>> beg = mystr('beg')
10. >>> bag = mystr('bag')
11. >>> bug = mystr('bug')
12. >>> beg // bug
13. True
14. >>> beg // mystr('zzz')
15. False
16. >>> beg or 8 // 7 or bag // bug # это то, чего ожидает юзер - два высокоприоритетных оператора, два низкоприоритетных, дальше первого элемента не уйдёт
17. 'beg'
18. >>> (beg or 8 // 7 or bag) // bug # а это то, что он получит с переопределением порядка, только тут скобки явно указывают, а там скобок не будет.
19. True

Balancer>>> Там всё логичнее было (p == q) и (*p == *q) имели вполне очевидное различие.
Mishka>> Ну, так та самая * и есть isequal.
Balancer> Однако (*p == *q) намного нагляднее, чем p.equals(q) Вот незамутнённый разум подумает, что как раз p.equals(q) - это стравнение эквивалетности указателей, а не значений
Э, Ром, ты о форме, а не о сути.

Murkt> В одном языке он или то, или другое. Если он в одном месте XOR, а в другом - возведение в степень, то это личная мозговая травма писателя, вводить ради этой травмы другую я смысла не вижу.

Почему? Всегда и везде стандартные операции зависят от типа данных. Возьми конкатенацию и/или + с | — они обозначают разное для разных типов данных. Более того, семантика операторов ввода-вывода зависят от типа данных.

Murkt> Введение новых операций в язык - это изменение синтаксиса. Если мы изменяем синтаксис, то нам, понятное дело, нужно как-то определить порядок. Но это уже в другую степь.

А ты посмотри всё-таки Алгол 68. Там это делается всё средствами языка. Для описания языка, правда, применяются мета-грамматики, которые генерят грамматики, которые описывают язык.

Murkt> Это доведение до абсурда - во-первых, строки друг на друга не умножаются;

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

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

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

Murkt> Я ведь говорю именно о возможностях для улучшения читаемости кода, а такие финты (умножение строк, например) эту самую читаемость улучшить не могут.

А почему ты отвергаешь создание людьми своего прикладного языка — с теми правилами, которые более привычны для них. В Ленинграде у Терехова, к примеру, создали язычок на Алголе 68 для микропрограммирования. В результате система команд процессора переписывалась на раз даже студентом, который был "в деле" за пару недель. Минчане (те, которые пытались делать это для ЕС ЭВМ) не верили, пока не поспорили с Тереховым на коньяк и студент Игорь (сейчас в Райли, Северная Королина) сделал по их заказу новую систему и показал на железе. Было очень удобно.

Murkt>> В одном языке он или то, или другое. Если он в одном месте XOR, а в другом - возведение в степень, то это личная мозговая травма писателя, вводить ради этой травмы другую я смысла не вижу.
Mishka> Почему? Всегда и везде стандартные операции зависят от типа данных. Возьми конкатенацию и/или + с | — они обозначают разное для разных типов данных. Более того, семантика операторов ввода-вывода зависят от типа данных.
Ещё раз объясняю. Числа можно и заXORить, и возвести в степень. Если в одном месте знак ^ обозначает XOR, а в другом - возведение в степень (в зависимости от флагов в начале файла, например), то ни к чему хорошему это не приведёт.

Murkt>> Это доведение до абсурда - во-первых, строки друг на друга не умножаются;
Mishka> С чего ты взял? Кто мешает тракторвать строки как множества и определить умножение как пересечение? Возьми битовое И и получишь именно это.
Отлично, воспользуемся битовым И, у него порядок вычисления меньше чем у конкатенации, что и требовалось тобой изначально.

Murkt>> а во-вторых умножение всегда должно быть выше приоритетом, чем сложение, чтобы не сбивать именно человека с толку.
Mishka> Ты мыслишь в пределах арифметики.
Нет. Если операция будет менять приоритет в зависимости от аргументов, то это будет сбивать человека с толку. Посмотри в этой теме пост #41, могу переписать пример на умножение - более понятной конечная запись не станет.

Mishka> Однако посмотри шире и для определения всяких групп, колец, полей вводятся свои пару операций, на которые накладываются условия, а потом и приоритеты (часто не явно). Возьми Булеву Алгебру — там умножение и сложение тоже с приоритетами, но правила совсем другие, чем в арифметике.
Да, и именно из-за того что приоритеты другие, в подавляющем большинстве языков для булевой алгебры введены другие операторы (я не могу назвать язык, в котором не так).

Mishka> Можно называть это умножением и сложением и оставить приоритеты, но прямой аналогии нет. Приоритеты ввели для того, чтобы был однозначный результат. Польская запись его тоже обеспечивает. При разложении в машинные коды приоритет определяется потоком команд.
К чему это?

Murkt>> Я ведь говорю именно о возможностях для улучшения читаемости кода, а такие финты (умножение строк, например) эту самую читаемость улучшить не могут.
Mishka> А почему ты отвергаешь создание людьми своего прикладного языка — с теми правилами, которые более привычны для них.
Где это я отвергаю создание своего прикладного языка? Создавайте себе на здоровье. Только это будет другой язык, а не изменение правил данного языка.

Murkt> Ещё раз объясняю. Числа можно и заXORить, и возвести в степень. Если в одном месте знак ^ обозначает XOR, а в другом - возведение в степень (в зависимости от флагов в начале файла, например), то ни к чему хорошему это не приведёт.

Как показывает опыт — приводит к очень положительным результатам. Более того, названия методов-процедур у людей часто совпадают, а делают они разное. Операции ни чем не хуже.

Mishka> Более того, названия методов-процедур у людей часто совпадают, а делают они разное. Операции ни чем не хуже.

У меня сегодня обратная проблема была. Я для одного метода всё в разных местах разные названия писал. То "called_url()", то "calling_url()" Так сейчас даже и не запомнил, к какому привёл в итоге...

Murkt> Отлично, воспользуемся битовым И, у него порядок вычисления меньше чем у конкатенации, что и требовалось тобой изначально.

Порядок вычисления — в смысле приоритет? А почему? пересечение множеств обычно имеет более высокий приоритет, т.к. аналог && в булевой алгебре. Т.е. получилось противоположно тому, что ты говоришь.

Murkt> Нет. Если операция будет менять приоритет в зависимости от аргументов, то это будет сбивать человека с толку. Посмотри в этой теме

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

Murkt> пост #41, могу переписать пример на умножение - более понятной конечная запись не станет.

Да, конечно же, станет. Она станет понятней тому, кто работает в этой области.

Murkt> Да, и именно из-за того что приоритеты другие, в подавляющем большинстве языков для булевой алгебры введены другие операторы (я не могу назвать язык, в котором не так).

В математике используются кучи символов. Она понятней не становится. А так — посмотри такой язычок — APL.

Murkt> К чему это?

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

Murkt> Где это я отвергаю создание своего прикладного языка? Создавайте себе на здоровье. Только это будет другой язык, а не изменение правил данного языка.

В том, что приоритеты и смысл стандартных обозначений менять нельзя.

Murkt>> Отлично, воспользуемся битовым И, у него порядок вычисления меньше чем у конкатенации, что и требовалось тобой изначально.
Mishka> Порядок вычисления — в смысле приоритет? А почему? пересечение множеств обычно имеет более высокий приоритет, т.к. аналог && в булевой алгебре. Т.е. получилось противоположно тому, что ты говоришь.
Я вообще запутался, чего вы там хотите с приоритетами, оставим эту ветку обсуждения

Murkt>> Нет. Если операция будет менять приоритет в зависимости от аргументов, то это будет сбивать человека с толку. Посмотри в этой теме
Mishka> Они существенно разные. И приоритеты у них разные. Пользователь строит модель вычислений (в смысле вычисляемости алгоритма) как это принято в его предметной области. А она (предметная область) может очень сильно отличаться от математики.
Хорошо, просто приведи пример, в котором умножение типа А на тип А и умножение типа Б на тип Б выполняются с разными приоритетами. Я с таким не сталкивался, и не могу придумать, кому может понадобиться такая ересь

Murkt>> пост #41, могу переписать пример на умножение - более понятной конечная запись не станет.
Mishka> Да, конечно же, станет. Она станет понятней тому, кто работает в этой области.
Продолжим эту тему после того, как я увижу вышеупомянутый пример. Если такой существует, и такая конструкция действительно кому-то нужна...

Murkt>> К чему это?
Mishka> К тому, что пользователь мыслит в своей предметной области. И очень не доволен навязыванием языка вещей, которые он привык использовать по другому.
Таки хочу пример.

Murkt>> Где это я отвергаю создание своего прикладного языка? Создавайте себе на здоровье. Только это будет другой язык, а не изменение правил данного языка.
Mishka> В том, что приоритеты и смысл стандартных обозначений менять нельзя.
В своём новом языке - меняйте на здоровье Они там тоже будут стандартные, но такие как вам будет удобно.