#1369 Deprecate readonly keyword

Akcelisto Wed 5 Jan 2011

I think, compiler must disallow readonly if set definition exists:

class ValFut{  
  readonly Future? future{

So, visibility of set will be expressed more explicit:

class ValFut{  
  Future? future{
    private set{        

andy Wed 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 }

Akcelisto Wed 5 Jan 2011

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

brian Wed 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.

qualidafial Thu 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.

Akcelisto Thu 6 Jan 2011

unmodifiable sounds too similar to immutable

brian Thu 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.

DanielFath Thu 6 Jan 2011

+1 to getonly or onlyget or perhaps even noset

andy Thu 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.

qualidafial Thu 6 Jan 2011

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

DanielFath Thu 6 Jan 2011

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

brian Thu 6 Jan 2011

But is which is really better:

privateset Int x := 7
readonly Int x := 7
getonly Int x := 7

Int x := 7 { private set }

I've been conditioned to want to read a field using a keyword, so that just looks better to me. But it is sort of a hack that seems unnecessary.

yachris Thu 6 Jan 2011

+1 to intentional code:

Int x := 7 { private set }

Save your keyword for more important cases... and save an organ (the C++ committee used to say "You must donate an internal organ to add a keyword" :-)

alexlamsl Thu 6 Jan 2011

This would do exactly what I expect

Int ans := 42 {private set}

whereas the readonly keyword would cause confusion as to what the (lack of) side-effects could be...

katox Thu 6 Jan 2011

I was the confused one originally. See 1043.

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}.

qualidafial Thu 6 Jan 2011

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

brian Thu 6 Jan 2011

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

brian Thu 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.

brian Mon 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.

tcolar Mon 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 ?)

brian Mon 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.

Login or Signup to reply.