-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename methods that return a new datastructure to not imply mutation #20
Comments
for adding the only one I like is I feel the same about the removing methods so I think |
My personal thoughts on this are: Adding
Reasons for rejecting the others:
Removing+1 omit or without
|
actually |
@jkroso: I love |
also, |
true |
There's the rub, i guess; to me it sounds less mutating than most verbs, but I could be alone in that. |
its not a bad name. can always add |
|
that's a consideration; but it is a terse and accurate discription; without suffers a little on the length side of things. mmm APIs; how complex they are - and yet how important. RE: |
A late-comer option: |
hmm... lets vote. +1 assoc/dissoc from me. I think its worth the new language |
a slightly unsure +1 assoc/dissoc from me too. ;) |
I really like merge/without. Though I still believe that union/disjunction describes the process perfectly, the latter isn't actually a nice API name though. You can always conj/disj though ;3 |
union is from set theory. to me it would suggest |
my bad I was thinking of intersection but still union is not an obvious name |
I think that neatly goes to show why union might be a barrier to adoption ;) |
@jkroso |
@killdream conj looks like a concat/push/cons op to me - i.e. adding something sequential, not associating w/ an associative array |
@killdream the problem though is what is the set. the key value pairs, the keys, or the values. |
@hughfdjackson it does everything in clojure. The name is basically |
@killdream us not being in clojure is almost exactly the crux of the debate ;) what would be clear en mass in javascript, and not a barrier to picking up? my hunch is 'not conj' |
From @mcameron: |
I am fond of 'without' - I think you need to find an opposite of that which isn't 'with'. It might be a present participle you're after. 'without' is a preposition, and many participles can also be used as prepositions: e.g. 'given', 'provided', 'assuming', 'barring', or perhaps even 'setting', 'having'... I think there's something about using present participles which implies non-mutation, so I reckon that's where you need to look for your answer. |
Again, the fact that omit reads like emit could be solved by using 'omitting', which to me signifies an absence of mutation |
I like |
@joeloverton One of the issues that I didn't throw in the ticket above initially (which I have now) is the need to balance the non-mutation sounding-ness of the method name with something terse enough to use all the time; I'm hoping that immutable will make immutable-by-default a pleasure to use. I think there's a significant difference between: var o = im.object({}).set({ x: 3 })
var o2 = o.set({ y: 3 }) and var o = im.object({}).setting{ x: 3 })
var o2 = o.setting({ y: 3 }) (ignoring the entirely contrived example for a mo; i hope :D). Looking at my own code, adding is far more common than removal, so a longer method name for removal may be a viable option. You're right that that tense does sound more immutable, though. |
After a few days of pondering (plus riding boris bikes), I've resolved to go for assoc/dissoc. I can't find a word that satisfies @joeloverton's suggestion of Assoc/dissoc have the following advantages:
Disadvantages:
Migration:
|
As a user, I want it to be clear that my code is intended for use with/is using immutable datastructures. I also don't want to have external code pass me a mutable object which my code will subsequently treat as immutable because it ducktypes identically.
I would also like these method names to be terse enough to be used consistently throughout a codebase.
Acceptance:
Suggestions:
The text was updated successfully, but these errors were encountered: