Добрый день! Разбираю чужой проект и вижу такие свойства:
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. Если свойство только для чтения (и всегда будет только для чтения), то стОит ли его заменять функцией? Есть ли какие-то "правила хорошего тона", когда лучше свойство для чтения, а когда функция.
Здравствуйте, 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 это события. Связать события с полем намертво да еще и обозвать это отдельным понятием просто глупо. Это разные вещи. А они еще и оба события связали вместе..Это уже совсем лишнее.
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>Впрочем, в вашем мире до сих пор, наверное, переход с 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. С фиксированой точкой двумя числами через запятую или точку.. Ну, и так далее.. Двоичнве еще как-то.. Но по любому значение как-то выражается текстом.. Надеюсь, это понятно? А раз это так то, это текстовое представление должен определять транслятор как значения какого-то типа. И выдавать ошибку при не соответствии типов.. Совсем не сложно отсюда сделать вывод что определение нового типа должно влиять на трансляцию в части опознавания значений вновь определенного типа..
Здравствуйте, pugv, Вы писали:
B>>Значение характерно тем, что его можно представить в тексте.. Int, например, ка 1, 25, 769.
P>Вот такая строчка "в тексте" представляет значение или объект? P>
примерно как в 1988 году
