Здравствуйте, maxkar, Вы писали:
M>Тут в соседней ветке Sinclar привел хороший пример с прямоугольниками, так что могу утверждать: даже при чтении (проверке!) вызова функции в виде f(a, b) могут быть проблемы.
Конечно могут. Кстати, вполне вероятно, что если сесть под люстрой, то тебя ею придавит. Ведь может быть землятресение.
Это я к тому говорю, что "могут" не показатель. Важно насолько часто они случаются и сколь ощутимые последствия от этого.
Скажем вместо f(a, b) можно же писать f(arg1 = a, arg2 = b). Но многие будут даже против такой записи (хотя она и правда более информативна). Так что тут компромис. Проблема может быть, но она редка и не страшна. Так что многие предпочитают более краткий синтаксис.
M>Касается как раз тех самых прямоугольников. Например, g.drawRect(x1, y1, x2, y2) является местом потенциальной ошибки (опять же, нужно знать библиотеку или читать документацию). По сравнению с ним вызов g.drawRect(rect) гораздо читабельнее. Да, там нужно проверять, что rect инициализирован правильно, но он то инициализируется через rect.setWidth(width) или rect.setX2(x2), что читается и проверяется легче (глаз цепляется за rest.setWidth(x2) или rect.setX2(width)).
Ну, и? Каков вывод? Отказываемся от передачи более чем одного параметра в функцию?
M>Где-то в ветке уже вывигалась идея, что такая проблема не существует, если элементы кортежа разных типов. С этим я согласен, при разных типах результата (с разной семантикой) путаницы не возникает (так же, как и при передаче параметров).
А тебе не кажется, что ты обсасываешь не стоящую выеденного яйца, гипотетическую проблему теолько для того, чтобы не принимать ничего нового?
Может быть поступить более конструктивно, и попробовать это новое, и уже потом составить свое мнение?
M>Теперь перейдем к математике.
Уже не хочется, спасибо. Подумай над моими словами. А то у нас получается спор о вкусе устриц с теми, кто их не ел.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
G>>Зато всегда есть имена принимающих переменных, которые названы так, что все понятно. Этого мало? S>Конечно мало. Возвращаясь к примеру с вызовом обычного метода — у тебя что, всегда имена фактических аргументов совпадают с именами параметров?
А мне достаточно. Возвращаясь к примеру — нет, у меня имена параметров всегда настолько информативны, что понятно, что в них лежит. Что и тебе советую. Это совсем не сложно — давать локальным переменным осмысленные имена.
S>Если убрать имена параметров из стандартной библиотеки, оставив только _1, _2, _3, то как-то трудновато будет разобраться с тем, что происходит, не так ли?
Кто-то заставляет меня, пользуясь туплами, их убирать из стандартной библиотеки? Странные вы люди, все таки. Вот, смотри — синтаксис нотации типов Эрланга, сигнатура функции.
Вопросы по пониманию — есть? С чем спорим?
G>> Кроме того, это имеет вообще значение только в случае, если возвращаемые значения тупла одного типа. Такое бывает редко, и обычно однозначно трактуется, скажем: G>>Прямоугольник, или линия — ( x1, y1, x2, y2 ). S>Отлично. Осталось понять, кто из них горизонтальный, а кто вертикальный. И x2 там в третьем члене или width.
В настоящем дизайне я напишу по другому. С туплами, разумеется — заводить для этой фигни типы — overkill. Я напишу так:
И верну тупл, да не один, а цельных три. Вопросы, что вернет get_rect — есть? Или опять остается что-то понять?
G>>Диапазон времени — ( startTime, endTime ). S>Или всё-таки startTime, timeSpan?
Да ради бога. Это разные типы. timeSpan — это интервал времени в минутах, диапазон — пара времен. Тайпчекер даст по рукам.
G>>Имена принимающих переменных в строке вызова — забыл, нет? На них смотреть религия не позволяет? S>А если их перепутали?
А если входные аргументы функции перепутали? Что тогда? Будешь из страха, что перепутаешь — по структуре на каждую функцию заводить? Странно, и почему этого никто не боится, а?
Здравствуйте, Sinclair, Вы писали:
S>Это аналогично вот такому варианту твоего предложения: S>
S>g.drawRect(new Rect{X1=x1, Y1=y1, X2=x2, Y2=y2}; // object initializers спешат на помощь
S>
S>Заметь, что мы по прежнему опираемся на именование параметров. Даже если мы перепутаем порядок, компилятор восстановит смысл за нас.
Кстити, в немерле 1.0 и C# 4.0 таки есть те самые именнованные параметры. От чего идея именованных возвращаемых параметров становится еще более очевидной, на мой згляд.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, maxkar, Вы писали:
M>Не может программист знать, что функция делает.
Да, ну?
Далее раговаривать нам с тобой не о чем. У нас диаметрально противоположенная база.
M>Для библиотек еще можно такого требовать, но для кода организации — нет.
Я не знаю кто такая "кода организации". Но знаю точно, что минимальная еденица абстракции в программировании на любом языке окромя ассемблера — это функция (метод/процедура). Оспоривать это глупо.
M> Иначе ценность программиста в компании сильно определяется тем, что же из ее кода он знает.
Причем тут код? Надо чеотко понимать, что знать что делает функция, и знать как она реализована — это не одно и то же.
Я не даром говорил об абстракции.
M>А это плохо и для организации, и для самого программиста. Для организации плохо тем, что менять программистов тяжело. Для программиста тем, что полученная информация совершенно не конвертируемая (в другой организации придется учить другой набор велосипедов). Чем меньше нужно учить — тем лучше.
А. Это теория по которой 1000 обезьян должны написать "Войну и мир"? Я с ней не согласен.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Могу. Но разобраться будте проще. Так как мне будте достаточно поглядеть на хинт в IDE и увидить несоответствие.
Нет, не проще. Мне _сейчас_ точно так же вполне достаточно поглядеть на сигнатуру функции, и увидеть несоответствие. И не имеет никакого значения, делаю я это в IDE или нет. Примеры мои видел? Прежде чем писать, посмотри как оно уже выглядит и работает в Эрланге. Это — рабочие примеры. Типы в статике проверяются, точно так же как в С#, не переживай, никакой разницы нет. Статическая проверка типов никак не противоречит динамической типизации.
Кроме того, ошибка эта, о которой ты говоришь — неуловимый Джо. Не помню, чтобы хоть раз путал аргументы функции.
G>>Разница — в чем? Вы о чем вообще говорите, люди? Бред какой-то.
VD>Мы говорим о статически типизированных языках имющих офигительную поддержку IDE. Она в сочетании с языковыми решениями позволяет делать меньше ошибок. Тюплы тут несколько не вписываются в картину.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>Он имел в виду, что функцию ты описываешь один раз и если накосячил с именами параметров, то только в ней. А вызваешь ты ее 100 раз и накосячить с именами можешь неограниченно количество раз:
ANS>Именно это я и хотел сказать. Спасибо.
О как. А я, вот, прикинь, сказал ровно то, что хотел.
Здравствуйте, Sinclair, Вы писали:
G>> Кроме того, это имеет вообще значение только в случае, если возвращаемые значения тупла одного типа. Такое бывает редко, и обычно однозначно трактуется, скажем: G>>Прямоугольник, или линия — ( x1, y1, x2, y2 ). S>Отлично. Осталось понять, кто из них горизонтальный, а кто вертикальный. И x2 там в третьем члене или width.
Как у вас все-таки все на ровном месте сложно и непросто. Не знаете, x вертикальный, или y, и норовите перепутать координаты с width. Для начала — последнее пишется не так. Он вот так пишется.
draw_rect( x1, y1, l, h ).
А первое —
draw_rect( x1, y1, x2, y2 ).
Типичный вызов из графической либы образца 90-х. Туплов в нем нет. Предлагаю поспорить со мной о том, что вызовы функций — это очень опасно. Желательно — с таким же огоньком, с которым вы рассуждаете о туплах .
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, VladD2, Вы писали:
VD>>Могу. Но разобраться будте проще. Так как мне будте достаточно поглядеть на хинт в IDE и увидить несоответствие.
G>Нет, не проще. Мне _сейчас_ точно так же вполне достаточно поглядеть на сигнатуру функции, и увидеть несоответствие.
Сейчас в сигнатуре кортеж без именованых полей. Так что взгляд на сигнатуру ничего не даст.
G> И не имеет никакого значения, делаю я это в IDE или нет. Примеры мои видел?
Какие?
G>Прежде чем писать, посмотри как оно уже выглядит и работает в Эрланге.
Ну, покажи. Только с объяснениями. А что в Эрлаг уже появились аннотации типов?
G>Это — рабочие примеры. Типы в статике проверяются, точно так же как в С#, не переживай, никакой разницы нет. Статическая проверка типов никак не противоречит динамической типизации.
Всегда был другого мнения.
G>Кроме того, ошибка эта, о которой ты говоришь — неуловимый Джо. Не помню, чтобы хоть раз путал аргументы функции.
Я помню пару случаев. И несколько случаев когда хотелось бы взглянуть на описание тюпла если бы оно было.
G>>>Разница — в чем? Вы о чем вообще говорите, люди? Бред какой-то.
VD>>Мы говорим о статически типизированных языках имющих офигительную поддержку IDE. Она в сочетании с языковыми решениями позволяет делать меньше ошибок. Тюплы тут несколько не вписываются в картину.
G>Они прекрасно вписываются в картину.
Да, кто бы спорил.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>Это у тебя предрссудок. Видимо он вызван роскознями тех кто придумал from в LINQ спереди ставить.
Ну да, совершенно верно.
VD>На само деле интелисенсу глубоко фиолетово какой конкретно синтаксис у выражения. Так что геерацию имен параметров или пдсказки можно сделать и так. Было бы с чем сравнивать (т.е. была бы метаинформация).
Ну вот мне как раз непонятно, откуда возьмется метаинформация.
VD>Например, в интеграции немерла ты можешь подвести курсор к имени переменной в паттерне декомпозиции кортежа и увидить ее тип. Были бы имена, то увидил бы и их. Можно даже было бы сделать аналог метод-хинта. Ну, и конечно можно было бы просто генерировать такие переменные по некоторому паттерну. Например, вбиваешь: VD>
VD>def () = GetPersonInfo(123)
VD>
VD>вызваешь комлейшон внутри скобок или жмешь некоторую комбинацию кнопок и получаешь заполненный список переменных.
Ну, то есть надо прыгать взад-вперёд? Как-то не очень удобно. VD>Ну, и естественно при этом можно было бы и через точку работать. Но об этом я уже говорил.
Ну, через точку то и так понятно. Вопрос только в присванивании результата в локальную переменную/поле/еще что-то.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gaperton, Вы писали:
G>А мне достаточно. Возвращаясь к примеру — нет, у меня имена параметров всегда настолько информативны, что понятно, что в них лежит. Что и тебе советую. Это совсем не сложно — давать локальным переменным осмысленные имена.
Так, еще раз поясни — ты сейчас про имена параметров или про имена переменных?
G>Вопросы по пониманию — есть? С чем спорим?
В этой сигнатуре компоненты тупла именованные. С чем спорим?
G>В настоящем дизайне я напишу по другому. С туплами, разумеется — заводить для этой фигни типы — overkill. Я напишу так:
G>
G>И верну тупл, да не один, а цельных три. Вопросы, что вернет get_rect — есть? Или опять остается что-то понять?
Опять у туплов компоненты именованные. Конечно, в таком варианте вопросов не будет. Но ты же вроде как утверждал, что туплам достаточно анонимных компонентов. Вот у тебя и будет
G>А если входные аргументы функции перепутали?
Еще раз поясняю: у входных аргументов, помимо типов, есть имена. Отсюда желание завести имена и у выходных аргументов, и по той же причине.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gaperton, Вы писали:
G>Типичный вызов из графической либы образца 90-х. Туплов в нем нет.
Зато есть имена у параметров. Нажал Ctrl-space — увидел: "int Height".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
. К>Это обработка "ошибочной" ситуации, она не покрывает все варианты использования туплов.
Во-первых, если ты хочешь синтаксиса один-в-один, то, естественно, получатся туплы. Но такая позиция в дискуссии — это тупик.
Во-вторых, деструкция туплов
Здравствуйте, Sinclair, Вы писали:
S>Ну, то есть надо прыгать взад-вперёд? Как-то не очень удобно.
Ты пишешь код один раз. А читаешь много, много раз. Так что при выборе синтаксиса нужно исходить в первую очередь из соображений простоты чтения и привычности для окружающих (принцип — не удивляй).
VD>>Ну, и естественно при этом можно было бы и через точку работать. Но об этом я уже говорил. S>Ну, через точку то и так понятно. Вопрос только в присванивании результата в локальную переменную/поле/еще что-то.
Ну, дык присвоил локальной переменной, а от нее через точку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
M>>Не может программист знать, что функция делает.
FR>Те же Filter и Partition это практически базовые стандартные ФВП. Их незнание для императивного программиста равносильно например незнанию цикла while.
Т.е. ни для чего кроме базовых стандартов ФВП (вроде Filter и Partition) туплы использовать нельзя? А зачем они тогда вообще нужны?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Ну, и добавлю, что такие техники в java/c# применять затруднительно из-за отсутствия нелокальных возвратов
Я потому и указал java/c#, что на нижележащих платформах их можно эмулировать. Обычно это делается через исключения. Вот я быстренько нашел что так для Scala и есть.
Есть у такого решения и минусы. Первый минус — нефункциональный — скорость работы. Второй минус — функциональный — исключение можно перехватить штатным обработчиком. Я с таким сталкивался когда использовал в ST реализацию на исключениях динамических переменных (dynamic scope). Точнее использовал не я, а сторонняя либа. Один неосторожный обработчик исключения и бабах.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Обычно это делается через исключения. Вот я быстренько нашел что так для Scala и есть. ANS>Есть у такого решения и минусы. Первый минус — нефункциональный — скорость работы. Второй минус — функциональный — исключение можно перехватить штатным обработчиком. Я с таким сталкивался когда использовал в ST реализацию на исключениях динамических переменных (dynamic scope). Точнее использовал не я, а сторонняя либа. Один неосторожный обработчик исключения и бабах.
Да, есть такая проблема. Я даже как-то открывал ticket по этому поводу. Кажется, в 2.8beta появились более совершенные механизмы (через continuations).
Бред какой-то.
