BP
Интерфейс ни от чего не наследуется, класс наследуется от эни только если если другого не указано, таким образом всё логично, равно или поздно эни будет в предках
объяви в интервейсе иквелс, тоСтринг
Size: a a a
2020 January 23
BP
*это ток в котлине так (мы про него и говорим)
BV
объяви в интервейсе иквелс, тоСтринг
Почти наверняка этого нет в рантайме
BV
А, я понял в чем смысл
BP
Почти наверняка этого нет в рантайме
врантайме может и нет никаких интерфейсов вовсе (тут не помню)
BV
Чтобы, даже если у тебя ссылка интерфейс, то объект всё равно содержит методы из эни
AM
объяви в интервейсе иквелс, тоСтринг
Интринсики и до свидания
BP
Интринсики и до свидания
? там нужно оверайд проставить, при объявлении в интерфейсе
BV
Это всё равно хак, просто знание, что объект наследуется от эни
BV
Если бы так не сделали, то переданные по интерфейсу объекты нельзя было бы продолжить в мапу и тд
BV
Тяжёлое наследие джавы я так думаю
BP
Если бы так не сделали, то переданные по интерфейсу объекты нельзя было бы продолжить в мапу и тд
не говорять что "почему Any не интерфейс" - лично у меня аргументов 0, мне всегда это казалось логичней
BP
и забить на эстетику (и так давно положили на нее)
AM
Тяжёлое наследие джавы я так думаю
Я всё ещё не понял проблему. Гипотетически Any становится интерфейсом, всё интерфейсы его наследуют, а классы реализуют. Его три метода имеют дефолтные реализации-интринсики. Что не так?
AM
Я уверен, что такой вариант при дизайне системы типов ее могли не рассматривать, но почему сделали не так и оставили "волшебный" класс, с которым возможно "множественное" наследование (всё ещё чисто с точки зрения системы типов), пока не понял.
BP
Я всё ещё не понял проблему. Гипотетически Any становится интерфейсом, всё интерфейсы его наследуют, а классы реализуют. Его три метода имеют дефолтные реализации-интринсики. Что не так?
проблема только в подкоучивании компилятора (хаки) и "а если мы так сделаем то многие могуть сказать - фууу не как у джавы (ООП)". Думаю на этом можно закончить тред и перейти в слак
AM
проблема только в подкоучивании компилятора (хаки) и "а если мы так сделаем то многие могуть сказать - фууу не как у джавы (ООП)". Думаю на этом можно закончить тред и перейти в слак
Там и так уже Any вместо былого жирного Object-а с монитором, то есть уже не как в у джавы, при этом тот же
Но согласен, гадать смысла нет. Если вы там задали вопрос в слаке -- киньте ссылку сюда, пожалуйста, завтра почитаем-с.
synchronized на объекте сделан на стрёмном тайпкасте (который небезопасный, но на JVM всегда успешен). И интерфейс в качестве верхнего типа вроде ООП не противоречит при этом :)Но согласен, гадать смысла нет. Если вы там задали вопрос в слаке -- киньте ссылку сюда, пожалуйста, завтра почитаем-с.
BP
Там и так уже Any вместо былого жирного Object-а с монитором, то есть уже не как в у джавы, при этом тот же
Но согласен, гадать смысла нет. Если вы там задали вопрос в слаке -- киньте ссылку сюда, пожалуйста, завтра почитаем-с.
synchronized на объекте сделан на стрёмном тайпкасте (который небезопасный, но на JVM всегда успешен). И интерфейс в качестве верхнего типа вроде ООП не противоречит при этом :)Но согласен, гадать смысла нет. Если вы там задали вопрос в слаке -- киньте ссылку сюда, пожалуйста, завтра почитаем-с.
"Там и так уже Any вместо былого жирного Object-а" - нк наследуешься ты
"интерфейс в качестве верхнего типа вроде ООП не противоречит при этом :)" - очень спорно
interface Foo : Any, не знаю какой точно там бйт код генерить нужно,но есть вероятностьчто компилятору нужно обяснить что не нужно делать interface Foo extend Object (это просто догадка, это может быть не одно место и решили тупо не рисковать)"интерфейс в качестве верхнего типа вроде ООП не противоречит при этом :)" - очень спорно
АО
"Там и так уже Any вместо былого жирного Object-а" - нк наследуешься ты
"интерфейс в качестве верхнего типа вроде ООП не противоречит при этом :)" - очень спорно
interface Foo : Any, не знаю какой точно там бйт код генерить нужно,но есть вероятностьчто компилятору нужно обяснить что не нужно делать interface Foo extend Object (это просто догадка, это может быть не одно место и решили тупо не рисковать)"интерфейс в качестве верхнего типа вроде ООП не противоречит при этом :)" - очень спорно
У вас так не получится - интерфейсы не могу расширять классы:)
АО
toString (и иже с ним) не переопределишь, при это правило "один класс - одно расширение другого класса" не работает