Qual è il nome migliore per un metodo "add" non mutante in una collezione immutabile?

Ci scusiamo per il titolo waffly - se potessi trovare un titolo conciso, non avrei dovuto porre la domanda.

Supponiamo che io abbia un tipo di elenco immutabile. Ha un'operazione Foo(x)che restituisce un nuovo elenco immutabile con l'argomento specificato come elemento aggiuntivo alla fine. Quindi, per creare un elenco di stringhe con valori "Hello", "immutable", "world" puoi scrivere:

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

(Questo è il codice C #, e sono molto interessato a un suggerimento C # se ritieni che la lingua sia importante. Non è fondamentalmente una domanda di lingua, ma gli idiomi della lingua possono essere importanti.)

L'importante è che gli elenchi esistenti non vengano modificati da Foo, quindi empty.Countrestituirebbe comunque 0.

Un altro modo (più idiomatico) per arrivare al risultato finale sarebbe:

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

La mia domanda è: qual è il nome migliore per Foo?

EDIT 3 : Come rivelerò più avanti, il nome del tipo potrebbe non essere effettivamente ImmutableList<T>, il che rende chiara la posizione. Immagina invece che sia TestSuitee che sia immutabile perché l'intero quadro di cui fa parte è immutabile ...

(Fine della modifica 3)

Opzioni che ho escogitato finora:

• Add: comune in .NET, ma implica la mutazione dell'elenco originale
• Cons: Credo che questo sia il nome normale nei linguaggi funzionali, ma privo di significato per coloro che non hanno esperienza in tali linguaggi
• Plus: il mio preferito finora, non implica mutazione per me . Apparentemente questo è usato anche in Haskell ma con aspettative leggermente diverse (un programmatore Haskell potrebbe aspettarsi di aggiungere due liste insieme invece di aggiungere un singolo valore all'altra lista).
• With: coerente con alcune altre convenzioni immutabili, ma non ha abbastanza la stessa "aggiunta" ad esso IMO.
• And: non molto descrittivo.
• Sovraccarico dell'operatore per +: non mi piace molto; In genere penso che gli operatori dovrebbero essere applicati solo a tipi di livello inferiore. Sono disposto a essere persuaso però!

I criteri che sto usando per scegliere sono:

• Fornisce l'impressione corretta del risultato della chiamata al metodo (ovvero che è l'elenco originale con un elemento aggiuntivo)
• Rende il più chiaro possibile che non muta l'elenco esistente
• Sembra ragionevole quando incatenati insieme come nel secondo esempio sopra

Si prega di chiedere maggiori dettagli se non mi sto chiarendo abbastanza ...

EDIT 1: Ecco il mio ragionamento per preferire Plusa Add. Considera queste due righe di codice:

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

Dal mio punto di vista (e questa è una cosa personale) quest'ultima è chiaramente buggy - è come scrivere "x + 5;" come una dichiarazione a sé stante. La prima riga sembra a posto, finché non ti ricordi che è immutabile. In effetti, il modo in cui l'operatore plus da solo non muta i suoi operandi è un altro motivo per cui Plusè il mio preferito. Senza il leggero fastidio del sovraccarico dell'operatore, fornisce comunque le stesse connotazioni, che includono (per me) la non mutazione degli operandi (o metodo target in questo caso).

EDIT 2: motivi per non gradire Aggiungi.

Diverse risposte sono effettivamente: "Vai con Aggiungi. Ecco cosa DateTimefa, e Stringha Replacemetodi ecc. Che non rendono evidente l'immutabilità." Sono d'accordo - qui c'è la precedenza. Tuttavia, ho visto un sacco di persone chiamano DateTime.Addo String.Replacee si aspettano la mutazione . Ci sono un sacco di domande sui newsgroup (e probabilmente SO se scavo in giro) a cui si risponde "Stai ignorando il valore di ritorno di String.Replace; le stringhe sono immutabili, viene restituita una nuova stringa".

Ora, dovrei rivelare una sottigliezza alla domanda: il tipo potrebbe non essere in realtà un elenco immutabile, ma un tipo immutabile diverso. In particolare, sto lavorando a un framework di benchmarking in cui aggiungi test a una suite e che crea una nuova suite. Potrebbe essere ovvio che:

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

non realizzerà nulla, ma diventa molto più oscuro quando lo cambi in:

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

Sembra che dovrebbe essere a posto. Considerando che questo, per me, rende più chiaro l'errore:

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

Sta solo chiedendo di essere:

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

Idealmente, vorrei che ai miei utenti non venisse detto che la suite di test è immutabile. Voglio che cadano nella fossa del successo. Questo potrebbe non essere possibile, ma mi piacerebbe provare.

Mi scuso per l'eccessiva semplificazione della domanda originale parlando solo di un tipo di elenco immutabile. Non tutte le raccolte sono auto-descrittive come ImmutableList<T>:)

In situazioni del genere, di solito vado con Concat. Ciò di solito implica per me che viene creato un nuovo oggetto.

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

Andrei con contro, per una semplice ragione: significa esattamente quello che vuoi che faccia.

1. Sono un grande fan di dire esattamente cosa intendo, soprattutto nel codice sorgente. Un principiante dovrà cercare la definizione di Contro solo una volta, ma poi leggerla e usarla mille volte. Trovo che, a lungo termine, sia meglio lavorare con sistemi che semplificano il caso comune, anche se il costo iniziale è leggermente più alto.

2. Il fatto che sarebbe "insignificante" per le persone senza esperienza FP è in realtà un grande vantaggio. Come hai sottolineato, tutte le altre parole che hai trovato hanno già un significato e quel significato è leggermente diverso o ambiguo. Un nuovo concetto dovrebbe avere una nuova parola (o in questo caso, una vecchia). Preferirei che qualcuno dovesse cercare la definizione di Contro, piuttosto che presumere erroneamente sappia cosa fa Add.

3. Altre operazioni prese in prestito da linguaggi funzionali spesso mantengono i loro nomi originali, senza apparenti catastrofi. Non ho visto alcuna spinta a trovare sinonimi di "mappa" e "ridurre" che suonano più familiari ai non FPer, né vedo alcun vantaggio nel farlo.

(Informativa completa: sono un programmatore Lisp, quindi so già cosa significa Contro.)

In realtà mi piace And, soprattutto in modo idiomatico. Mi piacerebbe particolarmente se tu avessi una proprietà di sola lettura statica per la lista vuota e forse rendi privato il costruttore, quindi devi sempre costruire dalla lista vuota.

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

Ogni volta che sono in difficoltà con la nomenclatura, raggiungo le interwebs.

thesaurus.com restituisce questo per "aggiungi":

Definizione: adiacente, aumentare; fare ulteriori commenti

Sinonimi: apporre, annettere, ante, aggiungere, aumentare, rinforzare, potenziare, aumentare, caricare, continuare, inserire, inserire, rimpolpare, riscaldare, aumentare, aumentare, agganciare, agganciare, agganciare con, include, jack up, jazz up, unisci insieme, pad, parlay, piggyback, plug in, pour it on, rispondi, corri, dì altro, schiaffi, snowball, soup up, speed up, spike, step up, supplemento, addolcimento, tack on, tag

Mi piace il suono di Adjoin, o più semplicemente Join. Questo è quello che stai facendo, vero? Il metodo potrebbe anche applicarsi all'unione di altri ImmutableList<>.

Personalmente, mi piace. Con (). Se stavo usando l'oggetto, dopo aver letto la documentazione o i commenti sul codice, sarebbe chiaro cosa fa, e legge ok nel codice sorgente.

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

Oppure aggiungi "Insieme" con esso .. :)

object.AlongWith("this new item");

Ho finito per andare con Aggiungi per tutte le mie collezioni immutabili in BclExtras . Il motivo è che è un nome facile e prevedibile. Non sono così preoccupato per le persone che confondono Aggiungi con un'aggiunta mutante poiché il nome del tipo ha il prefisso Immutable.

Per un po 'ho considerato i contro e altri nomi di stile funzionale. Alla fine li ho scontati perché non sono così famosi. Sicuramente i programmatori funzionali capiranno ma non sono la maggior parte degli utenti.

Altri nomi: hai menzionato:

• Inoltre: sono desideroso / lavaggio su questo. Per me questo non lo distingue come un'operazione non mutante più di Add
• Con: causerà problemi con VB (gioco di parole previsto)
• Sovraccarico dell'operatore: la rilevabilità sarebbe un problema

Opzioni che ho considerato:

• Concat: le stringhe sono immutabili e usano questo. Purtroppo è davvero buono solo per aggiungere alla fine
• CopyAdd: Copia cosa? La fonte, l'elenco?
• AddToNewList: forse un buon elenco. Ma che dire di una raccolta, stack, coda, ecc ...

Sfortunatamente non sembra esserci davvero una parola

1. Sicuramente un'operazione immutabile
2. Comprensibile per la maggior parte degli utenti
3. Rappresentabile in meno di 4 parole

Diventa ancora più strano se consideri raccolte diverse da Elenco. Prendi ad esempio Stack. Anche i programmatori del primo anno possono dirti che gli stack hanno una coppia di metodi Push / Pop. Se crei un ImmutableStack e gli dai un nome completamente diverso, chiamiamolo Foo / Fop, hai appena aggiunto più lavoro per loro per usare la tua collezione.

Modifica: risposta a Plus Edit

Vedo dove stai andando con Plus. Penso che un caso più forte sarebbe effettivamente meno per la rimozione. Se vedessi quanto segue mi chiederei sicuramente a cosa stia pensando il programmatore

list.Minus(obj);

Il problema più grande che ho con Plus / Minus o una nuova associazione è che sembra eccessivo. La collezione stessa ha già un nome distintivo, il prefisso Immutable. Perché andare oltre aggiungendo il vocabolario il cui intento è quello di aggiungere la stessa distinzione del prefisso immutabile già fatto.

Vedo l'argomento del sito di chiamata. Lo rende più chiaro dal punto di vista di una singola espressione. Ma nel contesto dell'intera funzione sembra non necessario.

Modifica 2

Concordo sul fatto che le persone siano state sicuramente confuse da String.Concat e DateTime.Add. Ho visto diversi programmatori molto brillanti colpire questo problema.

Tuttavia, penso che ImmutableList sia un argomento diverso. Non c'è nulla in String o DateTime che lo stabilisce come Immutabile per un programmatore. Devi semplicemente sapere che è immutabile tramite qualche altra fonte. Quindi la confusione non è inaspettata.

ImmutableList non ha questo problema perché il nome definisce il suo comportamento. Potresti sostenere che le persone non sanno cosa sia Immutabile e penso che sia anche valido. Di certo non lo sapevo fino al 2 ° anno al college. Ma hai lo stesso problema con qualsiasi nome tu scelga invece di Aggiungi.

Modifica 3: Che dire di tipi come TestSuite che sono immutabili ma non contengono la parola?

Penso che questo porti a casa l'idea che non dovresti inventare nuovi nomi di metodi. Vale a dire perché esiste chiaramente un impulso per rendere immutabili i tipi al fine di facilitare operazioni parallele. Se ti concentri sulla modifica del nome dei metodi per le raccolte, il passaggio successivo saranno i nomi dei metodi mutanti su ogni tipo che usi immutabile.

Penso che sarebbe uno sforzo più prezioso concentrarsi invece sul rendere identificabili i tipi come Immutabili. In questo modo è possibile risolvere il problema senza ripensare ogni modello di metodo di mutazione là fuori.

Ora come puoi identificare TestSuite come immutabile? Nell'ambiente odierno penso che ci siano alcuni modi

1. Prefisso con Immutable: ImmutableTestSuite
2. Aggiungi un attributo che descriva il livello di immutabilità. Questo è sicuramente meno rilevabile
3. Non molto altro.

La mia ipotesi / speranza è che gli strumenti di sviluppo inizieranno ad aiutare questo problema facilitando l'identificazione dei tipi immutabili semplicemente a vista (colore diverso, carattere più forte, ecc ...). Ma penso che questa sia la risposta oltre a cambiare tutti i nomi dei metodi.

Penso che questa possa essere una di quelle rare situazioni in cui è accettabile sovraccaricare l' +operatore. Nella terminologia matematica, sappiamo che +non aggiunge qualcosa alla fine di qualcos'altro. Combina sempre due valori insieme e restituisce un nuovo valore risultante.

Ad esempio, è intuitivamente ovvio che quando lo dici

x = 2 + 2;

il valore risultante di x è 4, non 22.

Allo stesso modo,

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

dovrebbe chiarire ciò che ogni variabile terrà. Dovrebbe essere chiaro che list2non è stato modificato nell'ultima riga, ma è invece list3assegnato il risultato dell'aggiunta della "parola" list2.

Altrimenti, vorrei solo nominare la funzione Plus ().

Per essere il più chiaro possibile, potresti voler andare con il wordier CopyAndAddo qualcosa di simile.

Lo chiamerei Extend () o forse ExtendWith () se ti senti davvero prolisso.

Estendere significa aggiungere qualcosa a qualcos'altro senza cambiarlo. Penso che questa sia una terminologia molto rilevante in C # poiché è simile al concetto di metodi di estensione: essi "aggiungono" un nuovo metodo a una classe senza "toccare" la classe stessa.

Altrimenti, se vuoi davvero sottolineare che non modifichi affatto l'oggetto originale, usare un prefisso come Get- mi sembra inevitabile.

Aggiunto (), aggiunto ()

Mi piace usare il tempo passato per operazioni su oggetti immutabili. Trasmette l'idea che non stai cambiando l'oggetto originale ed è facile riconoscerlo quando lo vedi.

Inoltre, poiché i nomi dei metodi mutanti sono spesso verbi al presente, si applica alla maggior parte dei casi immutabili di nome metodo necessario che si verificano. Ad esempio uno stack immutabile ha i metodi "pushed" e "popped".

Mi piace il suggerimento di mmyer di CopyAndAdd . In linea con un tema di "mutazione", forse potresti scegliere Bud (riproduzione asessuata), crescere , replicare o evolvere ? =)

EDIT: Per continuare con il mio tema genetico, che ne è di Procreate , sottintendendo che viene creato un nuovo oggetto che si basa su quello precedente, ma con qualcosa di nuovo aggiunto.

Questo è probabilmente un tratto, ma in Ruby c'è una notazione comunemente usata per la distinzione: addnon muta; add!muta. Se questo è un problema pervasivo nel tuo progetto, potresti farlo anche tu (non necessariamente con caratteri non alfabetici, ma usando costantemente una notazione per indicare metodi di mutazione / non mutazione).

Join sembra appropriato.

Forse la confusione deriva dal fatto che si vogliono due operazioni in una. Perché non separarli? Stile DSL:

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

Copyrestituirebbe un oggetto intermedio, ovvero una copia mutabile dell'elenco originale. Withrestituirebbe un nuovo elenco immutabile.

Aggiornare:

Ma avere una collezione intermedia e mutevole non è un buon approccio. L'oggetto intermedio dovrebbe essere contenuto Copynell'operazione:

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

Ora l' Copyoperazione richiede un delegato, che riceve un elenco modificabile, in modo che possa controllare l'esito della copia. Può fare molto di più che aggiungere un elemento, come rimuovere elementi o ordinare l'elenco. Può anche essere utilizzato nel ImmutableListcostruttore per assemblare l'elenco iniziale senza elenchi immutabili intermedi.

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

Ora non c'è possibilità di interpretazioni errate da parte degli utenti, che cadranno naturalmente nella fossa del successo .

Ancora un altro aggiornamento:

Se non ti piace ancora la menzione dell'elenco mutabile, anche ora che è contenuta, puoi progettare un oggetto di specifica, che specificherà , o script , come l'operazione di copia trasformerà il suo elenco. L'utilizzo sarà lo stesso:

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

Ora puoi essere creativo con i nomi delle regole e puoi solo esporre la funzionalità che vuoi Copysupportare, non le intere funzionalità di un IList.

Per l'utilizzo del concatenamento, puoi creare un costruttore ragionevole (che ovviamente non utilizzerà il concatenamento):

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

...

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

O usa lo stesso delegato in un altro costruttore:

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

Ciò presuppone che il rules.Appendmetodo ritorni this.

Ecco come sarebbe con il tuo ultimo esempio:

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

Alcuni pensieri casuali:

• ImmutableAdd ()
• Aggiungere()
• Costruttore ImmutableList <T> (ImmutableList <T> originalList, T newItem)

DateTime in C # usa Aggiungi. Quindi perché non usare lo stesso nome? Finché gli utenti della tua classe capiscono che la classe è immutabile.

Penso che la cosa chiave a cui stai cercando di ottenere che sia difficile da esprimere sia la non-valutazione, quindi forse qualcosa con una parola generativa, qualcosa come CopyWith () o InstancePlus ().

Non penso che la lingua inglese ti permetta di implicare l'immutabilità in modo inconfondibile mentre usi un verbo che significa la stessa cosa di "Aggiungi". "Plus" lo fa quasi, ma le persone possono ancora fare l'errore.

L'unico modo per impedire agli utenti di confondere l'oggetto con qualcosa di mutabile è renderlo esplicito, sia attraverso il nome dell'oggetto stesso o attraverso il nome del metodo (come con le opzioni dettagliate come "GetCopyWith" o "CopyAndAdd").

Quindi vai con il tuo preferito "Plus".

Innanzitutto, un interessante punto di partenza: http://en.wikipedia.org/wiki/Naming_conventions_(programming) ... In particolare, controlla i link "Vedi anche" in basso.

Sono a favore di Plus o And, effettivamente ugualmente.

Plus ed And sono entrambi basati sulla matematica in etimologia. Come tale, entrambi connotano operazioni matematiche; entrambi producono un'espressione che legge naturalmente come espressioni che possono risolversi in un valore, che si adatta al metodo che ha un valore di ritorno. Andporta una connotazione logica aggiuntiva, ma entrambe le parole si applicano intuitivamente agli elenchi. Addconnota l'azione eseguita su un oggetto, che è in conflitto con l'immutabile semantica del metodo.

Entrambi sono brevi, il che è particolarmente importante data la primitività dell'operazione. Le operazioni semplici eseguite di frequente meritano nomi più brevi.

Esprimere la semantica immutabile è qualcosa che preferisco fare tramite il contesto. Cioè, preferirei semplicemente implicare che l'intero blocco di codice ha un aspetto funzionale; supponiamo che tutto sia immutabile. Potrei essere io, comunque. Preferisco che l'immutabilità sia la regola; se è fatto, è fatto molto nello stesso posto; la mutabilità è l'eccezione.

Che ne dici di Chain () o Attach ()?

Preferisco Plus (e Meno). Sono facilmente comprensibili e mappano direttamente le operazioni che coinvolgono tipi immutabili ben noti (i numeri). 2 + 2 non cambia il valore di 2, restituisce un nuovo valore, altrettanto immutabile.

Alcune altre possibilità:

Splice ()

Corruzione()

Accrete ()

Che ne dici di mate , mateWith o coitus , per coloro che rimangono. In termini di riproduzione dei mammiferi sono generalmente considerati immutabili.

Andiamo a buttare fuori anche Union . Preso in prestito da SQL.

Apparentemente sono la prima persona Obj-C / Cocoa a rispondere a questa domanda.

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

Con questo non vincerò nessun gioco di golf con codice.

Penso che "Aggiungi" o "Plus" suona bene. Il nome dell'elenco stesso dovrebbe essere sufficiente per comunicare l'immutabilità dell'elenco.

Forse ci sono alcune parole che mi ricordano più di aver fatto una copia e di aggiungere cose a quella invece di mutare l'istanza (come "Concatenare"). Ma penso che avere una certa simmetria per quelle parole per altre azioni sarebbe bello avere anche. Non conosco una parola simile per "Rimuovi" che penso dello stesso tipo di "Concatenare". "Plus" mi suona un po 'strano. Non mi aspetto che venga utilizzato in un contesto non numerico. Ma ciò potrebbe anche provenire dal mio background non inglese.

Forse avrei usato questo schema

AddToCopy
RemoveFromCopy
InsertIntoCopy

Questi hanno i loro problemi però, quando ci penso. Si potrebbe pensare che rimuovano qualcosa o aggiungano qualcosa a un argomento dato. Non ne sono affatto sicuro. Penso che quelle parole non giochino neanche nel concatenarsi. Troppo prolisso per scrivere.

Forse userei semplicemente "Aggiungi" e anche gli amici. Mi piace come viene usato in matematica

Add 1 to 2 and you get 3

Bene, certamente, un 2 rimane un 2 e ottieni un nuovo numero. Si tratta di due numeri e non di un elenco e un elemento, ma penso che abbia qualche analogia. Secondo me, addnon significa necessariamente che muti qualcosa. Sicuramente vedo il tuo punto che avere una dichiarazione solitaria contenente solo un adde non usare il nuovo oggetto restituito non sembra buggy. Ma ora ho anche pensato un po 'di tempo a quell'idea di usare un nome diverso da "aggiungi" ma non riesco proprio a trovare un altro nome, senza farmi pensare "hmm, avrei bisogno di consultare la documentazione per sapere cosa si tratta di "perché il suo nome differisce da quello che mi aspetterei di essere chiamato" aggiungi ". Solo qualche strano pensiero su questo da litb, non sono sicuro che abbia senso :)

Guardando http://thesaurus.reference.com/browse/add e http://thesaurus.reference.com/browse/plus ho trovato guadagno e apposizione ma non sono sicuro di quanto implicino la non mutazione.

Penso che Plus()e Minus()o, in alternativa Including(), Excluding()siano ragionevoli a implicare un comportamento immutabile.

Tuttavia, nessuna scelta di denominazione lo renderà mai perfettamente chiaro a tutti, quindi credo personalmente che un buon commento sul documento xml andrebbe molto lontano qui. VS ti lancia questi in faccia quando scrivi il codice nell'IDE: sono difficili da ignorare.

Append- perché, nota che i nomi dei System.Stringmetodi suggeriscono che mutano l'istanza, ma non lo fanno.

O mi piace abbastanza AfterAppending:

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

list.CopyWith(element)

Come fa Smalltalk :)

Inoltre, list.copyWithout(element)ciò rimuove tutte le occorrenze di un elemento, che è molto utile quando viene utilizzato list.copyWithout(null)per rimuovere elementi non impostati.

Vorrei aggiungere Add, perché posso vedere il vantaggio di un nome migliore, ma il problema sarebbe quello di trovare nomi diversi per ogni altra operazione immutabile che potrebbe rendere la classe abbastanza sconosciuta se ciò ha senso.