Okay, I used to love Access modifiers like "public vector2 getPosition()"  But, because XNA uses it so often, I switched to properties, and all my code is written in properties.

Properties are supposed to be better, but I have a persistant problem.  When I try to access properties like a vector2, and try to access their variables, I get this error.

error CS1612: Cannot modify the return value of 'XNALibrary.Camera2D.Position' because it is not a variable

It's  quite irritating, is there any way to access these variables?  Because, otherwise I might switch back to access modifiers.


Here's an example:

public Vector2 Position

{

get { return this.position; }

set { this.position = value; }

}

 

The problem is not properties. Vector2 is a value type, so you will still have exactly the same problem if you use 'access modifiers'.

When you 'get' a value type, such as a Vector2, either via a property getter or an access modifier, you don't get a pointer to the object, you get a copy. So if you then go and change a variable on the Vector2, you are changing the copy, which of course does not change the original. So with properties, the compiler is letting you know that.

This problem is quite frustrating to people just starting with C#. But after awhile it's not actually a problem, because very rarely do you actually need to just modify one of the components of a Vector, more often you need to update the entire vector, so its not really a problem.

Okay, so how do I change it the right way?

Just update the whole Vector2.

e.g.

Postion += Movement;

or

Position = newPosition;

But, in situations like when you press the "left" key, I only need to update the .x

Say Object has a property "Position"

You can't do Object.Position.X = 5. This will throw an error, as you've found out.

Object.Position = new Vector2(Object.Position.X, 5) will work. As you are assigning a new Vector2 to the position.

This is only true for value types.

If Vector2 was a class, then you would not have a problem modifying one of its members.

DualOpAmp29:

But, in situations like when you press the "left" key, I only need to update the .x

Yes, this is true. In certain situations I want to sleep in and not go to work.

Well, if that's the only way, then I have to go back to access modifiers that don't have any getters or setters...  It's just to irritating to do it the other way.

That has nothing to do with the amount of work, it's just better syntax. IMO

DualOpAmp29:

Well, if that's the only way, then I have to go back to access modifiers that don't have any getters or setters...  It's just to irritating to do it the other way.

As I explained above, you will have exactly the same problem with access modifiers... unless you use the ref keyword, then it's getting real messy.

Trust me, it's not that big a deal really, the alternative -> access modifiers, will have a much greater impact on you in terms of less readability etc.

DualOpAmp29:

But, in situations like when you press the "left" key, I only need to update the .x

Do it like this:

Vector2 positionChange;

if (leftkey) positionChange.X = -5;
else if (rightkey) positionChange.X = 5;
etc...

Position += positionChange;

That really bums me out. 

this.position.x -= 1;

Looks a lot better than:

this.position = new Vector2(this.position.x - 1, this.position.y);

Eh, I might get out chewed for this but IMHO, properties are kinda overrated.  Maybe it's because I'm raised on C++, but after developing my current game (which was actually a very large project), I found that using properties caused me more headache than saved me time.  It should be said that in situations where you have complicated objects referencing other complicated objects, I understand how properties can make things more flexible.  But if you're creating a simple Kinematics struct (holds position, velocity, rotation, etc), then I find that properties will only complicate things unnecessarily.  On top of that, if you're in need of performance, properties are slightly more inefficient than direct access AFAIK.

There are places to use properties, and places not to use them. As with all programming, it takes skill, experience and taste to make the right design decisions.

C# allows you to use both fields and properties, so naturally the designers saw merits to both in your code. Neither one is intended to be used exclusively. If you want to use properties for kinematics data, you might consider making a set of them as floats; PositionX, PositionY, and PositionZ. You can also have more than one property per field in a class so there's no reason you can't have multiple visualizations of the same data. Position, PositionX|Y|Z, PositionRelativeToPlayer, etc. That gives you a framework for unified data validation in your code, for example: no matter how the position is being set do you want to have some special handling in case the object position gets set outside the world boundary?

DualOpAmp29:

That really bums me out. 

this.position.x -= 1;

Looks a lot better than:

this.position = new Vector2(this.position.x - 1, this.position.y);

When modifying the position internal to the object don't use the property, but the underlying private variable.  You shouldn't have any problems dealing with the individual Vector2 fields in that case.

If you need to do modifications from outside the object, why not use other methods?  To use your example...

public void MoveLeft(int x)
{
  position.x -= x;
}

MrLeebo:

C# allows you to use both fields and properties, so naturally the designers saw merits to both in your code. Neither one is intended to be used exclusively. If you want to use properties for kinematics data, you might consider making a set of them as floats; PositionX, PositionY, and PositionZ. You can also have more than one property per field in a class so there's no reason you can't have multiple visualizations of the same data. Position, PositionX|Y|Z, PositionRelativeToPlayer, etc. That gives you a framework for unified data validation in your code, for example: no matter how the position is being set do you want to have some special handling in case the object position gets set outside the world boundary?

Like MrLeebo said, when it comes to deciding between a property or a field, I've found that it really just depends on what kind of data you'll need to get or set.  If you want the set value to be clamped to some range or if you need a set accessor to raise an event, properties are the way to go, whereas fields don't have the same restrictions with Value types as properties do.  I personally like using properties for several reasons:

1. You can set breakpoints within properties' accessor methods to see why the heck they're being assigned to what they are.  This is really useful in situations where you have a commonly assigned to value that you think is the source of your problem.

2. You can have different access restrictors for the get/set accessor methods.  In my abstract camera class, for example, I have three properties- World, View, and Projection.  The set accessors are all protected, but the Get accessors are all public.  My Game-derrived class has a public Camera property, and all of my GameComponent-derrived objects can get the Camera's View and Projection matrices with ease, and yet I don't have to worry about making a stupid mistake and assigning to one of them out of context, which would screw everything up.

3. Accessing properties, because of their treatment as methods, is a teeny tiny bit slower than accessing fields, and, as we all know, every little bit counts in a game. (get it...? "bit"? haha... okay, that was a crappy pun, sorry)
An easy way to avoid this miniscule lag and still have the debugging help that breakpoints allow is to temporarily make the member a property until you don't need to breakpoint it anymore, and then just change it to a field.  The name and access syntax for it will still be exactly the same, but you won't have those extra method calls "slowing down" your framerate.

Please stop using the colored text and non-standard text. We're not that kind of forum. Consider this the warning, in the future instead of cleaning them up, I will just start deleting them. We try to keep it pretty clean and professional here and your posts are ruining the decor :)  Thanks!

it really just depends on what kind of data you'll need to get or set

Actually, on the Xbox, properties are significantly slower than fields, because of the Compact CLR. Thus, if you target Xbox, use a field if you can. Properties are still useful when you want to calculate the returned value, and/or hook setting of the value to mark yourself "dirty," for example. They just should probably not be used in the inner loop (and thus not for position or orientation in a collision system or scene graph, say).

I just do it like this:


From what I understand:

object.Position = new Vector2(0,100);

is faster than:

object.PY = 100.0f;

But I like having these properties for readability in my code.

faultymoose:

From what I understand:

object.Position = new Vector2(0,100);

is faster than:

object.PY = 100.0f;

But I like having these properties for readability in my code.

I think object.PY = 100 would be faster than object.Position = new Vector2(0, 100);

because it's only working with half the data. on modern architectures it might be irrelevant, but it wouldn't be slower.

George Clingerman:

Please stop using the colored text and non-standard text. We're not that kind of forum. Consider this the warning, in the future instead of cleaning them up, I will just start deleting them. We try to keep it pretty clean and professional here and your posts are ruining the decor :)  Thanks!

Who were you talking to, because if you were talking to me, I don't understand.  I didn't think I used any special text.

Nope not you, I replied directly below the offender and corrected his post (and made it clearer to him elsewhere). So nothing to see here, carry on :)

Craig Martin:

I think object.PY = 100 would be faster than object.Position = new Vector2(0, 100);
because it's only working with half the data. on modern architectures it might be irrelevant, but it wouldn't be slower.

 

You're mostly right. Shawn Hargreaves wrote a little about this in his blog.
http://blogs.msdn.com/shawnhar/archive/2007/01/02/inline-those-vector-constructors.aspx

George Clingerman:

Please stop using the colored text and non-standard text. We're not that kind of forum. Consider this the warning, in the future instead of cleaning them up, I will just start deleting them. We try to keep it pretty clean and professional here and your posts are ruining the decor :)  Thanks!

Sorry- I'll keep my posts normal from now on :)

mghoffmann:

You're mostly right.

Where am I slightly wrong?