Refactor/Remove `PropertyStore`

Background and motivation

We have had a few bugs caused by incorrect usage of PropertyStore. It’s clunky and we can use private backing fields instead. This would allow nullable annotations and compile time checks which would have prevented #8990

Also can look into using a dictionary instead to gain perf improvements. But

Issue raised based on comment: https://github.com/dotnet/winforms/pull/9503#pullrequestreview-1533416827

API Proposal

internal class PropertyStore
    {
        private sealed class ValueWrapper<T> where T : struct
        {
            public T Value { get; }

            public ValueWrapper(T value)
            {
                Value = value;
            }
        }

        private readonly Dictionary<int, object?> properties = new();

        private static int s_currentKey = 0;

        public static int CreateKey() => s_currentKey++;

        public void SetValue<T>(int key, T value) where T : struct
        {
            properties[key] = new ValueWrapper<T>(value);
        }

        public void SetObject<T>(int key, T value)
        {
            properties[key] = value;
        }

        public T GetValue<T>(int key) where T : struct
        {
            if (properties.TryGetValue(key, out var value) && value is ValueWrapper<T> wrapper)
            {
                return wrapper.Value;
            }

            return default;
        }

        public T? GetObject<T>(int key)
        {
            return properties.TryGetValue(key, out var value) && value is T tValue ? tValue : default;
        }

        public bool TryGetValue<T>(int key, out T? value) where T : struct
        {
            if (properties.TryGetValue(key, out var objValue) && objValue is ValueWrapper<T> wrapper)
            {
                value = wrapper.Value;
                return true;
            }

            value = default;
            return false;
        }

        public bool TryGetObject<T>(int key, out T? value) where T : class
        {
            if (properties.TryGetValue(key, out var objValue) && objValue is T tValue)
            {
                value = tValue;
                return true;
            }

            value = null;
            return false;
        }

        public bool Remove(int key) => properties.Remove(key);
    }

API Usage

N/A

Alternative Designs

No response

Risks

It is a large refactor and could cause subtle bugs. The current design is meant for performance reasons (I don’t understand why?).

Will this feature affect UI controls?

Controls will need testing.

[JeremyKuhne]

@elachlan ValueWrapper<T> is more trouble than it is worth. I was thinking of going as simple as possible:

internal class PropertyStore
{
    // Should set an appropriate capacity- what is typical for our controls?
    private readonly Dictionary<int, object?> _properties = new();

    private static int s_currentKey = 0;

    // What is our typical ratio of keys to used values? How much memory are we really saving?
    // Dictionary<TKey, TValue> is eating at least 12-16 extra bytes for everything we put in it.
    // We'd need to be something like 1 used value to 8 keys for this stuff to make any sense.
    //
    // We could potentially use a collection with less memory overhead, but that comes at significant
    // cost in additional complexity.
    //
    // If we can demonstrate that we don't save much memory, we're likely better off removing the
    // PropertyStore completely and utilizing fields. We can look at our field usages and optimize there.
    public static int CreateKey() => Interlocked.Increment(ref s_currentKey);

    public void SetValue(int key, object? value) => _properties[key] = value;
    public bool RemoveValue(int key) => _properties.Remove(key);

    public bool TryGetValue<T>(int key, out T? value)
    {
        if (!_properties.TryGetValue(key, out object? objectValue))
        {
            value = default;
            return false;
        }

        value = objectValue is null ? default : (T?)objectValue;
        return true;
    }
}

As mentioned in the comments above we really need to look at how much memory we’re actually saving with the current implementation. If we have 1000 live controls and are saving 32 bytes, that would be 32K of memory. 10,000 we’d save 320K. If we’re not saving several megabytes for 1000 controls, I don’t know that this complexity is worth maintaining. I’d rather see us gain the speed and simplicity and spend our time finding other ways to better use memory.

[elachlan]

@merriemcgaw can you please tag this to .NET9? Also I don’t think it is an API suggestion because PropertyStore is Internal? Do we need a full review or just a team sign off on the plan?