навеяно по большей части C#
ведь проперя укмеют всё что нужно и даже больше и гибче

у них можно управлять:
уровнем доступа
сопособностью гетить/сетить
уровнем доступа к гет/сет

если нужна сложная логика и нужен доступ к текущему значению можно добавить какоето ключевое слово типа own

int Prop
{
    get; // по умолчанию выполняется return own;
    set
    {
        if(own != value;)
        {
            own = value;
            Update();
        }
    }
}

если own в коде не встречается а get и set не тривиальные, то память под own не выделяется потому что данная пропертя это просто две функции

а объявление в стиле
int A;
будет просто равносильно
private int A{ public set; public get; }

в итоге получается обычные мемеберы не нужны вообще.

скорее проперти не нужны..

когда обьект меняется сеттерами-геттерами, то нужно прикладывать нехилые усилия по поддержки консистентности состояния обьекта
поэтому самое гламотное решение — поля задаются только в конструкторе, они публичные и доступны только для чтения
конечно, мегаперфоманса тут ждать не приходится в работе с такими обьектами, а с другой стороны когда это C# работал с большими данными и мегаперфомансом? мне кажется, наоборот, быстрее все только станет, когда уберутся ненужные вызовы апдейтов, которые часто по нескольку раз дергаются не в тему

Здравствуйте, Kingofastellarwar, Вы писали:



K>в итоге получается обычные мемеберы не нужны вообще.
Property=get+set функции, field=одно поле. Если исспользовать всегда функции для установки значений, то хз, какая тогда вообще будет производительность и сколько оно будет потреблять оперативки.
И в set/get писать логику -это зло.

Здравствуйте, _ichensky, Вы писали:

_>Здравствуйте, Kingofastellarwar, Вы писали:



K>>в итоге получается обычные мемеберы не нужны вообще.
_>Property=get+set функции, field=одно поле. Если исспользовать всегда функции для установки значений, то хз, какая тогда вообще будет производительность и сколько оно будет потреблять оперативки.
_>И в set/get писать логику -это зло.

это для программера это функции, а компилятор легко переведет это просто к адресу в памяти там где тривиальный доступ

K>если нужна сложная логика и нужен доступ к текущему значению можно добавить какоето ключевое слово типа own
за логику в гет/сет надо ставить к стенке.
K>в итоге получается обычные мемеберы не нужны вообще.
Мне нравится как в Котлине сделано с конструкторами, когда автоматом можно создать проперти.

Здравствуйте, Kingofastellarwar, Вы писали:

K>навеяно по большей части C#
K>ведь проперя укмеют всё что нужно и даже больше и гибче.

Ну так полно ж сценариев "нужно обратиться к полю в обход свойства". Первый пришедший в голову пример: геттер лениво инициализирует значение, нужно узнать, получено оно уже или нет.

Только не надо предлагать завести ещё одно приватное свойство с примитивными геттером-сеттером. По сути это будет попытка переизобрести поля после того, как от них отказались.

Это с практической точки зрения. С концептуальной — поля и свойства принципиально разные вещи и нефиг пытаться имитировать одно через другое

Здравствуйте, Kingofastellarwar, Вы писали:

так делать не стоит по крайней мере по трём причинам:

1) Interlocked.Decrement(ref <<---- вот из-за этого ключевого слова
2) Компилятор имеет право на reordering над полями (см. C# memory model), но не имеет этой привилегии для функций: вы ему руки связывает в плане оптимизаций.
3) Поля не должны использоваться для сериализации, а свойства могут. Сериализация может неожиданно появиться там, где вы этого не будете ждать. Например, в тот момент, когда в софтине появится больше одного домена.
4) При повсеместном использовании свойств, наследники могут определить свойства с точно таким же именем, что может привести к неожиданным последствиям.