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

FR>В D очень интересно свойства сделаны. Чистейший синтаксический сахар над функциями без аргументов и такой же функцией с одним аргументом и возвращающей тот же тип что и аргумент(если одной из функций нет, то будет или realonly или writeonly свойство):

Это действительно интересно, но не более Типа, у многих есть анонимные функции, а сантехники изголились и сделали целые анонимные классы. Решение интересное, но назвать его удачным язык не поварачивается.

Andrei N.Sobchuck,

LCR>>Свойства можно считать перегрузкой неявных операторов "взять значение" и "положить значение". Когда ты пишешь
LCR>>

LCR>>a.x = 5;
LCR>>

LCR>>то эту операцию можно мыслить как
LCR>>

LCR>>a.x._set_( 5._get_() );
LCR>>

ANS>Можно, но не нужно. А если именно нужно, то тяжело вам там в С#. Это во-первых.
Нет, тяжело нам там в Java, где свойства есть только в качестве соглашений. В C# ситуация полегче.

ANS> Во-вторых, мне эти аналогии кажутся притянутыми за уши. По-этому сформулируй правило, когда используются методы, а когда свойства. Например:
ANS>* Свойства используются вместо методов с одним параметром
ANS>И когда сформулируеш правило так же мне объясни, если у меня есть метод который возвращает строку — конкатенированое значение полей класса — то это должно быть ro свойство, обычный метод, некий унарный оператор? С обоснованием.
ANS>... И с операторами есть один момент. Арифметические операторы не мутирующие. Но, компилятор, увы, гарантий никаких не даёт. По-этому, для операторов, по крайней мере, можно сформулировать правило: их применять нельзя, если у метода есть побочные эфекты. Жду правило для свойств.

Оки-доки. Решение о том, будет ли "XXX" свойством или нет должно определяться на основании предполагаемого использования класса.

Моё видение свойств: чистый (т.е. side-effect free) эффективный доступ к данным.

Следствия:
В свойствах нежелателен доступ к несвязанным со этим свойством данных.
В свойствах нежелательно выполнение длительных операций.
В свойствах не рекомендуется броски исключений.

Как только ни одно из следствий не выполняется, то это свойство должно быть рассмотрено как кандидат для конвертации в метод.

LCR>Если все неявные вызовы методов писать в виде явных вызовов, то программа потеряет во всём, и я привёл соответствующий пример.
ANS>ST живёт и ничего. А пример был так себе, не убедительно Вот с BigInteger более жизненно. Увы, это всего лишь один случай.
Ну можно ещё написать MyDouble1, где не будет арифметических нулей, или MyDouble2, где не будет ошибок округления при выполнении арифметических операций, или MyDouble3, где числа 0.9999999.. и 1 будут представлять одно и то же число и т.п. Так что не согласен насчёт одного случая. Ну и конечно nth-мерный массив всегда

Да кста, не мог бы ты привести пример как ST живёт, и как там "a (+|-|*|%) b" в виде вызова метода поживает?

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

LCR>Нет, тяжело нам там в Java, где свойства есть только в качестве соглашений. В C# ситуация полегче.

Это одна из тех немногих вещей, что мне нравится в Жабке

LCR>Оки-доки. Решение о том, будет ли "XXX" свойством или нет должно определяться на основании предполагаемого использования класса.

LCR>Моё видение свойств: чистый (т.е. side-effect free) эффективный доступ к данным.

LCR>Следствия:
LCR>В свойствах нежелателен доступ к несвязанным со этим свойством данных.

??? То есть свойство всегда должно быть связано с одним полем?

LCR>В свойствах нежелательно выполнение длительных операций.

fire event можно делать или нельзя?

LCR>В свойствах не рекомендуется броски исключений.

Хм. А о (не)валидности как сигнализировать?

LCR>Как только ни одно из следствий не выполняется, то это свойство должно быть рассмотрено как кандидат для конвертации в метод.

маловато будет. Не совсем понятно, какая функциональность в них может быть и чем это будет отличаться от прямого доступа к полям?

ЗЫ Подключайтесь, господа. Сформулируйте, в конце концов, какая суть свойства (я не имею в виду определение типа "свойство это нечто у чего есть либо геттер, либо сеттер, либо и то и то"). Кстати, когда-то видел упоминание того, что C# легко с COM работает благодаря свойствам. Работа с легаси — согласен, хорошая причина. Но хотелось бы более "современного" объяснения.

ЗЫЫ Видел еще одно обяснение: если использовать аксесоры, то возникает отличие в синтаксисе. То есть внутри методов класса используется синтаксис доступа к полям, а с наружи — вызов методов-аксесоров. А это, типа, неудобно. А как по мне, то это самое оно. Так и должно быть.

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

LCR>Да кста, не мог бы ты привести пример как ST живёт, и как там "a (+|-|*|%) b" в виде вызова метода поживает?

А эти значки это имена сообщений и есть. В ST есть 3 типа сообщений:
* унарные — не имеют параметров, напр. 3 sqrt — отправка числу 3 сообщения #sqrt.
* бинарные — с хитрозначками, всегда имеют ровно один параметр, зачастую в диалектах присутствуют различные ограничения на имена таких сообщений, так, в VisualWorks максимальная ддлина бинарного сообщения — два значка. Пример: 3 + 4 — отправка числу 3 сообщения #+ с одним аргументом — 4, или 'qwerty' , 'asdfg' — отправка строке (коллекции) 'qwerty' сообщения #, с аргументом 'asdfg', результат выполнения метода — конкатенация.
* ключевые — любое количество аргументов. Напр. aDictionary at: x — отправка сообщения #at: с одним аргументом x, aDictionary at: x ifAbsentPut: [Object new] — отправка сообщения #at:ifAbsentPut: с двумя аргументами.

Первым стоит всегда получатель сообщения, все методы всегда возвращают значение, если возвращаемое значение не указано, то нейвно возвращается self (типа this). Бинарные сообщения это именно сообщения, а не операторы, и никаких спец приоритетов у них нет. То есть a+b*c это (a+b)*c. Приоритеты разные только у разных типов сообщений — унарные наивысший приоритет, потом бинарные, и у ключевых наинизший. Круглые скобки традиционно используются для управления порядком вычисления.

Andrei N.Sobchuck,

LCR>>Моё видение свойств: чистый (т.е. side-effect free) эффективный доступ к данным.

LCR>>Следствия:
LCR>>В свойствах нежелателен доступ к несвязанным со этим свойством данных.
ANS>??? То есть свойство всегда должно быть связано с одним полем?
Свойство может быть связано со множеством полей.

LCR>>В свойствах нежелательно выполнение длительных операций.
ANS>fire event можно делать или нельзя?
Зависит от. Обычно можно.

LCR>>В свойствах не рекомендуются броски исключений.
ANS>Хм. А о (не)валидности как сигнализировать?
Если ситуация с невалидными данными — достаточно редка, то можно использовать свойство. Если данный прилетают извне, то валидацию следует проводить в методе.

Вообще, в этом случае работает правило: Данные извне должны проверяться на корректность. Как только они попали внутрь системы, они должны быть корректными, и внутреннее мясо работает в предположении, что данные корректны.

LCR>>Как только ни одно из следствий не выполняется, то это свойство должно быть рассмотрено как кандидат для конвертации в метод.

ANS>маловато будет.
Практически больше и не надо.

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

LCR>>>В свойствах нежелателен доступ к несвязанным со этим свойством данных.
ANS>>??? То есть свойство всегда должно быть связано с одним полем?
LCR>Свойство может быть связано со множеством полей.

Как это увязывается с твоим начальным утверждением? Как устанавливается связанность со свойством?

LCR>>>В свойствах нежелательно выполнение длительных операций.
ANS>>fire event можно делать или нельзя?
LCR>Зависит от. Обычно можно.

Но время работы то будет неопределено.

LCR>>>В свойствах не рекомендуются броски исключений.
ANS>>Хм. А о (не)валидности как сигнализировать?
LCR>Если ситуация с невалидными данными — достаточно редка, то можно использовать свойство. Если данный прилетают извне, то валидацию следует проводить в методе.

А почему не вызывать метод валидации из свойства?

ANS>>маловато будет.
LCR>Практически больше и не надо.

"Ниччё не понимаю" (с) следствие ведут колобки. Я таки настаиваю на объяснении сути свойств. А то пока я только понял, что у них синтаксис удобный, а отчего, почему — не ясно.

Lazy Cjow Rhrr wrote:
> LCR>>Следствия:
> LCR>>В свойствах нежелателен доступ к несвязанным со этим свойством данных.
> ANS>??? То есть свойство всегда должно быть связано с одним полем?
> Свойство может быть связано со множеством полей.
Как? Если это "вычисляемое свойство" — делаем его методом.

> LCR>>В свойствах нежелательно выполнение длительных операций.
> ANS>fire event можно делать или нельзя?
> Зависит от. Обычно можно.
side-effect, причем нехилый.

Иногда приводит к трудноуловимым багам, если обработчики событий что-то
меняют в состоянии объекта.

Пример:

Iterator i=someObject.iterate();
while(i.hasNext())
{
    SomeAnotherObject o=(SomeAnotherObject)i.next();
    o->setSomething(1234);
}

И иногда получали в зубы ConcurrentModificationException так как
обработчик setSomething вызывал notify, которое обрабатывалось в совсем
левом модуле и меняло коллекцию во время итерации.

Поэтому лично мне такая автоматика очень не нравится — совершенно
невозможно становится понять что с чем связано.

Andrei N.Sobchuck wrote:

> "Ниччё не понимаю" (с) следствие ведут колобки. Я таки настаиваю на
> объяснении сути свойств. А то пока я только понял, что у них синтаксис
> удобный, а отчего, почему — не ясно.
Объясняю, свойства — сокращение записи "obj.getValue()" до "obj.value" или "obj.setValue(val)" до "obj.value = val".
Больше ничего.
Для чего это так необходимо — не знаю, некоторым так нравится.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>ЗЫ Подключайтесь, господа. Сформулируйте, в конце концов, какая суть свойства (я не имею в виду определение типа "свойство это нечто у чего есть либо геттер, либо сеттер, либо и то и то"). Кстати, когда-то видел упоминание того, что C# легко с COM работает благодаря свойствам. Работа с легаси — согласен, хорошая причина. Но хотелось бы более "современного" объяснения.

Сколько понаписали не лень? (Это ко всем а не к вам персонально)

Далее по делу:

1. Свойство это не просто 2 метода — это концептуально более широкое понятие, т.е. не все можно/удобно определять на уровне методов, есть вещи которые относяться целиком к свойству, о чем почему-то никто не упомянул. Например такие аттрибуты, как BrowsableAttribute, DefaultValueAttribute, DesignerSerializationVisibilityAttribute, CategoryAttribute, DescriptionAttribute (это пришедшие в голову прямо сейчас, к чему их писать к Get или к Set, а если нет Set или того хлеще нет Get тогда что?)
   
2. Посмотрите в сторону BLToolkit вот где свойство выступает именно как единая концептуальная единица (Мапинг и вещи с ним связанные). Пытаться выразить это без понятия свойства как концептуальной единицы просто застрелиться.
   
3. Вобщем под свойство попадает почти все что чтение/установка внутриннего состояния обьекта. Всякие туманные преобразования чего-либо в нечто другое это методы (даже если при этом изменяется внутреннее состояние обекта).

Дьяченко Александр wrote:
> 1. Свойство это не просто 2 метода — это концептуально более широкое
> понятие, т.е. не все можно/удобно определять на уровне методов,
> есть вещи которые относяться целиком к свойству, о чем почему-то
> никто не упомянул. Например такие аттрибуты, как
> BrowsableAttribute, DefaultValueAttribute,
> DesignerSerializationVisibilityAttribute, CategoryAttribute,
> DescriptionAttribute (это пришедшие в голову прямо сейчас, к чему
> их писать к Get или к Set, а если нет Set или того хлеще нет Get
> тогда что?)
К _полям_ класса! Или к get/set-методам для дизайнеров.

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

Например, предположим у нас есть объект с тремя свойствами:
1. Значение
2. Процент.
3. Результат.
Они связаны отношением "Результат"="Процент"*"Значение"/100

Если мы меняем результат, то автоматически пересчитываются проценты,
если меняем проценты, то пересчитывается результат и т.п. Представим,
что это сделано в виде свойств.

Как хорошие программисты, мы добавляем валидацию — если процент равен
нолю, то при изменении результата кидаем исключение (так как имеем
деление на ноль).

Внимание вопрос! Что произойдет, если при сериализации восстановится
сначала поле с процентом?

> 2. Посмотрите в сторону BLToolkit вот где свойство выступает именно
> как единая концептуальная единица (Мапинг и вещи с ним связанные).
> Пытаться выразить это без понятия свойства как концептуальной
> единицы просто застрелиться.
Странно. А разработчики iBatis'а, Hibernate (и даже EJB CMP) спокойно живут.

> 3. Вобщем под свойство попадает почти все что чтение/установка
> внутриннего состояния обьекта.
Проблема в том, что любители свойств используют их для достижения
side-effect'ов. Например, запись в свойство изменяет значение поля на форме.

Свойства хороши только если они не изменяют инвариант объекта. Но вот
только оказывается, что ради этого не имеет смысла городить огород, а
можно использовать get/set-методы.

Cyberax wrote:
> Внимание вопрос! Что произойдет, если при сериализации восстановится
> сначала поле с процентом?
Очепятка, читать как "поле с результатом".

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

C>Дьяченко Александр wrote:
>> 1. Свойство это не просто 2 метода — это концептуально более широкое
>> понятие, т.е. не все можно/удобно определять на уровне методов,
>> есть вещи которые относяться целиком к свойству, о чем почему-то
>> никто не упомянул. Например такие аттрибуты, как
>> BrowsableAttribute, DefaultValueAttribute,
>> DesignerSerializationVisibilityAttribute, CategoryAttribute,
>> DescriptionAttribute (это пришедшие в голову прямо сейчас, к чему
>> их писать к Get или к Set, а если нет Set или того хлеще нет Get
>> тогда что?)
C>К _полям_ класса! Или к get/set-методам для дизайнеров.

Ну допустим DefaultValueAttribute его к чему к get или к set методу?

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

Граф еще построить надо.

C>Например, предположим у нас есть объект с тремя свойствами:
C>1. Значение
C>2. Процент.
C>3. Результат.
C>Они связаны отношением "Результат"="Процент"*"Значение"/100

C>Если мы меняем результат, то автоматически пересчитываются проценты,
C>если меняем проценты, то пересчитывается результат и т.п. Представим,
C>что это сделано в виде свойств.

C>Как хорошие программисты, мы добавляем валидацию — если процент равен
C>нолю, то при изменении результата кидаем исключение (так как имеем
C>деление на ноль).

C>Внимание вопрос! Что произойдет, если при сериализации восстановится
C>сначала поле с процентом?

Ну есть несколько вариантов:

1. Сериализовать только 2 из 3 — "Процент" и "Значение" (я так и зделал бы).
   
2. Сделать методы., типа Begin/End которые отключают проверки.
   
3. Осуществлять присвоение только в случае другого значения (обычно так и делается). Т.е.:
   

       public double Result
       {
           get { return _result; }
           set
           {
               if (_result != value)
               {
                   // Тут все остально (проверки, события и т.д.)
               }
           }
       }

>> 2. Посмотрите в сторону BLToolkit вот где свойство выступает именно
>> как единая концептуальная единица (Мапинг и вещи с ним связанные).
>> Пытаться выразить это без понятия свойства как концептуальной
>> единицы просто застрелиться.
C>Странно. А разработчики iBatis'а, Hibernate (и даже EJB CMP) спокойно живут.

Пусть живут дальше . Ктомуже почти уверен что свойства как концепция там тоже есть, может она не выражается на уровне языка, но тем не менее на уровне соглашения наверняка есть (далее обсуждение по этому направлению попрошу не продолжать, так как всеравно яву знаю крайне поверхностно и про iBatis'а, Hibernate (и даже EJB CMP) вобще знать не знаю), NHibernate смотрел один раз и то с год назад и очень поверхностно, поэтому продолжать обсуждение в этом направлении тяжело.

>> 3. Вобщем под свойство попадает почти все что чтение/установка
>> внутриннего состояния обьекта.
C>Проблема в том, что любители свойств используют их для достижения
C>side-effect'ов. Например, запись в свойство изменяет значение поля на форме.

Ну использовать через задницу можно почти все .

C>Свойства хороши только если они не изменяют инвариант объекта. Но вот
C>только оказывается, что ради этого не имеет смысла городить огород, а
C>можно использовать get/set-методы.

К томуже объединяя в свойство 2 метода мы автоматом снижаем концептуальную слложность в 2 раза (2 метода -> 1 свойство) вот.

Дьяченко Александр wrote:
> C>К _полям_ класса! Или к get/set-методам для дизайнеров.
> Ну допустим DefaultValueAttribute его к чему к get или к set методу?
К полю. А вообще, для defval придуманы были конструкторы (в том числе и
анонимные).

> C>Сериализация работает с графом объектов, и с ее точки зрения объекты
> C>рассматриваются как просто данные. Попытки добавить туда поведение дадут
> C>только минусы.
> Граф еще построить надо.
Для постройки свойства не нужны. Достаточно полей (только некоторые поля
надо помечать как transient).

> Ну есть несколько вариантов:
> 1. Сериализовать только 2 из 3 — "Процент" и "Значение" (я так и
> зделал бы).
В этом примере все просто — а в более сложных случаях получается
сложнее. Особенно когда нельзя (или трудоемко) четко разделять на
вычислямые данные и исходные.

> 2. Сделать методы., типа Begin/End которые отключают проверки.
И получаем взрывы в runtime, если что-то не так сработает.

> 3. Осуществлять присвоение только в случае другого значения (обычно
> так и делается). Т.е.:
Ага, только тогда теряем гарантию семантической целостности графа. Тоже
неприятно.

> C>Странно. А разработчики iBatis'а, Hibernate (и даже EJB CMP) спокойно
> живут.
> Пусть живут дальше . Ктомуже почти уверен что свойства как концепция там
> тоже есть, может она не выражается на уровне языка, но тем не менее на
> уровне соглашения наверняка есть (далее обсуждение по этому направлению
> попрошу не продолжать, так как всеравно яву знаю крайне поверхностно и
> про iBatis'а, Hibernate (и даже EJB CMP) вобще знать не знаю)
В Java есть простое соглашение — для доступа к данным используются
методы без параметра с префиксом "get" (или "is" для булевских типов),
для присвоения — методы с префиксом "set" и одним параметром.

Почти все известные мне системы в Java замечательно могут работать с
любыми именами методов (за исключением уродцев типа JSF).

> C>Проблема в том, что любители свойств используют их для достижения
> C>side-effect'ов. Например, запись в свойство изменяет значение поля на
> форме.
> Ну использовать через задницу можно почти все .
А если это "что-то" специально предназначалось для такого использования?

> C>Свойства хороши только если они не изменяют инвариант объекта. Но вот
> C>только оказывается, что ради этого не имеет смысла городить огород, а
> C>можно использовать get/set-методы.
> К томуже объединяя в свойство 2 метода мы автоматом снижаем
> концептуальную слложность в 2 раза (2 метода -> 1 свойство) вот.
Концепетуальную сложность мы, наоборот, увеличиваем. Так как появляются
два типа синтаксически одинаковых, но семантически неэквивалентных
конструкций.

А уменьшаем мы только синтаксический оверхед (сахарком посыпаем код).

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

C>А уменьшаем мы только синтаксический оверхед (сахарком посыпаем код).

Настолько незначительно, что даже уменьшение оверхеда очень спорно.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>ЗЫ Подключайтесь, господа. Сформулируйте, в конце концов, какая суть свойства (я не имею в виду определение типа "свойство это нечто у чего есть либо геттер, либо сеттер, либо и то и то").

Видишь ли какое дело? Ты ищешь эту самую суть в другом месте. Ты пытаешься найти разницу в использовании геттера и метода без параметров, не можешь её найти и объявляешь свойства бесполезной фенькой. А меня, например, прежде всего интересует синтаксическая составляющая. Если у меня есть вычисляемое поле, то я хочу видеть синтаксис именно поля, а не метода без параметров. Объяснять и доказывать в данном случае что-либо бесполезно. Я уже пробовал. На прошлом проекте мне довелось работать с джавщиками, они все свойства объявляли по привычке как методы. Когда я сделал замечание, то мы долго смотрели друг на друга как идиотов. Я не мог смотреть без слёз на этот код, они апеллировали как и ты тем, что не видят принципиальной разницы. Остались каждый при своём, привычка и предпочтения всё же страшная сила.

Так что доказывать что-то тебе — это бесполезное занятие. Ты сам должен это прочувствовать. Я прочувствовал.

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

C>Внимание вопрос! Что произойдет, если при сериализации восстановится сначала поле с процентом?

Сериализация (если ты о сериализации) восстанавливает значения переменных не вызывая никакого кода. Так что ничего страшного не случится.

>> 2. Посмотрите в сторону BLToolkit вот где свойство выступает именно
>> как единая концептуальная единица (Мапинг и вещи с ним связанные).
>> Пытаться выразить это без понятия свойства как концептуальной
>> единицы просто застрелиться.
C>Странно. А разработчики iBatis'а, Hibernate (и даже EJB CMP) спокойно живут.

В BLToolkit тоже можно без свойств. Публичные поля вполне подойдут.

C>Проблема в том, что любители свойств используют их для достижения side-effect'ов. Например, запись в свойство изменяет значение поля на форме.

Я тебе даже больше скажу. Большие любители свойств доходят до того, что изменение свойства на форме меняет саму форму, как то скрывает контролы, дизэйблит/энейблит поля. Называется это — ability to reuse UI logic. Вещь по своей сути без копипейста трудно достижимая.

C>Свойства хороши только если они не изменяют инвариант объекта. Но вот только оказывается, что ради этого не имеет смысла городить огород, а можно использовать get/set-методы.

Да ладно тебе фантазёрствовать. Я уже 4 года как изменяю инварианты и живу не тужу.

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

IT> Если у меня есть вычисляемое поле, то я хочу видеть синтаксис именно поля

Блин, ты говориш "есть поле", а откуда оно взялось? С чего ты взял, что это именно поле? Стандарт кодирования у вас, что говорит?

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

>> C>К _полям_ класса! Или к get/set-методам для дизайнеров.
>> Ну допустим DefaultValueAttribute его к чему к get или к set методу?
C>К полю. А вообще, для defval придуманы были конструкторы (в том числе и
C>анонимные).

Ну к полю это еще туда сюда (Дизайнер должен сам догадываться к которому полю, или опять соглашение?). А с конструктором это вобще не катит — например класc Color у каждого Control-а несколько разных Color-ов и че в конструкторе?

>> C>Сериализация работает с графом объектов, и с ее точки зрения объекты
>> C>рассматриваются как просто данные. Попытки добавить туда поведение дадут
>> C>только минусы.
>> Граф еще построить надо.
C>Для постройки свойства не нужны. Достаточно полей (только некоторые поля
C>надо помечать как transient).

>> Ну есть несколько вариантов:
>> 1. Сериализовать только 2 из 3 — "Процент" и "Значение" (я так и
>> зделал бы).
C>В этом примере все просто — а в более сложных случаях получается
C>сложнее. Особенно когда нельзя (или трудоемко) четко разделять на
C>вычислямые данные и исходные.

Пример нарисуешь? А то у меня че-то не приходит в голову ничего.

>> 2. Сделать методы., типа Begin/End которые отключают проверки.
C>И получаем взрывы в runtime, если что-то не так сработает.

Я не говорил что это лучший вариант. Но он есть.

>> 3. Осуществлять присвоение только в случае другого значения (обычно
>> так и делается). Т.е.:
C>Ага, только тогда теряем гарантию семантической целостности графа. Тоже
C>неприятно.

В смысле? Нафига че-то делать если там и так тоже самое значение?

C>В Java есть простое соглашение — для доступа к данным используются
C>методы без параметра с префиксом "get" (или "is" для булевских типов),
C>для присвоения — методы с префиксом "set" и одним параметром.

Я же говорил что как концепция свойство все равно есть. Плюс такое раздвоение усложняет рефакторинг. Или ты против отображения этой концепции в синтаксисе языка?

>> C>Проблема в том, что любители свойств используют их для достижения
>> C>side-effect'ов. Например, запись в свойство изменяет значение поля на
>> форме.
>> Ну использовать через задницу можно почти все .
C>А если это "что-то" специально предназначалось для такого использования?

В смысле?

>> C>Свойства хороши только если они не изменяют инвариант объекта. Но вот
>> C>только оказывается, что ради этого не имеет смысла городить огород, а
>> C>можно использовать get/set-методы.
>> К томуже объединяя в свойство 2 метода мы автоматом снижаем
>> концептуальную слложность в 2 раза (2 метода -> 1 свойство) вот.
C>Концепетуальную сложность мы, наоборот, увеличиваем. Так как появляются
C>два типа синтаксически одинаковых, но семантически неэквивалентных
C>конструкций.

В смысле? В C# напрямую нельзя вызвать get/set. Или ты про что?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

IT>> Если у меня есть вычисляемое поле, то я хочу видеть синтаксис именно поля

ANS>Блин, ты говориш "есть поле", а откуда оно взялось? С чего ты взял, что это именно поле? Стандарт кодирования у вас, что говорит?

Пардон, вычисляемое свойство.

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

IT>Здравствуйте, Andrei N.Sobchuck, Вы писали:

IT>>> Если у меня есть вычисляемое поле, то я хочу видеть синтаксис именно поля

ANS>>Блин, ты говориш "есть поле", а откуда оно взялось? С чего ты взял, что это именно поле? Стандарт кодирования у вас, что говорит?

IT>Пардон, вычисляемое свойство.

Я его и имел ввиду. Читай просто вместо "поле", "свойство".