Rust vs C++ , очередная шляпа

Цитата Астарот @ 26.08.19, 13:23

Тут не знаю. Знаю, что джетбрейнсы для шарпея делают Rider https://www.jetbrains.com/rider/ а так как делают они, обычно, хорошо, то, скорее всего, все, что у твоего друга болит и чешется, там будет полечено и почёсано.

Это конечно хорошо, но это дело не IDE, это дело компилятора. А то получается, что убогость языка компенсируется IDE.

Цитата Wound @ 26.08.19, 14:31

Дело в том, что override несет несколько другую смысловую нагрузку, и к интерфейсам мягко говоря не применима. Потому как интерфейс не может иметь реализации. Соответственно и переопределять там нечего. Там реализовывать нужно. Поэтому override - это скорее про классы.

Если ты аннотируешь @override функцию в классе наследующем интерфейс и если прототипа этой функции в интерфейсе не будет, то будет ли ошибка?
Скажем вот тут компилятор D будет ругаться (function void Foo.foo() does not override any function):

interface Bar {
    void bar();
}
 
class Foo : Bar {
    override void bar() {}
    override void foo() {}
}

Если аналогично сделать в C# с @override будет также?

Цитата Wound @ 26.08.19, 14:31

Но ты можешь написать явную реализацию для интерфейса, например:

    interface MyInterface
    {
        string GetMyString();
        void SetMyString(string value);
    }
 
    public class MyClass : MyInterface
    {
        string MyInterface.GetMyString()
        {
            throw new NotImplementedException();
        }
 
        void MyInterface.SetMyString(string value)
        {
            throw new NotImplementedException();
        }
    }

При таком раскладе, если ты в интерфейсе грохнешь любой метод, будет ошибка компиляции, например можешь попробовать в этом коде закоментировать или переименовать любой метод у интерфейса
https://rextester.com/CEPE93720

А в этом случае можно будет потом написать вот так?

MyClass a = new MyClass();
a.GetMyString();

ЕМНИП, GetMyString не будет существовать для MyClass.

Цитата Wound @ 26.08.19, 17:24

Ну тогда, ИМХО, абстрактные классы уйдут в прошлое. Потому что не совсем понятно зачем они нужны.

Для того, для чего и всегда: экземпляры таких классов нежизнеспособны или не имеют смысла без того, чтобы быть допиленными производными классами. Ты ко всему ещё подзабыл, что в Плюсах есть множественное наследование реализаций, а также управление разделением/совмещением наследуемых атрибутов при этом. Посему на (не)вирутальном наследовании и (не)абстрактных классах можно собрать кучу всяких патернов, а не только реализацию интерфейсно-ориентированного и/или обычного суб/супер патернов.

Сообщение отредактировано: Qraizer - 26.08.19, 19:03

Цитата applegame @ 26.08.19, 18:51

Если ты аннотируешь @override функцию в классе наследующем интерфейс и если прототипа этой функции в интерфейсе не будет, то будет ли ошибка?
Скажем вот тут компилятор D будет ругаться (function void Foo.foo() does not override any function):

В C# сейчас по крайней мере ты не можешь так написать. Т.е. если у тебя класс реализует интерфейс, то ты не можешь написать override, Но можешь явно заимплементить интерфейс, я уже писал об этом:
Rust vs C++ (сообщение #3808100)

https://rextester.com/CEPE93720

Попробуй закоментить SetMyString в интерфейсе, сразу получишь ошибку компиляции.

Цитата applegame @ 26.08.19, 18:51

А в этом случае можно будет потом написать вот так?

Нет. Но и смысла не вижу потом писать вот так. Значит интерфейс там нафиг не нужен.
Можно юзнуть абстрактный базовый класс вместо интерфейса.

Добавлено 26.08.19, 19:13

Цитата Qraizer @ 26.08.19, 19:02

Для того, для чего и всегда: экземпляры таких классов нежизнеспособны или не имеют смысла без того, чтобы быть допиленными производными классами. Ты ко всему ещё подзабыл, что в Плюсах есть множественное наследование реализаций, а также управление разделением/совмещением наследуемых атрибутов при этом. Посему на (не)вирутальном наследовании и (не)абстрактных классах можно собрать кучу всяких патернов, а не только реализацию интерфейсно-ориентированного и/или обычного суб/супер патернов.

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

Сообщение отредактировано: Wound - 26.08.19, 19:13

Цитата applegame @ 26.08.19, 18:51

А то получается, что убогость языка компенсируется IDE.

Если тебе шашечки, то да, а если ехать, то тебе не пофиг, кто повезет?

Цитата applegame @ 26.08.19, 10:43

Последнее на что жаловался: https://stackoverflow.com/questions/5510343...ents-in-c-sharp

What?

Цитата applegame @ 26.08.19, 10:43

- невозможно stderr перенаправить в stdout.

Это вне программы делается.

Добавлено 27.08.19, 05:12

Цитата applegame @ 26.08.19, 18:51

Если ты аннотируешь @override функцию в классе наследующем интерфейс и если прототипа этой функции в интерфейсе не будет, то будет ли ошибка?
Скажем вот тут компилятор D будет ругаться (function void Foo.foo() does not override any function):

Почему это должно быть ошибкой? У класса есть свой неявный публичный интерфейс, в котором есть методы bar и foo, не зависимо от того, определены ли они в каком-то другом интерфейсе, или нет. Если ты убираешь метод из интерфейса, то компилятор будет ругаться на все существующие попытки в коде использовать этот метод через переменную интерфейсного типа:

Bar v = ...;
v.foo();

но следующий вызов совершенно законен:

Foo v = ...;
v.foo();

Так какого чёрта компилятор должен ругаться на метод foo в Foo? Из-за того, что у него аннотация override? А зачем вы её добавили? Чтобы что? Там и так указано, что Foo <: Bar — это не достаточно информативно? Нужно ещё на все методы override пихать? Чтобы потом убирать? Выглядит как создание пробемы самим себе и героическое её преодоление. В плюсах, делфи, вроде как, override имеет определённое назначение, т.к. методы могут быть не виртуальными и есть разница между

Bar v = new Foo();
v.bar();

и

Foo v = new Foo();
v.bar();

В D, видимо, тоже?

Хз как там в C#, но в Java она не имеет никакого смысла. Вот в Kotlin есть ключевое слово override вместо аннотации @Override, и нафига? Чтобы туда-сюда его гонять (добавлять/удалять) при рефакторинге? И саму аннотацию @Override в Java зря добавили, тупое захламление кода.

Сообщение отредактировано: korvin - 27.08.19, 05:15

Цитата Wound @ 26.08.19, 12:40

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

override разве нет в шарпе?

Добавлено 27.08.19, 06:01
А, ну про это дальше было сказано.

Цитата korvin @ 27.08.19, 04:49

Хз как там в C#,

В C# есть ключевое слово override, но только для классов.

Добавлено 27.08.19, 06:07

Цитата OpenGL @ 27.08.19, 05:59

override разве нет в шарпе?

Есть, для классов.

Цитата Wound @ 27.08.19, 06:06

В C# есть ключевое слово override, но только для классов.

Как это относится к тому, что я написал?

Цитата korvin @ 27.08.19, 06:10

Как это относится к тому, что я написал?

Ну ты написал Хз как там в шарпе, вот я и уточнил как там в шарпе

Сообщение отредактировано: Wound - 27.08.19, 06:14

Цитата korvin @ 27.08.19, 04:49

Там и так указано, что Foo <: Bar — это не достаточно информативно?

Ты точно читал тред? Очевидно, это недостаточно информативно.

Цитата OpenGL @ 27.08.19, 06:18

Ты точно читал тред? Очевидно, это недостаточно информативно.

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

Да это понятно. Я про наезды korvin-а на override - очевидно, override или явная имплементация интерфейса сильно упрощают жизнь при отсутствии в языке чего-то наподобие растовского impl Trait for MyClass, где по определению могут быть те и только те методы, которые есть в интерфейсе.

Цитата korvin @ 27.08.19, 04:49

Почему это должно быть ошибкой?

Потому что в большинстве случаев оно ей является на практике.

Цитата

Из-за того, что у него аннотация override? А зачем вы её добавили? Чтобы что?
...
Хз как там в C#, но в Java она не имеет никакого смысла. Вот в Kotlin есть ключевое слово override вместо аннотации @Override, и нафига? Чтобы туда-сюда его гонять (добавлять/удалять) при рефакторинге?

Чтобы защититься от ошибок при этом самом рефакторинге, например.
Конкретно в Kotlin ведь и виртуальные методы нужно явно указывать через open.
Так же ещё полезно при чтении кода класса - сразу видно, "родная" эта функция у класса или переопределенная.

Цитата OpenGL @ 27.08.19, 06:29

при отсутствии в языке чего-то наподобие растовского impl Trait for MyClass, где по определению могут быть те и только те методы, которые есть в интерфейсе.

Я тут поигрался на досуге, так вот могу сказать, что при таком подходе лично мне тяжело избавиться от ощущения "размазанности" сущности. Если в "нормальном" языке я читаю класс и вижу весьма цельную сущность, то тут я вижу структурку (в том же C++ я обращаю внимание на поля только при необходимости) и набор разрозненных impl'ов.

Цитата korvin @ 27.08.19, 04:49

но в Java она не имеет никакого смысла.

Подожди. Вот есть у тебя в классе A метод foo. С какой-то реализацией. Наследники переопределили. Override не написали. Потом ты рефакторишь A и меняешь сигнатуру метода. Во всех наследниках код будет валиден и компилятору не к чему придраться, хотя это ошибка. Где-то ты поправил сам(потому что помнил), где-то свалились тесты. А где-то это уехало на прод
Не?

Сообщение отредактировано: D_KEY - 27.08.19, 07:03