Добрый день! Разбираю чужой проект и вижу такие свойства:

public static string NewDocFolder
{
    get
    {
         return Что-то там вычисляется;
    }
    set
    {
         throw new DebugApplicationException(Resources.MessageException.NotAccessorException);
    }
}

1. В чем может быть смысл такой диагностики, ведь если просто убрать из свойства set, то присваивание в вызывающем коде не скомпилится.
2. Если свойство только для чтения (и всегда будет только для чтения), то стОит ли его заменять функцией? Есть ли какие-то "правила хорошего тона", когда лучше свойство для чтения, а когда функция.

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

AT>1. В чем может быть смысл такой диагностики, ведь если просто убрать из свойства set, то присваивание в вызывающем коде не скомпилится.

возможно set оставили для совместимости, чтобы код компилировался, но тот код, который использует Set сейчас не будет работать

AT>2. Если свойство только для чтения (и всегда будет только для чтения), то стОит ли его заменять функцией? Есть ли какие-то "правила хорошего тона", когда лучше свойство для чтения, а когда функция.

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

Здравствуйте, alex-t, Вы писали:
AT>2. Если свойство только для чтения (и всегда будет только для чтения), то стОит ли его заменять функцией? Есть ли какие-то "правила хорошего тона", когда лучше свойство для чтения, а когда функция.

Choosing Between Properties and Methods

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

AT>Добрый день! Разбираю чужой проект и вижу такие свойства:

Возможно, это сделано для сериализации, при этом десериализация не требуется.

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

AT>Добрый день! Разбираю чужой проект и вижу такие свойства:

AT>

AT>public static string NewDocFolder
AT>{
AT>    get
AT>    {
AT>         return Что-то там вычисляется;
AT>    }
AT>    set
AT>    {
AT>         throw new DebugApplicationException(Resources.MessageException.NotAccessorException);
AT>    }
AT>}
AT>

AT>1. В чем может быть смысл такой диагностики, ведь если просто убрать из свойства set, то присваивание в вызывающем коде не скомпилится.
AT>2. Если свойство только для чтения (и всегда будет только для чтения), то стОит ли его заменять функцией? Есть ли какие-то "правила хорошего тона", когда лучше свойство для чтения, а когда функция.
Перемудрили или не домудрили философы микрософтовские.. Свойство это обычное поле, а Set и Get это события. Связать события с полем намертво да еще и обозвать это отдельным понятием просто глупо. Это разные вещи. А они еще и оба события связали вместе..Это уже совсем лишнее.

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

AT>>

AT>>public static string NewDocFolder
AT>>{
AT>>    get {/*...*/ } set {/*...*/}
AT>>}
AT>>

B>Перемудрили или не домудрили философы микрософтовские.. Свойство это обычное поле, а Set и Get это события. Связать события с полем намертво да еще и обозвать это отдельным понятием просто глупо. Это разные вещи. А они еще и оба события связали вместе..Это уже совсем лишнее.
Это только до того момента, пока вы мыслите строками и интами.
Как только в вашем мышлении появляются абстрактные типы данных, всё начинает выглядеть уже совсем по-другому

Get и set предоставляют отличную возможность использовать по сути специализированный тип, не пугая неквалифицированных программистов (которые и дальше будут видеть число/строчку/другой примитив и два события). А мы, bydlosoft valuable professionals, в это время будем видеть инкапсуляцию, абстракцию и гарантии соблюдения контракта.

Впрочем, в вашем мире до сих пор, наверное, переход с 16 на 32 разряда принципиально меняют всю разработку примерно как в 1988 году

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

b-3>Это только до того момента, пока вы мыслите строками и интами.
b-3>Как только в вашем мышлении появляются абстрактные типы данных, всё начинает выглядеть уже совсем по-другому

b-3>Get и set предоставляют отличную возможность использовать по сути специализированный тип, не пугая неквалифицированных программистов (которые и дальше будут видеть число/строчку/другой примитив и два события). А мы, bydlosoft valuable professionals, в это время будем видеть инкапсуляцию, абстракцию и гарантии соблюдения контракта.

b-3>Впрочем, в вашем мире до сих пор, наверное, переход с 16 на 32 разряда принципиально меняют всю разработку примерно как в 1988 году
Не уловил что должено поменяться с абстактными типами? Если можно подробнее.. Объектная парадигма как-то не должна различать эти дела.. Хотя разница между типами и объектами не прописана так четко как у меня в субъектно-ориентированной парадигме. И я против свойства как специализированного типа..По моему это вообще может быть не тип..

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

.

b-3>Впрочем, в вашем мире до сих пор, наверное, переход с 16 на 32 разряда принципиально меняют всю разработку примерно как в 1988 году
В связи с этим хотелось проверить ваше понимание Int это что? Тип или класс?

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

b-3>Впрочем, в вашем мире до сих пор, наверное, переход с 16 на 32 разряда принципиально меняют всю разработку примерно как в 1988 году
И что замолчал? А так яростно начал..

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

B>Перемудрили или не домудрили философы микрософтовские.. Свойство это обычное поле, а Set и Get это события. Связать события с полем намертво да еще и обозвать это отдельным понятием просто глупо. Это разные вещи. А они еще и оба события связали вместе..Это уже совсем лишнее.

Щито?

Здравствуйте, Аноним, Вы писали:

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

B>>Перемудрили или не домудрили философы микрософтовские.. Свойство это обычное поле, а Set и Get это события. Связать события с полем намертво да еще и обозвать это отдельным понятием просто глупо. Это разные вещи. А они еще и оба события связали вместе..Это уже совсем лишнее.

А>Щито?
Переведи. А падонковский не понимаю.

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

b-3>>Впрочем, в вашем мире до сих пор, наверное, переход с 16 на 32 разряда принципиально меняют всю разработку примерно как в 1988 году
B>В связи с этим хотелось проверить ваше понимание Int это что? Тип или класс?
Инт является типом, т.к. представляет собой множество термов (0x80000000..0x00000000..0x7FFFFFFF), по сути арифметическое кольцо. Над термами определён предикат типизирования и правила, которые позволяют выводить утверждения о принадлежности к типу операций (лямбда-выражений) относительно данного множества значений

Математически набор правил формулируется примерно в таком стиле:



(из классической книжки)

Во многих языках существует класс Int, который к делу не относится. Ну, максимум — служит для реализации системы типов в языке и её проверки на стадии компиляции
Однако сам по себе тип Int существует отдельно от вычислительной машины и от любых битиков в ОЗУ. Он — математическое, умозрительное понятие. Но это не самое важное. Самое важное то, что если я, к примеру, возьму 48-битные последовательности, в которых от 10 до 20 битов равны единице, и сформулирую некий операций, замкнутых на этом множестве — я имею полное право назвать это типом. Ничуть не хуже 32-битного инта с переполнением)

B> Не уловил что должено поменяться с абстактными типами? Если можно подробнее..
C абстрактными типами меняется то, что они не допускают работы с ними так же, как с нижележащими типами рантайма. К примеру, в 16-битной ячейке хранится число от 0 до 16383, либо 0xFFFF. 0xFFFF, например, сигнализируют отказ датчика, с которого мы снимаем значение. Но 0x1000 < 0xFFFF — ложное утверждение. И 0x1000 > 0xFFFF — тоже ложное утверждение.

Такая конструкция по сути — тип. Мы можем даже отобразить этот тип в пространство типов языка программирования, сделав struct MyMeasuredValue. Вот только сразу же, как мы это сделаем, появится желание, чтобы наша структура данных:
а) была неизменяемой
б) поддерживала copy semantic
в) поддерживала операции сравнения
б) гарантировала принадлежность терма типу (т.е. значения в 16 битной ячейке вышеуказанному множеству)
Я здесь, в операциях с результатом измерения, наблюдаю специализированный тип данных, но где тут события? В упор не вижу никаких "событий"

Зато вижу: для того, чтобы зафиксировать тип, объявленный технологом в ТЗ, в языке программирования, нужно, как вы выразились, "Связать get и set с полем намертво да еще и обозвать это отдельным понятием".

Потому что заказчику на мои заявления "у нас всё в знаковых 32-битных целых на самом деле" глубоко безразлично. У него — результат замера от 0 до 16383 или отказ. У него для этого почему-то отдельное понятие, и у инженера — такое же отдельное понятие. А у программиста что, по-другому должно быть?

B> Объектная парадигма как-то не должна различать эти дела.. Хотя разница между типами и объектами не прописана так четко как у меня в субъектно-ориентированной парадигме.
А вы уверены, что объектно ориентированная парадигма не должна различать? Я вам классиков алгебраического подхода к типам процитировал, можно ответного цитату из Буча или что-то подобное?

Насколько я знаю, объектно-ориентированная парадигма допускает понятие "контракт" и "инвариант", и вовсе не обязательно смотрит на все поля как на мутабельные сущности плюс события, связанные с их изменениями.

B> И что замолчал? А так яростно начал..
Так вы ж меня много писать провоцируете. Пока подумаешь, пока пролистнёшь TAPL, пока наберёшь ответ....

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

b-3>Насколько я знаю, объектно-ориентированная парадигма допускает понятие "контракт" и "инвариант", и вовсе не обязательно смотрит на все поля как на мутабельные сущности плюс события, связанные с их изменениями.

B>> И что замолчал? А так яростно начал..
b-3>Так вы ж меня много писать провоцируете. Пока подумаешь, пока пролистнёшь TAPL, пока наберёшь ответ....

Вижу что хорошо поработал. Не со всем согласен.. Но где-то так.. Устраивать здесь детальное обсуждение будет не продуктивно. Порадовало что вопрос понят правильно. Вообще то я думал своими словами расскажешь. Потому подозрение что долго гуглил. А может и понимаешь. Ну, и кое-какие мои слова там не совсем в правильном контексе восприняты. Все равно хорошо.
Да и про свойство тоже не все так однозначно и в разных языках и тоже разница в философии, определянии и реализации. Было приятно пообщаться..
P.S.
С типами есть еще одна деталь нигде не замеченая, потому я считаю додумался самостоятельно.. Типы порождают значения.. И эти значения имеют кроме двоичного и текстовое представление. Тем самым влияя на процесс трансляции. Принято определять эти значения на этапе семантического разбора, потому как сделать это до того как оттранслировано определение типа невозможно по понятным причинам. В своей системе я применил, как мне кажется, более естественно, определение значений на этапе лексического разбора. Правда ради этого пришлось определение типов транслировать отдельно перед трансяцией документа в котором встречаются эти значения. Спорное решение, конечно. Но мне кажется это правильно. Слишком многое стало на свои места и упростилось.

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

B>С типами есть еще одна деталь нигде не замеченая, потому я считаю додумался самостоятельно.. Типы порождают значения.. И эти значения имеют кроме двоичного и текстовое представление. Тем самым влияя на процесс трансляции. Принято определять эти значения на этапе семантического разбора, потому как сделать это до того как оттранслировано определение типа невозможно по понятным причинам. В своей системе я применил, как мне кажется, более естественно, определение значений на этапе лексического разбора. Правда ради этого пришлось определение типов транслировать отдельно перед трансяцией документа в котором встречаются эти значения. Спорное решение, конечно. Но мне кажется это правильно. Слишком многое стало на свои места и упростилось.
Без неонки унутре оно корованы не заграбит.

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

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

B>>С типами есть еще одна деталь нигде не замеченая, потому я считаю додумался самостоятельно.. Типы порождают значения.. И эти значения имеют кроме двоичного и текстовое представление. Тем самым влияя на процесс трансляции. Принято определять эти значения на этапе семантического разбора, потому как сделать это до того как оттранслировано определение типа невозможно по понятным причинам. В своей системе я применил, как мне кажется, более естественно, определение значений на этапе лексического разбора. Правда ради этого пришлось определение типов транслировать отдельно перед трансяцией документа в котором встречаются эти значения. Спорное решение, конечно. Но мне кажется это правильно. Слишком многое стало на свои места и упростилось.
S>Без неонки унутре оно корованы не заграбит.
Если не понял спроси. Так вот типы порождают значения, а классы — объекты. Что б не повторять азбуку надеюсь между объектами и значениями разницу понимаешь. Значение характерно тем, что его можно представить в тексте.. Int, например, ка 1, 25, 769. С фиксированой точкой двумя числами через запятую или точку.. Ну, и так далее.. Двоичнве еще как-то.. Но по любому значение как-то выражается текстом.. Надеюсь, это понятно? А раз это так то, это текстовое представление должен определять транслятор как значения какого-то типа. И выдавать ошибку при не соответствии типов.. Совсем не сложно отсюда сделать вывод что определение нового типа должно влиять на трансляцию в части опознавания значений вновь определенного типа..

B>Значение характерно тем, что его можно представить в тексте.. Int, например, ка 1, 25, 769.

Вот такая строчка "в тексте" представляет значение или объект?

"[{id:1, name:'name1'}, {id:2, name:'name2'}]"

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

B>>Значение характерно тем, что его можно представить в тексте.. Int, например, ка 1, 25, 769.

P>Вот такая строчка "в тексте" представляет значение или объект?
P>

P>"[{id:1, name:'name1'}, {id:2, name:'name2'}]"
P>

Читаем еще раз "... его (значение) можно представить в тексте..". А можно и идентификатором.. или указателем.. Да мало как еще можно и в каком языке..