Support readonly/final fields

[Chuck]

Support readonly/final fields as found in C# and Java.

These can be initialized when declared or in the init cue, but then cannot be assigned to afterwards.

What keyword to use? Potential choices include:

• immutable
• readonly
• final
• unchanging
• fixed
• unvarying

 http://www.google.com/search?hl=en&q=C%23+readonly

 http://www.google.com/search?hl=en&safe=off&q=java+final

[hopscc]

I'll do it as 'final'

[Chuck]

• I want to use "readonly" instead of "final".
• There is no error checking in the patch that you're not assigning to a readonly field in a method or property. See  http://msdn.microsoft.com/en-us/library/acdd6hb7.aspx

The second point is particularly important and the main reason I'm not applying the patch yet (the first point is an easy edit).

[hopscc]

To clarify the second point
If I augment the patch as stated the only way to set a readonly field will be in its declaration. I'm guessing that what you really mean is that

You want an error message from the cobra compiler if an assignment attempts to change a variable marked as readonly AND the assignment is not in a constructor - yes ??

Sigh .. and Why do you want 'readonly' rather than 'final' (now) ?

[Chuck]

Yes you can assign the field in the declaration or a constructor/initializer.

I think 'readonly' is a better word that more directly states what's going on. Coders across a variety of languages are familiar with the term "read only".

[hopscc]

Second attachment is a patch to apply after the first for the assignment error check.

I havent done anything about changing the keyword since I dont find your assertion for readonly vs final ( or any of the rest of the list at the top of the page) particularly compelling, its already implemented and tested as is and if its an easy edit you can no doubt adjust it to your (belatedly notified) desires in passing.

[Chuck]

"belatedly notified?" You already knew it was up in the air via the ticket description ("Potential choices include: ..."). You assigned and patched on the same day. It wasn't like there was a big gap in there.

I recall the command line arg patch was missing "cobra prog arg1 arg2" and the "for" patch was missing support for KeyValuePair. Seems like every patch creates a "homework assignment" for me.

[hopscc]

Hmm 'Up in the air' - 1.5 months for any of 6 choices. No indication of preference, no other feedback
a reasonable assumption was that there was no preferred option

OK fair cop - I got the patch done in the same day I assigned it to myself - sorry about that. (the gap there was something like 4 hours)
There was a 5 day gap between assign(+patch) and any sort of feedback though - how long a gap between announcing intention and action should I wait for?
..
SO yes 'Belatedly notified' - new additions/augmentations/requirements after a patch has been made and uploaded.

'every patch creates homework' - If you take a breathe and stop for a moment you'll surely admit that thats just a little bit of an exaggeration given the number of patches I've provided.. or even given the number provided and still waiting any sort of feedback (much less been applied).

I think if you look at the 'homework' you get supposedly left with( specifically the two you mentioned) with you'll find they're all additions you brought up as requirements/necessary/desirable after a patch was provided and without any prior indication/discussion - perhaps they were in your head as needed prior but thats no use to me since I can only see the discussion and bug tickets
also (and not insignificantly) they're items I disagree with or dont care about (Mea culpa)..

I'm sometimes not averse to providing patches for those sort of things (disagree/dont care) if I know about them before I've done the work but I'm ( in case you've not noticed) really, really anti redoing/revisting/adding to a patch thats already done, tested, packaged, uploaded, gets ignored for a (gap) then gets additional new requirements added to it (that I dont care about/for)...

Think of it as a personal foible ( and the fact that getting a patch
tested, pkged, uploaded, docced takes me the best part of a (tedious) hour )..

SO for your consideration

Consider the singing dog - Its not that it sings songs you dislike, its that it sings at all..

and

feedback sooner is better than feedback later or feedback none

and

Changes to things already done might need a better rationale than a bare 'I want'

and

1) Accept/Apply? the patches...
2) then suggest what you'd like additionally

Its easier that way...
(:-)

[hopscc]

I guess this didn't take then (:-)

[hopscc]

Looks like this has been applied in some form changeset:2074
const and readonly so I'm closing it as fixed.