Re: Struct vs Class

Hi Bruce,

I agree with your new reasoning :)

I guess I don't mind this too much:

Point pt = new Point(
[complex math for x goes here],
[complex math for y goes here]
);

I've used the format above a lot and it's just as clean as assignments that
follow construction, IMO. However, ".X = ..." and ".Y = ..." is a bit more
intuitive, although Point is probably a bad example of this because everyone
knows it's (x,y), but if it were a struct with several parameters then inline
construction might get confusing. Although, you can declare local variables
instead and pass the variables to the constructor. But that seems a bit
ridiculous just to construct a single value type.

Whatever - I'm just going to stick with the idea that all structs should be
immutable for now in light of the reasons that you have stated.

myRectangle.Location.X = 7;

I know this won't compile, but I think the only way for the compiler to miss
an assignment to a mutable struct that doesn't have a variable is when it's
boxed. I don't know what kind of effect this would have on the CLR, but maybe
a subsequent version of the framework could force immutability on all boxed
value-types and throw an exception on an assignment attempt. C# 8.5 perhaps?

Of course, I really don't know for sure if the compiler will miss non-variable
assignments on boxed structs only.

--
Dave Sexton

"Bruce Wood" <brucewood@xxxxxxxxxx> wrote in message
news:1162256655.354432.235400@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Dave Sexton wrote:
Hi Bruce,

<snip>
I'm sure you know about the confusion: non-intuitive behaviour when a
property returns a Point, or when a Point is boxed for storage in an
aggregate structure. Many, many newbies try to use the above p.X = 7
syntax in those situations and then wonder why their point's
coordinates didn't change. Yuck.

I just plain don't indulge in creating mutable structs for questionable
improvements in syntax
<snip>

I agree that structs should be immutable, without question. However, many,
many newbies do many, many things wrong. I'm not sure that I agree with
the
reasoning behind your conclusion. Newbs seems to always catch all
exceptions
too, but we really can't get rid of that functionality either.

I guess I'd prefer immutability in structs just so shrewd programmers don't
make the same mistake on accident. I can't think of a better reason than
that, unfortunately.

LOL... well, I guess appealing to the newbie thing wasn't a good
argument. :-)

What I meant to say is that if Location is a property of type Point,
then this looks as though it ought to work:

myRectangle.Location.X = 7;

but it doesn't. It's perfectly logical that it doesn't work, but the
logic is subtle and requires considerable knowledge of how .NET / C#
works. I dislike things that look as though they should do something
but which, for subtle reasons, do something else (or, in this case,
nothing). Granted, the compiler complains about this specific case, but
there are other cases in which it doesn't. I prefer that my code be
clearly readable to all: newbies and veterans alike, so I prefer to
give up syntactic sugar if it makes my code clearer.

It's so much easier to remember that you can't change a struct's
state--ever--than to remember that you can change it under some
circumstances but not under other circumstances, for perfectly logical
but non-obvious reasons. That just makes the code more difficult to
maintain, IMHO.

One of the clues that this is going on is when newbies (who usually
know other languages, so they're not new to programming, just new to
C#) make the same mistake over and over again. Now, sometimes the
feature is so truly useful that its very utility outweighs the
resulting confusion. Structs, for example, confuse the heck out of
people coming from the C/C++ world, but it's so very useful to be able
to create new objects with value semantics that I wouldn't give it up
to make the language easier to understand. Mere semantic sugar, such as

myPoint.X = 7;

is another thing entirely. I would rather live with more long-winded
code and do away with the confusion than have a handy shorthand that
then creates problems elsewhere in the language.

I've worked in several shops of mixed-language, mixed-skill
programmers, so I prefer code that someone not terribly familiar with
the language can understand. Mutable structs just throw a big wrench
into that, so I avoid them.



.

Relevant Pages

  • Re: Struct vs Class
    ... I agree that structs should be immutable, ... many newbies do many, many things wrong. ... but non-obvious reasons. ... then creates problems elsewhere in the language. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Naming structs with a variable
    ... remember that structs are value types in .NET. ... reference semantics) should be the default choice. ... I said that there were two reasons. ... Experienced .NET programmers with a firm grasp of value semantics ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Naming structs with a variable
    ... value semantics versus reference semantics. ... structs are _copied_ constantly, whereas classes aren't. ... a struct type for efficiency reasons. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Define my own data type
    ... While the former code looks tidier, there are resons why it is "bad": ... the reasons have to do with how structs act when boxed, ... act as results returned by methods or properties. ... the last line is a no-op for similar reasons to those above: ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Naming structs with a variable
    ... Structs are "lightweight" only in the sense that they avoid garbage ... Rectangle as structs rather than as classes: ... heavyweight" arguing is way down the list of reasons why you would want ...
    (microsoft.public.dotnet.languages.csharp)