IB wrote:
> ZEN>В случае со свойством сложно-составной геттер *может* иметь
> собственную семантику,
> Может, но не должен. О чем собственно и речь.
А как быть с вещами типа lazy-loading/lazy-creation?

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

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

__>>>>Единственное что реально мешает это — Причина в том, что свойства выглядят как поля, на самом деле являясь методами.

HB>>Гм... Ну так надо просто считать, что все, что торчит из класса наружу — это либо метод либо свойство (тоже метод). Собственно, других классов я давно не видел.

___>Спасибо за совет. Обязательно им воспользуюсь. Слушаем да не слышим, смотрим, но не видим?

Ну вы-то похоже точно!

Здравствуйте, Константин Б., Вы писали:

___>>- при вызове несколько ряд подряд метод свойства может возвращать разные значения, а поле возвращает одно и тоже значение. В классе System.DateTime есть неизменяемое свойство Now ...
КБ>Ну есть косячок. Но неужели у кого-то с этим свойством проблемы?

Хм, а какие проблемы? Оно же статическое к тому-же... И объект вроде один — время — и состояние постоянно меняется.

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

___>>Спасибо за совет. Обязательно им воспользуюсь. Слушаем да не слышим, смотрим, но не видим?

S>Ну вы-то похоже точно!

Ладно я, допустим. А Рихтер?

IB,

ZEN>>Этот "геморрой" проверяется компилятором на этапе компиляции (или сразу в редакторе кода)
IB>Угу, то-то большинство явистов, оптом предпочитают декларировать одно большое исключение на все случаи жизни, чтобы компилятор лишний раз не тревожил. Похоже классический пример, когда лекарство хуже болезни.

Есть "правельный" (TM) спосоп:

public void doSomfin(byte[] is) /*nofin here*/
    try
    {
        fileinputstream.read(is);
    }
    catch (Exception e)
    {
        throw new RuntimeException(e);
    }

Хотя... тоже гемор. В идеале хотелось бы на этапе компиляции вытащить весь список эксепшнов там, где это требуется, но они не были бы контролируемыми.

Здравствуйте, _d_m_, Вы писали:
___>Нда? Ну в таком случае — тебе прямая дорога в церковь. Я с этой мыслью не первый, а лишь согласен с Рихтером. Слышал про такого?
У Рихтера, имхо, какие-то личные проблемы с шарпом и дотнетом. Он в своей книге дает много откровенно бредовых рекомендаций. В целом, они выглядят как рассуждения престарелой монашки о сексе. Я лично не могу поверить, что от сходства синтаксиса проперти и поля могла возникнуть хоть на полпальца серъезная проблема. Что, кто-то хоть раз предположил, что Array.Length — это поле? Или от неверного предположения пострадали сотни невинных? Все эти рассказы про то, что код вида A+=1; вдруг имеет сложность O(N^6), "а мы не знали" — это ламерство вопиющее. Если ваше подсознание нашептывает, что A+=1 выполняется за константное время — сделайте вашему подсознанию апгрейд.

Еще он предлагал чтобы реализация object.Equals всегда возвращала true. Так, дескать, не будет разницы при перегрузке Equals, от какого класса мы наследуемся. Реальный бред — в дизни перегрузка Equals встречается очень редко, и она требует высокой квалификации. Иначе можно наделать чудных граблей. А вот рекомендация Рихтера махом привела бы к тому, что у всех экземпляров любого ссылочного типа был бы одинаковый хэш-код. И Equals приходилось бы перегружать на каждый чих. В общем, тяжелая наркомания налицо.

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

C>А как быть с вещами типа lazy-loading/lazy-creation?
Во-первых, а что тут не так с семантикой геттера?
А во-вторых — Следовать SRP.
Умение себя загружать или создавать — это не свойство объекта (объект другоми вещами заниматься должен), это свойство "загружателя" и "создавателя". Следовательно, вся эта ленивость содержится в соответствующих методах "загружателей" и "создавателей".

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

ZEN>Но это ваше "большинство явистов" либо не умеют программировать логику обработки контролируемых исключений, либо не знакомы с EJB (где повсеместно используются неконтролируемые исключения, откуда бы они черпали идеи для реализации), что в любом случае говорит об их низкой квалификации.
=> большинство явистов обладают низкой квалификацией..

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

S>Еще он предлагал чтобы реализация object.Equals всегда возвращала true. Так, дескать, не будет разницы при перегрузке Equals, от какого класса мы наследуемся. Реальный бред — в дизни перегрузка Equals встречается очень редко, и она требует высокой квалификации. Иначе можно наделать чудных граблей. А вот рекомендация Рихтера махом привела бы к тому, что у всех экземпляров любого ссылочного типа был бы одинаковый хэш-код. И Equals приходилось бы перегружать на каждый чих. В общем, тяжелая наркомания налицо.

Хм, а вообще нужно ли перегружать Equals и GetHashCode у классов с reference-type семантикой? ИМХО, они (а так же интерфейс IComparable) как раз и нужны для эмуляции сущностей с value-type семантикой. Или бывают ещё случаи?

Кстати, а как работает object.GetHashCode()? Я так понимаю, он жёстко привязывается к объекту. Т.е. должно быть какое-то спец. поле у каждого объекта. Но, видимо, это не так...

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

K>Т.е. должно быть какое-то спец. поле у каждого объекта. Но, видимо, это не так...
Есть такое поле, sync block index называется. Оно же заодно связано с объектом синхронизации, который потенциально может быть заведен для любого экземпляра.

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

K>Хм, а вообще нужно ли перегружать Equals и GetHashCode у классов с reference-type семантикой?
У них — нет.
Но в жизни классы с value-type семантикой встречаются достаточно часто. Я, кстати, до сих пор не знаю, как ими правильно пользоваться.
Во мне крепнет убеждение, что value-type семантика однозначно требует immutability, иначе начинаются чудные спецэффекты. Посудите сами: Equals придуман так, что если два объекта в какой-то момент времени эквивалентны, то так будет и навсегда в будущем. На этом, в частности, построены все коллекции, которые вообще используют Equals. Из этого непосредственно следует, что если Equals строится на состоянии объекта, то это состояние нельзя изменять. В свете этого, мне вообше непонятно, зачем в дотнете разрешили сочетать перегрузку Equals/GetHashCode для изменяемых объектов.
Хэш-код — это всего лишь приятное дополнение к методу Equals, более грубое разбиение на классы эквивалентности.
K>Кстати, а как работает object.GetHashCode()? Я так понимаю, он жёстко привязывается к объекту. Т.е. должно быть какое-то спец. поле у каждого объекта. Но, видимо, это не так...

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

_FR>>А теперь грабли: список исключений, выбрасываемых методом не является частью сигнатуры метода

AVK>В джаве является.

Вау, то есть в классе могут быть два метода с одинаковым списком входных параметров и различающимися только секцией throws?

ZEN>>Категорически согласен.
ZEN>>Кстати, в JavaBeans сделано прозрачнее, но доктрина "свойств" отвратительна (пришла в JavaBeans из ActiveX) и порождает массу ненужного кода -- часто огромный список финальных методов get|is/set с простым получением/присваиванием значений полей, которые никогда не будут перегружены. Такова плата за "инкапсюляцию".

___>Ну вот, мы с Рихтером теперь не одни

___>Резюме.
___>Вобщем аргументы оппонентов сводятся к следующему:
___>Ну да в свойствах могут быть косяки, но только если их неправильно применять. Но мы их всегда правильно применяем. И давайте же будем оптимистами, что и другие программисты их применяют правильно. Но если они их применяют неправильно, то это сразу видно и не стОит использовать их сборки. Но на всякий случай, от сборок третьих фирм всегда надо ждать сюрпризов при обращении со свойствами.
___>С последним предложением, в принципе, я согласен.


Браво!!!
А теперь замените выделеное слово на любое другое (например "функциях", или "классах") и опять же получите совершенно верное утверждение!


Резюмирую: свойства тоже полезны.

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

K>>Хм, а вообще нужно ли перегружать Equals и GetHashCode у классов с reference-type семантикой?
S>У них — нет.
S>Но в жизни классы с value-type семантикой встречаются достаточно часто. Я, кстати, до сих пор не знаю, как ими правильно пользоваться.

Как и обычными value в ФЯ. Просто делаем аналог алгебраического типа с одним конструктором. Я подобные классы оформляю согласно следующему паттерну:

public class MyClass
{
    public static readonly MyClass SpecialCase1 = new MyClass(...);
    public readonly ValueType Param1;
    private readonly ImmutableInterfaceImplementor param2;
    public readonly ReferenceType Param3;

  // Может быть и private, тогда предполагается создание объекта через
  // статический метод-конструктор
    public MyClass(ValueType param1, IReadOnlyInterface param2, ReferenceType param3)
    {
        this.Param1 = param1;
        // Обязательно делаем локальную иммутабельную копию!
        // ImmutableInterfaceImplementor тоже должен иметь value-type семантику.
        this.param2 = new ImmutableInterfaceImplementor(param2);
        this.Param3 = param3;
    }
    
    public static MyClass SpecialConstructor(...)
    {
        // ...
    }
    
    public IReadOnlyInterface Param2
    {
        get
        {
            return param2;
        }
    }
    
    public static bool operator ==(MyClass a, MyClass b)
    {
        if (object.ReferenceEquals(a, b))
            return true;
        return
            a.Param1 == b.Param1 &&
            a.param2 == b.param2 &&
            a.Param3 == b.Param3;
    }
    
    public static bool operator !=(MyClass a, MyClass b)
    {
        return !(a == b);
    }
    
    public override int GetHashCode()
    {
        // Возможна ленивая реализация для больших объектов. При этом заводятся мутабельны поля
        // hash = 0 и needHash = true.
        //
        return
            (a.Param1.GetHashCode() << 2) ^
            (a.param2.GetHashCode() << 1) ^
            a.Param3.GetHashCode();
    }
    
    public override bool Equals(object obj)
    {
        if (!(obj is MyClass))
            return false;
        return this == ((MyClass)obj);
    }
}

Немного задалбывает в таких случаях пороться со стандартными дотнетовскими коллекциями. Я даже всё время обещаю себе написать небольшую библиотеку для эмуляции функционального стиля, но всё руки не доходят.

Для эмуляции алгебраических типов с несколькими конструкторами юзаю более сложный паттерн, с вложенными sealed-классами, одновременно наследующими абтрактный родительский класс.

Надо сказать, что в последнее время мне нравится совмещать ФП и ООП стили. Потому объекты с value-type семантикой у меня в коде попадаются весьма часто. Например, в отличие от известных мне GUI-библиотек, в своей я сделал вещи вроде Brush, Pen, Font value-типами, причём Brush — аналог алебраического типа с несколькими конструкторами (Flat, LinearGradient, RadialGradient, Transparent, Inherit).

S>Во мне крепнет убеждение, что value-type семантика однозначно требует immutability, иначе начинаются чудные спецэффекты. Посудите сами: Equals придуман так, что если два объекта в какой-то момент времени эквивалентны, то так будет и навсегда в будущем. На этом, в частности, построены все коллекции, которые вообще используют Equals. Из этого непосредственно следует, что если Equals строится на состоянии объекта, то это состояние нельзя изменять. В свете этого, мне вообше непонятно, зачем в дотнете разрешили сочетать перегрузку Equals/GetHashCode для изменяемых объектов.

Вот именно. Но вот в чём беда: любой класс может быть использован как ключ в словаре. Это источник потенциальных ошибок. Правда, это не значит, что мне, допустим, не надо иметь множество объектов с reference-type семантикой, потому интерфейс тут не подошёл бы. Потому при документировании нужно явно указывать, какую семантику имеет объект. Хотя это порождает вопрос: а как быть с индусокодерами, которые над подобными вещами не задумываются.

S>Хэш-код — это всего лишь приятное дополнение к методу Equals, более грубое разбиение на классы эквивалентности.

Ага. Только Equals должен разбивать на классы по отношению равенства. ИМХО, всякие отношения (эквивалентности, порядка и т.п.), если они нужны в каких-то методах, должны явно передаваться этим методам, а не браться из классов. Т.е. Equals, GetHashCode и IComparable должны использоваться исключительно для того, чтобы эмулировать ФП, и не для чего-либо ещё.

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

Mab>Есть такое поле, sync block index называется. Оно же заодно связано с объектом синхронизации, который потенциально может быть заведен для любого экземпляра.

А значение поля уникально для каждого объекта? Меня это интересует в свете того, что в Nemerle Set['a] и Map['a] имеют ограничение IComparable['a], а мне хотелось бы его снять...

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

K>А значение поля уникально для каждого объекта?
Оно постоянно все время жизни объекта, но не уникально, так что возможны коллизии. Линейного порядка на них не построишь, увы.

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

AVK>>В джаве является.

_FR>Вау, то есть в классе могут быть два метода с одинаковым списком входных параметров и различающимися только секцией throws?

А кто сказал что перегрузка обязана быть возможной по любой части сигнатуры?

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

AVK>>>В джаве является.
_FR>>Вау, то есть в классе могут быть два метода с одинаковым списком входных параметров и различающимися только секцией throws?
AVK>А кто сказал что перегрузка обязана быть возможной по любой части сигнатуры?

Ага, ты понимаешь под сигнатурой контракт метода? Мне казалось, что сигнатура это вот.

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

_FR>Ага, ты понимаешь под сигнатурой контракт метода? Мне казалось, что сигнатура это вот.

То есть, по твоему, в C# можно перегружать по типу возвращаемого значения?

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

_FR>>Ага, ты понимаешь под сигнатурой контракт метода? Мне казалось, что сигнатура это вот.

AVK>То есть, по твоему, в C# можно перегружать по типу возвращаемого значения?

В топку это определение из википедии.

Ecma-334, 10.6 Signatures and overloading

The signature of a method specifically does not include the return type, parameter names, or
type parameter names, nor does it include the params modifier that can be specified for the right-most
parameter.

Тем не менее, различие в сигнатурах не всегда влечет возможность перегрузки. Например:

Ecma-334, 10.6 Signatures and overloading

Although out and ref parameter modifiers are considered part of a signature, members declared in a single
type cannot differ in signature solely by ref and out.