Unable to set struct property returned from method

Question

I got the following error, which I translated from German:

error BC30068: expression is a value and cannot be a destination.

I am trying to do the following:

sheet.Cells(row, col).Value = newVal ' this is VB 

Where I declared cells as:

 public Cell Cells(int x, int y) // this is C# { return new Cell(this, x, y); } public struct Cell { Worksheet ws; int x; int y; public Cell(Worksheet ws, int x, int y) { this.ws = ws; this.x = x; this.y = y; } public object Value { get { return ws.GetCellValue(x, y); } set { ws.SetCellValue(x, y, value); } } } 

How can I solve this problem? I don’t want Cell to be a class, but instead to be a structure, because otherwise, any access would create a new object on the heap. Of course, I can cache all created Cell objects, but this can lead to errors and a lot of waste and a new layer of indirection.

Is there a better way to do this?

Answer 1

Now I solved this by returning the CellCollection property from Cells, which contains the index. That way, I no longer get the error, and I just create one object for all cells.

Answer 2

What is the problem of creating a class?

Also, why don't you just use the index:

 public object this[int column, int row] { get { return this.GetCellValue(column, row); } set { this.SetCellValue(column, row, value); } } 

this way you can use it like this:

 sheet[column, row] = newValue; 

Answer 3

If this is a structure, you will need to get the value, change it and pass it back:

 Cell cell = sheet.Cells(row, col); cell.Value = newVal; sheet.Cells(row, col) = cell; // assuming this has a setter 

But, frankly, I believe that your statement that an object (class) is too expensive per cell does not make sense ...

By the way, I would also advise that structures should be immutable whenever possible (except, for example, XNA, for certain reasons).

Answer 4

The behavior you see is a consequence of the fact that .net makes no distinction between structure properties and methods that mutate field structures themselves and those that do not. Ideally, .net languages ​​would prohibit the use of any mutation methods and properties in read-only structures, and would allow them not to mutate. Unfortunately, since .net does not indicate whether the method or property of the struct will mutate the base structure, today C # and vb.net simply assume that property definition tools will affect the main structure, and other methods will not. Older C # compilers allow the invocation of all member code, including property attributes, often with undesirable results.

Too bad that Microsoft decided that structures should be mutated using property definition tools, rather than specifying that structures that should be mutable should either open fields directly or be modified using static methods. If they took such an approach to things like Point , complaints that would cause mutable structures that could be branded as “evil” would be prevented, and code like yours would work very well. Oh well, so much for the wonders of useless "encapsulation."

Answer 5

My answer would be - don't do the Value a property. Do this in two ways - GetValue() and SetValue() . So there are no appointments.