Develop Reference

Is it possible to get a property value within the getter for that property?

I have a basic test console app going with the following property:
public static string testString { get{ } set{ } }
I want to do a sort of singleton like setup with the property where if the property value is null, I initialize the property and return the property value. If it's not null, I return the current property value.
Bad practices aside, is this possible without using an additional variable?
Trying to check the value of the property within get{} using traditional means of course creates a stackoverflow exception. I presume each time it tries to check null it's just using the getter again and getting stuck in an infinite loop.

Properties are just syntax sugar for getter/setter methods. So there is no in-build storage behind them.
Properties can be used as if they are public data members, but they are actually special methods called accessors. This enables data to be accessed easily and still helps promote the safety and flexibility of methods.
Therefore you have to create a field or so.
(There are also auto-implemented properties, for which which the compiler creates backer fields automatically. But you do not have direct access to these fields anyway.)

Yes this is quite possible:
private static string _testString;
public static string testString {
get
{
return _testString = _testString ?? "MyDefaultValue";
}
set
{
_testString = value;
}
}
Adding a private field will do what you're wanting. While this may look like an additional variable, this is what actually occurs when your application gets compiled. No loss of optimization or performance.

What is the difference b/w public variable and public auto property [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Difference between Property and Field in C#
I know it is a very basic question but I cannot read any valid answer after searching
E.g
public string abc;
public string abc { get; set; }
Please describe this.

(About my terminology: "field" = public variable, "property" = get/set)
One thing to be mentioned additionally to the differences in usage: A property, unlike a field, gets compiled to a method (I think it's called something like get_abc internally). Declaring an auto property from beginning on has therefor two advantages:
1) No problems with reflection. If some reflection code is based on the value being a field, and later you think "well, now I'd like to add null testing" and change to a property, then the reflection code will eventally fail (unless you expected that in the reflection, but that would be extra effort for nothing imho)
2) "Warning" of possible side effects. Fields can only change their values, methods can do arbitrary things to a class. So, declaring a property from beginning on signalizes the possibility of other changes happening in the background. (Of course one shouldn't do weird stuff in a setter, but sometimes it isn't impractical to get additional initialization from one value provided; e.g. measuring the length of a list)
I also would say that it's good style to use properties wherever possible. Especially for the two reasons provided, but also for consistency.

Variables store direct value but property are a window to your class and its variables.
Even though they work the same(almost), one very good thing with field is that if you want to do some extra work with field (like validation or doing any calculations) you can do so.
This will explain you
public string _abc;
public string abc
{
get
{
return _abc;
};
set
{
if (value == null)
_abc = "";
else
_abc = value;
};
}
Here if null is passed to property abc then it will be checked it and an empty value will be assigned to _abc. otherwise value.
If we wanted this with a variable. every where we had to do this.
if(foo == null) // here foo is some string
_abc = ""
else
_abc = foo;
with property this can be done like
abc = foo;
Now it will check for in the set section of property.

Properties can contain some code on setting/getting the value. Public variables can't and will not contain any code when you access them. This is a huge difference.
Using a property you're saying to whomever uses you're code that there might be some code behind the value now or in the future.
Using a public variable you're saying its just a boring old field that will contain some value.

One reason for using an auto property instead of a Field is compatibility.
For example, when you assign a field, the CLR does just that. It sets the field.
When you have a property (auto or not), and you type
someObject.Whatever = "Value";
it looks like you are assigning a field, but in reality, the C# compiler inserts something like this for you:
someObject.set_Whatever("Value");
That's not the same as setting a field. And if you have a field and change it to a property later (e.g. if you want to implement change notifications or things like that), you will have to recompile all assemblies that used the original field, since assigning a Field requires different code than setting a property (no matter if auto or not).
There is almost never a reason to use a public field. Automatic properties can be inlined at runtime, so there would be no performance difference. And they leave the possibility open to add additional logic to your get / set methods without having to recompile dependent assemblies.

Same difference as a property over public variable such as property support binding but variable not.

can't I use TryGetValue and assign the value to a property?

I'm trying to do
myDic.TryGetValue("username", out user.Username);
but its not working.
is this not possible?

No, from the documentation:
"Properties are not variables and therefore cannot be passed as out parameters."
http://msdn.microsoft.com/en-us/library/t3c3bfhx.aspx

To continue John's answer, do this instead:
string username;
if (myDic.TryGetValue("username", out username))
{
user.Username = username;
}

You could do this in VB, but not C#.
VB will generate a temporary variable (on the stack), pass in it's address to the out value, and then do an assignment to the property after the method call.
Generally VB does this because it does lots of implicit stuff all over the place. That's just the way it works.
C#, on the other hand, tends to eschew implicitness as part of its philosophy. That's why, for example, you have to add "out" to the call site in order to get out parameters to work, and why it doesn't support "ref" parameters for the first argument to extension methods.
It would be possible to support properties here, using an explicit "out" syntax at the call site. However, I believe the reason they don't do this is because the trick VB uses does not behave exactly the same for properties as it does for fields. With a field, the assignment would take place immediately where it occurred inside the method. If there was other code in the method that read the field (by calling a method on the object), it would read the new field value assigned via the output parameter.
With properties, using the VB trick, the property doesn't get assigned until after the method returns. This means that any code that read the property directly after the out parameter assignment would read the old value.
Here's a simple example of what I mean:
class C
{
private int m_bar;
public int Bar { get { return m_bar; } set { m_bar = value; }}
void foo(out int x)
{
x = 2;
Console.WriteLine(Bar);
}
void DoStuff()
{
foo(out m_bar); //outputs 2
Bar = 0;
//pretend this works
foo(out Bar); //outputs 0
Console.WriteLine(Bar); // outputs 2
}
}
Inside DoStuff(), you would get different behavior for the first call to foo than you would from the second call to foo, although most folks would expect them to behave the same way.
Generally C# tries to avoid these types of things.
That's my guess as to why they don't support it (the spec just says that don't support, it doesn't really say why).

Question about c# optimizer

If I write:
SomeType simpleName = classWithLongName.otherLongName;
And then use "simpleName" instead of "classWithLongName.otherLongName", will this change the program in any way (for instance performance wise)?
What does the compiler do with this? Does it copy+paste "classWithLongName.otherLongName", everywhere I use "simpleName".

No, the C# compiler doesn't translate a call to "simpleName" to be the same as copying and pasting "classWithLongName.otherLongName". The difference could be profound or simply semantic, but what you're doing is assigning the value from classWithLongName.otherLongName to simpleName. Whether the type is a value type or a reference type will determine exactly what happens and what will happen if you manipulate that value, but you're not creating a function pointer or delegate in doing that.
Whether it will have an effect on performance really isn't something that can be answered here, other than to say that it won't have a NEGATIVE effect. We can't say if it will have a positive effect, since that would depend on what actually happens when you call classWithLongName.otherLongName. If that's an expensive operation, then this could make it faster, but the downside would be that any differences in value upon subsequent calls to classWithLongName.otherLongName wouldn't be reflected if you cached its value in simpleName.

It depends what "otherLongName" is actually doing. If it's a property, then the difference is between executing the property several times or only executing it once. That may or may not change the behaviour of the program in a significant way, depending on what it's doing.

The compiler is only allowed to cache the value and re-use it itself when you always type "classWithLongName.otherLongName" if it knows that the value will not change in the course. However, this is seldom the case.
Therefore, if "classWithLongName.otherLongName" does perform some computation, you'll usually get better performance by caching it manually in a local variable as you suggested. However, keep in mind that you are working with a cached value and that changes in the original value or property will not be reflected on your cached value.
The length of the name however is just metadata and has no influence whatsoever on runtime performance, since the name is already resolved to an internal handle during compilation.

Is this a question about instances or classes?
For instance
namespace MyCompany.MyApp.LongNamespaceName
{
public class MyClassWithALongName {
public SomeType AnInstanceProperty {get;set;}
public static SomeType AStaticProperty {get { ... }}
}
}
Now:
//this gets the static property
SomeType simpleName = MyClassWithALongName.AStaticProperty;
Alternatively:
MyClassWithALongName anInstanceWithALongName = new MyClassWithALongName();
//this gets the instance property
SomeType simpleName = anInstanceWithALongName.AnInstanceProperty;
These will behave in different ways.
There's another case here though, you can create an alias for the actual name of the class:
using simpleName = MyCompany.MyApp.LongNamespaceName.MyClassWithALongName;
...
simpleName anInstance = new simpleName ();

If classWithLongName.otherLongName is a property, than changes to simpleName will NOT change classWithLongName.otherLongName.
If classWithLongName.otherLongName is a public data member (a field) of a value type, than changes to simpleName will NOT change classWithLongName.otherLongName.
If classWithLongName.otherLongName is a public data member (a field) of a reference type, than changes to simpleName WILL change classWithLongName.otherLongName.

Assuming your type is an object (reference) type then simpleName will end up containing a reference to the object returned by classWithLongName.otherLongName. If you are then going to make lots of calls to properties on that object then you may get a performance improvement, especially if otherLongName is a property as opposed to a field.

You can always make it a function.
SomeType simpleName() { return classWithLongName.otherLongName; }

C# mimic overridding the assignment operator (=)

I've got a bit of a problem with a somewhat simple wrapper class I have.
It looks something like this:
public class Wrapper<T>
{
private T _value;
public Wrapper<T>(T value)
{
_value = value;
}
public static implicit operator Wrapper<T>(T value)
{
return new Wrapper<T>(value);
}
public static implicit operator T(Wrapper<T> value)
{
return value._value;
}
}
I've overriden the implicit converters from and to T, so it behaves almost like an instance of T itself.
e.g.
Wrapper<int> foo = 42;
However I've got a slight problem when assigning one instance of Wrapper to another, since I only want to assign the value of the second Wrapper class.
So right now, I have to do this:
Wrapper<int> foo = 42;
Wrapper<int> bar = (int)foo;
Or expose _value publicly through a property.
However since this is in a library, and I don't want the user to depend on remembering this, do you guys have any idea how I could mimic overridding the assignment operator ?
The problem in just changing the pointer (as it does when assigning a class instance to another), is that I've got a dictionary of pointers to these Wrapper objects, so I cannot have them changing all the time, since the dictionary would stop matching then.
I can see if this is somewhat confusing, so if I've left anything important out, please feel free to ask :-)

Since the assignment operator can't be overloaded, there isn't a real good solution. As somebody else pointed out, using a struct will give you the assignment semantics that you want, but then you're faced with value semantics--often not a good thing.
One option is to overload the constructor:
public Wrapper(Wrapper<T> w)
{
_value = w._value;
}
Which would result in this syntax:
Wrapper<int> foo = 42;
Wrapper<int> bar = new Wrapper<int>(foo);
Although more verbose than what you have, it reads better.
Or you could add a Clone method (not the ICloneable interface), so that you could write:
Wrapper<int> bar = foo.Clone();
You could get really creative and overload some operator, making it do essentially nothing. I wouldn't recommend that, though. Using operator overloading for those kinds of things typically makes code cryptic and often breaks.

You could make Wrapper<T> a struct. However I'm not sure if this would suit your application design or not.

If you look at Nullable<T>...which does a very similar thing to what you are doing here, it exposes the internal value using a .Value property.
The problem in just changing the pointer (as it does when assigning a class instance to another), is that I've got a dictionary of pointers to these Wrapper objects, so I cannot have them changing all the time, since the dictionary would stop matching then.
I'm not sure I follow this, what exactly are you storing in the dictionary? Because if you are storing references, the CLR will update them as necessary.

Don't implicitly cast your wrapper both ways.
public class DBValue<T>
{
public static implicit operator DBValue <T>(T value)
{
return new DBValue<T>(value);
}
public static explicit operator T(DBValue <T> dbValue)
{
return dbValue.Value;
}
private readonly T _value;
public T Value { get { this._value; } }
public DBValue(T value)
{
this._value = value;
}
}
Casting from DBValue<T> to T is a lossy conversion (as a minimum, you lose the fact that it's a value from the database), and by best-practice should be explicit. If you don't lose anything by casting from DBValue<T> to T, you might as well just use properties that return T.
Basically, you've already seen why you shouldn't be trying to do this: if a DBValue can be substituted for T and the other way around, how does the compiler (or developer) know which one to choose?
Requiring down-stream developers to write:
string value = MyProperty.Value
or
string value = (string)MyProperty
instead of
string value = MyProperty
...isn't all that onerous, and makes sure that everyone knows exactly what's going on.
EDIT:
To actually answer the question, you can't override reference assignment - or make it look like you have - but you shouldn't really need to.

This is what properties are for. They allow you to define what assignment means. You can't define it for a class or struct itself because they are already defined by the language to do necessary things. Just add a Value property to the class.
Alternatively, edit your question to give a broader description of your design and how this Wrapper fits into it, as someone may be able to suggest a simpler approach.

I just looked into it, making the class a struct is really not an option, since it has some logic in the parameterless constructor, plus it inherits an abstract class, which contains internal abstract functions.
I cannot use an interface, as that'd make those functions public, which would break the logic entirely.
I can post the entire class if that'd be helpful, but it's somewhat long (130 lines)
Or I could toss up on a seperate server, if that'd be better ? (though it hurts the integrity of this question, as I may delete it eventually from that server)
Also explaining the class is really difficult, without writing a complete essay :-/
Anyway I'll try to illustrate the problem I'm having.
Assume 2 table classes: CustomerTable and UserTable:
public class CustomerTable
{
Wrapper<string> Name;
}
public class UserTable
{
Wrapper<string> Name;
}
Now the problem is that some other developer, may use the above code as follows:
CustomerTable customer = new CustomerTable();
UserTable user = new UserTable();
user.Name = customer.Name; // This breaks my internal dictionary
What the developer should had done, in order for it to work, was:
user.Name = (string)customer.Name;
The problem is however, who in their right mind would think about that, when writing code ?
Even if I used a Value property, the developer would still have to remember to write
user.Name = customer.Name.Value; // or user.Name.Value = ....
And again the developer may forget this, and all of a sudden he gets exceptions, or worse: data which isn't persisted to the database.
So my issue is really, that I want the wrapper to be completely transparent (it should be usable as if it was in fact the class/primitive it's wrapping).
However when assigning from one wrapper to another, my internal logic breaks.
Phew a lot of writing, and a lot of code - let me know if I overdo the writing.

A J Lane I see what you mean, and I guess you're right - I just wanted to make it as simple as possible to use the library.
The reason for the implicit cast from DbValue to T, is to simply functions which expects T.
for example
literalSomething.Text = Server.HtmlEncode(SomeTable.SomeStringColumn);
rather than
literalSomething.Text = Server.HtmlEncode((string)SomeTable.SomeStringColumn);
This requires the cast to be implicit.
That being said I just read your comment whilst typing this, and I can see that's quite the issue.
I think I'll go back to exposing value through a property, it just requires the developer to type more, and kinda makes the code ugly I think.
Just imagine DbValue:
if (someValue.Value.HasValue) // someValue is DbValue<int?>
But then again it's probably better with "ugly" code, than code which behaves differently from what you'd expect by merely reading it.
I guess this question ends up as a "best practice" question really.
So to conclude, I'll create a Value property and use that instead of implicit casts, and the developer using the library will just have to live with that.
Thanks for your inputs :-)

This old post stills needs additional information to be complete. It's apparent that the original desired behavior cannot be accomplished since the = operator cannot be overloaded, and likewise C# cannot be "tricked" into casting an object to its own type... it will always boil down to a class reference assignment. But Steffen's further posts show the Wrapper class being used not just with local variables, but as a class field type. The desired semantics can be used AND the integrity of the internal dictionary maintained by using class properties instead of public fields.
Even keeping the original given Wrapper<T> class with both its implicit operators, here's code that would work:
public class CustomerTable
{
private Wrapper<string> _Name;
public Wrapper<string> Name {
get { return _Name; }
set { _Name = (string)value; }
}
}
public class UserTable
{
private Wrapper<string> _Name;
public Wrapper<string> Name {
get { return _Name; }
set { _Name = (string)value; }
}
}
If this change were made, it would not break existing code since it still allows various modes of setting the property:
CustomerTable customer = new CustomerTable();
UserTable user = new UserTable();
user.Name = customer.Name; //*** No longer breaks internal data structures
user.Name = "string literal"; // Works as expected with implicit cast operator
user.Name = (string)customer.Name; // Still allowed with explicit/implicit cast operator
user.Name = customer.Name.Value; // Also works if Value property is still defined
Because this still doesn't answer the original question, use of the Wrapper class could still be problematic if its used outside the class property context, i.e. passed between object, etc. Perhaps the entire Wrapper class could be eliminated with the proper class design, including use of property set/get accessors.