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

погуглил тему про instanceof

1) в спеке джавы сказано что equals должен обладать среди прочих свойств симметричностью

https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#equals(java.lang.Object)

2) один долбоеб (автор effective java) оказывается считает что лучше юзать instanceof

офк нам должно быть похуй че там считает чел из каменного века

погуглил тему про instanceof

 

1) в спеке джавы сказано что equals должен обладать среди прочих свойств симметричностью

https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#equals(java.lang.Object)

 

2) один долбоеб (автор effective java) оказывается считает что лучше юзать instanceof

офк нам должно быть похуй че там считает чел из каменного века

этот "один долбоеб из каменного века" (писавший JDK, к слову) так же объясняет что equals через getClass нарушает LSP.

но ддамагеру виднее

несовпадение типов == объекты по умолчанию не равны, в чьей логике там вообще true может получиться?

несовпадение типов == объекты по умолчанию не равны, в чьей логике там вообще true может получиться?

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

потому что если реализация класса А проверяет равенство как для своей имплементации, то ты не можешь сделать такую реализацию Б чтоб подсунув её правым операндом равенства имплементация А вернула false при выполнении условий равенства родительского класса

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

@@AskMe-

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

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

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

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

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

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

ну и на худой конец я так понимаю a instanceof b && b instanceof a должны гарантировать что a и b одного типа?

Если это то же, что в шарпе is, судя по названию похоже

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

 

ну и на худой конец я так понимаю a instanceof b && b instanceof a должны гарантировать что a и b одного типа?

Если это то же, что в шарпе is, судя по названию похоже

в джаве есть getClass

обычно его и юзают в кастомных equals методах

 

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

 

ну и на худой конец я так понимаю a instanceof b && b instanceof a должны гарантировать что a и b одного типа?

Если это то же, что в шарпе is, судя по названию похоже

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

 

А нахуя тебе вообще реализация родительского класса?

На твоем объекте вызывают перегруженный equals, который ОБЯЗАН удостовериться что то, что ему передали в параметре это тот же самый тип, и только потом начинать делать всё остальное.

Как ты будешь шарить логику сравнения в иерархии это уже твои проблемы, в шарпе просто после этой проверки на тип и вообще равенство ссылки вызывается другой protected bool Equals принимающий уже конкретный тип твоего класса, который и занимается непосредственно сравнением.

Хочет дочка, вызовет, не хочет, ну и пусть конем ебется.

Твоему классу надо обеспечивать исключительно равенство его любимого, дети и предки никого не волнуют.

Пиздец, только что вылез из пещеры ебаного незнания и открыл для себя css grid. Какая же это ахуенная вещь. Бутстрап иди нахуй кста, давно пора уебище

Твоему классу надо обеспечивать исключительно равенство его любимого, дети и предки никого не волнуют.

Ну смотри

boolean isToday4may(Date date) {

return MAY_THE_4TH.equals(date);

}

Timestamp time = (4 мая 17 00)

isToday4may(time)//false 

нарушен принцип Лисков, если проверять как equals конечно а не запилить экстенд сейф проверку

потому что 9 мая != 4 мая

гагаггагагаг

ШО

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

потому что 9 мая != 4 мая

 

гагаггагагаг

ШО

У меня просто ветераны в голове

 

Твоему классу надо обеспечивать исключительно равенство его любимого, дети и предки никого не волнуют.

 

Ну смотри

 

boolean isToday4may(Date date) {

return MAY_THE_4TH.equals(date);

}

 

Timestamp time = (9 мая 17 00)

 

isToday4may(time)//false 

нарушен принцип Лисков, если проверять как equals конечно а не запилить экстенд сейф проверку

 

не один тип == не равны

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

что сложного в этой логике? какие нахуй нарушения лисков?

equals вообще не является поведением, это определение равенства типа себе самому

virtual на объекте стоит исключительно потому, чтобы дать его вообще всем объектам, а не чтобы шарить логику. Если бы была возможность запретить в некоторых вызовах virtual делать super.* или как там в джаве, я уверен, что так бы и сделали сразу, но всем насрать уже

сами смотрите на код, сами видите хуйню, но при этом пытаетесь доказать сами себе, что эта хуйня - это нормально?

я вас не понимать

Читал тут кстати какие-то вопросы к собесу по жаве

Немного кекнул с неправильно решения, которое упадет подай '*' например как символ.

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

но что ж сказать тогда, джава еще большая хуйня, чем я думал

Я бы так написал

я не знаю, может в джаве не завезли во все методы стандартной библиотеки, делающие сравнения, перегрузки с такой штукой как IEqualityComparer<T> / IComparer<T>, который позволяет тебе в нужном месте сравнивать вообще как хочешь, и поэтому вы страдаете такой хуйней

 

но что ж сказать тогда, джава еще большая хуйня, чем я думал

Хранишь в SortedSet элементы, сравниваешь по своему компаратору. Можно так например.

Есть забавный пример кстати.

BigDecimal a = new BigDecimal("1.00");

BigDecimal b = new BigDecimal("1.0");

Set<BigDecimal> setOne = new TreeSet<>();

setOne.add(a);

setOne.add(b);

Set<BigDecimal> setTwo= new HashSet<>();

setTwo.add(a);

setTwo.add(b);

print setTwo.size()==setOne.size() //>false 

:mameprivet: :mameprivet:

ну нахуй, лучше на жсе писать, чем с такой типизацией

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

А нахуя тебе вообще реализация родительского класса?

На твоем объекте вызывают перегруженный equals, который ОБЯЗАН удостовериться что то, что ему передали в параметре это тот же самый тип, и только потом начинать делать всё остальное.

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

я пишу равно(объ) => пизда == ((А)объ).пизда;

потому что так сравнимается мой класс

потом васян подключает его себе либой, решает что классу А катастрофически не хватает ещё одного поля и делаешь класс Б : А {публичное говно моча} и хуярит там свой equals

у меня есть

A a = new A();

B b = new B();

вопрос

a.equals(b)

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

edit: офк с учётом что поле пизда у обоих классов одинаково