Здравствуйте, IB, Вы писали:
ANS>>Но раз ты так написал, то вопрос, почему так? IB>Я не написал, я процитировал.
Понятно.
ANS>> Чем публичное поле отличается от публичного свойства для пользователя контракта (в смысле для программиста, который пользуется объектом)? IB>Хотя бы метаданными.
Если бы пара гетер/сетер была обязательной, то в этом был бы смысл. А так...
ANS>> Например создаётся событие "свойство такое-то поменялось". IB>Событие — это не побочный эффект.
Неужто? Зачем же нужны события, в ответ на которые никто ничего не делает?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Если бы пара гетер/сетер была обязательной, то в этом был бы смысл.
В этом и так есть смысл.
ANS>Неужто?
Ужто.
ANS> Зачем же нужны события, в ответ на которые никто ничего не делает?
В ответ на события делают снаружи объекта, а не внутри оного.
Здравствуйте, _FRED_, Вы писали:
_FR>Получается, что массив не может быть полем неизменяемого объекта? Или нужен будет ещё и read-only неизменяемый массив?
Если вводить неизменяемость на уровне рантайма, то все базовые структуры обязаны иметь неизменяемые варианты.
_FR>Или, нарпимер, DataSet — он тоже не может быть полем неизменяемого объекта?
Не может.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _FRED_, Вы писали:
_FR>На самом деле предложение VladD2 запретить неизменяемым объектам ссылаться (иметь как поля) изменяемые меня удивила. Выходит, неизменяемые объекты не могут содержать событий, например. То есть резко ограничены по функциональности по сравнению с обычными типами (классами), зато выгодны с точки зрения потребления ресурсов, например. И я пока не вижу, где была бы польза от использования таких объектов
А зачем неизменяемому объекту события? Она же получил свое состояние раз и на всегда. Зачем кого-то оповещать? В прочем, если надо, то нет проблем передатьс ссылки на методы обратной свизи в констурктор.
Есть туча мест где было бы выгодно иметь неизменяемые объекты. И контроль во время компиляции в купе с уменьшением цены владения объектом никому бы не помешал бы. Примеры таких объектов у нас перед глазами: связанные списки (очень часто используются в ФП), строки, бинарные деревья. Неизменяемыми можно было бы сделать шрифты, кисти и другие информационные объекты.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, konsoletyper, Вы писали:
VD>>По идее — нет.
K>На самом деле, да. Ведь ссылка на mutable-объект — это как-бы его identity. Если этот самый identity нельзя изменить, то иммутабельность сохраняется. Например, в Nemerle можно написать
K>
K>controls : list[Control]
K>
K>При этом список останется иммутабельным, у него будет неизменный хэш-код, и он будет эквивалентен другим спискам, содержащим те же контролы в том же порядке (здесь под "те же" имеется в виду равенство идентичностей, а не содержимого).
Это разные вещи. То о чем говоришь ты уже есть и для этого ничего не надо делать. А вот неизменяемые объекты — это немного другое дело.
Бло бы здорово если компилятор бы автоматом проверял бы вложенность и не позволял бы хранить в неизменяемых объектах списки изменяемых, но позволял бы хранить списки неизменяемых.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _d_m_, Вы писали:
___>Поэтому Microsoft должна была реализовать метод Equals типа Object так: ___>
___>public class Object {
___> public virtual Boolean Equals(Object obj) {
___> if( obj == null ) return false;
___> if( this.GetType() != obj.GetType() ) return false;
___> // Т.к. в System.Object не определены поля, следует считать, что поля равны
___> return true;
___> }
___>}
___>
___>... ___>[/q]
Согласен с Синклером. Заявление мягко говоря опрометчивое. По фигу что "в System.Object не определены поля". Ведь метод автоматически наследуется всеми потомками! Это приведет к тому, что всенаследники по умолчанидю получат некорректную реализацию этого метода. А это уже натуральная деверсия.
Сейчас реализация рассчитана на то, что по умолчанию объекткт опеределяется его ссылкой. Разные ссылки == разные объекты. Такое поведение приемлемо для большинства применений (что и показывает практика). Если это поведение неприемлемо, то нужно просто переопределять его.
Так что на мой взгляд Риктер неправ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IB, Вы писали:
ANS>> Зачем же нужны события, в ответ на которые никто ничего не делает? IB>В ответ на события делают снаружи объекта, а не внутри оного.
Аа. Изменение состояния не объекта, но всей системы делает эффект не побочным? Понимаю...
Здравствуйте, VladD2, Вы писали: VD>Синклер... Что-то ты разошелся. VD>Это называется — заблуждение. А то и просто "несовпадение мнений".
Заблуждение — это когда, к примеру, Рихтер делает утверждение, оказавшееся ложным. Например, "размер system.IntPtr не зависит от платформы". Ну то есть если он знает, что оно ложное, то это — вранье, а если не знает — то честное заблуждение. (Примечание: Рихтер такого на самом деле не утверждает. Это вымышленный пример.)
А вот очевидно тупиковые решения, из которых последуют массовые неудобства — это бред. Не, ну я могу назвать это как-то политкорректно, например "не вполне продуманные рекомендации", но сути это не изменит.
Ход мысли, приводящий к таким "не вполне продуманным рекомендациям", традиционно называется в нашей русскоязычно-программистской среде "наркоманией".
Я бы мог, опять же, завуалировать мое профессиональное мнение привычной риторикой типа "что курил Рихтер перед этим?", но сути бы это опять же не изменило.
Кроме того, привычный к забористой ругани завсегдатай ФП вряд ли сможет оценить всю глубину моего негодования по поводу данных предложений Рихтера, смягчи я формулировку.
А меня крайне напрягает эта магия имени. Если бы с предложением реализовать дефолтный Equals как проверку на совпадение типа выступил рядовой аноним, его бы тут подняли на смех (и поделом). Но сейчас это предложение обрело священный ореол знаменитого имени — и ты погляди, с каким усердием народ защищает эту дурость! Уже неканонические трактовки сочиняются, мол он не это имел в виду.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, _FRED_, Вы писали:
_FR>Да, спасибо. AndrewVK c IT уже мне всё объяснили.
_FR>Я понимал под "неизменяемостью" немного другое: запрет на изменение полей класса.
Объекта наверное... А что в нем еще что-то можно менять?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_FR>>Я понимал под "неизменяемостью" немного другое: запрет на изменение полей класса. VD>Объекта наверное...
Конечно
VD>А что в нем еще что-то можно менять?
class A
{
public object b;
}
class X
{
A a = new A();
static void Main() {
X x = new X();
x.a.b = "aaa"; // здесь поле 'a' объекта 'x' не меняется, а меняется поле 'b' объекта 'x.a'
x.a = new A(); // а вот тут меняется поле 'a' объекта 'x'
}
}
Другими словами, я называл "неизменяемым" тип, все поля которого являются "readonly" (в терминах C#), без ограничения того, что типы полей такого типа так же должны быть "неизменяемыми".
... << RSDN@Home 1.2.0 alpha rev. 717>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _d_m_, Вы писали:
___>Ага, я решил в своем проекте использовать сборку Васи Пупкина. Где гарантия, что он их использовал по назначению? Уж если даже в самой FCL они не всегда по назначению. Это как с управлением памятью в C/C++ — надо просто ее всегда ее освобождать. Но... не всегда получалось — и память текла. И тогда подумали и сделали .Net и в нем GC. Чуствуешь взаимосвязь?
Если использовать в своих проектах черт-знает-что от черт-знает-кого, то результат будет понятно какой.
Связь между пропертями и управлением памятью не чувстствую...
Здравствуйте, _d_m_, Вы писали:
HB>>А где гарантия, что Вася, например, не написал метод get_Something(), который меняет состояние объекта? ___>Гарантии нет, но: ___>
___>...
___> MyClass c = new MyClass();
___> int d = c.I; // то, что здесь меняется состояние объекта "c" уж очень неочевидно
___> int e = c.get_I();
___>...
___>
Если честно, мне это в обоих случаях не очевидно — меняется оно или нет. Но если клиент должен немедленно реагировать на изменение состояния, то в C# это будет событие. В какую из пар фигурных скобочек при этом заключен код, изменивший состояние, а равно как и то, что перед этими скобочками написано (get, set, get_I() или ещё что) — совершенно не важно.
Здравствуйте, VladD2, Вы писали:
VD>Бло бы здорово если компилятор бы автоматом проверял бы вложенность и не позволял бы хранить в неизменяемых объектах списки изменяемых, но позволял бы хранить списки неизменяемых.
Ещё одно полезное применение неизменяемости это covariant generic parameters — неизменяемые типы дают статическую гарантию безопасности этой фичи.
А то я уже задолбался yield return писать.
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, VladD2, Вы писали:
VD>>Бло бы здорово если компилятор бы автоматом проверял бы вложенность и не позволял бы хранить в неизменяемых объектах списки изменяемых, но позволял бы хранить списки неизменяемых. EC>Ещё одно полезное применение неизменяемости это covariant generic parameters — неизменяемые типы дают статическую гарантию безопасности этой фичи. EC>А то я уже задолбался yield return писать.
Можете по подробней описать, при чем тут yield return?
Здравствуйте, Kore Sar, Вы писали:
EC>>Ещё одно полезное применение неизменяемости это covariant generic parameters — неизменяемые типы дают статическую гарантию безопасности этой фичи. EC>>А то я уже задолбался yield return писать.
KS>Можете по подробней описать, при чем тут yield return?
Например есть IEnumerable<string>, надо вернуть IEnumerable<object>.
Тупо return значение типа IEnumerable<string> из функции с типом возвращаемого значения IEnumerable<object> не прокатит.
Вот yield return единственный известный мне выход.
now playing: Marc Antona & Anthony Collins — AM-PM
Здравствуйте, _d_m_, Вы писали:
___>И что же такого хорошего в этих пропетях? По моему так без них только лучше.
Все сообщения этой темы ниасилил. Не знаю, может кто-нить уже упоминал об этом. Самое главное достоинство пропертей — это то, что их семантика идеально подходит для различных визуальных сред программирования, свойства объектов которых радактируются в проперти-гридах. Скрытие чтение и записи под одним именем свойства позволяет одновременно видеть значение свойства в проперти-гриде и при необходимости изменять его:
*-----------*------------*
| Caption | Window cap |
*-----------*------------*
| Left | 253 |
*-----------*------------*
Представим себе, что мы бы отказались от пропертей. Тогда таблица свойств объекта получилась бы примерно такой:
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, Kore Sar, Вы писали:
EC>>>Ещё одно полезное применение неизменяемости это covariant generic parameters — неизменяемые типы дают статическую гарантию безопасности этой фичи. EC>>>А то я уже задолбался yield return писать.
KS>>Можете по подробней описать, при чем тут yield return?
EC>Например есть IEnumerable<string>, надо вернуть IEnumerable<object>. EC>Тупо return значение типа IEnumerable<string> из функции с типом возвращаемого значения IEnumerable<object> не прокатит. EC>Вот yield return единственный известный мне выход.
Мы уже победили, просто это еще не так заметно...
Конечно
