Feature/prop

[massimosiani]

Addresses #3313.

[djspiewak]

Thank you for looking at this! An interesting question for us to answer though is what we want to do with Native and JavaScript. This is a bit different from Env, which works on all three platforms (with the exception of in-browser JS).

[armanbilge]

Native and JavaScript

They both support System properties. It's basically just a global mutable map.

[durban]

A question: the getAndSet, modify, and similar methods look like the ones on Ref. However, here they are not atomic, right? So having them could be somewhat misleading. (While having only get and set would make it clear, that there is no atomicity for modification.)

[massimosiani]

I would agree. TBH, I wondered whether we should try and make them atomic, but that's probably not something you'd expect by system props.

[durban]

I don't think we can make them atomic. Or do you know a way?

[massimosiani]

Right, not sure how could be made atomic. Citing Arman, it's basically just a global mutable map.
I'll remove getAndSet and getAndUpdate but I think that update is still useful if we make clear that there are no guarantees about concurrent modifications. It's a handy wrapper for a get followed by set. I also like modify as a wrapper but would like to hear other opinions.

[armanbilge]

I think that update is still useful if we make clear that there are no guarantees about concurrent modifications

Unfortunately I think it's still confusing. Anyway, I expect 99% of usecases to just be reading system properties. APIs that require setting/updating system properties seem really dicey 🙄

[durban]

I'd just go with get, set and remove. If that's the functionality offered by the platform, and we can't provide atomicity, its best simply to wrap those.

[armanbilge]

Similar to Env, we can also add something to list/iterate the keys/entries.

[durban]

I'm not sure I like returning a mutable object here. (I think we usually try to avoid that?)

[armanbilge]

For Env we decided to return an Iterable[(String, String)], but that was because of case-sensitivity issues which I don't think apply here. So probably makes most sense to return an immutable Map[String, String].