Здравствуйте, korzey, Вы писали:
K>Как описать в "шарпе", что параметр, переданный в функцию, есть КОНСТАНТА? Или остается только уповать на "доброжелательность окружающего мира"...
Здравствуйте, korzey, Вы писали:
K>Здравствуйте, Ракот, Вы писали:
Р>>А если передавать value тип?
K>Это, через struct, что ли?
K>Таки есть "поведенческие отличия" class vs struct у C#... K>Начиная с отсутсвия наследования....
Структуры при передачи в функцию копируются по значению, классы передаются по ссылке.
То же поведение возникает при присваивании.
Re: Константный параметр
От:
Аноним
Дата:
07.07.05 17:32
Оценка:
Здравствуйте, korzey, Вы писали:
Вот так:
public interface IReadOnly
{
// Методы на чтение
};
public interface IReadWrite : IReadOnly
{
// Методы на запись
};
public class SomeClass : IReadOnly, IReadWrite
{
// Реализация
};
public delegate bool TestFunction01(IReadWrite obj);
public delegate bool TestFunction02(IReadOnly obj);
K>Как описать в "шарпе", что параметр, переданный в функцию, есть КОНСТАНТА? Или остается только уповать на "доброжелательность окружающего мира"...
А что если сделать ответ в ввиде еленмнтав перечисления, т.е. я так понимаю, что есть некий набор констант , который может прингимамать входной параметр, ну и поппробуй ввести собственное перечисление. Я так лично думаю.
Здравствуйте, korzey, Вы писали:
K>Как описать в "шарпе", что параметр, переданный в функцию, есть КОНСТАНТА? Или остается только уповать на "доброжелательность окружающего мира"...
никак не описать, только уповать или реализовать класс согласно паттерну Immutable. Обсуждение отсутствия const в С++ стиле уже обсуждалось, надо поискать по форуму.
Ну, мысль, конечно, интересная... Только, при наличии трех отдельных библиотек, надо будет с каждой кидать еще и четвертую, в которой "иметь" IReadOnly|IReadWrite.
А "оконечный" разработчик будет потом сидеть и матерится над строками кода, вида
class SomeClass: korzey.IReadOnly, vasja.IReadOnly, petja.IReadOnly......... pupkin.IReadOnly
Избави бог от дураков, а с врагами и сами, как-нибудь, разберемся...
Здравствуйте, zlobnik, Вы писали:
Z>Здравствуйте, korzey, Вы писали:
Z>А что если сделать ответ в ввиде еленмнтав перечисления, т.е. я так понимаю, что есть некий набор констант , который может прингимамать входной параметр, ну и поппробуй ввести собственное перечисление. Я так лично думаю.
Нет. Есть некий базовый класс. Есть функция, скажем
bool SomeTest(/*const*/ BaseObj obj)
где я даю гарантию, что функция ничего не изменит в проверяемом объекте, который от этого класса унаследован(т.е НИ перечисление, НИ структура не подходят). Плюс, для меня проверка: компилятор не "собирает" код, где меняется "неизменяемый" объект, а вываливается с сообщением.
ЗЫЖ В принципе, в "ша(р)пке" сильно не хватает "константных" определений...
bool function(const SomeObject obj)
или
class AnotherObject
{
...
bool isLive() const;
Избави бог от дураков, а с врагами и сами, как-нибудь, разберемся...
Здравствуйте, SiAVoL, Вы писали:
K>>Как описать в "шарпе", что параметр, переданный в функцию, есть КОНСТАНТА? Или остается только уповать на "доброжелательность окружающего мира"... SAV>никак не описать, только уповать или реализовать класс согласно паттерну Immutable. Обсуждение отсутствия const в С++ стиле уже обсуждалось, надо поискать по форуму.
Угум-с. Поищем... А, если не затруднит, не "припомните" ссылочку?....
Избави бог от дураков, а с врагами и сами, как-нибудь, разберемся...
Здравствуйте, Максим Зелинский, Вы писали:
МЗ>Здравствуйте, korzey, Вы писали:
K>>Здравствуйте, Ракот, Вы писали:
Р>>>А если передавать value тип?
K>>Это, через struct, что ли?
K>>Таки есть "поведенческие отличия" class vs struct у C#... K>>Начиная с отсутсвия наследования....
МЗ>Структуры при передачи в функцию копируются по значению, классы передаются по ссылке. МЗ>То же поведение возникает при присваивании.
Спасибо. Я тоже умею хелп читать, и тесты писать...
Потому и сказал, что ValueType не подходит для "константых параметров", ибо необходимо иметь возможность передавать, как параметр, и "наследников". Т.е. описав, некую "поведенческую базу", я даю возможность ее "наследовать", и при этом даю гарантию, что в моей функции "наследник" не изменится.
К тому, же, со структурами, еще возня, при передаче(копировании), если ее размер не два три поля.
Опять же, если в состав структуры "попадает" ReferenceType, то он копируется "по ссылке", и менять его(!) можно сколько угодно....
Избави бог от дураков, а с врагами и сами, как-нибудь, разберемся...
Здравствуйте, korzey, Вы писали:
K>Угум-с. Поищем... А, если не затруднит, не "припомните" ссылочку?....
а что там искать-то? Ищем в форуме dotnet по ключевым словам
K>Как описать в "шарпе", что параметр, переданный в функцию, есть КОНСТАНТА? Или остается только уповать на "доброжелательность окружающего мира"...
Когда я столкнулся с такой проблемой, то поступил следующим образом:
— вся работа с данными в передаваемом объекте ведется через сетоды (вспомним основную рекомендацию при использовании ООП писать методы доступа )
— Объект имеет bool параметр, например is_readonly
— в случае вызова метода объекта, который изменяет данные в объекте, первой строкой проверяем is_readonly и если он false — даем exception
— Перед вызовом функции, которая модет изменить данные в объекте, но не должна этого делать — ставим is_readonly в true, а по окончании — обратно в false.
Здравствуйте, Fahrain, Вы писали:
F>Здравствуйте, korzey, Вы писали:
K>>Как описать в "шарпе", что параметр, переданный в функцию, есть КОНСТАНТА? Или остается только уповать на "доброжелательность окружающего мира"...
F>Когда я столкнулся с такой проблемой, то поступил следующим образом:
F>- вся работа с данными в передаваемом объекте ведется через сетоды (вспомним основную рекомендацию при использовании ООП писать методы доступа ) F>- Объект имеет bool параметр, например is_readonly F>- в случае вызова метода объекта, который изменяет данные в объекте, первой строкой проверяем is_readonly и если он false — даем exception F>- Перед вызовом функции, которая модет изменить данные в объекте, но не должна этого делать — ставим is_readonly в true, а по окончании — обратно в false.
Здравствуйте, korzey, Вы писали:
K>Здравствуйте, Fahrain, Вы писали:
F>>Здравствуйте, korzey, Вы писали:
K>>>Как описать в "шарпе", что параметр, переданный в функцию, есть КОНСТАНТА? Или остается только уповать на "доброжелательность окружающего мира"...
F>>Когда я столкнулся с такой проблемой, то поступил следующим образом:
F>>- вся работа с данными в передаваемом объекте ведется через сетоды (вспомним основную рекомендацию при использовании ООП писать методы доступа ) F>>- Объект имеет bool параметр, например is_readonly F>>- в случае вызова метода объекта, который изменяет данные в объекте, первой строкой проверяем is_readonly и если он false — даем exception F>>- Перед вызовом функции, которая модет изменить данные в объекте, но не должна этого делать — ставим is_readonly в true, а по окончании — обратно в false.
K>Ну, это аналог K>http://www.rsdn.ru/Forum/Message.aspx?mid=1261763&only=1
Да. Только интерфейс не нужно реализовывать. Плюс можно в явном виде указать блок кода в котором объект readonly, например. Для реализации через интерфейсы придется для каждого вызова функций в явном виде указывать как с ним работать (только для чтения или нет). По написанию кода — мой способ короче. По возможности совершить ошибку — скорее всего тот способ лучше...
Здравствуйте, Fahrain, Вы писали:
K>>>>Как описать в "шарпе", что параметр, переданный в функцию, есть КОНСТАНТА? Или остается только уповать на "доброжелательность окружающего мира"...
...
F>Да. Только интерфейс не нужно реализовывать. Плюс можно в явном виде указать блок кода в котором объект readonly, например. Для реализации через интерфейсы придется для каждого вызова функций в явном виде указывать как с ним работать (только для чтения или нет). По написанию кода — мой способ короче. По возможности совершить ошибку — скорее всего тот способ лучше...
Ну, в случае с интерфейсом, я не ограничиваю других разработчиков в плане наследования. Все таки, интерфейс "прикрутить" можно на любой стадии. Тем более, что его можно использовать, как extention, а не только как derivation. И реализовать через него доп.функциональность, необходимую в моей функции, в примеру, получение статуса. По-большому счету, можно вообще сделать интерфейс, только с read-only свойствами, но это не всегда реализуемо на практике, к сожалению...
Таки const был в C++, в этом плане, и декларативнее, и интуитивно понятнее, тем более, что входил в стандарт языка, а не был сторонней реализацией, как в случае "моей" библиотеки. Да и позволял делать "compile-time check", а не "run-time".
Тут как раз получается, что ОЧЕНЬ многое, при такой постановке вопроса переводится в "тормознутый .NET FW runtime". В то время, как скорость компиляции "в разы!" не так критично, как выполнение...
Избави бог от дураков, а с врагами и сами, как-нибудь, разберемся...
