Search Feedback

389
votes
Declined

Scripting: C#: expose properties to editor

Scripting

-

-

C# programmers will love it :)

Today, public variables are exposed to editor, like this:
public float SomeVariable;

However, my sugestion is that in C# we could use public properties with public getter and setter too, like this:
private float someVariable;
public float SomeVariable { get { return someVariable; } set { someVariable = value; } }

This will improve a lot some logics, and will use one of the most useful features of C# language.

Response avatar

Tak

Nov 10, 2014

This isn't likely to happen any time soon.
The workaround that Nicholas posted is usable for simple cases, and http://docs.unity3d.com/ScriptReference/ISerializationCallbackReceiver.html for more complex cases.

Comments (27)

  1. 7138eeb0ab295da6d962fa40844981bb?d=mm

    Moonblade-Studios

    Apr 09, 2017 16:58

    and that's why c++ friend classes rules :P

  2. 14579b1cd8bb75b9b732d405f545dd8c?d=mm

    vexe

    Sep 18, 2014 10:29

    I'd like to share my solution (free) http://forum.unity3d.com/threads/free-showemall-extensive-set-of-property-drawers-serialize-interfaces-generics-auto-properties.266165/

    exposes properties, methods, etc. as well as serialization for auto properties, interfaces, generics and abstract system objects

  3. 74c7998d446936399f6642a1a98d6615?d=mm

    IntDev

    Jun 10, 2014 11:37

    And if your property has only 'get', it should be displayed as read only.

  4. 1df9bcbf690b998fcc7dcd20518a4196?d=mm

    Wisteso

    Mar 24, 2014 01:15

    I think that implementing this feature is fairly essential for having solid bug-free code. Right now, I'm forced to use private variables and then annotate them with [SerializeField] but even with that hack, I still cannot perform additional processing on get/set operations (such as input validation) on data without writing some pretty kludged code.

    To those saying it's slower, I would like to remind you that even if it is slower, it will still be optional. Also, most code in the game loop does not need to be highly optimized. Code that is run a few times per game update can be horribly inefficient and not cause any noticeable slowdown. The "critical section" of code is what matters most, and this change would not affect that.

  5. Ee24023e26ed5539548cbb41988e96f6?d=mm

    Jes28

    Jun 05, 2013 17:19

    >>>Jordan Pickwell
    >>>Because properties are really just methods, over using them can potentially slow down the engine. I don't like
    >>>using public fields, but I know that they're faster (performance) than properties.

    It is wrong. JIT compiler do inline all methods that smaller than 32 bytes of IL.

    from http://blogs.msdn.com/b/davidnotario/archive/2004/11/01/250398.aspx :
    A typical example of a really good candidate for inlining is a property getter/setter. These are usually really small methods that usually just do a memory fetch or store, so it's usually a size and speed win to inline them.

  6. 33d41d3d23a0eb581567e0e2b5b930f7?d=mm

    aWarlt

    Apr 12, 2013 03:13

    I've always used properties and was GUTTED when i started with unity that they wernt supported. Definitely!!

  7. A87c4a0dfc984c84ea19f6bedfc21acf?d=mm

    DanielSig

    Nov 16, 2012 16:37

    This could be dangerous if it's not done right. The getter and setters would need to be called using child threads and the main thread needs to keep track of a timeout and terminate the other threads if they surpass it. This could eliminate the worry of accidentally making an infinite loops or too slow getters and setters (recursion anyone?)

    It would also be nice if Unity would simple detect if the property was only returning and assigning a private variable and then it would serialize that private variable instead.

    e.g. instead of serializing this and performing numerous pointless function calls
    [System.Serializable]
    public float Health{ get{ return _health; } set{ _health = value; }}

    it should simply serialize this variable instead
    private float _health;

  8. C6768f8be92fe851f2a5502fb9845778?d=mm

    caue

    Jun 21, 2012 17:02

    As Keld said, Nicholas's script won't call the setter from Property Inspector.

  9. 11a10f1e9d25e7d72c69437492a0e9f5?d=mm

    Greg Quinn

    Jun 13, 2012 10:51

    Please! Must have feature.

  10. 1ce5eac95b395eec88959ee667d25316?d=mm

    Jordan Pickwell

    May 02, 2012 22:28

    I would also like to see properties be visible in the inspector. But I also understand that C# properties are syntactic sugar for get/set methods. The C# compiler generates methods, replacing all uses of a property with its respective get/set methods. Because properties are really just methods, over using them can potentially slow down the engine. I don't like using public fields, but I know that they're faster (performance) than properties.

Your opinion counts

Help us make things better. Share your great idea for improving Unity or vote for other people’s.

Log in to post a new idea

Categories

All

(11030)

2D

(290)

Ads

(63)

AI & Navigation

(83)

Analytics

(130)

Animation

(413)

Asset Store

(370)

Asset Store Publisher

(21)

Assets

(557)

Audio

(185)

Cloud Build

(154)

Collaborate

(70)

Docs & Tutorials

(251)

Editor

(2579)

Everyplay

(17)

Game Performance Reporting

(22)

General

(1003)

Graphics

(903)

GUI

(447)

Input

(173)

Licensing

(93)

Networking

(192)

Physics

(392)

Platforms

(448)

Profiling & Optimization

(84)

Runtime

(188)

Scripting

(1154)

Terrain

(177)

WebGL

(145)