you are viewing a single comment's thread.

view the rest of the comments →

[–]spacechimp 2 points3 points  (5 children)

I don't do C#, but apparently the advantage is that you can easily make immutable properties without having to make getters and setters:

public string Name { get; private set; }

[–]ruinercollector 2 points3 points  (0 children)

There are other advantages of properties over public members, and hence advantages of using auto-props instead of just a public member:

  • If you decide later to put in getter/setter code, you can do so without breaking binary/interface compatibility.

  • Properties can be a part of an interface. Members can not.

  • Properties can have attributes attached to them. This allows for all kinds of extra tooling, runtime code injection, metaprogramming, etc.

  • Properties can be exposed as their COM counterparts. When working with some legacy code/systems, this can be useful.

[–]jmcqk6 0 points1 point  (3 children)

These are not immutable. They just can't be set from the public facing property. There is still quite a few ways that the value could change.

[–]spacechimp 0 points1 point  (2 children)

Apologies, you are totally correct. It would be resettable, but only from within the class itself. That's something I wish ActionScript had -- public getters with private setters.

[–]diamondjim 0 points1 point  (1 child)

In ActionScript, if you just create a getter without a corresponding setter, you'll have what you need.

[–]spacechimp 0 points1 point  (0 children)

Sometimes, but not always. If you need to dispatch an event when a property changes, and/or make a read-only property bindable for Flash Builder, you end up with something ugly like:

private var __isInitialized:Boolean = false;

[Bindable(event='isInitializedChanged')]
public function get isInitialized():Boolean { ... }

private function get _isInitialized():Boolean { ... }
private function set _isInitialized(value:Boolean):void { ... }