Какое имя лучше всего использовать для неизменяемого метода add в неизменяемой коллекции?

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

Предположим, у меня есть неизменный тип списка. У него есть операция, Foo(x)которая возвращает новый неизменный список с указанным аргументом в качестве дополнительного элемента в конце. Таким образом, для построения списка строк со значениями «Hello», «immutable», «world» вы можете написать:

var empty = new ImmutableList<string>();
var list1 = empty.Foo("Hello");
var list2 = list1.Foo("immutable");
var list3 = list2.Foo("word");

(Это код C #, и меня больше всего интересует предложение C #, если вы чувствуете, что язык важен. Это не принципиально вопрос языка, но идиомы языка могут быть важны.)

Важно то, что существующие списки не изменяются Foo- так empty.Countчто все равно вернет 0.

Другой (более идиоматичный) способ достижения конечного результата:

var list = new ImmutableList<string>().Foo("Hello")
                                      .Foo("immutable")
                                      .Foo("word");

Мой вопрос: как лучше назвать Foo?

РЕДАКТИРОВАТЬ 3 : Как я покажу позже, имя типа может не быть ImmutableList<T>, что делает позицию ясной. Вместо этого представьте, что он TestSuiteи что он неизменен, потому что весь фреймворк, частью которого он является, неизменен ...

(Конец редактирования 3)

Варианты, которые я придумала до сих пор:

  • Add: обычное в .NET, но подразумевает мутацию исходного списка
  • Cons: Я считаю, что это нормальное имя в функциональных языках, но бессмысленно для тех, кто не имеет опыта работы с такими языками.
  • Plus: мой любимый до сих пор, это не подразумевает мутацию для меня . Очевидно, это также используется в Haskell, но с несколько иными ожиданиями (программист на Haskell может ожидать, что он добавит два списка вместе, а не добавит одно значение в другой список).
  • With: согласуется с некоторыми другими неизменными соглашениями, но не имеет такой же «добавляемости» к этому IMO.
  • And: не очень описательный.
  • Перегрузка оператора для +: мне действительно это не очень нравится; Я вообще думаю, что операторы должны применяться только к типам более низкого уровня. Я готов быть убежденным, хотя!

Критерии, которые я использую для выбора:

  • Дает правильное представление о результате вызова метода (то есть, что это оригинальный список с дополнительным элементом)
  • Делает это настолько ясным, насколько это возможно, что он не изменяет существующий список
  • Звучит разумно, когда соединены вместе, как во втором примере выше

Пожалуйста, попросите более подробную информацию, если я не проясняю себя достаточно ...

EDIT 1: Вот мои рассуждения для предпочитая , Plusчтобы Add. Рассмотрим эти две строки кода:

list.Add(foo);
list.Plus(foo);

На мой взгляд (и это является личная вещь) последний явно глючит - это как письмо «х + 5;» как заявление само по себе. Первая строка выглядит нормально, пока вы не помните, что она неизменна. Фактически, то, что оператор плюс сам по себе не изменяет свои операнды, является еще одной причиной, по которой Plusя предпочитаю. Без небольшой неровности перегрузки операторов, он по-прежнему дает те же коннотации, которые включают (для меня) не мутирование операндов (или цель метода в этом случае).

РЕДАКТИРОВАТЬ 2: Причины не нравится Add.

По сути, есть разные ответы: «Идите с Add. Это то, что DateTimeделает, и Stringимеет Replaceметоды и т . Д., Которые не делают неизменность очевидной». Я согласен - здесь есть приоритет. Тем не менее, я видел много людей называют DateTime.Addили String.Replaceи ожидать мутации . Есть множество вопросов группы новостей (и, вероятно, SO, если я копаюсь), на которые отвечают: «Вы игнорируете возвращаемое значение String.Replace; строки неизменны, возвращается новая строка».

Теперь, я должен раскрыть тонкость на вопрос - тип может не быть на самом деле неизменяемый список, но другой тип неизменны. В частности, я работаю над платформой для сравнительного анализа, где вы добавляете тесты в комплект, и это создает новый комплект. Может быть очевидно, что:

var list = new ImmutableList<string>();
list.Add("foo");

не собирается ничего делать, но становится намного мрачнее, когда вы изменяете это на:

var suite = new TestSuite<string, int>();
suite.Add(x => x.Length);

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

var suite = new TestSuite<string, int>();
suite.Plus(x => x.Length);

Вот только прошу:

var suite = new TestSuite<string, int>().Plus(x => x.Length);

В идеале я бы хотел, чтобы моим пользователям не говорили, что набор тестов является неизменным. Я хочу, чтобы они упали в пропасть успеха. Это может быть невозможно, но я хотел бы попробовать.

Я прошу прощения за чрезмерное упрощение исходного вопроса, говоря только о неизменяемом типе списка. Не все коллекции настолько информативны, как ImmutableList<T>:)

6.02.2009 19:49:29
@ Адам: Нет, последний явно глючит. Они оба на самом деле багги ( так как они не делают ничего с результатом) - но первый не выглядеть багги для меня.
Jon Skeet 6.02.2009 20:35:35
Является ли кошка собакой?
Michael Myers♦ 6.02.2009 21:15:16
Concat / Condog ... работает на меня! ;)
gnovice 6.02.2009 21:16:12
Uncat - это был бы зомби-кот.
Erik Forbes 7.02.2009 00:22:00
@Trap: Это отстой с точки зрения создания API API, хотя.
Jon Skeet 9.03.2009 15:02:46
30 ОТВЕТОВ

В итоге я выбрал « Добавить» для всех моих неизменных коллекций в BclExtras . Причина в том, что это легко предсказуемое имя. Я не очень беспокоюсь о людях, которые путают Add с мутирующим add, так как имя типа имеет префикс Immutable.

Некоторое время я обдумывал «против» и другие названия функциональных стилей. В конце концов я обесценил их, потому что они не так хорошо известны. Конечно, функциональные программисты поймут, но они не большинство пользователей.

Другие имена: вы упомянули:

  • Плюс: я не хочу этого делать. Для меня это не отличает его от того, что он не является мутирующей операцией больше, чем Add
  • С: вызовет проблемы с VB (каламбур)
  • Перегрузка оператора: проблема с обнаружением

Варианты, которые я рассматривал:

  • Concat: строки неизменны и используют это. К сожалению, это действительно хорошо только для добавления в конец
  • CopyAdd: Скопировать что? Источник, список?
  • AddToNewList: Может быть, хороший для списка. Но как насчет коллекции, стека, очереди и т. Д ...

К сожалению, на самом деле, кажется, нет слова, которое

  1. Определенно неизменная операция
  2. Понятно для большинства пользователей
  3. Представляется менее чем за 4 слова

Это становится еще более странным, когда вы рассматриваете коллекции, отличные от List. Возьмите, например, стек. Даже программисты первого года могут сказать вам, что в стеках есть пара методов Push / Pop. Если вы создаете ImmutableStack и даете ему совершенно другое имя, назовем его Foo / Fop, вы просто добавили больше работы для них, чтобы использовать вашу коллекцию.

Редактировать: Ответ на Плюс Редактировать

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

list.Minus(obj);

Самая большая проблема, с которой я сталкиваюсь с плюсом / минусом или новым сочетанием, - это ощущение, что это излишнее. Сама коллекция уже имеет отличительное имя, неизменный префикс. Зачем идти дальше, добавляя словарь, цель которого - добавить то же различие, что и префикс Immutable.

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

Редактировать 2

Согласитесь, что людей определенно смутили String.Concat и DateTime.Add. Я видел несколько очень ярких программистов, решивших эту проблему.

Однако я думаю, что ImmutableList - это другой аргумент. В String или DateTime нет ничего, что устанавливало бы его как неизменное для программиста. Вы должны просто знать, что он неизменен через какой-то другой источник. Так что путаница не является неожиданной.

ImmutableList не имеет этой проблемы, потому что имя определяет его поведение. Можно утверждать, что люди не знают, что такое Неизменное, и я думаю, что это также верно. Я, конечно, не знал об этом примерно до 2 года в колледже. Но у вас та же проблема с любым именем, которое вы выберете вместо «Добавить».

Изменить 3: Как насчет типов, таких как TestSuite, которые являются неизменными, но не содержат слово?

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

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

Теперь, как вы можете определить TestSuite как неизменный? В сегодняшней среде я думаю, что есть несколько способов

  1. Префикс с неизменным: ImmutableTestSuite
  2. Добавьте Атрибут, который описывает уровень Immutablitiy. Это, безусловно, менее заметно
  3. Не намного больше.

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

33
6.02.2009 21:08:37
Добавили причины моего предпочтения для Plus над Добавить к вопросу. Хотелось бы получить комментарии по этому поводу. Я действительно открыт для мысли, что я глупый.
Jon Skeet 6.02.2009 20:02:42
@JaredPar: А что если тип называется TestSuite?
Jon Skeet 6.02.2009 20:39:08
Хотел бы дать еще один +1 для редактирования 3, но, очевидно, не может. (В моем случае я не пытаюсь получить параллелизм - я считаю, что неизменность приводит к коду, о котором легче рассуждать.) Я все еще не совсем уверен, что Add - это путь, но поддержка ответов здесь убедительно.
Jon Skeet 6.02.2009 21:01:51
Если бы вы могли вставить этот вопрос в разговор на работе, это тоже было бы здорово. Я начал обсуждение списка C #, поэтому некоторые коллеги могут быть уже вовлечены. Можно спросить и у себя в Google ...
Jon Skeet 6.02.2009 21:02:45
@ Джон, я думаю, я знаю хорошее место, чтобы
JaredPar 6.02.2009 21:03:54

Чтобы быть как можно более понятным, вы, возможно, захотите пойти со словом CopyAndAddили чем-то подобным.

22
6.02.2009 19:55:03
Не все неизменные коллекции требуют копии, чтобы добавить все же. Подумайте о неизменных деревьях, им просто нужен новый узел и они могут использовать существующее дерево в качестве листа.
JaredPar 6.02.2009 21:40:55
Кстати, я прочитал ваш профиль, затем возраст в порядке и был кратко удивлен тем, сколько вам лет. Вскоре после этого появился здравомыслие.
JaredPar 6.02.2009 21:42:45
Первый комментарий: я использую деревья настолько редко, что эта мысль никогда не приходила мне в голову. Это хороший момент.
Michael Myers♦ 6.02.2009 22:03:54
Повторяю второй комментарий: признаюсь, я сделал это для значка! Я просто не люблю указывать свой возраст. (Я на самом деле моложе вас, но я могу играть капризно старомодного довольно хорошо, если мне нужно. И я не единственный, чей возраст указан как 89.)
Michael Myers♦ 6.02.2009 22:07:52
Аргумент о неизменных деревьях - сильный аргумент. Так что тогда EquivalentReferenceWithAdded (x) будет бороться с этим аргументом, но звучит глупо, и его трудно вывести.
TheBlastOne 10.08.2011 22:43:42

Мне нравится И () . Я думаю, что это имеет наименьший потенциал для двусмысленности. Единственное столкновение, о котором я могу думать, - это логическое И, я не вижу, чтобы это было проблемой для разработчика на C # и даже для VB, я думаю, что контекст делает его маловероятным, чтобы вызвать проблему, и любая проблема будет быстро решена в время компиляции. Это также хорошо работает на английском языке «Сделай что-нибудь с этим и этим» или «Положи это и это в коробку».

Я думаю. С () все в порядке . Меня беспокоит, что это может выглядеть немного как метод linq Where <>, особенно если в качестве аргумента есть лямбда-выражение. Английский в моей голове также менее ясен, особенно "Делай что-нибудь с этим".

Мне не нравится .Plus () . Я не могу пропустить это как синоним для Add: плюс = знак плюс = + = добавить.

0
6.02.2009 22:14:19

DateTime в C # использует Add. Так почему бы не использовать одно и то же имя? Пока пользователи вашего класса понимают, что класс неизменен.

10
6.02.2009 19:55:32
Я бы сказал, что DateTime.Add, как известно, сбивает с толку людей ... но я согласен, что это показывает приоритет.
Jon Skeet 6.02.2009 19:58:18
Точно так же, как методы изменения строки сбивают с толку новых разработчиков. Но достаточно скоро все узнают, что «струны неизменны»
Tundey 6.02.2009 20:59:21

Несколько случайных мыслей:

  • ImmutableAdd ()
  • Append ()
  • Конструктор ImmutableList <T> (ImmutableList <T> originalList, T newItem)
11
6.02.2009 19:56:44
+1 для НеизменныйДобавить; не увлекается Append (слишком похоже на StringBuilder.Append, который мутирует), а версия конструктора - это проблема с цепочкой.
Jon Skeet 6.02.2009 19:58:48

Я думаю, что «Добавить» или «Плюс» звучит хорошо. Название самого списка должно быть достаточно, чтобы передать неизменность списка.

5
6.02.2009 19:57:15
Это не список, это набор тестов.
tstenner 8.02.2010 20:46:37

«Заменить»? Он не добавляет в список, он заменяет список новым.

0
6.02.2009 20:00:40
Если я увижу foo.Replace (), я подумаю, что foo заменяется.
chaos 6.02.2009 20:47:03
Да, потому что это так. Принимая во внимание, что когда я вижу foo.add (), я думаю, что что-то будет добавлено в foo, чего не происходит в этом случае.
Paul Tomblin 6.02.2009 20:53:27
Обычно replace () принимает 2 аргумента: что-то для замены и что-то для замены. Не уверен, насколько ясно было бы увидеть метод замены, который делает что-то другое ...
Outlaw Programmer 6.02.2009 21:48:44

Я бы назвал это Extend () или, может быть, ExtendWith (), если вы хотите по-настоящему многословно.

Расширение означает добавление чего-либо к чему-то другому без изменения. Я думаю, что это очень актуальная терминология в C #, поскольку она похожа на концепцию методов расширения - они «добавляют» новый метод в класс, не «касаясь» самого класса.

В противном случае, если вы действительно хотите подчеркнуть, что вы вообще не изменяете исходный объект, использование какого-либо префикса, такого как Get, выглядит для меня неизбежным.

21
6.02.2009 20:54:28
Тем не менее, подразумевается что-то делать с базовым объектом.
chaos 6.02.2009 20:46:01

Я бы пошел на простой Add (). Альтернативой будет Append (), если вы хотите передать, что это действительно операция сбора.

В дополнение к явному методу я бы по-прежнему предлагал реализацию obverloaded + operatr. Это хорошо известная операция. Все знают, что String неизменен, но все используют «+» для создания новых экземпляров.

0
6.02.2009 20:02:26

Append- потому что, обратите внимание, что имена System.Stringметодов предполагают, что они видоизменяют экземпляр, но это не так.

Или я совсем как AfterAppending:

void test()
{
  Bar bar = new Bar();
  List list = bar.AfterAppending("foo");
}
4
6.02.2009 20:02:37
Как и DateTime аргумент раньше, я согласен с старшинства , если бы не тот факт , что так многие программисты действительно ожидают строковые методы , чтобы делать вещи. Им нужно сказать (иногда неоднократно), что строки неизменны. Я хотел бы заманить своих клиентов-разработчиков в пропасть успеха :)
Jon Skeet 6.02.2009 20:03:52
Мне нравится Добавлять все больше и больше. Это отличает то, что вы не мутируете коллекцию, а присоединяетесь к ней.
user29439 4.02.2011 21:06:59

Мне нравится предложение mmyers CopyAndAdd . В соответствии с темой «мутации», возможно, вы могли бы пойти с Bud (бесполое размножение), Grow , Replicate или Evolve ? знак равно

РЕДАКТИРОВАТЬ: продолжить с моей генетической темой, как насчет Procreate , подразумевая, что создается новый объект, который основан на предыдущем, но с добавлением чего-то нового.

18
7.02.2009 04:13:16

Как насчет "Аугмента"?

Это слово отличается от Add, но это близкий синоним.

0
6.02.2009 20:05:53
Это все еще глагол, который звучит так, как будто он что-то делает для своей цели.
Jon Skeet 6.02.2009 20:10:49

Я думаю, что ключевая вещь, которую вы пытаетесь понять, это трудно выразить, это может быть что-то с порождающим словом, что-то вроде CopyWith () или InstancePlus ().

9
6.02.2009 20:07:11

На самом деле мне нравится And, особенно в идиоматическом смысле. Мне бы особенно понравилось, если бы у вас было статическое свойство readonly для пустого списка, и, возможно, вы сделали конструктор закрытым, чтобы вам всегда приходилось строить из пустого списка.

var list = ImmutableList<string>.Empty.And("Hello")
                                      .And("Immutable")
                                      .And("Word");
59
6.02.2009 20:12:41
Мне нравится Пустая идея. Все еще не убежден в И хотя. Это просто немного бла.
Jon Skeet 6.02.2009 20:15:45
Это просто больше похоже на то, как я думаю о создании списка вещей на естественном языке. Если вы читаете это вслух, это кажется более интуитивным, чем «Добавить» или «Плюс». «list» - это пустой список, а также «Hello», «Immutable» и «Word». Я согласился бы, что это менее ясно в изоляции, хотя.
tvanfosson 6.02.2009 20:19:39

Поскольку имя типа - ImmutableList, что указывает на то, что оно является неизменяемым, я думаю, что .Add () - это хорошо. Однако, если вы действительно настаиваете на чем-то другом, я мог бы пойти с чем-то вроде .AddEx (), где Ex означает расширенный и подразумевает, что пользователь должен определить, что это за Ex (читая документы) перед использованием. Мне также нравится предложение Plus () и GetCopyWith ()

0
6.02.2009 20:34:50

Я не думаю, что английский язык позволит вам безошибочно подразумевать неизменность при использовании глагола, который означает то же самое, что и «Добавить». «Плюс» почти делает это, но люди все еще могут ошибаться.

Единственный способ запретить пользователям принимать объект за что-то изменяемое - это сделать его явным, либо через имя самого объекта, либо через имя метода (как в случае с подробными опциями, такими как «GetCopyWith» или "CopyAndAdd").

Так что просто иди с любимым, «Плюс».

9
6.02.2009 20:36:08

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

thesaurus.com возвращает это для «добавить»:

Определение: соприкосновение, увеличение; сделать дальнейший комментарий

Синонимы: аффикс, приложение, анте, добавление, увеличение, усиление, повышение, наращивание, зарядка, продолжение, наведение, фигура, всплеск, нагрев, поход, повышение, зацепление, зацепление, зацепление с, включают, поднять, взбодрить, объединить, колодки, parlay, автожелезнодорожные перевозки, подключить, налить его, ответить, подбежать, скажем дальше, хлопнуть, снежный ком, суп, ускорить, всплеск, шаг вверх, добавка, подсластить, прихватить, тег

Мне нравится звук Adjoin, или более просто Join. Это то, что ты делаешь, верно? Этот метод может также применяться для присоединения к другим ImmutableList<>.

52
6.02.2009 20:57:56
Мне также нравится «Присоединиться», но в большинстве случаев, когда вы объединяете 2 объекта, вы получаете 1. В этом случае, если вы объединяете 2 объекта, вы фактически создаете новый объект.
Outlaw Programmer 6.02.2009 21:52:48
Я не знаю ни одного случая в .NET, Perl, PHP или даже VBScript, где Join подразумевает мутацию. Конструкция такова, что A и B объединяются, чтобы создать C, где C всегда новый объект.
spoulson 6.02.2009 22:05:14
Мне нравится Join, и я полностью согласен с thesaurus.com :) Используйте это все время, когда сомневаетесь в имени.
Skurmedel 26.06.2009 12:50:45
var suite = new TestSuite <string, int> () .Join (x => x.Length);
Sly Gryphon 15.08.2009 03:58:10
Иди с Piggyback, IMO. Или HookUp с.
Chris Marasti-Georg 28.09.2011 21:56:46

Лично мне нравится .With (). Если бы я использовал объект, после прочтения документации или комментариев к коду, было бы понятно, что он делает, и он хорошо читается в исходном коде.

object.With("My new item as well");

Или вы добавляете "Вместе" с этим .. :)

object.AlongWith("this new item");
48
6.02.2009 21:02:38
+1. «WITH» - это инфиксный оператор в SETL, который делает то же самое. Если SETL использует это, то это должно быть правильно :-)
finnw 26.06.2009 12:51:58
Бах ... Кто больше использует VB? :) Эээ ... Оппс ... Это было вслух? хех .. Но, нет, со всей серьезностью, поэтому я рассмотрел «AlongWith», который бы убрал проблему VB. Есть только около миллиона различных способов, которыми он мог бы пойти с этим ... Я имею в виду, даже безумные, такие как: object.Plus () или Object.ExistingPlus () ... и т.д ... Это чертовски хороший вопрос, он опубликовано, однако ... хе ..
LarryF 24.11.2009 03:24:57

Я бы пошел с минусами по одной простой причине: это означает именно то, что вы хотите.

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

  2. Тот факт, что это было бы «бессмысленно» для людей без опыта FP, на самом деле является большим преимуществом. Как вы указали, все остальные слова, которые вы нашли, уже имеют какое-то значение, и это значение немного отличается или неоднозначно. Новая концепция должна иметь новое слово (или в этом случае старое). Я предпочел бы, чтобы кто-то посмотрел определение «Минусы», чем предположил, что он неправильно знает, что делает Ад.

  3. Другие операции, заимствованные из функциональных языков, часто сохраняют свои оригинальные имена без явных катастроф. Я не видел никакого толчка, чтобы придумать синонимы для «map» и «lower», которые звучат более знакомо не-FPers, и при этом я не вижу никакой выгоды от этого.

(Полное раскрытие: я программист на Лиспе, так что я уже знаю, что означает «Против».)

119
6.02.2009 21:03:37
Не забывайте, что обнаружение важно, хотя - если я наберу «testSuite». и посмотрите на список методов, я хотел бы увидеть метод, который предлагает правильную вещь. Я, вероятно, не буду искать бессмысленное (для меня) имя на случайности, это то, что я хочу.
Jon Skeet 6.02.2009 21:09:40
Если бы я чувствовал себя странно, я бы создал метод Add, который просто вызывал бы исключение с message = "Использовать Cons для добавления в ImmutableList". :-)
Ken 9.02.2009 18:12:14
Никто не убьет, если прочтет несколько строк комментариев, объясняющих, почему это имя, и ссылается на, скажем, Abelson & Sussman «Структура и интерпретация компьютерных программ».
John R. Strohm 7.02.2010 16:25:27
Традиционно минусы добавляют в начале, а не в конце. Так что это потенциально вводящее в заблуждение название для описанного метода.
walkytalky 23.04.2010 15:02:48
Просто чтобы сохранить следующего неработающего программиста щелчком или 3 ... en.wikipedia.org/wiki/Cons из слова «конструировать», выражение «превратить х в у» означает создание нового объекта с помощью ( минусы ху)
Myster 26.05.2010 23:17:10

.Trail подразумевает, что очень четкое понимание списка не изменилось, этот объект отстает от списка, он не был добавлен к нему.

var list = new ImmutableList<string>().Trail("Hello");
                                      .Trail("immutable");
                                      .Trail("word");
0
6.02.2009 21:09:57

Может быть, есть некоторые слова, которые больше меня помнят, когда я делал копию и добавлял к ней что-то, а не изменял экземпляр (например, «Конкатенация»). Но я думаю, что иметь некоторую симметрию для этих слов для других действий было бы тоже хорошо. Я не знаю подобного слова для «Удалить», которое я думаю такого же типа, как «Конкатенация». «Плюс» звучит немного странно для меня. Я не ожидал бы, что это будет использоваться в нечисловом контексте. Но это может также исходить из моего не английского языка.

Может быть, я бы использовал эту схему

AddToCopy
RemoveFromCopy
InsertIntoCopy

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

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

Add 1 to 2 and you get 3

Ну, конечно, 2 остается 2, и вы получите новый номер. Речь идет о двух числах, а не о списке и элементе, но я думаю, что у него есть некоторая аналогия. На мой взгляд, addэто не обязательно означает, что вы что-то мутируете. Я, конечно, понимаю вашу мысль, что наличие одинокого оператора, содержащего только « addа» и не использующего возвращенный новый объект, не выглядит ошибочным. Но теперь я тоже некоторое время думал об этой идее использования другого имени, кроме «добавить», но я просто не могу придумать другое имя, не заставив меня задуматься «хм, мне нужно было бы взглянуть на документацию, чтобы узнать, что речь идет о «потому что его имя отличается от того, что я ожидал бы назвать« добавить ». Просто какая-то странная мысль об этом из litb, не уверен, что это имеет смысл вообще :)

5
6.02.2009 22:33:36
Но копия не всегда необходима в неизменной коллекции. Возьмите двоичное дерево, например. Добавление нового корня не требует копирования, просто новое значение, где одним из листьев является старое дерево
JaredPar 6.02.2009 21:21:42
KISS - Если бы в именовании начали указываться детали реализации, все имена методов стали бы слишком длинными. «Добавить» достаточно просто и делает свою работу.
mP. 7.02.2009 07:42:09
@mP: Опять же, вы используете фразу «детали реализации» таким образом, который я считаю неподходящим. Будь то связанный список или массив под капотом - деталь реализации . Я мог бы изменить реализацию, не меняя API. Неизменный аспект не является деталью реализации.
Jon Skeet 8.02.2009 20:22:27
правильно. JaredPar, но я думаю , что это тоже не важно , является ли на самом деле копирует дерево или просто использует существующее дерево и использовать его в качестве листа для нового дерева вернулись. Я имею в виду, это просто деталь реализации. это то же самое для (я полагаю) операции подстроки для строкового класса Java.
Johannes Schaub - litb 8.02.2009 20:50:16

"Добавить()"

Тот факт, что он возвращает новый список, не имеет значения, что является реализацией, раскрытой подписью. Основное действие, которое выполняет метод, это «добавление» нового элемента в список. Как или что он deos или возвращает не должно быть частью имени метода. Если бы метод был синхронизирован, это повлияло бы на имя метода - "synchronizedAdd ()" ??? - конечно, нет.

Классы, такие как String, которые следуют за шаблоном возможных мутантов, все еще имеют действительно простые имена методов - ни один из них не является составным словом.

0
6.02.2009 21:14:48
а) струна смущает людей; б) подпись не показывает немутации: см. StringBuilder.Append. Дело в том, что метод не добавляет новый элемент в этот список; он создает новый список с дополнительным элементом. Я не верю, что «Добавить» проясняет это.
Jon Skeet 6.02.2009 21:22:15
Я также оспариваю идею, что это «деталь реализации». Для меня детали реализации - это то, что можно в значительной степени игнорировать - здесь, если вы проигнорируете это и предположите, что он работает как изменяемый список, вы почти наверняка ошибетесь.
Jon Skeet 6.02.2009 21:22:55
(Я не хочу казаться неблагодарным только потому, что я не согласен, кстати - большое спасибо за ответ!)
Jon Skeet 6.02.2009 21:27:21
Факт, что это возвращает новый список, является всем смыслом. Если вы изменили, то "b = a.Add (x);" может даже не скомпилироваться, и правильный код просто "a.Add (x);". Если вы не мутируете, то "a.Add (x);" все равно будет компилироваться, но на самом деле это просто неоперация.
Wedge 7.02.2009 00:28:54
@Jon Разработчики должны иметь некоторый уровень конкуренции и понимать, что происходит с так называемыми методами-мутаторами в неизменяемых классах. Учитывая, что мы знаем, что String является неизменным, становится очевидным, что любые методы-мутаторы возвращают новые String ...
mP. 7.02.2009 06:36:29

В таких ситуациях я обычно иду Concat. Это обычно подразумевает для меня, что создается новый объект.

var p = listA.Concat(listB);
var k = listA.Concat(item);
130
6.02.2009 21:22:32
Это то, что я использую, потому что это то, что использует System.Linq.Enumerable - решение уже принято. :) Я не могу быть единственным человеком, который определил свою собственную перегрузку расширения Concat в IEnumerable, чтобы принять одно значение для добавления.
Daniel Earwicker 23.06.2009 20:04:31
+1 Это правильный ответ для поддержания согласованности имен в рамках.
Sam Harwell 7.02.2010 18:23:02
Если я не пропустил это, System.Linq.Enumerable (и Linq в целом) использует Concat () только для «sequence + sequence», а не «item + sequence». Проблема в том, что кто-то «может ожидать, что он добавит два списка вместе, а не добавит одно значение в другой список», был явно указан как причина не использовать один из других оригинальных параметров.
Ssswift 11.01.2018 01:14:39

Я думаю, что это может быть одной из тех редких ситуаций, когда допустимо перегрузить +оператора. В математической терминологии мы знаем, что +это не добавляет что-то к концу чего-то другого. Он всегда объединяет два значения вместе и возвращает новое результирующее значение.

Например, очевидно, что когда вы говорите,

x = 2 + 2;

результирующее значение х равно 4, а не 22.

По аналогии,

var empty = new ImmutableList<string>();
var list1 = empty + "Hello";
var list2 = list1 + "immutable";
var list3 = list2 + "word";

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

В противном случае я бы просто назвал функцию Plus ().

27
6.02.2009 21:35:24
Что если у вас есть общий список, к которому вы могли бы законно добавить целое число (скажем) или другой список целых чисел? Тогда это использование + будет конфликтовать с конкатенацией.
finnw 26.06.2009 12:53:43
@finnw: я не понимаю твою точку зрения. Со списком я всегда ожидал, что + будет означать добавление, добавляете ли вы один элемент или несколько.
Bill the Lizard 26.06.2009 12:59:16
Для API многократного использования неплохо также иметь именованный метод, если кто-то использует ваш класс из языка без перегрузки операторов.
Neil 22.12.2009 20:50:30
«добавляете ли вы один элемент или несколько» - что, если вы хотите добавить список как один элемент? то есть, [1] + 2 = [1,2]но [1] + [2] = [1,[2]]. То, что вы предлагаете, - это непоследовательное поведение. Вероятно, поэтому Python не позволяет вам добавлять один элемент таким способом.
mpen 7.08.2010 01:29:13
Что ж, в статически типизированном языке, таком как C #, вы можете сказать, какой тип элементов списка, будь то список списков или список элементов, так что вы можете использовать тип, чтобы решить, добавлять ли один элемент, который является списком, или объединять два списка.
Dobes Vandermeer 18.05.2014 05:28:42

Во-первых, интересная отправная точка: http://en.wikipedia.org/wiki/Naming_conventions_(programming) ... В частности, проверьте ссылки «См. Также» внизу.

Я за Плюс или А, в равной степени.

Плюс и А являются математическими в этимологии. Таким образом, оба обозначают математическую операцию; оба дают выражение, которое естественно читается как выражения, которые могут преобразовываться в значение, которое соответствует методу, имеющему возвращаемое значение. Andнесет дополнительную логическую коннотацию, но оба слова применяются интуитивно к спискам. Addобозначает действие, выполняемое над объектом, что противоречит неизменной семантике метода.

Оба коротки, что особенно важно, учитывая примитивность операции. Простые, часто выполняемые операции заслуживают более коротких имен.

Выражение неизменной семантики - это то, что я предпочитаю делать через контекст. То есть, я бы скорее подразумевал, что весь этот блок кода имеет функциональное ощущение; Предположим, что все неизменно. Это может быть только я, однако. Я предпочитаю неизменность, чтобы быть правилом; если это сделано, то сделано много в одном и том же месте; изменчивость является исключением.

9
6.02.2009 21:30:17

Добавлен (), Добавлен ()

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

Кроме того, поскольку изменяющиеся имена методов часто являются глаголами настоящего времени, это относится к большинству случаев, требующих неизменного имени метода, с которыми вы сталкиваетесь. Например, в неизменяемом стеке есть методы «push» и «popped».

18
6.02.2009 21:46:31
Python также использует это соглашение. Например, встроенные функции reversed () и sorted ().
Joe 27.12.2010 04:17:47

Как насчет Chain () или Attach ()?

8
6.02.2009 21:48:32
Присоединение наверняка звучит как мутирование. Может быть, WithAttached будет мудрее, но очень близок к WithAdded, о котором говорилось выше.
TheBlastOne 10.08.2011 22:46:49
Забавно, сколько раз "цепочка" упоминается при описании того, что пытается с этим сделать. (5 раз), но не предлагается в качестве предложения! Это первое, на что я наткнулся visualthesaurus.com(без принадлежности), когда я искал concatenate.
cod3monk3y 28.01.2014 20:27:34

2 предложения:

«Свободная» функция:

Foo f = new Foo(whatever);
Foo fPlusSomething = Foo.Concat(f, something);

Перегрузка конструктора (которая, в некотором смысле, является вариацией темы «свободная функция»):

Foo f = new Foo(whatever);
Foo fPlusSomething = new Foo(f, something);
2
6.02.2009 22:18:45

Как насчет помощника , помощника или соития , для тех, кто придерживается. С точки зрения размножения млекопитающие обычно считаются неизменными.

Собираюсь выбросить Союз там тоже. Заимствовано из SQL.

6
6.02.2009 22:52:04
+1 за союз. Я, однако, заимствую это непосредственно из теории множеств. :-)
Christoffer Lette 22.10.2009 20:14:44
Разве SQL не получает большую часть своей терминологии из теории множеств?
Jason D 27.11.2009 04:33:48
Кроме того, Union подразумевает различие. Если вы хотите включить дубликаты (по крайней мере, в TSQL), вы должны явно использовать Union All.
hemp 4.06.2010 18:06:14

Join кажется уместным.

13
6.02.2009 22:42:17