Как произносится "=>", как используется в лямбда-выражениях в.Net?
Я очень редко встречаю других программистов!
Моя мысль, когда я впервые увидел токен, была "подразумевает, что", поскольку это то, что он будет читать как математическое доказательство, но это явно не его смысл.
Так как же сказать или прочитать "=>", как в:-
IEnumerable<Person> Adults = people.Where(p => p.Age > 16)
Или есть даже согласованный способ сказать это?
15 ответов
Я обычно говорю "такой, что" при чтении этого оператора.
В вашем примере p => p.Age > 16 читается как "P, так что p.Age больше 16."
На самом деле, я задал этот вопрос на официальных предварительных форумах linq, и Андерс Хейлсберг ответил, что
Я обычно читаю оператор => как "становится" или "для чего". Например,
Func f = x => x * 2;
Func test = c => c.City == "Лондон";
читается как "x становится x * 2" и "c, для которого c.City равен Лондону"
Что касается "идет" - это никогда не имело смысла для меня. "р" никуда не денется.
В случае чтения кода кому-то, скажем, по телефону, тогда, пока он является программистом на C#, я бы просто использовал слово "лямбда", то есть "p lambda p dot age шестнадцать."
В комментариях Стив Джессоп упомянул "преобразования в" в случае преобразований - так, например, на примере Андерса:
x => x * 2;
будет читать
х отображается в х раз 2.
Это кажется гораздо ближе к реальному замыслу кода, чем "становится" для этого случая.
Из MSDN:
Все лямбда-выражения используют лямбда-оператор =>, который читается как "идет".
От Эрика Липперта:
Я лично сказал бы, что c=>c+1 как "видеть, чтобы видеть плюс один". Некоторые варианты, которые я слышал:
Для прогноза (Customer c)=>c.Name: "клиент видит, видит имя точки"
Для предиката (Customer c)=>c.Age > 21: "клиент видит так, что возраст точки больше двадцати одного"
Я всегда называл это "оператор Ван":-)
"р ван возраст р больше 16"
Как насчет "карты для"? Это одновременно лаконично и, возможно, более технически точно (т. Е. Нет предположения об изменении состояния, как в случае "идет" или "становится"), нет сопоставления множества с его характеристической функцией, как с "таким, что" или "для которого"), чем другие альтернативы. Хотя, если на странице MSDN уже есть стандарт, возможно, вам следует просто пойти на это (по крайней мере, для кода C#).
"Карты в" - мое предпочтительное произношение. Математически говоря, функция "отображает" свои аргументы на свое возвращаемое значение (можно даже назвать функцию "отображением"), поэтому мне имеет смысл использовать эту терминологию в программировании, особенно в качестве функционального программирования (особенно лямбда-исчисления) очень близко к математике. Он также более нейтрален, чем "становится", "уходит" и т. Д., Поскольку не предполагает смены состояния, как уже упоминалось в контексте.
Помимо получения предыдущей области видимости (все переменные и константы, которые находятся в области видимости для нормальной строки кода в точке, где происходит лямбда-выражение, доступны для кода выражения), лямбда-выражение по сути является синтаксическим сахаром для встроенной функции.
Список значений слева от производственного оператора ("=>") вносит вклад в структуру и содержимое стекового фрейма, используемого для вызова этой функции. Можно сказать, что в список значений входят как объявления параметров, так и передаваемые аргументы; в более традиционном коде они определяют структуру и содержимое кадра стека, используемого для вызова функции.
В результате значения "идут" в коде выражения. Вы бы предпочли сказать "определяет фрейм стека" или "идет к"?:)
В узко определенном применении булевых выражений, используемых в качестве условий фильтра (доминирующее использование лямбда-выражений, широко рассмотренное другими ответами на этот вопрос), очень разумно пропустить метод в пользу намерения кода, и это приводит к " за что "быть таким же кратким и сказать больше о значении кода.
Однако лямбда-выражения не являются единственной провинцией Линка, и вне этого контекста следует использовать более общую форму "идет".
Но почему "уходит"?
Потому что "заполняет кадр стека следующего кода" слишком долго, чтобы продолжать это говорить. Я полагаю, вы могли бы сказать, "это / передано".
Принципиальное различие между явно переданными параметрами и захваченными переменными (если я правильно помню - поправьте меня, если я ошибаюсь) заключается в том, что первые передаются по ссылке, а вторые - по значению.
Если вы представляете лямбда-выражение как анонимный метод, то оно "подходит для" имеет достаточно приличный смысл.
(n => n == String.Empty)
n "идет" к выражению n == String.Empty.
Это относится к анонимному методу, поэтому вам не нужно идти к методу в коде!
Простите за это.
Честно говоря, я не люблю использовать "идет к" в моей голове, но я видел, как другие люди говорили, что это кажется странным, и я подумал, что проясню это.
Мой краткий ответ: "c 'lambda-of' e". Хотя я цепляюсь за "лямбда-с" функцию "е", я думаю, что лямбда-о - это экуменический компромисс. Анализ следует.
Это отличный вопрос хотя бы для причудливых ответов. Большинство переводов имеют иные значения, чем для лямбда-выражений, что приводит к экзотическим интерпретациям. Как старый хакер с лямбда-выражениями, я просто игнорирую нотацию.NET и переписываю ее как лямбда в моей голове, желая, чтобы они сделали для этого почти все остальное.
Для передачи кода по телефону вы хотите, чтобы кто-то мог записать код по порядку. Это, конечно, проблема, но лямбда-стрелка или что-то, возможно, лучшее, что вы можете получить, или, может быть, лямбда-в, но лямбда-в является наиболее точным.
Проблема заключается в использовании инфикса и в том, как назвать всю вещь и роль левой и правой частей чем-то, что работает, когда говорят в месте инфикса.
Это может быть чрезмерно ограниченной проблемой!
Я бы не использовал "такой, что", потому что это означает, что правая часть является предикатом, который должна удовлетворять левая часть. Это очень отличается от разговора о правой стороне, от которой левая сторона была абстрагирована как функциональный параметр. (Заявление MSDN о "всех лямбда-выражениях" является просто оскорбительным и неточным.)
Что-то раздражает в том, что "идет", хотя это может быть как можно ближе. "Идет к" подразумевает преобразование, но нет точно некоторой переменной с, которая идет к выражению в с. Абстракция к функции немного неуловима. Я мог бы привыкнуть к этому, но я все еще жажду чего-то, что подчеркивает абстракцию переменной.
Так как левая часть всегда является простым идентификатором в используемых до сих пор случаях [но ждать расширений, которые могут запутать это позже], я думаю, что для "c => expression" я бы прочитал "c" выражение лямбда-функции. "'или даже" c' arg '' function' expression". В последнем случае я мог бы сказать такие вещи, как "b 'arg' c 'arg' 'function' expression".
Может быть, лучше сделать еще более понятным введение лямбда-выражения и сказать что-то вроде "arg" b "arg" c "function" expression ".
Выяснить, как перевести все это на другие языки, - это упражнение для студента [;<).
Я все еще беспокоюсь о "(b, c) => expression" и других вариантах, которые могут возникнуть, если они этого еще не сделали. Возможно "args" b, c "function" expression ".
После всего этого размышления я замечаю, что перехожу к переводу "c => e" как "lambda" c "function 'e" и замечаю, что отображение на точную форму следует понимать по контексту: λc(e), c => e, f, где f(c) = e и т. д.
Я ожидаю, что объяснение "уходит" будет преобладать просто потому, что именно здесь доминирующее большинство впервые увидит лямбда-выражения. Какая жалость. Хорошим компромиссом может быть "c 'lambda-of' e"
Я не слишком много думал об этом, но просто лаконично говорю "к". Это коротко и кратко, и подразумевает, что переменная передана выражению. Я полагаю, что это может быть перепутано с цифрой 2 ("два"), но я склонен произносить "на" больше как "та" при разговоре. Никто (кто знает лямбды, по крайней мере) никогда не говорил мне, что они думают, что это неоднозначно...
// "Func f equals x to x times two"
Func f = x=> x * 2;
// "Func test equals c to c dot City equals London"
Func test = c => c.City == "London"
В Ruby этот же sybmol называется hashrocket, и я слышал, что программисты на C# тоже используют этот термин (хотя это неправильно).
Часть проблемы заключается в том, что вы можете прочитать его вслух по-разному в зависимости от его структуры. Жаль, что это не так красиво и не так интегрировано, как у Рубина.
Мои два цента:
s => s.Age > 12 && s.Age < 20
"Лямбда-выражение с параметром s равно { return s.Age > 12 && s.Age < 20; }"
Мне нравится это, потому что это напоминает мне о том, откуда исходит выражение lamdba
delegate(Student s) { return s.Age > 12 && s.Age < 20; };
=> это просто ярлык, поэтому вам не нужно использовать ключевое слово делегата и включать информацию о типе, так как он может быть выведен компилятором.
Мой термин для => применительно к показанным примерам результат
'result = s => s.Age > 12 && s.Age < 20'
s, где s. возраст больше 12 и s. возраст менее 20
'result = x => x * 2'
x, где x умножается на 2
'result = c => c.City == "London"'
c, где c.city эквивалентно "Лондону"
'result = n => n == String.Empty'
n, где n - пустая строка