Здравствуйте, _nn_, Вы писали:
__>Все дело в неявном создании кортежа.
Ага.
__>Посему и вопрос не стоит ли эту фичу убрать и явно указывать создание кортежа ?
Откровенно говоря эта хрень мня тоже достала, но:
1. Она весьма глубоко встроена в систему типов. Придется курочить все начиная с солвера.
2. Довольно много кода использует эту фичу. Боюсь, что даже в компиляторе его будет не мало.
Но действительно вреда от фичи куда больше чем достоинств.
Что касается явного указания, то надо предложить синтаксис.
Дело даже не в явном указании, а в том что немерл поддерживает неявное преобразование. Скажем если у нас есть функция с двумя параметрами, то в нее всегда можно передать кортеж. Если мы запрещаем неявное преобразование, то и эта фича отвалится. А будет ли это хорошо? Если нет, то нужен синтаксис позволяющий явно указать, что нам нужно передать элементы кортежа в качестве параметров методов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Но действительно вреда от фичи куда больше чем достоинств.
VD>Что касается явного указания, то надо предложить синтаксис. VD>Дело даже не в явном указании, а в том что немерл поддерживает неявное преобразование. Скажем если у нас есть функция с двумя параметрами, то в нее всегда можно передать кортеж. Если мы запрещаем неявное преобразование, то и эта фича отвалится. А будет ли это хорошо? Если нет, то нужен синтаксис позволяющий явно указать, что нам нужно передать элементы кортежа в качестве параметров методов.
Согласен, нужно это хорошо продумать.
Тут много вариантов как указать.
Скажем как-то так:
def a = (1,2);
def f(x,y) {}
f(a) // Error
f(*a) // OK
Здравствуйте, VladD2, Вы писали:
VD>Народ! Высказываетесь по этому поводу!
VD>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.
Лично мне она не мешает. Несколько раз использовал её, но если её не станет, то не расстроюсь.
Здравствуйте, VladD2, Вы писали:
VD>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.
плюс адын.
Но ломающие изменения предлагаю оставлять на 2.0
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Народ! Высказываетесь по этому поводу!
VD>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.
Мне нравится (кажется удобным), что можно написать [(1,2)].Map(fun(a,b){ ... }) не смотря на то, что Map имеет тип 'a->'b. Если фичу запретить, то придется писать [(1,2)].Map(fun(_){ | (a,b) => ... }), что менее элегантно. С другой стороны именно неявными преобразованиями меня пугает scala.
Здравствуйте, WolfHound, Вы писали:
VD>>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы. WH>плюс адын. WH>Но ломающие изменения предлагаю оставлять на 2.0
Дык до релиза это даже и не ломающее изменение. А в 2.0 это уже будет точно несовместимость с предыдущей версией.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Рысцов Денис, Вы писали:
РД>Мне нравится (кажется удобным), что можно написать [(1,2)].Map(fun(a,b){ ... }) не смотря на то, что Map имеет тип 'a->'b.
Тут можно будет писать [(1,2)].Map(fun((a,b)){ ... })
РД>Если фичу запретить, то придется писать [(1,2)].Map(fun(_){ | (a,b) => ... }), что менее элегантно. С другой стороны именно неявными преобразованиями меня пугает scala.
Проблема в том, что это преобразование создает невероятное количество вариантов при работе с LINQ-ом.
Я был вынужден ввести очень не простые эвристики в алгоритм разрешения перегрузки, чтобы это дело наконец-то заработало. Причем в режиме интеграции (когда код не дописан до конца) это все равно приводит к проблемам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Соглашаюсь с удалением этой фичи(бага)
Мне кажется, что если пишем def a = (1,2); , то a уже кортеж и использовать её как массив смысла нет... Хотя если можно это оставить, то почему бы и нет. С магическим синтаксисом, например f([a])
الحقيقة:الشئ الوحيد الذي(لا)يصدقه الناس!ا الزواج : جمع.وطرح.ثم(ضرب)!ولكنه قبل ذلك(قسمة) المحامي:لسان.وحنجرة.وروب!يدافع عن مال موكله (أعزائي)!وهو لا يعرف أحد منّا!الطالب (الأول)على فصله!لولا وجود الأخرين
Здравствуйте, Рысцов Денис, Вы писали:
РД>Мне нравится (кажется удобным), что можно написать [(1,2)].Map(fun(a,b){ ... }) не смотря на то, что Map имеет тип 'a->'b. Если фичу запретить, то придется писать [(1,2)].Map(fun(_){ | (a,b) => ... }), что менее элегантно.
По всей видимости поляки именно ради такого использования внедрили эту фичу.
Здравствуйте, VladD2, Вы писали:
VD>Но действительно вреда от фичи куда больше чем достоинств.
+1
VD>Дело даже не в явном указании, а в том что немерл поддерживает неявное преобразование. Скажем если у нас есть функция с двумя параметрами, то в нее всегда можно передать кортеж. Если мы запрещаем неявное преобразование, то и эта фича отвалится. А будет ли это хорошо?
Вот этот сценарий — кортеж распаковываемый в аргументы функции, мне думается автоматизировать нужно.
Но обратная операция весьма спорная, так как код подобный этому выглядит весьма странно:
Здравствуйте, VladD2, Вы писали:
VD>Дык до релиза это даже и не ломающее изменение. А в 2.0 это уже будет точно несовместимость с предыдущей версией.
2.0 один хрен будет не совместима с 1.0.
У нас просто нет ресурсов чтобы в 2.0 воспроизвести все баги 1.0
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, SergASh, Вы писали:
SAS>Здравствуйте, WolfHound, Вы писали:
WH>>Но ломающие изменения предлагаю оставлять на 2.0
SAS>Если делать ломающие изменения, то гораздо лучше делать их до первого релиза.
+1
Раз эта фича не полезна, то лучше ее продумать и внести изменения до 2-й версии.
Т.к. проблему 1-й версии это решит уже сейчас, а 2-я версия будет не очень скоро.
SAS>С исходной посылкой согласен, фича вредная.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, hardcase, Вы писали:
H>>
H>>def f(a) ...
H>>f(1,2)
H>>
ВВ>Я так понимаю, это ввели отчасти из-за... "эстетических" причин. Т.к. с Си-подобным синтаксисом вызов бы выглядел так:
ВВ>
ВВ>f((1,2))
ВВ>
Что-то нечасто я вдел чтобы функция принимала чисто кортеж.
Но я всеже предполагаю, что выбрасывание этой чисто эстетической фичи позволит упростить алгоритм выбора перегрузок и механизм вывода типов, что положительно скажется на скорости компиляции.