Здравствуйте, c-smile, Вы писали: CS>1) имплементация const как он есть в C++. Со всеми вытекающими за и против.
CS>2) введение двух новых метатипов readonly array & pointer, типа такого:
CS> char#[] — readonly array CS> char#* — readonly pointer.
А чего не как в си-шарп с ключевым словом readonly?
Здравствуйте, Александр Сергеевич, Вы писали:
АС>Здравствуйте, c-smile, Вы писали: CS>>1) имплементация const как он есть в C++. Со всеми вытекающими за и против.
CS>>2) введение двух новых метатипов readonly array & pointer, типа такого:
CS>> char#[] — readonly array CS>> char#* — readonly pointer.
АС>А чего не как в си-шарп с ключевым словом readonly?
C# readonly не есть то же самое что const char[] в С++ —
задача в основном состоит в том чтобы можно было
изобразить такое:
void foo( const char[] s )
Т.е. такая декларация предполагает что содержимое
массива s внутри функции foo не изменится.
Здравствуйте, c-smile, Вы писали:
CS>Без наличия чего-то типа const char[] имплементация строк CS>в классическом виде невозможна.
Очень смешно. И как Ява с Шарпом живут?
Про immutable-типы слышал? Если в языке нормально поддерживается инкапсуляция, то нет проблем создать тип экземпляры которого можно будет только создавать, но нельзя будет изменять. Далее дело техники. Примеры в той же Яве и Шарпе.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>Без наличия чего-то типа const char[] имплементация строк CS>>в классическом виде невозможна.
VD>Очень смешно. И как Ява с Шарпом живут?
VD>Про immutable-типы слышал? Если в языке нормально поддерживается инкапсуляция, то нет проблем создать тип экземпляры которого можно будет только создавать, но нельзя будет изменять. Далее дело техники. Примеры в той же Яве и Шарпе.
Я ж про это и говорю.
const char[] - immutable.
char[] - mutable.
В C# и Java проблема (проблема ли?) — нет понятия deep immutable:
int foo(in MyClass cls)
in защищает от изменения переменную cls в вызывающей процедуре
но сам объект передаваемый — конем гуляй по нему.
const MyClass& cls в C++ означает что для cls объекта в классе
MyClass подавлены все изменяющие методы.
immutable — это характиристика типа. const же всего лишь предохраняет от модификации переменной.
CS>В C# и Java проблема (проблема ли?) — нет понятия deep immutable: CS>
CS>int foo(in MyClass cls)
CS>
CS>in защищает от изменения переменную cls в вызывающей процедуре CS>но сам объект передаваемый — конем гуляй по нему.
Объект или передается по значению и тогда хоть обмодифицируйся. Или по ссылке. При этом возмжность модификации объекта зависит от того ползволяет ли он себя модифицировать.
Например, попроубуй изменить в C# строку или значение типа DateTimr.
CS>const MyClass& cls в C++ означает что для cls объекта в классе CS>MyClass подавлены все изменяющие методы.
Нет. cls означет, что ссылка недопускает модфикации объекта. В то же время всегда можно создать новую ссылку или указатель и модифицировать через него тот же объект. Модифицировать же immutable-объект невозможно.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>immutable — это характиристика типа. const же всего лишь предохраняет от модификации переменной.
C точки зрения формальной логики
class A{...};
const A a;
const A есть образование нового типа A' у которого отсутвуют (или закрыты) все мутирующие методы.
immutability может быть "ручной" и "автоматической" — в С# доступна только "ручная". В C++ и первая и вторая.
CS>>В C# и Java проблема (проблема ли?) — нет понятия deep immutable: CS>>
CS>>int foo(in MyClass cls)
CS>>
CS>>in защищает от изменения переменную cls в вызывающей процедуре CS>>но сам объект передаваемый — конем гуляй по нему.
VD>Объект или передается по значению и тогда хоть обмодифицируйся. Или по ссылке. При этом возмжность модификации объекта зависит от того ползволяет ли он себя модифицировать.
VD>Например, попроубуй изменить в C# строку или значение типа DateTimr.
Я ж и говорю — зависит от ручной импелементации. В Java например String immutable а DateTime — нет.
Автоматической — нет.
CS>>const MyClass& cls в C++ означает что для cls объекта в классе CS>>MyClass подавлены все изменяющие методы.
VD>Нет. cls означет, что ссылка недопускает модфикации объекта. В то же время всегда можно создать новую ссылку или указатель и модифицировать через него тот же объект. Модифицировать же immutable-объект невозможно.
Мы говорим не про mutability enforcment, а про нормальное использование.
Из-за того что в C++ используется deep immutability который(ая) есть вещь суровая, то для практических целей оставлен
const_cast<> — явное снятие immutability.
Полный режим readonly возможен только на хардверном уровне.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, c-smile, Вы писали:
CS>"И ниччо ему золота рыба не сказала..."
Так ничего удивительного, имхо. Из любителей D на этом форуме я могу припомнить тебя, uw и Зверька Харьковского.
CS>deep immutable references — C++ const CS>shallow immutable references — предлагаемый вариант (#)
CS>Тогда вопрос — а нужно ли оно вообще?
Это ты про D?
Имхо, что-то подобное, определенно, нужно. Меня в Java очень добивало то, что объекты передавались в методы по ссылке, но никак нельзя было запретить методу модифицировать объект.
Как C++ник, думаю, что нужно делать аналог C++ const. Хотя выльется это, вероятно, в очень серьезную модификацию D. И, кроме того, придется поддерживать mutable-атрибуты у объектов. Кстати, в первом посте ты сказал: "1) имплементация const как он есть в C++. Со всеми вытекающими за и против". А что под "против" понимается?
Ну а второй вариант мне даже синтаксически не нравится. Использование спецсимволов для обозначения характеристик объектов -- это, имхо, прямой путь к perl-подобному синтаксису.
И еще во втором варианте меня вот что смущает. Я уже не помню D толком, но кажется там есть понятие указателей и есть операция разыменования указателя (ты сам сказал: "у readonly указателя нет опреации dereferencing to l-value"). Это позволяет делать на шаблонах что-то вроде (синтаксис C++):
template< class T >
T f( T * p ) { T c = *p; ...; return c; }
т.е., если f() вызывается для const T *, то T внутри шаблона будет иметь тип const T.
А если в D сделать readonly pointer, то не введет ли это новую абстракцию "readonly pointer", который вроде как pointer, но не такой? И не создаст ли это сложностей при программировании тех же шаблонов?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VD>>immutable — это характиристика типа. const же всего лишь предохраняет от модификации переменной.
CS>C точки зрения формальной логики
CS>
CS>class A{...};
CS>const A a;
CS>
CS>const A есть образование нового типа A' у которого отсутвуют (или закрыты) все мутирующие методы.
Нет здесь никакой логики. const всего лишь модификатор распространяющийся на переменную. Самому объекту от этого не горячо и не холодно. Вот такой код тебя ведь не смущат:
class A { };
void main()
{
A* a1 = new A();
const A* a2 = a2;
}
При этом a1 можно менять, а a2 нет. Но по твоим словам у них разный тип.
CS>immutability может быть "ручной" и "автоматической" — в С# доступна только "ручная". В C++ и первая и вторая.
В С# доступна инкапсуляция которая позволяет создать immutability-объекты. Отальное от лукавого.
Главное, что этого достаточно для создания immutability-классов решающих поставленную проблему.
CS>Я ж и говорю — зависит от ручной импелементации.
Как меня раздражает эта твоя "импелементации"... если бы ты знал.
CS> В Java например String immutable а DateTime — нет. CS>Автоматической — нет.
А зачем автоматическое? Это характиристика типа. Пусть тот кто проектирует тип и определяет эту характиристику.
Причем я как бы не спорю, что нечто вроде readonly для локальных переменных очень не помешало бы в Шарпе. Но immutable тем не менее — это характеристика класса. Это можно сказать паттерн проектрования. И никакие const его не заменят.
Тут уж было бы разумно говорить о ключевом слове (или атрибуте) immutable применяемом к классу. Ну, чтобы запретить модификацию полей вне конструктора (т.е. дополнительная проверка).
CS>Мы говорим не про mutability enforcment,
Ну, пошли иностранные ругательства.
CS> а про нормальное использование.
Дык что есть нормальное это еще очень большой вопрос.
CS>Из-за того что в C++ используется deep immutability который(ая) есть вещь суровая, то для практических целей оставлен CS>const_cast<> — явное снятие immutability.
Это ты себе придумываешь. С++ предоставляет возможность локальной защиты в виде объявления переменных как неизменяемыми. Ничего "глубокого" тут нет.
Как показывает практика при работе в рамках подхода когда сам тип определяет возможность своей модификации эта константность не так уж и необходима. Скорее возникает ощущение отсуствие того к чему привык. Но это проходит.
CS>Полный режим readonly возможен только на хардверном уровне.
Ну почему же? Если у меня полностью типобезопасный язык и язык действительно декларирует, что "A != const A", то он обязан гарантировать невозможность изменения объектов типа const A. Просто С++ никогда не бы типобезопасным. Только и всего. Да и const в нем все же трактуется как модификатор переменной.
... << RSDN@Home 1.2.0 alpha rev. 516>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
CS>>Из-за того что в C++ используется deep immutability который(ая) есть вещь суровая, то для практических целей оставлен CS>>const_cast<> — явное снятие immutability.
VD>Это ты себе придумываешь. С++ предоставляет возможность локальной защиты в виде объявления переменных как неизменяемыми. Ничего "глубокого" тут нет.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, c-smile, Вы писали:
CS>>Здравствуйте, c-smile, Вы писали:
CS>>"И ниччо ему золота рыба не сказала..."
E>Так ничего удивительного, имхо. Из любителей D на этом форуме я могу припомнить тебя, uw и Зверька Харьковского.
CS>>deep immutable references — C++ const CS>>shallow immutable references — предлагаемый вариант (#)
CS>>Тогда вопрос — а нужно ли оно вообще?
E>Это ты про D?
E>Имхо, что-то подобное, определенно, нужно. Меня в Java очень добивало то, что объекты передавались в методы по ссылке, но никак нельзя было запретить методу модифицировать объект.
E>Как C++ник, думаю, что нужно делать аналог C++ const. Хотя выльется это, вероятно, в очень серьезную модификацию D. И, кроме того, придется поддерживать mutable-атрибуты у объектов. Кстати, в первом посте ты сказал: "1) имплементация const как он есть в C++. Со всеми вытекающими за и против". А что под "против" понимается?
E>Ну а второй вариант мне даже синтаксически не нравится. Использование спецсимволов для обозначения характеристик объектов -- это, имхо, прямой путь к perl-подобному синтаксису.
В общем-то не так.
typename [] — означает массив элементов типа typename
typename #[] — означает immutable массив элементов типа typename.
Т.е. для лексера #[ это один токен. Примерно так же как << и <<=
Т.е. # не есть синоним слова const.
E>И еще во втором варианте меня вот что смущает. Я уже не помню D толком, но кажется там есть понятие указателей и есть операция разыменования указателя (ты сам сказал: "у readonly указателя нет опреации dereferencing to l-value"). Это позволяет делать на шаблонах что-то вроде (синтаксис C++): E>
E>template< class T >
E>T f( T * p ) { T c = *p; ...; return c; }
E>
E>т.е., если f() вызывается для const T *, то T внутри шаблона будет иметь тип const T. E>А если в D сделать readonly pointer, то не введет ли это новую абстракцию "readonly pointer", который вроде как pointer, но не такой? И не создаст ли это сложностей при программировании тех же шаблонов?
Мысль понял. Спасибо. В предлагаемом варианте получентие значения по ссылке все та же
*.
Т.е.
f<char*>( p )
f<char#*>( p )
будут одинаково работать.
Спец. символы в общем не must.
Проблема в том что например const в С++ означает две или три разные сущности.
Eugene Pelekhay предложил например вариант когда все массивы
по определению read-only:
: // function returns mutable string
: var char[] func1(){}
: // function returns immutable string
: char[] func2(){}
: // function with argument of immutable string
: void func3(char[] s) {}
: // function with argument of reference to immutable string
: // reference assigned during function call and content can't be
: // changed in caller trough returned reference
: void func4(out char[] s) {}
: // function with argument of initialized immutable string
: // that reference can be changed during function call
: void func5(inout char[] s) {}
: // function with argument of mutable string
: // content of string can be changed during function call
: void func6(var char[] s) {}
: // function with argument of reference to mutable string
: // content of string can be changed outside of function
: // through returned reference
: void func7(out var char[] s) {}
: // function with argument of reference to initialized mutable string
: // content of string can be changed outside of function or during call
: // through returned/passed reference
: void func8(inout var char[] s) {}
Это тоже так называемая shallow immutability ( см. ссылки в моих ответах Владу )
Считается (не мной) что попытка сделать deep immutability как в C++ чревата
а) многословием (const everywhere) b) уровень верификации immutability не является достаточным
(a.k.a. овчинка выделки не стоит)
Shallow immutability используется в Deplphi насколько мне известно
Здравствуйте, VladD2, Вы писали:
VD>Тогда напиши в МС, что у них в компиляторе серьезный баг, так как вот такой код:
5.2.8 Type identification
...
The top-level cv-qualifiers of the lvalue expression or the type-id that is the operand of typeid are always ignored. [Example:
class D { ... };
D d1;
const D d2;
typeid(d1) == typeid(d2); // yields true
typeid(D) == typeid(const D); // yields true
typeid(D) == typeid(d2); // yields true
typeid(D) == typeid(const D&); // yields true
—end example]
3.9.3 CV-qualifiers
A type mentioned in 3.9.1 and 3.9.2 is a cv-unqualified type. Each type which is a cv-unqualified complete or incomplete object type or is void (3.9) has three corresponding cv-qualified versions of its type: a const-qualified version, a volatile-qualified version, and a const-volatile-qualified version. The term object type (1.8) includes the cv-qualifiers specified when the object is created. The presence of a const specifier in a decl-specifier-seq declares an object of const-qualified object type; such object is called a const object.
Здравствуйте, VladD2, Вы писали:
VD>То есть ты хочешь сказать, что объект A меняет свой тип будучи присвоеным в константную переменную?
Нет, он присваиваеся объекту другого типа. В том, что CV-квалификация входит в тип выражения (скажем, в отличие от ссылки), можно легко убедиться анализируя как производится вывод типов аргументов шаблонов по аргументам функции. Или просто посмотреть на то, как вводится CV-квалификация в стандарте:
3.9.3 CV-qualifiers [basic.type.qualifier]
1 A type mentioned in 3.9.1 and 3.9.2 is a cv-unqualified type. Each type which is a cv-unqualified complete or incomplete object type or is void (3.9) has three corresponding cv-qualified versions of its type: a const-qualified version, a volatile-qualified version, and a const-volatile-qualified version. The term object type (1.8) includes the cv-qualifiers specified when the object is created. The presence of a const specifier in a decl-specifier-seq declares an object of const-qualified object type; such object is called a const object. The presence of a volatile specifier in a decl-specifier-seq declares an object of volatile-qualified object type; such object is called a volatile object. The presence of both cv-qualifiers in a declspecifier-seq declares an object of const-volatile-qualified object type; such object is called a const volatile object. The cv-qualified or cv-unqualified versions of a type are distinct types; however, they shall have the same representation and alignment requirements (3.9).
VD>Тогда напиши в МС, что у них в компиляторе серьезный баг, так как вот такой код: VD>
Да, хороший пример. Для typeid, т.к. CV-квалифицированные версии являются отдельными типами, присутствует специальное правило, предписывающее именно для целей typeid считать типы, отличающиеся только CV-квалификацией верхнего уровня, идентичными (5.2.8/5).
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
E>5.2.8 Type identification
E>...
E>The top-level cv-qualifiers of the lvalue expression or the type-id that is the operand of typeid are always ignored. [Example:
E>class D { ... };
E>D d1;
E>const D d2;
E>typeid(d1) == typeid(d2); // yields true
E>typeid(D) == typeid(const D); // yields true
E>typeid(D) == typeid(d2); // yields true
E>typeid(D) == typeid(const D&); // yields true
E>—end example]
E>
E>3.9.3 CV-qualifiers
E>A type mentioned in 3.9.1 and 3.9.2 is a cv-unqualified type. Each type which is a cv-unqualified complete or incomplete object type or is void (3.9) has three corresponding cv-qualified versions of its type: a const-qualified version, a volatile-qualified version, and a const-volatile-qualified version. The term object type (1.8) includes the cv-qualifiers specified when the object is created. The presence of a const specifier in a decl-specifier-seq declares an object of const-qualified object type; such object is called a const object.
Ну, тоесть стандарт противоречит сам себе? Или это все же не тип в полном понимании этого слова?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
> E>The top-level cv-qualifiers of the lvalue expression or the type-id that is the operand of typeid are always ignored. [Example:
> E>
> > E>
> E>A type mentioned in 3.9.1 and 3.9.2 is a cv-unqualified type. Each type which is a cv-unqualified complete or incomplete object type or is void (3.9) has three corresponding cv-qualified versions of its type: <...>
> E>
> > Ну, тоесть стандарт противоречит сам себе? Или это все же не тип в полном понимании этого слова?
Не противоречит. Это такое специальное правило: для нескольких различных, но некоторым образом связанных, типов объект type_info хранится общий на всех. Также точно можно было бы внести в спецификацию требование идентичности результата typeid для всех типов, начинающихся с одной и той же буквы. И, хотя в последнем шаге никакого смысла нет, от этого эти типы одним типом бы не стали. Соответственно, CV-квалифицированные версии некоторого типа являются вполне различимыми типами в полном понимании этого слова, но для них введены некоторые специальные правила (идентичность типов с точки зрения typeid — из них далеко не единственное).
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VD>В С# доступна инкапсуляция которая позволяет создать immutability-объекты. Отальное от лукавого. VD>Главное, что этого достаточно для создания immutability-классов решающих поставленную проблему.
Нифига это не решает проблеммы.
Вот пример на С++ из реальной жизни
struct KnotVector
{
double knot_at( int idx ) const;
void resize( int p, int n );
};
struct PointVector
{
const HPoint& point_at( int idx ) const;
void resize( int n );
};
// а теперь внимание сюда:class NurbsCurve
{
KnotVector m_U;
PointVector m_Pw;
public:
const KnotVector& U() const { return m_U; }
const PointVector& Pw() const { return m_Pw; }
// вот здесь:void resize( int p, int n )
{
m_U.resize(p,n);
m_Pw.resize(n);
}
};
Классы KnotVector и PointVector могут юзатся пользователем сами по себе или как агреггаты в других классах NurbsCurve, NurbsSurface и т.п. Причем когда они юзаются как часть агрегата естественно что модификация возможна только классом владельцем.
Если бы не было const то пришлось бы копировать read-only интерфейс KnotVector и PointVector в каждый из классов:
class NurbsSurface
{
KnotVector m_U, m_V;
public:
double u_knot_at(int idx);
double v_knot_at(int idx);
// и еще тридцать методов
};
А const позволяет все закрыть и грамотно все спроектировать. Конечно щас кое кто возразит что можно заюзать const_cast? но это уже не мои проблеммы. Почему бы сразу не заюзать format c:?
Здравствуйте, Kluev, Вы писали:
K>А const позволяет все закрыть и грамотно все спроектировать. Конечно щас кое кто возразит что можно заюзать const_cast? но это уже не мои проблеммы. Почему бы сразу не заюзать format c:?
Вот именно. Кто хочет тот добъётся. Так зачем тогда вообще всё это нужно?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Kluev, Вы писали:
K>>А const позволяет все закрыть и грамотно все спроектировать. Конечно щас кое кто возразит что можно заюзать const_cast? но это уже не мои проблеммы. Почему бы сразу не заюзать format c:?
IT>Вот именно. Кто хочет тот добъётся. Так зачем тогда вообще всё это нужно?
Как зачем? Чтобы тот, кто не хочет (== не написал const_cast), не мог "добиться" ненужного поведения.
Здравствуйте, pvgoran, Вы писали:
IT>>Вот именно. Кто хочет тот добъётся. Так зачем тогда вообще всё это нужно? P>Как зачем? Чтобы тот, кто не хочет (== не написал const_cast), не мог "добиться" ненужного поведения.
Но что делать, если они без этого поведения не могут прожить ни дня Как неправильно не хочется, а как правильно нельзя.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
есть 1) immutable resource, а есть
2) immutable reference — суть readonly observer.
сторонники ultimate immutability (включая Вальтера)
утверждали (past continious, sic!) следующее:
т.к. в C++ нельзя достичь №1 (что правда) значит это все обман
и профанация поэтому народу не нужны ни №1 ни №2.
Путем неслабого LOLQ ( Loss of life quotient, the amount you post is the equivilent to your
loss of life. Очень понравилась аббревиатура ) похоже удалось договориться что
№2 является вельми полезной вещью.
Здравствуйте, c-smile, Вы писали:
CS>есть 1) immutable resource, а есть CS>2) immutable reference — суть readonly observer.
CS>Путем неслабого LOLQ ( Loss of life quotient, the amount you post is the equivilent to your CS>loss of life. Очень понравилась аббревиатура ) похоже удалось договориться что CS>№2 является вельми полезной вещью.
c-smile, а можно для менее эрудированных читателей описать тоже самое в более доступной форме и на русском?
И с примерами, если не сложно.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
IT>>>Вот именно. Кто хочет тот добъётся. Так зачем тогда вообще всё это нужно? P>>Как зачем? Чтобы тот, кто не хочет (== не написал const_cast), не мог "добиться" ненужного поведения.
IT>Но что делать, если они без этого поведения не могут прожить ни дня Как неправильно не хочется, а как правильно нельзя.
Типа, const_cast — это сознательное нарушение const-семантики. (А сознательно, как уже было сказано, можно и format c: сделать.) Важно, чтобы этого нельзя было (или сложно) сделать неосознанно...
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, c-smile, Вы писали:
CS>>есть 1) immutable resource, а есть CS>>2) immutable reference — суть readonly observer.
CS>>Путем неслабого LOLQ ( Loss of life quotient, the amount you post is the equivilent to your CS>>loss of life. Очень понравилась аббревиатура ) похоже удалось договориться что CS>>№2 является вельми полезной вещью.
E>c-smile, а можно для менее эрудированных читателей описать тоже самое в более доступной форме и на русском? E>И с примерами, если не сложно.
Я извиняюсь что получилось как-то уж слишком...
Смысл примерно такой:
В D есть три типа ссылок:
1) array (или slice) ссылка на последовательность элементов, имеет атрибуты ptr — ссылка на первый элемент и length длина в элементах.
2) pointer — обычный pointer на место в памяти — то же самое что и в C/C++
3) object reference — закамуфлированный указатель на объект — то же что и в Java.
Постулируется следующее: Объект(его класс) (если нужно) можно всегда описать таким образом что он будет
"только для чтения" для внеших пользователей.
Т.е. основная проблема и потребность состоит в обеспечентии immutability для arrays и pointers.
Идея предложения состоит в ведении двух новых (и явных в отличии от C++)
типов read-only array (slice) и read-only pointer — типы ссылок
"только читающий наблюдатель".
В общем все просто и очевидно как двери.
Реализация всего этого дела проста до примитивности —
статическое расширение таблицы типов. Внешне все просто
и очевидно. В общем — в D стиле.
Если чего не понятно — свистите попробую объяснить.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, pvgoran, Вы писали:
P>>Важно, чтобы этого нельзя было (или сложно) сделать неосознанно...
IT>Ну а если мне всё-таки это нужно сделать и сделать осознанно? Ну всякие бывают в жизни случаи
Вот когда осознанно — тогда и используешь себе спокойно const_cast. Ровно как и format c:.
Здравствуйте, pvgoran, Вы писали:
IT>>Ну а если мне всё-таки это нужно сделать и сделать осознанно? Ну всякие бывают в жизни случаи P>Вот когда осознанно — тогда и используешь себе спокойно const_cast. Ровно как и format c:.
Т.е. если у меня 30 методов в классе. 15 из них мне не нужно пользовать напрямую, 15 нужно, то мы ставим const, а там где нужно вызываем const_cast? Зашибатый дизайн! Как там Kluev говорил?
А const позволяет все закрыть и грамотно все спроектировать.
Грамотнее уже дальше некуда.
... << RSDN@Home 1.1.4 stable rev. 510>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Ну а если мне всё-таки это нужно сделать и сделать осознанно? Ну всякие бывают в жизни случаи P>>Вот когда осознанно — тогда и используешь себе спокойно const_cast. Ровно как и format c:.
IT>Т.е. если у меня 30 методов в классе. 15 из них мне не нужно пользовать напрямую, 15 нужно, то мы ставим const, а там где нужно вызываем const_cast? Зашибатый дизайн!
Так... Что-то я не понял, причем здесь const и const_cast. Можно поподробнее?
Здравствуйте, pvgoran, Вы писали:
IT>>Т.е. если у меня 30 методов в классе. 15 из них мне не нужно пользовать напрямую, 15 нужно, то мы ставим const, а там где нужно вызываем const_cast? Зашибатый дизайн! P>Так... Что-то я не понял, причем здесь const и const_cast. Можно поподробнее?
Что тут непонятного? Что ты будешь делать, если половину методов в классе тебе нужно разрешить использовать, а вторую половину ты хочешь "грамотно все спроектировать" и закрыть?
... << RSDN@Home 1.1.4 stable rev. 510>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, pvgoran, Вы писали:
IT>>>Т.е. если у меня 30 методов в классе. 15 из них мне не нужно пользовать напрямую, 15 нужно, то мы ставим const, а там где нужно вызываем const_cast? Зашибатый дизайн! P>>Так... Что-то я не понял, причем здесь const и const_cast. Можно поподробнее?
IT>Что тут непонятного? Что ты будешь делать, если половину методов в классе тебе нужно разрешить использовать, а вторую половину ты хочешь "грамотно все спроектировать" и закрыть?
Здравствуйте, c-smile, Вы писали:
IT>>Что тут непонятного? Что ты будешь делать, если половину методов в классе тебе нужно разрешить использовать, а вторую половину ты хочешь "грамотно все спроектировать" и закрыть?
CS>Что значит "закрыть"? CS>Это не про private/protected/public ли?
Нет, это const. См. выше по топику.
... << RSDN@Home 1.1.4 stable rev. 510>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
IT>>>Что тут непонятного? Что ты будешь делать, если половину методов в классе тебе нужно разрешить использовать, а вторую половину ты хочешь "грамотно все спроектировать" и закрыть?
CS>>Что значит "закрыть"? CS>>Это не про private/protected/public ли?
IT>Нет, это const. См. выше по топику.
Где? Я совсем запутался.
Вот эта твоя фраза:
"Что ты будешь делать, если половину методов в классе тебе нужно разрешить использовать, а вторую половину ты хочешь "грамотно все спроектировать" и закрыть?"
Имеет ответ:
...разрешить использовать — объявить public
...закрыть — объявить private/protected/package
1) Есть абстрактное понятие resource immutability
гипотетическая возможность объявление фрагмента памяти "только для чтения".
2) Есть второе понятие — reference immutability — "через эту ссылку на память её (память) изменить нельзя"
Известно что №1 имплементировать на уровне компилятора практически нельзя —
требуется runtime имплементация на уровне virtual machine. Для C++ виртуальной машиной
явлеяется сам процессор. Т.е. без поддержки процессора №1 имплементирвать нельзя.
На уровне VM (.NET/Java) это сделать можно, но путем еще большей потери эффективности
Как я понял ты утверждаешь следующее :
Если №1 сделать практически нельзя то и №2 никому не нужен.
Я правильно тебя понял?
Дело в том что reference immutability (№2) есть того же поля ягода
что и наличие в языках атрибутов видимости public / private / protected.
const в С++ это просто еще один инструмент на эту тему.
Т.е. если считать что const это не решение, то и public / private / protected тоже
бесполезны — эти атрибуты "снимаются" простым кастом к открытому типу.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, pvgoran, Вы писали:
IT>>>Ну а если мне всё-таки это нужно сделать и сделать осознанно? Ну всякие бывают в жизни случаи P>>Вот когда осознанно — тогда и используешь себе спокойно const_cast. Ровно как и format c:.
IT>Т.е. если у меня 30 методов в классе. 15 из них мне не нужно пользовать напрямую, 15 нужно, то мы ставим const, а там где нужно вызываем const_cast? Зашибатый дизайн! Как там Kluev говорил?
IT>
А const позволяет все закрыть и грамотно все спроектировать.
IT>Грамотнее уже дальше некуда.
Уважаемый IT я не понимаю на что ты жалуешься? Если ты юзаешь в С++ const_cast это значит что ты изучил классцы и знаешь что делаешь. В С# вася пупкин напишет immutable-proxy и прийдется только через рефлекшн лезть в обход private (еще хуже чем конст_каст). Или самому все переписать и кататся на своих собственных велосипедах. Проблема не в констах а в вася-пупкиных. Только в С++ проще — написал const и спи отдыхай. А в С# прийдется пыхтеть для каждого класса readonly-прохор писать. Или вообще забить на константность. Только это тоже не выход. Забиваем на константноть потребуется писть доку: что можно, а что нельзя. Забиваем на доку — нужен самодокументируемый внятный код. Иными словами троерожный бес — как не кинь всегда рогом вверх.
Здравствуйте, IT, Вы писали:
K>>А const позволяет все закрыть и грамотно все спроектировать. Конечно щас кое кто возразит что можно заюзать const_cast? но это уже не мои проблеммы. Почему бы сразу не заюзать format c:? IT>Вот именно. Кто хочет тот добъётся. Так зачем тогда вообще всё это нужно?
А зачем тогда вобще типизация нужна? Назад к ассемблеру?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Kluev, Вы писали:
IT>>Грамотнее уже дальше некуда.
K>Уважаемый IT я не понимаю на что ты жалуешься? Если ты юзаешь в С++ const_cast это значит что ты изучил классцы и знаешь что делаешь.
Знаешь что ты только что сказал? Примерно следующее. У нас есть классная фича в виде const, но иногда она не работает, поэтому у нас есть const_cast, стандартное средство для обхода классной фичи, а по сути грязный стандартизированный хак, встроенный непосредственный язык.
K>В С# вася пупкин напишет immutable-proxy и прийдется только через рефлекшн лезть в обход private (еще хуже чем конст_каст).
Вася не будет этого делать. Если Васе очень будет это надо, то скорее всего он откажется от столь "грамотно всё спроектированного" и напишет свой велосипед, не столь "грамотно спроектированный", но делающий то, что ему надо.
K>Или самому все переписать и кататся на своих собственных велосипедах.
Вот-вот. Так обычно и происходит с черезчур "грамотным проектированием".
K>Проблема не в констах а в вася-пупкиных. Только в С++ проще — написал const и спи отдыхай. А в С# прийдется пыхтеть для каждого класса readonly-прохор писать. Или вообще забить на константность. Только это тоже не выход. Забиваем на константноть потребуется писть доку: что можно, а что нельзя. Забиваем на доку — нужен самодокументируемый внятный код. Иными словами троерожный бес — как не кинь всегда рогом вверх.А const позволяет все закрыть и грамотно все спроектировать.
Ты это расскажи всё тем кто пишет и использует .NET Framework. Расскажи им, что они все лохи, потому что не используют const и, главное, потом не обходят его с помощью const_cast.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
K>>Уважаемый IT я не понимаю на что ты жалуешься? Если ты юзаешь в С++ const_cast это значит что ты изучил классцы и знаешь что делаешь. IT>Знаешь что ты только что сказал? Примерно следующее. У нас есть классная фича в виде const, но иногда она не работает, поэтому у нас есть const_cast, стандартное средство для обхода классной фичи, а по сути грязный стандартизированный хак, встроенный непосредственный язык.
const_cast это такойже грязный хак как добираться до приватных методов через рефлекшен.
У нас в .НЕТ есть такая мегафича как модификаторы доступа но иногда она не работает потомучто у нас есть стандартное средство для ее обхода.
IT>Ты это расскажи всё тем кто пишет и использует .NET Framework. Расскажи им, что они все лохи, потому что не используют const и, главное, потом не обходят его с помощью const_cast.
Я почти год пишу практически только под .НЕТ и могу сказать что авторы .НЕТ сильно облажались не введя модификатор const(с этим даже Влад согласен).
Из-за этого "гениального" решения мне несколько раз приходилось писать immutable proxy для того чтобы защититься от собственных случайных ошибок. Причем если в С++ это встроено в язык и не вызывает накладных расходов во в .НЕТ мне пришлось повозиться и смириться с мение понятным кодом который жрал ресурсы во время исполнения.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>const_cast это такойже грязный хак как добираться до приватных методов через рефлекшен. WH>У нас в .НЕТ есть такая мегафича как модификаторы доступа но иногда она не работает потомучто у нас есть стандартное средство для ее обхода.
Только почему-то эту мегафичу хотят заиспользовать в основном те, кто раньше жить не мог без const_cast. Странное совпадение.
IT>>Ты это расскажи всё тем кто пишет и использует .NET Framework. Расскажи им, что они все лохи, потому что не используют const и, главное, потом не обходят его с помощью const_cast. WH>Я почти год пишу практически только под .НЕТ и могу сказать что авторы .НЕТ сильно облажались не введя модификатор const(с этим даже Влад согласен).
Я уже три года пишу под .NET, а до этого с 88 по 2003 писал на C/C++ и всегда использовал const как завещал великий Страуструп. Но что забавно, под .NET я великолепно обхожусь без const и его отсутствие мне не досаждает. А вот на плюсах доводилось периодически материться. А так как я человек, не ищущий приключений на свою задницу в виде рефлекшинов и const_cast, то чаще всего приходилось выпиливать свои велосипеды.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, c-smile, Вы писали:
CS>Я правильно тебя понял? CS>Или я неправильно тебя понял?
Да
const очень неоднозначная конструкция. И очень часто решая одну проблему, порождает массу дргих. Соответствовать доказывать её экстраординарность глупо. Именно это я и хотел сказать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Ты это расскажи всё тем кто пишет и использует .NET Framework. Расскажи им, что они все лохи, потому что не используют const и, главное, потом не обходят его с помощью const_cast.
Незнаю, но от readonly для внутренних переменных и содержимого массива я бы не отказался. Хотя конечно товарищи пропагандирующие const явно преувеличивают его необходимость.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>У нас в .НЕТ есть такая мегафича как модификаторы доступа но иногда она не работает потомучто у нас есть стандартное средство для ее обхода.
Оно, кстати, защитой регулируется. Настрой палитику и фига два ты доберешся до скрытых членов.
WH>Я почти год пишу практически только под .НЕТ и могу сказать что авторы .НЕТ сильно облажались не введя модификатор const(с этим даже Влад согласен).
Ты явно преувеличиваешь. Да и ключевое слово const тут не очень уместно. Но readonly для локальных переменных и содержимого массивов было бы поиметь очень приятно. Тут я с тобой согласен. Еще хорошо бы все же иметь некий механизм позволяющий инкапсулировать общение между двумя тесносвязанными классами (вроде држбы в плюсах) и для инкапсуяции части реализации класса. Но это все же не так критично как тут пояют артодоксальные плюсовики.
WH>Из-за этого "гениального" решения мне несколько раз приходилось писать immutable proxy для того чтобы защититься от собственных случайных ошибок. Причем если в С++ это встроено в язык и не вызывает накладных расходов во в .НЕТ мне пришлось повозиться и смириться с мение понятным кодом который жрал ресурсы во время исполнения.
Зато это намного более надежное решение, и как следсвие лучший дизайн.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>Я правильно тебя понял? CS>>Или я неправильно тебя понял?
IT>Да
IT>const очень неоднозначная конструкция. И очень часто решая одну проблему, порождает массу дргих. Соответствовать доказывать её экстраординарность глупо. Именно это я и хотел сказать.
То что const не решает каких-то проблем известно.
В начальном послании я хотел узнать альтернативы. Они есть?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WolfHound, Вы писали:
WH>>У нас в .НЕТ есть такая мегафича как модификаторы доступа но иногда она не работает потомучто у нас есть стандартное средство для ее обхода.
VD>Оно, кстати, защитой регулируется. Настрой палитику и фига два ты доберешся до скрытых членов.
WH>>Я почти год пишу практически только под .НЕТ и могу сказать что авторы .НЕТ сильно облажались не введя модификатор const(с этим даже Влад согласен).
VD>Ты явно преувеличиваешь. Да и ключевое слово const тут не очень уместно. Но readonly для локальных переменных и содержимого массивов было бы поиметь очень приятно. Тут я с тобой согласен. Еще хорошо бы все же иметь некий механизм позволяющий инкапсулировать общение между двумя тесносвязанными классами (вроде држбы в плюсах) и для инкапсуяции части реализации класса. Но это все же не так критично как тут пояют артодоксальные плюсовики.
WH>>Из-за этого "гениального" решения мне несколько раз приходилось писать immutable proxy для того чтобы защититься от собственных случайных ошибок. Причем если в С++ это встроено в язык и не вызывает накладных расходов во в .НЕТ мне пришлось повозиться и смириться с мение понятным кодом который жрал ресурсы во время исполнения.
VD>Зато это намного более надежное решение, и как следсвие лучший дизайн.
В ответ на
VD>Как меня раздражает эта твоя "импелементации"... если бы ты знал.
Спешу заверить в аналогичном:
Ортодоксальные, и политику, доберешься ... и так далее
Здравствуйте, c-smile, Вы писали:
CS>То что const не решает каких-то проблем известно. CS>В начальном послании я хотел узнать альтернативы. Они есть?
Не знаю Хотя... Например, в .NET строчку нельзя изменить. Нельзя! Вообще никак. Любые манипуляции над строкой всегда возвращают новый экземпляр. Поначалу напрягало, такие вещи воспринимались как дикость:
string s = "111";
s[1] = '2'; // error CS0200: Property or indexer 'string.this[int]' cannot be assigned to -- it is read only
Особенно в голову лезли всякие дурацкие мысли о производительности.
Сейчас как дикостью воспринимается обратная ситуация.
CS>В любом случасе спасибо за участие.
Дык, you are welcome!
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Еще хорошо бы все же иметь некий механизм позволяющий инкапсулировать общение между двумя тесносвязанными классами (вроде држбы в плюсах)
internal — редкостная дрянь, впрочем не на много хуже чем friend в плюсах.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Незнаю, но от readonly для внутренних переменных
А чем свойства не устраивают?
VD>и содержимого массива я бы не отказался. Хотя конечно товарищи пропагандирующие const явно преувеличивают его необходимость.
А как в строке сделан индексер?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Знаешь что ты только что сказал? Примерно следующее. У нас есть классная фича в виде const, но иногда она не работает, поэтому у нас есть const_cast, стандартное средство для обхода классной фичи, а по сути грязный стандартизированный хак, встроенный непосредственный язык.
Во первых в этом несовершенном мире не может быть совершенных решений. Поэтому у const есть и достоинства и недостатки. Лично мне конст помогает избежать многих ошибок: имеешь read-only доступ к агрегатам класса, а модификация только через обьект владелец (пример я уже приводил). А "грязный хак" const_cast мне приходилось использовать всего два раза. Так то я не вижу никаких проблем и считаю критику конст необоснованой.
З.Ы. То что const нет в шарпе еще не повод его критиковать. Я вот попробовал на шарп перелезть и оказалось, что для меня он не подходит совершенно.Для моих задач основной тип данных — интрузивные списки, а шарп для их реализации может только copy-paste предложить. Т.к. интрузивные списки — это тот редкий случай когда нужно либо множественное наследование либо указатели на члены.
Здравствуйте, IT, Вы писали:
IT>Только почему-то эту мегафичу хотят заиспользовать в основном те, кто раньше жить не мог без const_cast. Странное совпадение.
Я почемуто прекрасно обходился без const_cast. Что я делал не так?
IT>Я уже три года пишу под .NET, а до этого с 88 по 2003 писал на C/C++ и всегда использовал const как завещал великий Страуструп. Но что забавно, под .NET я великолепно обхожусь без const и его отсутствие мне не досаждает. А вот на плюсах доводилось периодически материться. А так как я человек, не ищущий приключений на свою задницу в виде рефлекшинов и const_cast, то чаще всего приходилось выпиливать свои велосипеды.
В С++ с const у меня ниразу небыло проблем. А под .НЕТ я уже несколько раз матерился из-за того что мне на ровном месте приходилось писать immutable proxy там где в С++ я просто напсал бы const.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
WH>>Из-за этого "гениального" решения мне несколько раз приходилось писать immutable proxy для того чтобы защититься от собственных случайных ошибок. Причем если в С++ это встроено в язык и не вызывает накладных расходов во в .НЕТ мне пришлось повозиться и смириться с мение понятным кодом который жрал ресурсы во время исполнения. VD>Зато это намного более надежное решение, и как следсвие лучший дизайн.
Когда я в С++ помечаю методы модификатором const я фактически описываю интерфейс класса который содержит методы которые не могут менять содержимое класса.
Те примерно так
C++
Итого: В С++ мы имеем поддержку языка что позволяет не писать дополнительных интерфейсов, правильность реализации константных методов контролирует компилятор...
А теперь объясни с какого перепугу решение на C# болие надежно?
Короче const рулит. Никаких аргументов против я до сих пор не услышал.
Единственное что смогли придумать это то что некоторые несознательные личности ставят const не там где он нужен. Но дело в том что таже проблема есть у модификаторов доступа и следуя этой логике нужно отменить private, protected, internal... оставляем все public и радуемся жизни
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
IT>А чем свойства не устраивают?
Под "внутренними" я понимаю "локальные" переменные и параметры.
Кстати, readonly не устраивает тем, что оно защищает переменную. В случае ссылки на массив оно не работет. Даже вводит в заблуждение:
class A
{
readonly int[] _array = new int[] { 1, 2 };
public void X()
{
_array[0] = 123; // OK :(
}
}
IT>А как в строке сделан индексер?
Я как бы не против ООП-зашиты и все такое. Но расширенная семантика readonly явно каши не испортила бы.
Кстати, я бы еще ввел понятие immutable-класса. Чтобы контроль таких классов как string осуществлялся бы не разработчиком, а компилятором. А то ведь ничего не стоит по шибке залепить модифицирующий метод. Во втором фрэймворке ввели static-классы. Почему бы был не ввести immutable-классы?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>То что const не решает каких-то проблем известно. CS>>В начальном послании я хотел узнать альтернативы. Они есть?
IT>Не знаю Хотя... Например, в .NET строчку нельзя изменить. Нельзя! Вообще никак. Любые манипуляции над строкой всегда возвращают новый экземпляр. Поначалу напрягало, такие вещи воспринимались как дикость:
IT>
IT>string s = "111";
IT>s[1] = '2'; // error CS0200: Property or indexer 'string.this[int]' cannot be assigned to -- it is read only
IT>
IT>Особенно в голову лезли всякие дурацкие мысли о производительности.
IT>Сейчас как дикостью воспринимается обратная ситуация.
А если так?:
s[1] = '2';
s[2] = '3';
s[3] = '4';
Создастся три строки? Если нет то как это сделано?
reference counting?
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>c-smile,
>> IT>
>> IT>string s = "111";
>> IT>s[1] = '2'; // error CS0200: Property or indexer 'string.this[int]' cannot be assigned to -- it is read only
>> IT>
>> IT>Особенно в голову лезли всякие дурацкие мысли о производительности. >> IT>Сейчас как дикостью воспринимается обратная ситуация.
>> А если так?: >>
>> s[1] = '2';
>> s[2] = '3';
>> s[3] = '4';
>>
>> Создастся три строки?
ПК>Нет, это просто не скомпилируется: содержимое объекта System::String менять нельзя.
Mea culpa, проглядел комментарий
Да и знаю же сам про StringBuffer/Builder...
Здравствуйте, WolfHound, Вы писали:
WH>Из-за этого "гениального" решения мне несколько раз приходилось писать immutable proxy для того чтобы защититься от собственных случайных ошибок.
Угу, причем именно отдельных прокси-имплементаторов отдельных immutable интерфейсов.
Поначалу я посчитал себя шибко умным, сделал имплементацию некоего MyReadOnlyBase — класса, и в public сигнатурах использовал именно его. Однако, соседи за партой так же быстро приводили его к наследнику, типа:
(MyMutable)myReadOnlyBaseVariable;
Так что, остается именно так — полновесные прокси, с разделением на интерфейсы и реализации на ровном месте (где этого не требовалось).
А потом подумаешь малость... И придет к тебе еще более "просветленное" решение: "да нахрена это вообще надо, есть же юнит тесты... и их все-равно запускать"...
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VladD2, Вы писали:
VD>>Еще хорошо бы все же иметь некий механизм позволяющий инкапсулировать общение между двумя тесносвязанными классами (вроде држбы в плюсах)
IT>internal — редкостная дрянь, впрочем не на много хуже чем friend в плюсах.
кстати, это единственный механизм реализации открытого immutable класса, при реально использующемся internal mutable-наследнике без дополнительного прокси.
Опять же, такая фича провоцирует на порождение множества мелких сборок.
Здравствуйте, vdimas, Вы писали:
V>кстати, это единственный механизм реализации открытого immutable класса, при реально использующемся internal mutable-наследнике без дополнительного прокси.
Проблемы начинаются когда ты такой класс начинаешь выносить из сборки. Тут сразу же появляются и прокси и другие подпорки
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
V>А потом подумаешь малость... И придет к тебе еще более "просветленное" решение: "да нахрена это вообще надо, есть же юнит тесты... и их все-равно запускать"...
Вот-вот. Сначала нужно определиться с уровнем доверия к вызывающему коду, а уже потом строить от него всякие защиты.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vdimas, Вы писали:
V>>А потом подумаешь малость... И придет к тебе еще более "просветленное" решение: "да нахрена это вообще надо, есть же юнит тесты... и их все-равно запускать"...
IT>Вот-вот. Сначала нужно определиться с уровнем доверия к вызывающему коду, а уже потом строить от него всякие защиты.
Уровень доверия... вона как...
Нужно тогда ввести в язык вместе с private, readonly и пр. конструкцию мамой_клянусь
или там в особо ответственных случаях мля_буду ...
Здравствуйте, IT, Вы писали:
V>>А потом подумаешь малость... И придет к тебе еще более "просветленное" решение: "да нахрена это вообще надо, есть же юнит тесты... и их все-равно запускать"...
IT>Вот-вот. Сначала нужно определиться с уровнем доверия к вызывающему коду, а уже потом строить от него всякие защиты.
Это не защита, и уровень доверия здесь ни при чем. Это ближе к более ясному выражению своих намерений, и к переносу информации из комментариев в код, для того чтобы компилятор мог напоминать, например, о расхождениях в намерениях автора класса/функции и их пользователя.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vdimas, Вы писали:
V>>кстати, это единственный механизм реализации открытого immutable класса, при реально использующемся internal mutable-наследнике без дополнительного прокси.
IT>Проблемы начинаются когда ты такой класс начинаешь выносить из сборки. Тут сразу же появляются и прокси и другие подпорки
К сожалению, они зачастую "невыносимы", т.е. даже подпорки иногда не помогают. Например, мы не можем подменить Nodes-collection в том же TreeView, да и во многих других аналогичных моментах. Сделать в своем наследнике прокси для Nodes — тоже фигушки, ибо не все события внутри него поддаются перехвату/обнаружению.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, vdimas, Вы писали:
V>>>А потом подумаешь малость... И придет к тебе еще более "просветленное" решение: "да нахрена это вообще надо, есть же юнит тесты... и их все-равно запускать"...
IT>>Вот-вот. Сначала нужно определиться с уровнем доверия к вызывающему коду, а уже потом строить от него всякие защиты.
CS>Уровень доверия... вона как... CS>Нужно тогда ввести в язык вместе с private, readonly и пр. конструкцию мамой_клянусь CS>или там в особо ответственных случаях мля_буду ...
А ещё -- никому не дам, дам только ему и его друзьям, дам всем и.т.п.
Если нам не помогут, то мы тоже никого не пощадим.
