Почему нельзя сделать половинчатое автосвойство?

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

S>Почему нельзя сделать половинчатое автосвойство?

А чем не устраивает?

public A { private get; set; }

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

S>Почему нельзя сделать половинчатое автосвойство?
А каков сценарий использования такого свойства?

Здравствуйте, MxMsk, Вы писали:
MM>А каков сценарий использования такого свойства?

user u = users_repository.get( ... );
u.password = "blahblah";

пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

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

IB>Здравствуйте, MxMsk, Вы писали:
MM>>А каков сценарий использования такого свойства?

IB>user u = users_repository.get( ... );
IB>u.password = "blahblah";

IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

Я выше предложил вариант.

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

IB>Здравствуйте, MxMsk, Вы писали:
MM>>А каков сценарий использования такого свойства?

IB>user u = users_repository.get( ... );
IB>u.password = "blahblah";

IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

public string Password
{
    set { .... }
    get { throw new InvalidOperationException("Password can not be read."); }
}

Как-то так.

Сначала думал использовать NotSupportedException, но тут по идее не не поддерживается, а не допускается. InvalidOperationException больше подходит.

Здравствуйте, ilya.buchkin, Вы писали:
IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

А почему, в свою очередь, нельзя сделать
user u = users_repository.get( ... );
u.setPassword("blahblah");

За свой короткий срок написания ПО, пришел к выводу, что решения, подобные Вашему суть дефекты.

Здравствуйте, ilya.buchkin, Вы писали:
IB>u.password = "blahblah";
IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
Так ТС про автосвойство говорит, без кастомной логики в сеттере.

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

S>Почему нельзя сделать половинчатое автосвойство?
А зачем оно такое нужно?
Зачем нужно устанавливать свойство, которое не содержит логики и которое никто не может прочитать?
В случае не обычного свойства (не авто, с переменной) половинчатое свойство вполне можно сделать.

А вообще — на троллинг смахивает...

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

W>Здравствуйте, ilya.buchkin, Вы писали:
IB>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
W>А почему, в свою очередь, нельзя сделать
W>user u = users_repository.get( ... );
W>u.setPassword("blahblah");

конечно, "можно"... вопрос — почему нужно? т.е. почему нельзя (или чем именно плохо) то, что у меня.

W>За свой короткий срок написания ПО, пришел к выводу, что решения, подобные Вашему суть дефекты.

объясните? (каюсь — мой пример не из практики; действительно интересно, чем плохим он заканчивается.)

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

S>Почему нельзя сделать половинчатое автосвойство?

Потому что вы не сможете достать из него значение, не прибегая к рефлексии и не завязываясь на текущую реализацию компилятора.

Впрочем, обычные свойства с одним setter'ом — тоже не лучшее решение. FDG -Property Design:

Do not provide set-only properties.

If the property getter cannot be provided, use a method to implement the functionality instead. The method name should begin with Set followed by what would have been the property name. For example, AppDomain has a method called SetCachePath instead of having a set-only property called CachePath.

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

IB>user u = users_repository.get( ... );
IB>u.password = "blahblah";

IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

Вот интересно, что за фича — записать можно, а прочесть нельзя.

Вот, к примеру, записал ты в свойство пароль. А потом тебе надо этот парол отправить на сервер. Откуда возьмешь его если свойство прочесть нельзя ?

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

IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
И что прикажете с этим делать потом? Нафига что-то записывать куда-то, откуда это что-то нельзя потом прочитать?

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

I>Здравствуйте, ilya.buchkin, Вы писали:

IB>>user u = users_repository.get( ... );
IB>>u.password = "blahblah";

IB>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

I>Вот интересно, что за фича — записать можно, а прочесть нельзя.

I>Вот, к примеру, записал ты в свойство пароль. А потом тебе надо этот парол отправить на сервер. Откуда возьмешь его если свойство прочесть нельзя ?

Ниоткуда. В клиентском софте не нужен пароль в открытом виде.

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

MM>Здравствуйте, ilya.buchkin, Вы писали:

IB>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
MM> И что прикажете с этим делать потом? Нафига что-то записывать куда-то, откуда это что-то нельзя потом прочитать?

Пароль во многих современных системах, фактически, write-only. В открытом виде его не хранят. Следовательно, прочесть его невозможно.

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

I>>Вот, к примеру, записал ты в свойство пароль. А потом тебе надо этот парол отправить на сервер. Откуда возьмешь его если свойство прочесть нельзя ?

AS>Ниоткуда. В клиентском софте не нужен пароль в открытом виде.

Т.е. свойство исключительно для того, что бы можо было его установить, безо всякой полезной функции ?

Нахрена тогда свойство нужно ?

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

AS>Пароль во многих современных системах, фактически, write-only. В открытом виде его не хранят. Следовательно, прочесть его невозможно.
Ну круто. Я таки снова попрошу сценарий использования такого свойства (мы говорим об автосвойствах, конечно же).

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

I>Здравствуйте, Aen Sidhe, Вы писали:

I>>>Вот, к примеру, записал ты в свойство пароль. А потом тебе надо этот парол отправить на сервер. Откуда возьмешь его если свойство прочесть нельзя ?

AS>>Ниоткуда. В клиентском софте не нужен пароль в открытом виде.

I>Т.е. свойство исключительно для того, что бы можо было его установить, безо всякой полезной функции ?

Полезная функция свойства в том, что оно позволяет изменить пароль, если надо. И не позволяет его прочитать. В этом тоже польза.

I>Нахрена тогда свойство нужно ?

Да, в этом плане логичнее бы выглядел метод ChangePassword, но write-only свойство тоже норм.

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

MM>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Пароль во многих современных системах, фактически, write-only. В открытом виде его не хранят. Следовательно, прочесть его невозможно.
MM>Ну круто. Я таки снова попрошу сценарий использования такого свойства (мы говорим об автосвойствах, конечно же).

А чем использование обычного свойства отличается от использования автосвойства?

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

AS>А чем использование обычного свойства отличается от использования автосвойства?
В обычном свойстве сеттер может быть не пустой и на запись пароля можно хоть как-то прореагировать, хэшировать, например. У автосвойства тело сеттера — это простая запись в "невидимую" переменную, которую генерирует компилятор. Какой прок от этого действия?