Программирование, т. 8

а схуяли ты пишешь в своем классе equals как  пизда == ((А)объ).пизда; ?

у тебя во-первых, каст может упасть, потому что засунуть тебе туда могут что угодно вообще

а во-вторых, ты должен сначала проверить тип

вот даже вам что решарпер генерит сам по умолчанию, в идее для джавы должно генериться всё то же самое

public class A
  {
    public int i;

    protected bool Equals(A other)
    {
      return i == other.i;
    }

    public override bool Equals(object obj)
    {
      if (ReferenceEquals(null, obj)) return false;
      if (ReferenceEquals(this, obj)) return true;
      if (obj.GetType() != this.GetType()) return false;
      return Equals((A) obj);
    }

    public override int GetHashCode()
    {
      return i;
    }
  }

  public class B : A
  {
    public string s;

    protected bool Equals(B other)
    {
      return base.Equals(other) && string.Equals(s, other.s);
    }

    public override bool Equals(object obj)
    {
      if (ReferenceEquals(null, obj)) return false;
      if (ReferenceEquals(this, obj)) return true;
      if (obj.GetType() != this.GetType()) return false;
      return Equals((B) obj);
    }

    public override int GetHashCode()
    {
      unchecked
      {
        return (base.GetHashCode() * 397) ^ (s != null ? s.GetHashCode() : 0);
      }
    }
  }

всё, что ты не сунь в Equals любого из классов, он сразу пойдет нахуй встретив if (obj.GetType() != this.GetType()) return false;

конец истории

если ты вообще не хочешь никакого разрешения изменения логики твоего класса, то сори, кроме sealed / final это ничем не лечится

особенно у джавы, где всё по умолчанию виртуальное

каким образом вот эту вот поеботину хотя бы в теории можно заставить вернуть false?

если у A есть getPizda(); то васян может в B переопределить getPizda() в нем вызвать стактрейс и проверить, не долбят ли его полиморфизмом из A::equals и если так, то через геттер вернуть null 

Ну это прям совсем костыль если надо починить instanceof 

ну скоро var завезут, через годика 2 в энтерпрайз мб или на котлин все перекатятся.

Вроде как год назад завезли...Хотя все равно все на 8й сидят(в лучшем случае) 

пиздец, заебали с джавой.

понял

я же спрашивал вшиваются ли эти хардкорные проверки в родителский класс

я просто недосмотрел что в первом примере индекса тоже проверка на тип была, чето думал что только во втором

этом ебаный object тип ещё более надоедливый чем void *, хорошо что в шарпе по больше части ты его вообще не встречаешь и кол-во дебильных кастов поэтому это 5% от джавовских

у меня есть класс А {публичный хуй пизда;} , его можно сравнивать
я пишу равно(объ) => пизда == ((А)объ).пизда;

по своему опыту, сравнение классов ставят когда "полнейший пиздец крайней степени" в проекте, как и любые переносы/переходы "на уровень выше" в ООП

если проект в начальной стадии лучше добавить лишнее поле obj_id в каждом классе(можно просто наследуя класс control_id с методами), и это поле сравнивать

в джаве же должен быть аналог шарповского typeof и anyobject.GetType()

.class ?

@@AskMe-

нарушение лсп делает код менее элегантным

нарушение симметрии равентсва ломает ЛОГИКУ

 

что хуже хммм даже не знаю

что у меня состояние хешпамы может зависеть от порядка в котором я буду вставлять элементы т.к. равенстно не симметрично. нормально

 

имхо не стоит доверять авторитетным динозаврам ибо они высирают хуйню по кд

equals через getClass точно так же нарушает логику. пример из всё той же эффектив джавы:

есть класс точки, есть хешсет, содержащий точки на плоскости. Наследуемся от точки и создаем цветную точку с координатами (1,1), закидываем её в сет. Проверяем наличие точки(1,1) в сете - получаем ответ что её там нет, потому что нас выкинуло уже на сравнении типов, хотя очевидно что цветная точка это всё еще точка и она есть на плоскости, цвет нас не интересует, мы даже и не в курсе что кто то наследовался там где то. 

Проблемы в любом случае возникают при наследовании вэлью объектов и добавления к ним значимого вэлью (а при использовании геткласса даже без добавления, нас все равно выкинет при сравнении типов) и куча бизнесовой логики проверяет именно равенство некоторого бизнес вэлью (в данном случае координат), мы не должны отбрасывать наследников из-за того что они "другого" типа, потому что они бля всё еще являются точкой. полиморфизм, ооп, anyone?

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

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

Астанавитесь.

есть класс точки, есть хешсет, содержащий точки на плоскости. Наследуемся от точки и создаем цветную точку с координатами (1,1), закидываем её в сет. Проверяем наличие точки(1,1) в сете - получаем ответ что её там нет, потому что нас выкинуло уже на сравнении типов, хотя очевидно что цветная точка это всё еще точка и она есть на плоскости, цвет нас не интересует, мы даже и не в курсе что кто то наследовался там где то.

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

тебе даже не надо оверрайдить имплементацию из обычной т.к. тебе наоборот нужно чтоб все дети точки сравнивались на true с родителем если координаты совпадают

но это не есть general-case применение равенства. обычно a.equals(b) == true значит что две инстанции ну прям совсем идентичные дальше некуда

есть класс точки, есть хешсет, содержащий точки на плоскости. Наследуемся от точки и создаем цветную точку с координатами (1,1), закидываем её в сет. Проверяем наличие точки(1,1) в сете - получаем ответ что её там нет

Да я уже понял изящное решение.

Ты просто для таких задач заводишь TreeSet например с компаратором координат. И пихай уже туда хоть слона extends Point

А у equals контракта соблюдаешь симметричность.

пиздец о какой же ненужной хуйне вы тут думаете, ребята

Как понял из написанного джависты пытаются когда удобно возвращать тру для двух на самом деле разных типов и жалуются что неудобно

Как понял из написанного джависты пытаются когда удобно возвращать тру для двух на самом деле разных типов и жалуются что неудобно

это только аскми притащил за уши кейс где ему надо равенство разных типов которое по нормальному делается как написал индекс кастомным компаратором

 

@@AskMe-

нарушение лсп делает код менее элегантным

нарушение симметрии равентсва ломает ЛОГИКУ

 

что хуже хммм даже не знаю

что у меня состояние хешпамы может зависеть от порядка в котором я буду вставлять элементы т.к. равенстно не симметрично. нормально

 

имхо не стоит доверять авторитетным динозаврам ибо они высирают хуйню по кд

equals через getClass точно так же нарушает логику. пример из всё той же эффектив джавы:

 

есть класс точки, есть хешсет, содержащий точки на плоскости. Наследуемся от точки и создаем цветную точку с координатами (1,1), закидываем её в сет. Проверяем наличие точки(1,1) в сете - получаем ответ что её там нет, потому что нас выкинуло уже на сравнении типов, хотя очевидно что цветная точка это всё еще точка и она есть на плоскости, цвет нас не интересует, мы даже и не в курсе что кто то наследовался там где то. 

Проблемы в любом случае возникают при наследовании вэлью объектов и добавления к ним значимого вэлью (а при использовании геткласса даже без добавления, нас все равно выкинет при сравнении типов) и куча бизнесовой логики проверяет именно равенство некоторого бизнес вэлью (в данном случае координат), мы не должны отбрасывать наследников из-за того что они "другого" типа, потому что они бля всё еще являются точкой. полиморфизм, ооп, anyone?

 

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

 

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

 

надеюсь ты лутаешь 5к в месяц иначе нахуй ты всё это знаешь

ДА УЖ ЭТО ПРЯМО МЕГАМОЗГ КАКОЙ-ТО

можно ли web-storm купить раз и навсегда ? Чтоб не ебаться с подпиской

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

Ну электроэнергия заканчивается а за вебшторм деньги лишний раз берут просто потому что могут

А можно спиратить

кого там программировать нефть интересовало?

смотрите какую красоту подвезли