andyWed 5 Jan 2011

I still think we should remove readonly entirely. Its a bit confusing in context of const and really doesn't save many keystrokes, is not consistent, and is less clear than just using the standard field protection semantics:

readonly Int x := 5
Int x := 5 { private set }

AkcelistoWed 5 Jan 2011

I agree. I decide to no more use readonly in own code.

brianWed 5 Jan 2011

This has been discussed previously, although I can't find the original discussion.

About two years I began removing readonly to use { private set } and didn't like where it was going (readonly is used very heavily).

Although I can live with it if virtually everyone agrees since it is a fairly big breaking change.

Other options would be to use a more meaningful keyword like getonly or something like that that indicated the field may change, but only the class itself has set access.

qualidafialThu 6 Jan 2011

I'd prefer to keep readonly, although I'd favor renaming it to something more accurate. "Read only" sounds too similar to "immutable," at least to me.

I like "unmodifiable," although that's pretty long for a keyword.

AkcelistoThu 6 Jan 2011

unmodifiable sounds too similar to immutable

brianThu 6 Jan 2011

Well the most accurate keyword would be privateset but is that really better than not having a keyword at all? Best I can think of is getonly.

DanielFathThu 6 Jan 2011

+1 to getonly or onlyget or perhaps even noset

andyThu 6 Jan 2011

I think anything besides privateset has misleading connotations. I'm not convinced we actually need a shortcut here - but I could live with privateset.

qualidafialThu 6 Jan 2011

+1 for privateset. It's only two keystrokes more and has the advantage of not being confusing :)

DanielFathThu 6 Jan 2011

If we are going to use privateset then we might as well as remove readonly altogether.

katoxThu 6 Jan 2011

And I still think that the readonly keyword is confusing at best. What about

@NoSet Int ans := 40

but I could easily live with the explicit version {private set}.

qualidafialThu 6 Jan 2011

...Ok, I'm convinced. +1 to jettison readonly and make {private set } the sole way to do this.

brianThu 6 Jan 2011

Renamed from **[idea] disallow readonly and set for same field** to **Deprecate readonly keyword**

brianThu 6 Jan 2011

Promoted to ticket #1369 and assigned to brian

Not sure I am really sold on getting rid of the keyword entirely, but using {private set} seems just about almost as good. So seems like the same simple path is to just get rid of it.

brianMon 28 Feb 2011

Ticket resolved in 1.0.58

In the next build use of the readonly keyword will report a compiler warning, and support will be removed completely in build after that (1.0.59).

I feel like this is the right thing to do to clean the stage. However, I still feel there is some future feature to handle what seems to be a very common case where you want a "getter" method as part of your public API, but want to implement it using a field. The readonly keyword didn't actually implement this use case very well since the docs/reflections still exposed the slot as a field, not a method. Something to consider, but don't see any rush to figure it out.

tcolarMon 28 Feb 2011

I actually liked the read-only keyword, well it's functionality at least.

I see the point here and agree mostly, but I'd still like to have a way to make a field read-only without having to specify a private setter chunk of code.

I mean the private setter is ok, but it's a bit "heavy" to type and a bit weird looking to a Fantom newcomer IMO.

Anyway, just saying I'm not against removing read-only, but I'd like something almost as easy / clear to take it's place (Facet ?)

brianMon 28 Feb 2011

Well I am up for trying to come up with alternatives - but I personally think the use case is more than a convenience of creating a private setter. What I really want is something like that looks and works like a field, but is really this:

Str foo() { _foo }
private Str _foo

In the public docs and reflection I want foo to look like a method and not expose anything that a field was used to implement it.

Another use case that also seemed to fit was something like Java final - a field set in the constructor, but then the reference is fixed. Virtually every place I used readonly would also have been easily mapped to final.