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

https://stackoverflow.com/questions/8107134/how-set-value-a-property-selector-expressionfunct-tresult
Вот здесь народ изгалялся. В принципе если кэшировать по типу и свойству должно быстро работать

Здравствуйте, VladD2, Вы писали:
VD>Поля передаются по ссылке. Делаешь универсальный метод в классе и дело в шляпе.
Повторяю вопрос: занафига тогда заводить свойство, если наружу всё равно торчит поле?

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

S>Повторяю вопрос: занафига тогда заводить свойство, если наружу всё равно торчит поле?

Не хочу повторяться:

Поля передаются по ссылке. Делаешь универсальный метод в классе и дело в шляпе.

где тут поле торчит?

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

Используй ref свойство!
https://gist.github.com/mgravell/c46a1de553abe325dea0c44ac7fa7766

Здравствуйте, VladD2, Вы писали:
VD>Не хочу повторяться:
VD>

VD>Поля передаются по ссылке. Делаешь универсальный метод в классе и дело в шляпе.

VD>где тут поле торчит?
Там, откуда оно передаётся по ссылке.
Что за универсальный метод будет в классе?

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

Угу, плюсовый подход.


S>

S>public abstract class Weird
S>{
S>    public abstract string? Apply(string? value);
S>

Я бы сделал Apply protected.

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

S>Можно напилить библиотеку string transformations, которая построена на перегрузке операторов. Использовать "<<" не выйдет, но оператор & не намного хуже.

В плюсах в либах трансформации обычно используют operator|

Здравствуйте, vdimas, Вы писали:
V>В плюсах в либах трансформации обычно используют operator|
А можно посмотреть на пример такой либы? Как там вообще что устроено.

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

V>>В плюсах в либах трансформации обычно используют operator|
S>А можно посмотреть на пример такой либы?

Одна из таких популярных — Boost.Range.
Это набор концептов/адаптеров/алгоритмов для связи всего со всем через итераторы.

Живой пример:

#include <boost/range/algorithm.hpp>
#include <boost/range/adaptors.hpp>
#include <boost/phoenix.hpp>

#include <iostream>

using namespace boost::phoenix::arg_names;
using namespace boost::adaptors;
using namespace boost;
using namespace std;

int main() 
{
    vector<int> const     input  { 1, 2, 3, 4, 5, 3 };
    ostream_iterator<int> output { cout, ", " };

    range::copy(input | filtered(arg1 % 2) | transformed(arg1 * 7) | reversed | uniqued, 
                output);
            
    return 0;
}

Раздел доки про адаптеры:
https://www.boost.org/doc/libs/1_82_0/libs/range/doc/html/range/reference/adaptors/introduction.html

Полная дока либы:
https://www.boost.org/doc/libs/1_82_0/libs/range/doc/html/index.html


S>Как там вообще что устроено.

Если вопрос про синтаксис, то примерно как и у тебя — вводится доп. тип сугубо для оператора пайпа (по аналогии с передачей данных через stdio в консольных программах).
Каждый адаптер идёт в двух вариантах:

Syntax	Code
Pipe	rng | boost::adaptors::filtered(pred)
Function	boost::adaptors::filter(rng, pred)

Верхний "модный" вариант раскрывается в нижний классический.

Результатом применения адаптера является объект-ренж — это объект такого типа, для которого определены операции begin(rng) и end(rng), т.е. у которого можно получить пару итераторов.

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

S>Использовать "<<" не выйдет

Почему не выйдет? Relaxing shift operator requirements, Пример

Здравствуйте, _FRED_, Вы писали:
_FR>Почему не выйдет?
Потому что у этого оператора слева должен быть custom type. А нам нужно, чтобы слева была строка.
Ведь compound assignment раскрывается из x op= Smth в x = x op Smth.

Здравствуйте, Serginio1, Вы писали:
S>https://gist.github.com/mgravell/c46a1de553abe325dea0c44ac7fa7766
Это — плохая идея.
Кто угодно со ссылкой на объект может менять такое свойство так, как захочется.
С такой семантикой проще отказаться от свойства и выставить наружу голое поле.

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

S>Здравствуйте, Serginio1, Вы писали:
S>>https://gist.github.com/mgravell/c46a1de553abe325dea0c44ac7fa7766
S>Это — плохая идея.
S>Кто угодно со ссылкой на объект может менять такое свойство так, как захочется.
S>С такой семантикой проще отказаться от свойства и выставить наружу голое поле.

Ну и обычное свойство ты можешь менять через set_PropertyName.
Ну и не голое поле, а ref поле. Большой разницы нет. Просто обычно поля не публичны, а свойства публичны через тот же {get;set}

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

S> Ну и обычное свойство ты можешь менять через set_PropertyName.
Нет, там вызовется мой сеттер, который может проверять и гарантировать инварианты.
S>Ну и не голое поле, а ref поле. Большой разницы нет. Просто обычно поля не публичны, а свойства публичны через тот же {get;set}
Свойства публичны не через get/set, а через модификатор public. Как, впрочем, и поля.
Я могу себе представить сценарий, что мы объект готовим для подачи в какой-то библиотечный код, который принципиально не умеет работать с FieldInfo, а требует всенепременно PropertyInfo.
Но даже в таком сценарии шансы на то, что этот внешний код готов к ref-свойству — нулевые.

Так что реф-свойство в данном случае — фикция.
Ну, и, опять же, решение является интрузивным. То есть оно требует изменения дизайна всех классов, задействованных в задаче. Что, в свою очередь повлечёт непредсказуемое количество последствий.
Где-то у свойства был нетривиальный сеттер; где-то класс надо было отдавать в биндинг гуя, не умеющий работать с ref string, где-то ещё что-то отвалится.

Как и замена свойства на поле — слишком много усилий для слишком маленького выигрыша.

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


S>Так что реф-свойство в данном случае — фикция.
S>Ну, и, опять же, решение является интрузивным. То есть оно требует изменения дизайна всех классов, задействованных в задаче. Что, в свою очередь повлечёт непредсказуемое количество последствий.
S>Где-то у свойства был нетривиальный сеттер; где-то класс надо было отдавать в биндинг гуя, не умеющий работать с ref string, где-то ещё что-то отвалится.

S>Как и замена свойства на поле — слишком много усилий для слишком маленького выигрыша.

Ну свйство на самом деле внутри может вызывать некий метод, возвращающий ref structure например
https://learn.microsoft.com/ru-ru/dotnet/api/system.span-1.item?view=net-7.0

public ref T this[int index] { get; }

Здравствуйте, Serginio1, Вы писали:
S> Ну свйство на самом деле внутри может вызывать некий метод, возвращающий ref structure например
S>https://learn.microsoft.com/ru-ru/dotnet/api/system.span-1.item?view=net-7.0
S>

S>public ref T this[int index] { get; }
S>

Это я всё понимаю — просто мы говорим не о ref-свойствах вообще, а об их применении для решения конкретной задачи.
И вот сюда они как раз не подходят.