C# struct by-ref

Question

Is there any way in C# to be able to do this:

map.player.x = 5;

while keeping player of type Point (or silently convertible to one) and still be able to check the value for correctness when doing the assignment?

To be clearer:

• Point is a struct defined by the C#/.net standard libraries and is passed by value.
• Making a wrapper class and implementing all of Point's methods as call-throughs to Point is long and tedious.
• Having a wrapper class with nothing but an implicit coversion to/from Point will not allow the above. It would have to be written as (Point)(map.player).x, which is clumsy.

Answer 1

If I understand you right, you seem to want to get some flexibility by defining type-conversions. That won't go very far.

Avoid mutable structs (value types). struct Point is an unfortunate leftover from the old Win32 API.

So aim for map.player = new Point(5, map.player.y);

Answer 2

No. Either player is a variable, in which case you don't get any chance to verify the change during the assignment, or player is a property, in which case the expression map.player is categorized as a value and you're not allowed to set the x part (as it would be usless).

I would suggest you create a method, so you can call:

map.SetPlayerX(5);

... or you make changing the x value part of a larger operation which is owned by the Player class. That's likely to be a more OO approach - usually if you find yourself wanting to do something like this, it's worth taking a look at the design and responsibilities.

Answer 3

1

What about assigning both coordinates at the same time?

map.player = new Point(5, 7);

Now you can have the validation logic inside of the player property.

---

2

Do you really need to implement all the stuff of System.Drawing.Point? It should not be all too difficult to implement your own version with only the things you really need. There is not much logic in Point.

Answer 4

Some people would suggest using a class type to hold the X and Y values. I am leery of that approach, and would suggest that in many cases the semantics obtained by exposing player as a field would be much cleaner (though I'm unclear why map has a member called player. If an map is reference to MapType, and instance of MapType has a field of struct type player, with a field x of type integer, it is clear that a change to map.player.x will affect one instance of MapType. Also, saying map1.player = map2.player; will copy the fields from map2.player to map1.player. By contrast, if player were of a class type and one did map1.player = map2.player; map1.player.x = 5;, that would affect both map1 and map2.

The question of whether to use a mutable struct versus a mutable class is pretty straightforward, but the notion of "If it's mutable make it a class" is just plain wrong. Simply ask yourself, given:

  thing1 = thing2;
  thing1.x = 5;

would you want the second statement to affect the value of thing2.x? If yes, use a class. If no, use a struct.

BTW, abother pattern to consider if you don't want your map type to expose player as a field would be to have it expose an ActOnPlayer method:

  public delegate ActionByRef<T>(ref T p);
  public delegate ActionByRef<T1,T2>(ref T1 p1, ref T2 p2);

  public void ActOnPlayer(ActionByRef<playerType> proc;)
  {
    proc(ref _player);
  }
  public void ActOnPlayer<T>(ActionByRef<playerType,T> proc, ref T param;)
  {
    proc(ref _player, ref param);
  }
... sample usage:
  map.ActOnPlayer((ref playerType it, ref int theParam) ->
    {it.x = theParam;}, someIntVariable);

Note that the latter approach would look something like using a closure, but unlike using a closure it would not generate any new temporary heap objects, and would thus not create any pressure on the garbage collector.