When I do this:

fansh> [:].ro.isRO

I get:

true

But when I try to do this:

fansh> AtomicRef([:].ro)

I get this:

sys::NotImmutableErr
  concurrent::AtomicRefPeer.val (AtomicRefPeer.java:29)
  concurrent::AtomicRef.val(AtomicRef.fan)
  concurrent::AtomicRef.make$ (AtomicRef.fan:21)
  concurrent::AtomicRef.make (AtomicRef.fan:21)

Map.isRO says that a read-only map is guaranteed to be immutable. Is there a way to do this?

Read-only and immutability are not the same. It may seem silly but even if your list is empty, to be immutable it must be both read-only, and have an element type that is immutable.

In your example, your list is of type Obj which is mutable.

Ahh I see. With that piece of advice I used

AtomicRef([:].toImmutable)

and that worked. Though, I feel like immutability and read-only should be the same thing.

fansh> [:].ro.isImmutable
false
fansh> Str:Str[:].ro.isImmutable
false
fansh> Str:Str[:].toImmutable.isImmutable
true

Interesting. I expected Str:Str[:].ro to be immutable. Is this a bug?

I feel like immutability and read-only should be the same thing.

I agree it can be confusing, but there are valid use cases for the distinction. It's kind of like a file with unix permissions rw-r--r--, meaning read-write for the owner but read-only for anybody else. This is what java.util.Collections#unmodifiableList does for example.

Checking out Map.java, I'm thinking that ro() method should set ro.immutable = type.v.isConst().

Thats fair, it's just ultimately I wanna be able to do something like

b := AtomicRef([:].toImmutable)
s := b.val->rw->add("new","test")
b.getAndSet(s.toImmutable)

and toImmutable is a whole 9 characters more than .ro haha

I feel they should both achieve the same goal and that's only because Map.isRO says it in the description. But ultimately it's really not much of a big deal to use .toImmutable instead.

Just to make it clear, a readonly list means you cannot change the items in the list. But it says nothing about whether the items themselves are mutable or not. An immutable list is guaranteed to be deeply immutable. Consider a list of OutStream - you can make it readonly, but you could never make it immutable.

Checking out Map.java, I'm thinking that ro() method should set

That would be interesting - it does make sense. My main concern is that it might be more confusing that ro() sometimes return immutable and sometimes not. Plus it would encourage programmers to use that in their code which wouldn't signal intent as well as toImmutable. Although I definitely do wish that method name was so long!

Plus it would encourage programmers to use that in their code which wouldn't signal intent as well as toImmutable.

I had the same thoughts - while it sounds like a shortcut - I think overall it creates confusion - and we should force code intent with toImmutable.

Although I definitely do wish that method name was so long!

How about toConst?

Although I definitely do wish that method name (wasn't) so long!

Any thoughts about giving toImmutable a shortcut operator? like

[:]!! => [:].toImmutable //This one screams excitement for Immutability
[:]## => [:].toImmutable //while, this one says I'm really Immutable
[:]$$ => [:].toImmutable //lastly, lets profit on this Immutability 

Just throwing these ideas out there. I feel like concurrency is one of Fantom's strong points, so couldn't hurt to add some shortcuts designed for it.

Umm. No it would be best if all structures were immutable on construction and then declared mutable, but no !!, ##, $$ signs for immutability. It's confusing and hard to search for.

but no !!, ##, $$ signs for immutability. It's confusing and hard to search for.

It's just an idea but it wouldn't be any more confusing then any other operator.

You would just search "Operators" or "Expressions" and it would be under http://fantom.org/doc/docLang/Expressions.html#shortcuts as a shortcut for .toImmutable .

No it would be best if all structures were immutable on construction and then declared mutable

I feel like someone starting out with Fantom would be using mutable structures right off the bat, and then ease into immutability after they've wrapped their head around the concept. So changing the construction of all objects to immutable would kind of a be a drastic language change.

A shortcut operator for toImmutable would just be some syntax sugar.

Yeah, for begginers it would be hard to do that if they came from Java. But if you came from a functional background you'd be surprised things aren't immutable by default.

And best was a too strong of a word. For "Optimal/Ready concurrency" it would be great if all structures are immutable.

A shortcut operator for toImmutable would just be some syntax sugar.

At this point Fantom has a lot of syntax sugar. I'm more terrified of getting syntax diabetes at this point ;)