Rename ARC to Arc

[brson]

Arc's are yelling at me.

[bblum]

really? :\ I picked it that way 'cause it's an acronym. RWARC too. I guess it could stand to be RWArc.

It might do to have an entirely new name - "arc" has always felt kind of researcher-speak-y. Maybe SharedState for ARC, SharedMutableState for MutexARC, and RWSharedState for RWARC.

[brson]

I usually prefer to not do allcaps acronyms with camel case, like Url.

[bblum]

the thing i was afraid of when i camelcased the arc module was that someone else would come along before me and write Rwarc or RwArc, which would be terrible. I wouldn't mind it being RWArc I guess.

[graydon]

+1 for something involving "shared", and get rid of the "arc" moniker altogether. Perhaps SharedConst and SharedMut?

[graydon]

(keeping in mind that @ is being conceptually renamed to "managed")

[bblum]

Involving const in the name is tricky, since they both require T:const. Maybe something like SharedState and SharedLockedState.

I dunno, though. The more I think about it (while writing blog posts about it) the more I like how concise ARC and RWARC are as typenames. They take a while to understand, but they don't have the AbstractSingletonProxyFactoryBean problem. I like the idea that the sort of "primitive" concurrency types have snappy names - task, pipe, port, chan, arc, rwarc...

[jruderman]

How about just Shared for the const version? Shared<int> reads nicely.

[bstrie]

I'm a fan of Shared and SharedMut.

[brson]

I think Shared is not specific enough. There are a number of types involving atomic reference counting for different scenarios and we'll probably grow more.

[Seldaek]

I'd happily try and tackle the renames (ARC => Arc / RWARC => RWArc / MutexARC => MutexArc) if you can agree that this is the best? It seems like no other wording can be clear enough without being overly verbose. I personally like that ARC is weird enough that it forces you to look up what it means, but then it's quite memorable.

I think it would be good to fix them for consistency with other things (IpAddr, Url to name a few), because it's a pain when the case isn't consistently guessable.

That said, on the topic of consistency, I also see stuff like extra::sync::RWlock which should be RWLock if we follow this pattern I suppose? Similarly extra::sync::semaphore sounds like it should be Semaphore to me but maybe I'm missing something?

[bblum]

I personally prefer ARC to Arc, although it seems like our conventions have been shifting toward the initial-caps-only pattern overall, and it wouldn't be so bad. I definitely agree with preferring it to be memorable than autological.

The semaphore() consutrctor should be Semaphore::new(); it's just left over from before we had static methods. exclusive() and RWARC() and so on also have this problem.

[thestinger]

@bblum: I think AtomicRc would be nice to match extra::rc's naming

[bblum]

I dunno. That sounds ok at first, but then you'll wind up with RWAtomicRc and MutexAtomicRc, which are getting into the "too afraid of scaring beginners away that our type names turn ugly" territory for my (personal, subjective) taste. I feel moderately strongly that ARC and RWARC are iconic.

[thestinger]

this is done now

[bblum]

Super.