Prev: Bus Speed
Next: MEF with VS2008
From: Jeroen Mostert on 25 May 2010 20:48
On 2010-05-26 2:31, Stefan Ram wrote:
> In Java, I am used to write code like:
>
> void f( final int i ){ final int j = g( i ); ... }
>
> . But neither »const« nor »readonly« in C# seem
> to be apppropriate for this purpose.
>
> The intention is to enhance readability of source
> code by conveying the intention that
>
> - the parameter i will not be changed within
> the body and that
>
> - the variable j will not be changed after its
> initialization.
>
> Something similar is possible with »const« in C
> and C++.
>
There is nothing similar for local variables in C#. If there were it
probably would have been "readonly" for locals, but there isn't.

Much like C++'s "const", this is one of those things I don't really miss.
It's easy to compensate for by not writing methods large enough to need such
hints in the first place. For parameters it's certainly unnecessary if you
simply heed the rule to never modify them in the first place (adding these
hints to prevent others from doing this is unnecessary or ineffective,
depending on your successor's level).

That's not to say anyone who does like these things is "doing it wrong", and
I would be the first to cheer better support for immutability added to the
language, of the kind that can help you with concurrency -- C++'s "const"
isn't quite it.

--
J.
From: Arne Vajhøj on 25 May 2010 21:57
On 25-05-2010 20:31, Stefan Ram wrote:
> In Java, I am used to write code like:
>
> void f( final int i ){ final int j = g( i ); ... }
>
> . But neither �const� nor �readonly� in C# seem
> to be apppropriate for this purpose.
>
> The intention is to enhance readability of source
> code by conveying the intention that
>
> - the parameter i will not be changed within
> the body and that
>
> - the variable j will not be changed after its
> initialization.
>
> Something similar is possible with �const� in C
> and C++.

If one want to do functional programming, then my
suggestion would be to use a functional language.

I don't like the practice used by some to sprinkle final
all over Java code.

I would only use it if necessary (inner classes).

Arne



From: Arne Vajhøj on 25 May 2010 21:59
On 25-05-2010 20:48, Jeroen Mostert wrote:
> On 2010-05-26 2:31, Stefan Ram wrote:
>> In Java, I am used to write code like:
>>
>> void f( final int i ){ final int j = g( i ); ... }
>>
>> . But neither »const« nor »readonly« in C# seem
>> to be apppropriate for this purpose.
>>
>> The intention is to enhance readability of source
>> code by conveying the intention that
>>
>> - the parameter i will not be changed within
>> the body and that
>>
>> - the variable j will not be changed after its
>> initialization.
>>
>> Something similar is possible with »const« in C
>> and C++.
>>
> There is nothing similar for local variables in C#. If there were it
> probably would have been "readonly" for locals, but there isn't.
>
> Much like C++'s "const", this is one of those things I don't really
> miss. It's easy to compensate for by not writing methods large enough to
> need such hints in the first place. For parameters it's certainly
> unnecessary if you simply heed the rule to never modify them in the
> first place (adding these hints to prevent others from doing this is
> unnecessary or ineffective, depending on your successor's level).
>
> That's not to say anyone who does like these things is "doing it wrong",
> and I would be the first to cheer better support for immutability added
> to the language, of the kind that can help you with concurrency -- C++'s
> "const" isn't quite it.

C++ const is a must to get some C++ code to work.

And I actually miss the C++ const in both Java and C#.

Arne

From: Jeroen Mostert on 26 May 2010 01:19
On 2010-05-26 3:59, Arne Vajhøj wrote:
> On 25-05-2010 20:48, Jeroen Mostert wrote:
>> On 2010-05-26 2:31, Stefan Ram wrote:
>>> In Java, I am used to write code like:
>>>
>>> void f( final int i ){ final int j = g( i ); ... }
>>>
>>> . But neither »const« nor »readonly« in C# seem
>>> to be apppropriate for this purpose.
>>>
>>> The intention is to enhance readability of source
>>> code by conveying the intention that
>>>
>>> - the parameter i will not be changed within
>>> the body and that
>>>
>>> - the variable j will not be changed after its
>>> initialization.
>>>
>>> Something similar is possible with »const« in C
>>> and C++.
>>>
>> There is nothing similar for local variables in C#. If there were it
>> probably would have been "readonly" for locals, but there isn't.
>>
>> Much like C++'s "const", this is one of those things I don't really
>> miss. It's easy to compensate for by not writing methods large enough to
>> need such hints in the first place. For parameters it's certainly
>> unnecessary if you simply heed the rule to never modify them in the
>> first place (adding these hints to prevent others from doing this is
>> unnecessary or ineffective, depending on your successor's level).
>>
>> That's not to say anyone who does like these things is "doing it wrong",
>> and I would be the first to cheer better support for immutability added
>> to the language, of the kind that can help you with concurrency -- C++'s
>> "const" isn't quite it.
>
> C++ const is a must to get some C++ code to work.
>
I'm not really sure what the statement is, here. C# "class" is a must to get
most C# code to work. Less flippantly, checked exceptions are a must to get
some Java code to work. The language itself is a poor yardstick for its
features.

In a legal C++ program you should be able to erase "const" everywhere
(including every place it's mentioned in the standard, and duplicate
overloads) and still end up with a working program, right? It's been a few
years since I've hacked C++ in a serious way, so maybe I'm overlooking
something.

> And I actually miss the C++ const in both Java and C#.
>
Like I said, different strokes. I haven't yet written a piece of C# code
where I thought "gee, if only I had const here" because it wouldn't have
added anything to the code. The one exception being immutability for
concurrency, as I mentioned. In frameworks, readonly properties and the
occasional read-only collection are usually sufficient, and even then
frameworks are not the majority of code. C++ code involves "const" even in
places where it's not buying you anything, other than a slightly misplaced
feeling of safety.

....but I really don't want to continue discussing the merits of "const", as
that must have been done to death. I'm certainly not going to tell C++
programmers how to do their jobs.

--
J.
 | 
Pages: 1
Prev: Bus Speed
Next: MEF with VS2008