[+Haze]

yeah i updated my post after realizing the point u were making. im just doing this in preparation, and it doesn't really add much code. also other than changing access modifier, is there any benefit to using a public property over a public field?

Yes. A public property can have getters and setters whilst a public field cannot. Also, in all .NET lirabries I've seen, properties are almost always used. Field variables are normally only used within the scope of the class.

It may seem pointless to use a property over a public field when you don't need to have the full {get; set;} syntax, but it all derives from the olden days when getters and setters were a huge part of object-oriented programming. C# has evolved seen then and has provided a more succinct syntax.

[ＪＵＳＴＩＮ]

Yes. A public property can have getters and setters whilst a public field cannot. Also, in all .NET lirabries I've seen, properties are almost always used. Field variables are normally only used within the scope of the class.

It may seem pointless to use a property over a public field when you don't need to have the full {get; set;} syntax, but it all derives from the olden days when getters and setters were a huge part of object-oriented programming. C# has evolved seen then and has provided a more succinct syntax.

Well what I really meant is "also other than changing access modifier, is there any benefit to using a public property with auto get/set over a public field". Since I've read it's bad practice, I wont use them in my API wrappers from now on. I've written code with properties after I gravitated away from creating my own functions for getting/setting variables (like in Java) due to how verbose it is. In my own projects I typically use public fields in scenarios where the get/set wont be used. Anyway you're definitely right about .NET libs using properties, I've noticed that tendency. According to this post on StackOverflow (https://stackoverflow.com/questions/1180...properties) there are some benefits other than simply being able to easily implement get/set. I'll be sure to use them in my code more frequently from now on.

[0xDEAD10CC]

Yes, you've got the right idea. Your code could be simplified a bit more like this
https://pastebin.com/RMkmiUmi

You can use the shorthand auto property syntax because you're not really doing any processing or logic with the get and set methods. The only time you'd explicitly declare the get and set methods would be when you need to handle some logic when a property has been accessed or changed. Getters and setters were something more prevalent in Java due to its verbose syntax, but C# has a more syntactically less verbose option which is properties. Behind the scenes, auto properties still generate the full get and set methods, but the nicer syntax allows for cleaner code.

In regards to the JsonProperty, it's not all that necessary to explicitly put the JsonProperty attribute on all properties because Json.Net will recognize the ones that have a matching name, but ones with different names do have to use the JsonProperty attribute.

For naming consistency I would still apply JsonPropertyAttribute to all of the properties. If you don't, you'll have some lowercase and the rest will match the property names, which in this case are PascalCase and not all lowercase. Additionally, if you ever decided to change a property name, this won't break the serialization/deserialization naming when your identifier changes.

@OP: Going from auto-properties to fully defined ones is not a breaking change. Modifying the accessibility or including/excluding an accessor or mutator is however. This is why using properties is preferred in any kind of situation like this. They can (for the most part) behave exactly like your public field, but it's a lot more scalable if you need to use the getter or setter to do things in the future, and your users won't be mad that they have to re-write a bunch of code because doing so won't change anything on their end. When you get into writing more complex frameworks this is far more important to understand, especially if you're including properties as part of an interface.

This topic extends further than just framework design, even in your own code you can control immutability too using properties to prevent yourself from using your own classes incorrectly. Protected or private setters, or no setter at all, for properties that return a private readonly field that is set within a constructor -- just as one example. As another example, say you need to return a value depending on a certain condition... With a property, you can use the getter to conditionally branch that out without editing the field, and without having to write inline code everywhere you use that field to conditionally branch to return the special case value. They have all the same benefits that you could apply to a method, but in the context of specific pieces of information.

[ＪＵＳＴＩＮ]

@OP: Going from auto-properties to fully defined ones is not a breaking change. Modifying the accessibility or including/excluding an accessor or mutator is however. This is why using properties is preferred in any kind of situation like this. They can (for the most part) behave exactly like your public field, but it's a lot more scalable if you need to use the getter or setter to do things in the future, and your users won't be mad that they have to re-write a bunch of code because doing so won't change anything on their end. When you get into writing more complex frameworks this is far more important to understand, especially if you're including properties as part of an interface.

i'm aware of that, that's pretty much what i said. i stated that i included the private fields to maintain consistency if i need to add logic to a getter/setter in the future. it doesnt make the code any more complicated as is and its just slightly lmore verbose for the time being.

---

This topic extends further than just framework design, even in your own code you can control immutability too using properties to prevent yourself from using your own classes incorrectly. Protected or private setters, or no setter at all, for properties that return a private readonly field that is set within a constructor -- just as one example. As another example, say you need to return a value depending on a certain condition... With a property, you can use the getter to conditionally branch that out without editing the field, and without having to write inline code everywhere you use that field to conditionally branch to return the special case value. They have all the same benefits that you could apply to a method, but in the context of specific pieces of information.

well yes i've used properties for these things, just not in the context of anticipating changes for something like a library where (without properties) a change to an API can break your project alongside those of everybody else using your library

[0xDEAD10CC]

i'm aware of that, that's pretty much what i said. i stated that i included the private fields to maintain consistency if i need to add logic to a getter/setter in the future. it doesnt make the code any more complicated as is and its just slightly lmore verbose for the time being.

---

well yes i've used properties for these things, just not in the context of anticipating changes for something like a library where (without properties) a change to an API can break your project alongside those of everybody else using your library

What you said is not what I said at all. I stated that developers don't worry about consistency when it comes to automatic properties vs the more verbose but semantically identical equivalent--where you as the programmer manually define the backing field. Thus, there's essentially no discernible difference between these two snippets of code:

Code

public Type PropertyName { get; set; }

Code

private Type _propertyName;
public Type PropertyName {
  get { return _propertyName; }
  set { _propertyName = value; }
}

Depending on your code formatting preference, you can be wasting up to almost 10 lines of code for something that should really only be one. Evidently, people care about succinct code simplifications like these too, otherwise Microsoft wouldn't have created more features to compact property assignment all within the same line (among other things) in recent C# language versions.

Subsequently, there's no implications in terms of breaking changes when switching between the two, AND, with automatic properties, another important point is that you're less likely to interchangeably use the field and property within your own code which complicates the logic flow. So why are you worrying about that in your code? ❓ You're only unknowingly needlessly over-complicating what can be simplified. When we do peer code reviews at my company we look for all these things. This is why people use automatic properties over fields, because they can go from a { get; set; } which is hardly different from the implementation of a field, however switching to a custom getter or setter doesn't break anything for anyone implementing the framework.

With that clarified - I'm not sure why you even have private backing fields at all if you're not using it for anything more than what an automatic property would already do for you.

You also only updated one class but you left the rest of them using fields. :/ And your HF_API class has IDisposable members so it should therefore implement the IDisposable interface to reflect the appropriate disposable pattern for cleanup.

[ＪＵＳＴＩＮ]

@OP: Going from auto-properties to fully defined ones is not a breaking change. Modifying the accessibility or including/excluding an accessor or mutator is however. This is why using properties is preferred in any kind of situation like this. They can (for the most part) behave exactly like your public field, but it's a lot more scalable if you need to use the getter or setter to do things in the future, and your users won't be mad that they have to re-write a bunch of code because doing so won't change anything on their end. When you get into writing more complex frameworks this is far more important to understand, especially if you're including properties as part of an interface.

i'm aware of that, that's pretty much what i said. i stated that i included the private fields to maintain consistency if i need to add logic to a getter/setter in the future. it doesnt make the code any more complicated as is and its just slightly lmore verbose for the time being.

What you said is not what I said at all. I stated that developers don't worry about consistency when it comes to automatic properties vs the more verbose but semantically identical equivalent--where you as the programmer manually define the backing field.

I think you misunderstood what Haze was talking about in that first post. We weren't talking about going from auto-properties to fully defined ones being breaking or not, he was just pointing out that unless I'm actually adding logic to get/set there's no point of not using the autos.

With that clarified - I'm not sure why you even have private backing fields at all if you're not using it for anything more than what an automatic property would already do for you.

This is exactly what Haze was saying. I'll switch to using the autos for now until I have reason to use the get/set funcs.

You also only updated one class but you left the rest of them using fields

well yeah, it's not the master branch. i'll turn the rest into properties and merge to master before updating the nuget package.

And your HF_API class has IDisposable members so it should therefore implement the IDisposable interface to reflect the appropriate disposable pattern for cleanup.

good point, I'll add that

[0xDEAD10CC]

he was just pointing out that unless I'm actually adding logic to get/set there's no point of not using the autos.

Well then that's what I mean, yes. :)

But then again, even when switching from public fields to public properties with get/set, this wouldn't be a breaking change unless the property name was changed.

If you developed a more complex framework this wouldn't hold true. For instance, if you had interfaces that needed to use the properties/fields in question. You can't substitute one for the other without the interface implementation changing.

In your case however, this may be true, as long as people aren't using reflection on your fields for whatever reason. (Properties can't be treated the same way as normal fields in reflection.)

If you want your wrapper to be the best framework available out there though for now, you still have time to make corrections and improvements.

[ＪＵＳＴＩＮ]

In your case however, this may be true, as long as people aren't using reflection on your fields for whatever reason. (Properties can't be treated the same way as normal fields in reflection.)

ok well
1.) properties have diff membertypes during reflection
2.) data binding on properties
3.) out/ref args on fields
4.) access modifiers

aside from these, are there any other differences? just asking out of curiosity, even though it's a little out of context of this thread now

[0xDEAD10CC]

Within the context of library/framework design, all you need to think about is encapsulation for the most part and in a lot of cases you can avoid problems if your skillful at appropriately implementing those concepts.

[ＪＵＳＴＩＮ]

Within the context of library/framework design, all you need to think about is encapsulation for the most part and in a lot of cases you can avoid problems if your skillful at appropriately implementing those concepts.

I was just asking in general but yeah auto public properties should be good for now

[ＪＵＳＴＩＮ]

Just released version 1.2.0 using properties.
Also included a feature allowing you to bypass the captcha system that's enabled on the API (for some reason), so you can run your programs on a VPS/VPN. More information about that feature here: https://hackforums.net/showthread.php?ti...id58590656

[incelsubhuman]

For naming consistency I would still apply JsonPropertyAttribute to all of the properties. If you don't, you'll have some lowercase and the rest will match the property names, which in this case are PascalCase and not all lowercase. Additionally, if you ever decided to change a property name, this won't break the serialization/deserialization naming when your identifier changes.

@OP: Going from auto-properties to fully defined ones is not a breaking change. Modifying the accessibility or including/excluding an accessor or mutator is however. This is why using properties is preferred in any kind of situation like this. They can (for the most part) behave exactly like your public field, but it's a lot more scalable if you need to use the getter or setter to do things in the future, and your users won't be mad that they have to re-write a bunch of code because doing so won't change anything on their end. When you get into writing more complex frameworks this is far more important to understand, especially if you're including properties as part of an interface.

This topic extends further than just framework design, even in your own code you can control immutability too using properties to prevent yourself from using your own classes incorrectly. Protected or private setters, or no setter at all, for properties that return a private readonly field that is set within a constructor -- just as one example. As another example, say you need to return a value depending on a certain condition... With a property, you can use the getter to conditionally branch that out without editing the field, and without having to write inline code everywhere you use that field to conditionally branch to return the special case value. They have all the same benefits that you could apply to a method, but in the context of specific pieces of information.

Teaching basic SE principles to beginners in the .NET section is a waste of your time

[ＪＵＳＴＩＮ]

Teaching basic SE principles to beginners in the .NET section is a waste of your time

This is a matter of library design, not SE principles, and I'm not a beginner. When it comes down to it, normal variables can be changed to properties whenever logic needs to be implemented and that wont be a breaking change unless the project using your library implemented one of the concepts I mentioned in this post: https://hackforums.net/showthread.php?ti...id58579244

[doxerhacker]

This is a matter of library design, not SE principles, and I'm not a beginner. When it comes down to it, normal variables can be changed to properties whenever logic needs to be implemented and that wont be a breaking change unless the project using your library implemented one of the concepts I mentioned in this post:

SE principles -> SOLID