What is the alternative to lack of C++ style "const" in C#

[mswlogo]

There are many threads on the lack of a true unmanaged C++ const like
behavior in C# (.Net) and that's not what this topic is about. The
topic is, what is the best practical way to live with it.

Some developers feel any function that returns an object should copy
it. This gets pretty expensive performance wise and development wise
and hard to enforce. It also defeats a lot of what C# intentionally
did.

Other developers feel you should build your own protection. This has
good performance but again. This is a high development cost to add to
all your objects and on a large team with faces coming and going and
wide range of experience, pretty hard to enforce.

The last option is, screw it, and don't worry about it. You'll create
more bugs or performance issues by trying to fix it than the problem
(lake of protection) will likely cause. Super critical objects could
be manually protected as needed. Hopefully good design will avoid most
issues.

What is your thoughts and practices?

 

[Nicholas Paldino [.NET/C# MVP]]

mswlogo,

Not to be flippant, but I take option #3 (screw it). While I do see the
practical application of const in C++, the fact that you can just cast it
away made the statement (in my eyes) pretty worthless.

Also, I'm a strong believer in the last statement in option #3, that
good design will alleviate this in most cases (of course not all, but that's
the ideal).

 

[Michael S]

I would go for the 'screw it' approach.

Happy Screwing
- Michael S

 

[Guest]

Screw it.

There are times when it is nice to design a system with many overriding
ideals in place, however often when you do so as you said in point 1, you end
up costing yourself a lot for not a lot of actual benefit.

When coding, I often keep MacLennan's Language Principles
(http://csis.pace.edu/~bergin/slides/Maclennan.html) in mind, especially in
cases like this, #6 comes into play "Localized Cost: Users should only pay
for what they use; avoid distributed costs." Where needed a new instance will
be returned, otherwise it’ll just be a reference, and in either case, such
ends up being well documented... granted this does kind of violate #15.

Brendan

 

[Michael S]

When coding, I often keep MacLennan's Language Principles
(http://csis.pace.edu/~bergin/slides/Maclennan.html) in mind,

Thanks for the link. I like what I read.

- Michael S

 

[Jeff Louie]

In a multi threaded situation I would consider using immutable objects.

Regards,
Jeff

 

[Guest]

Nicholas,

Of course one can cast const away, but it can only be done explicitely
(const_cast, or _deprecated_ C-style cast). If it is intentional then there
is no problem with encapsulation (like friend) or constness.

The lack of const in C# has the result that the implementor of an interface
has to enforce constness, by either using readonly properties, or copying
objects. But it is hard to enfore though IMO. One could for instance use
enumeration interface to expose collections, so that a user cannot change
contents of the collection.

Cheers,
--
Tom Tempelaere.

mswlogo,

Not to be flippant, but I take option #3 (screw it). While I do see the
practical application of const in C++, the fact that you can just cast it
away made the statement (in my eyes) pretty worthless.

Also, I'm a strong believer in the last statement in option #3, that
good design will alleviate this in most cases (of course not all, but that's
the ideal).


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

There are many threads on the lack of a true unmanaged C++ const like
behavior in C# (.Net) and that's not what this topic is about. The
topic is, what is the best practical way to live with it.

Some developers feel any function that returns an object should copy
it. This gets pretty expensive performance wise and development wise
and hard to enforce. It also defeats a lot of what C# intentionally
did.

Other developers feel you should build your own protection. This has
good performance but again. This is a high development cost to add to
all your objects and on a large team with faces coming and going and
wide range of experience, pretty hard to enforce.

The last option is, screw it, and don't worry about it. You'll create
more bugs or performance issues by trying to fix it than the problem
(lake of protection) will likely cause. Super critical objects could
be manually protected as needed. Hopefully good design will avoid most
issues.

What is your thoughts and practices?