Яке найкраще ім’я для немутуючого методу "додати" для незмінної колекції?

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

Припустимо, у мене є незмінний тип списку. Він має операцію, Foo(x)яка повертає новий незмінний список із вказаним аргументом як додатковий елемент в кінці. Отже, для складання списку рядків зі значеннями "Привіт", "незмінний", "світ" ви можете написати:

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");

Моє запитання: яке найкраще ім’я для Фоо?

EDIT 3 : Як я виявив пізніше, назва типу може насправді не бути ImmutableList<T>, що робить позицію зрозумілою. Уявіть собі, натомість, що це TestSuiteі що це незмінне, оскільки вся структура, до якої вона входить, незмінна ...

(Кінець редагування 3)

Варіанти, які я придумав поки що:

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

Критерії, які я використовую для вибору:

• Створює правильне враження про результат виклику методу (тобто, це вихідний список із додатковим елементом)
• Зробити це максимально зрозумілим, що він не мутує існуючий список
• Звучить розумно, коли це пов'язано разом, як у другому прикладі вище

Будь ласка, запитайте детальніше, якщо я не даю про себе зрозуміти ...

EDIT 1: Ось мої міркування для вважаючи за краще , Plusщоб Add. Розглянемо ці два рядки коду:

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

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

EDIT 2: Причини не подобається Додати.

Ефективні різні відповіді: "Ідіть з Add. Ось що і DateTimeробить, і Stringє Replaceметоди тощо, які не роблять незмінність очевидною". Я згоден - тут є пріоритет. Тим НЕ менше, я бачив багато людей називають DateTime.Addабо String.Replaceй очікувати мутації . Є безліч питань групи новин (і, мабуть, ТАК, якщо я викопаю), на які відповідає "Ви ігноруєте значення повернення 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>:)

У таких ситуаціях, як правило, я йду з цим Concat. Зазвичай для мене означає, що створюється новий об’єкт.

var p = listA.Concat(listB);
var k = listA.Concat(item);

Я б пішов із мінусами з однієї простої причини: це означає саме те, що ти хочеш.

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

2. Те, що це було б "безглуздо" для людей, які не мають досвіду ПП, насправді є великою перевагою. Як ви зазначали, всі інші знайдені вами слова вже мають певне значення, і це значення є дещо іншим або неоднозначним. У новому понятті має бути нове слово (або в цьому випадку старе). Я вважаю за краще, щоб хтось шукав визначення мінусів, ніж припускати неправильно, що він знає, що робить Add.

3. Інші операції, запозичені з функціональних мов, часто зберігають свої оригінальні назви, без явних катастроф. Я не бачив жодного поштовху придумати синоніми "карта" та "зменшити", які звучать більш звично для не-FPers, і я не бачу ніякої користі від цього.

(Повне розкриття: Я програміст Ліспа, тому я вже знаю, що означає Мінуси.)

Насправді мені подобається And, особливо ідіоматично. Особливо мені сподобається, якби у вас було статичне властивість лише для перегляду порожнього списку, і, можливо, зробити конструктор приватним, так що вам завжди доведеться будувати з порожнього списку.

var list = ImmutableList<string>.Empty.And("Hello")
                                      .And("Immutable")
                                      .And("Word");

Кожного разу, коли я перебуваю в варенні з номенклатурою, я забиваю інтербети.

thesaurus.com повертає це для "додати":

Визначення: примикати, збільшувати; зробити додатковий коментар

Синоніми: афікс, додаток, анте, додати, збільшити, яловичину, збільшити, наростити, заряджати, продовжувати, кидатись, фігурувати, вилуплювати, нагрівати, походити, підходити, зачіпляти, зачіпляти, підключити з, включити, підключити, джаз вгору, об'єднатися разом, колодка, парламент, косичка, підключити, залити його, відповісти, бігти вгору, сказати далі, ляпати, сніжний ком, суп, пришвидшити, шип, піднятися, доповнювати, підсолоджувати, приставляти, мітити

Мені подобається звук Adjoinабо, простіше кажучи Join. Це те, що ти робиш, правда? Метод також може бути застосований до приєднання інших ImmutableList<>осіб.

Особисто мені подобається .With (). Якби я використовував об’єкт, прочитавши документацію або коментарі до коду, було б зрозуміло, що він робить, і він зчитує нормально у вихідному коді.

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

Або ви додаєте "Разом" з ним .. :)

object.AlongWith("this new item");

В кінцевому підсумку я пішов з Add для всіх своїх незмінних колекцій у BclExtras . Причина в тому, що це легко передбачувана назва. Я не так хвилююся, що люди плутають додаток з мутуючим додаванням, оскільки ім'я типу з префіксом Immutable.

Деякий час я розглядав мінуси та інші назви функціональних стилів. Врешті-решт я знизив їх, бо вони не так добре відомі. Звичайно, функціональні програмісти зрозуміють, але вони не більшість користувачів.

Інші імена: ви згадали:

• Плюс: я бажаю / миюсь на цьому. Для мене це не відрізняє це як не мутаційну операцію більше, ніж Add
• З: Викличе проблеми з VB (призначений каламбур)
• Перевантаження оператора: проблема виявлення може бути проблемою

Я розглядав варіанти:

• Concat: String's є незмінними і використовують це. На жаль, це дійсно добре для додавання до кінця
• CopyAdd: скопіювати що? Джерело, список?
• AddToNewList: Можливо, це хороший список. А як щодо колекції, стека, черги тощо ...

На жаль, насправді, здається, немає слова

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

Це стає ще більш дивним, якщо розглядати колекції, крім List. Візьмемо для прикладу стек. Навіть програмісти першого року можуть сказати вам, що в стеках є пара методів Push / Pop. Якщо ви створюєте ImmutableStack і даєте йому зовсім інше ім’я, давайте назвати його Foo / Fop, ви тільки що додали більше роботи для використання вашої колекції.

Редагувати: відповідь на Plus Edit

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

list.Minus(obj);

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

Я бачу аргумент сайту виклику. Це робить більш зрозумілим з точки зору одного виразу. Але в контексті всієї функції це видається непотрібним.

Редагувати 2

Погодьтеся, що String.Concat і DateTime.Add, безумовно, збентежили людей. Я бачив, як кілька дуже яскравих програмістів потрапили на цю проблему.

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

У ImmutableList немає такої проблеми, оскільки назва визначає її поведінку. Ви можете стверджувати, що люди не знають, що таке незмінне, і я думаю, що це також справедливо. Я, звичайно, не знав цього приблизно до 2 року в коледжі. Але у вас є те саме питання з будь-яким ім'ям, яке ви виберете замість Add.

Редагувати 3: Що з типами типу TestSuite, які незмінні, але не містять цього слова?

Я думаю, що це приводить додому ідею, що ви не повинні вигадувати нові назви методів. А саме тому, що явно є прагнення зробити типи непорушними, щоб полегшити паралельні операції. Якщо ви зосередитесь на зміні назви методів для колекцій, наступним кроком стануть мутаційні назви методів для кожного використовуваного типу, який є незмінним.

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

Тепер, як можна визначити TestSuite як незмінний? Я думаю, що в сучасних умовах існує кілька способів

1. Префікс з Immutable: ImmutableTestSuite
2. Додайте атрибут, який описує рівень Імутаблітії. Це, звичайно, менш відкрито
3. Не багато іншого.

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

Я думаю, що це може бути однією з тих рідкісних ситуацій, коли допустимо перевантажувати +оператора. У математичній термінології ми знаємо, що +не додає щось до кінця чогось іншого. Він завжди поєднує два значення разом і повертає нове отримане значення.

Наприклад, інтуїтивно очевидно, що коли ти кажеш

x = 2 + 2;

отримане значення x дорівнює 4, а не 22.

Аналогічно

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

має чітко визначити, що має містити кожна змінна. Повинно бути зрозуміло, що в останньому рядку list2це не змінюється , а замість цього list3присвоюється результат додавання "слова" до list2.

В іншому випадку я б просто назвав функцію Plus ().

Щоб бути максимально зрозумілим, можливо, ви захочете піти з дурнем CopyAndAddабо чимось подібним.

Я б назвав це Extend () або, можливо, ExtendWith (), якщо ви відчуваєте, що справді багатослівний.

Розширення означає додавання чогось іншого, не змінюючи цього. Я думаю, що це дуже актуальна термінологія в C #, оскільки це схоже на поняття методів розширення - вони "додають" новий метод до класу, не "торкаючись" самого класу.

В іншому випадку, якщо ви дійсно хочете підкреслити, що ви взагалі не змінюєте оригінальний об'єкт, використання якогось префікса типу Get- мені здається неминучим.

Додано (), додано ()

Мені подобається використовувати минулий час для операцій над незмінними об'єктами. Він передає думку про те, що ви не змінюєте початковий об'єкт, і його легко розпізнати, коли ви його бачите.

Крім того, оскільки назви методів, що мутують, часто є дієсловами, що перебувають у напруженому часі, він застосовується до більшості випадків, у яких ти потребуєш незмінний метод-ім'я. Наприклад, незмінний стек має методи "висунутий" і "вискочив".

Мені подобається пропозиція mmyers від CopyAndAdd . Відповідно до теми "мутації", можливо, ви могли б перейти з Bud (безстатеве розмноження), Grow , Replicate або Evolve ? =)

EDIT: Щоб продовжити мою генетичну тему, як щодо Procreate , маючи на увазі, що створюється новий об’єкт, який базується на попередньому, але додається щось нове.

Це, мабуть, розтягнення, але в Рубі є часто використовувані позначення для розрізнення: addне мутує; add!мутує. Якщо це поширена проблема у вашому проекті, ви можете зробити це теж (не обов'язково з не алфавітними символами, але послідовно використовуючи позначення для позначення методів, що мутують / не мутують).

Join здається доречним.

Можливо, плутанина випливає з того, що потрібно дві операції в одній. Чому б не розділити їх? Стиль DSL:

var list = new ImmutableList<string>("Hello");
var list2 = list.Copy().With("World!");

Copyповерне проміжний об'єкт, це змінна копія оригінального списку. Withповерне новий незмінний список.

Оновлення:

Але проміжна колекція, що змінюється, не є гарним підходом. Проміжний об'єкт повинен міститися в Copyоперації:

var list1 = new ImmutableList<string>("Hello");
var list2 = list1.Copy(list => list.Add("World!"));

Тепер Copyоперація бере делегата, який отримує список, що змінюється, щоб він міг контролювати результат копіювання. Це може зробити набагато більше, ніж додавання елемента, як-от видалення елементів або сортування списку. Він також може бути використаний в ImmutableListконструкторі для складання початкового списку без посередницьких незмінних списків.

public ImmutableList<T> Copy(Action<IList<T>> mutate) {
  if (mutate == null) return this;
  var list = new List<T>(this);
  mutate(list);
  return new ImmutableList<T>(list);
}

Тепер немає можливості неправильного тлумачення з боку користувачів, вони, природно, потраплять у яму успіху .

Ще одне оновлення:

Якщо ви все ще не любите згадку про змінний список, навіть зараз, коли він міститься, ви можете створити об'єкт специфікації, який буде визначати або сценарій , як операція копіювання перетворить його список. Використання буде таким же:

var list1 = new ImmutableList<string>("Hello");
// rules is a specification object, that takes commands to run in the copied collection
var list2 = list1.Copy(rules => rules.Append("World!"));

Тепер ви можете бути творчими з іменами правил, і ви можете лише розкрити функціонал, який ви хочете Copyпідтримувати, а не всі можливості програми IList.

Для використання ланцюга можна створити розумний конструктор (який, звичайно, не використовуватиме ланцюжок):

public ImmutableList(params T[] elements) ...

...

var list = new ImmutableList<string>("Hello", "immutable", "World");

Або використовувати того ж делегата в іншому конструкторі:

var list = new ImmutableList<string>(rules => 
  rules
    .Append("Hello")
    .Append("immutable")
    .Append("World")
);

Це передбачає, що rules.Appendметод повертається this.

Ось як це виглядатиме з вашим останнім прикладом:

var suite = new TestSuite<string, int>(x => x.Length);
var otherSuite = suite.Copy(rules => 
  rules
    .Append(x => Int32.Parse(x))
    .Append(x => x.GetHashCode())
);

Кілька випадкових думок:

• ImmutableAdd ()
• Додати ()
• Конструктор ImmutableList <T> (ImmutableList <T> originalList, T newItem)

DateTime в C # використовує Додати. То чому б не використати те саме ім’я? Поки користувачі вашого класу розуміють, що клас непорушний.

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

Я не думаю, що англійська мова дозволить вам наводити незмінність безпомилково під час використання дієслова, що означає те саме, що і "Додати". "Плюс" майже це робить, але люди все ж можуть помилитися.

Єдиний спосіб заборонити вашим користувачам помиляти об’єкт на щось змінне - це зробити його явним або через ім'я самого об'єкта, або через ім'я методу (як у паралельних варіантах типу "GetCopyWith" або "CopyAndAdd").

Тому просто зайдіть з улюбленим "Плюсом".

По-перше, цікавий вихідний пункт: http://en.wikipedia.org/wiki/Naming_conventions_(programming) ... Зокрема, перевірте посилання "Дивіться також" внизу.

Я виступаю за Плюс або І, фактично однаково.

Плюс та І обидва математики базуються в етимології. Отже, обидва означають математичну операцію; обидва дають вираз, який природним чином читається як вирази, які можуть перетворитися на значення, що відповідає методу, що має зворотне значення. Andмає додаткову логічну конотацію, але обидва слова інтуїтивно застосовуються до списків. Addконотує дію, що виконується на об'єкті, що суперечить незмінній семантиці методу.

Обидва вони короткі, що особливо важливо з огляду на примітивність операції. Прості, часто виконувані операції заслуговують на коротші назви.

Висловлення незмінної семантики - це те, що я вважаю за краще робити через контекст. Тобто я скоріше просто маю на увазі, що весь цей блок коду має функціональне відчуття; припустимо, що все незмінне. Це, можливо, просто я. Я вважаю за краще незмінність як правило; якщо це зроблено, робиться багато в тому ж місці; Мінливість є винятком.

Як щодо Chain () або Attach ()?

Я віддаю перевагу Плюс (і Мінус). Їх легко зрозуміти і відображати безпосередньо в операціях, що включають добре відомі незмінні типи (числа). 2 + 2 не змінює значення 2, воно повертає нове, однаково незмінне значення.

Деякі інші можливості:

Сплайс ()

Трансплантат ()

Бетон ()

Як щодо матерів , матерів чи коїтусів для тих, хто перебуває. З точки зору розмноження ссавці, як правило, вважаються непорушними.

Збираюся викинути Союз і там. Позичені у SQL.

Мабуть, я перший Obj-C / какао, який відповів на це питання.

NNString *empty = [[NSString alloc] init];
NSString *list1 = [empty stringByAppendingString:@"Hello"];
NSString *list2 = [list1 stringByAppendingString:@"immutable"];
NSString *list3 = [list2 stringByAppendingString:@"word"];

З цим не збирається вигравати будь-які ігри в гольф.

Я думаю, що "Додати" або "Плюс" звучить чудово. Назви самого списку має бути достатньо, щоб передати незмінність списку.

Можливо, є кілька слів, які мені більше запам'ятовують копію та додають до цього речі замість того, щоб мутувати екземпляр (наприклад, "Concatenate"). Але я думаю, що було б добре мати симетричність цих слів для інших дій. Я не знаю подібного слова "Видалити", яке я думаю, такого ж типу, як "З'єднати". "Плюс" для мене звучить трохи дивно Я б не очікував, що він буде використовуватися в нечисловому контексті. Але це могло виникнути і з мого неанглійського походження.

Можливо, я б скористався цією схемою

AddToCopy
RemoveFromCopy
InsertIntoCopy

Однак у них є свої проблеми, коли я думаю про це. Можна подумати, що вони щось видаляють або додають щось до наведеного аргументу. Не впевнений у цьому взагалі. Ці слова теж не грають приємно, якщо я прикутий. Занадто багатослівний для набору.

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

Add 1 to 2 and you get 3

Ну, звичайно, 2 залишається 2, і ви отримуєте нове число. Йдеться про два числа, а не про список та елемент, але я думаю, що це має певну аналогію. На мою думку, addце не означає, що ти щось мутуєш. Я, безумовно, бачу ваше твердження, що мати самотнє твердження, що містить просто addі не використовувати повернутий новий об’єкт, не виглядає баггі. Але зараз я також подумав деякий час про цю ідею використання іншого імені, ніж "додати", але я просто не можу придумати інше ім'я, не змушуючи мене думати "хм, мені потрібно було б переглянути документацію, щоб знати, що мова йде про "тому, що його назва відрізняється від того, що я б очікував назвати" додати ". Просто деякі дивні думки про це з лампа, не впевнені, що це має сенс взагалі :)

Дивлячись на http://thesaurus.reference.com/browse/add та http://thesaurus.reference.com/browse/plus, я знайшов виграш та прикріплення, але не знаю, наскільки вони мають на увазі немутацію.

Я думаю, що це Plus()і, Minus()або, альтернативно Including(), Excluding()є розумним, коли мається на увазі незмінна поведінка.

Однак жоден вибір імен не зробить це абсолютно зрозумілим для всіх, тому я особисто вважаю, що хороший коментар документа xml пройде дуже довгий шлях. VS кидає це вам прямо в обличчя, коли ви пишете код в IDE - їх важко ігнорувати.

Append- тому що зауважте, що назви System.Stringметодів говорять про те, що вони мутують екземпляр, але вони цього не роблять.

Або мені дуже подобається AfterAppending:

void test()
{
  Bar bar = new Bar();
  List list = bar.AfterAppending("foo");
}

list.CopyWith(element)

Як і Smalltalk :)

А також, list.copyWithout(element)що видаляє всі виникнення елемента, що найкорисніше, коли використовується list.copyWithout(null)для видалення невстановлених елементів.

Я б пішов на Add, тому що я бачу перевагу кращого імені, але проблема полягає в тому, щоб знайти різні назви для кожної іншої непорушної операції, яка може зробити клас зовсім незнайомим, якщо це має сенс.