История изменений
Исправление hobbit, (текущая версия) :
Потому, что мне крайне не нравится принятый в Java/C# подход, когда интерфейсная часть класса в исходниках файла отсутствует. Это удобно для быстрого говнокодинга, но крайне неудобно для сопровождения. Да, там МОЖНО отдельно сделать интерфейс и породить от него класс, на деле же этим занимаются только когда в проекте это принято сверху, волевым решением.
Я вот ковырялся в исходниках сишарпного NBU Explorer, чтобы понять, как там этот NBU разбирается — занятие в программе с кучей классов и методов было на любителя. К автору программы претензий, разумеется, нет, он не обязан поощрять написание программ-аналогов (хотя если кто-то захочет написать и прислать автору патч для развития самого NBU Explorer, ему тоже будет несладко). Претензии к языку, который такой стиль исходников поощряет в качестве основного.
Как в жаве: .jar-архив содержит скомпилятые .class-файлы, из которых javac эффективно выковыривает интерфейс.
Вот только я хочу возможность читать интерфейс, имея только исходники. Иначе это уже метапрог какой-то.
Основная же проблема, которую должны решать модули (на мой взгляд) — это замена кошмарных препроцессорных костылей на синтаксические единицы языка, которые контролируются компилятором. Это позволит 1) радикально ускорить сборку; 2) исключить глупые, труднообнаруживаемые и зависящие от применяемых библиотек ошибки, связанные с разруливанием зависимостей; 3) для проектов низкой и средней сложности вообще отказаться от сборочной системы как отдельной по отношению к ЯП сущности (в Delphi/fpc это работает, например, там все зависимости разматываются непосредственно компилятором из главного модуля).
Решит ли эти проблемы реализация в C++20 — пока не знаю. Это для плюсов вообще новая концепция и можно ожидать, что она будет эволюционировать. Поэтому,
не могут сразу нормально и ДО КОНЦА проработать.
ИМХО, это предсказуемо.
Исправление hobbit, :
Потому, что мне крайне не нравится принятый в Java/C# подход, когда интерфейсная часть класса в исходниках файла отсутствует. Это удобно для быстрого говнокодинга, но крайне неудобно для сопровождения. Да, там МОЖНО отдельно сделать интерфейс и породить от него класс, на деле же этим занимаются только когда в проекте это принято сверху, волевым решением.
Я вот ковырялся в исходниках сишарпного NBU Explorer, чтобы понять, как там этот NBU разбирается — занятие в программе с кучей класс и методов было на любителя. К автору программы претензий, разумеется, нет, он не обязан поощрять написание программ-аналогов (хотя если кто-то захочет написать и прислать автору патч для развития самого NBU Explorer, ему тоже будет несладко). Претензии к языку, который такой стиль исходников поощряет в качестве основного.
Как в жаве: .jar-архив содержит скомпилятые .class-файлы, из которых javac эффективно выковыривает интерфейс.
Вот только я хочу возможность читать интерфейс, имея только исходники. Иначе это уже метапрог какой-то.
Основная же проблема, которую должны решать модули (на мой взгляд) — это замена кошмарных препроцессорных костылей на синтаксические единицы языка, которые контролируются компилятором. Это позволит 1) радикально ускорить сборку; 2) исключить глупые, труднообнаруживаемые и зависящие от применяемых библиотек ошибки, связанные с разруливанием зависимостей; 3) для проектов низкой и средней сложности вообще отказаться от сборочной системы как отдельной по отношению к ЯП сущности (в Delphi/fpc это работает, например, там все зависимости разматываются непосредственно компилятором из главного модуля).
Решит ли эти проблемы реализация в C++20 — пока не знаю. Это для плюсов вообще новая концепция и можно ожидать, что она будет эволюционировать. Поэтому,
не могут сразу нормально и ДО КОНЦА проработать.
ИМХО, это предсказуемо.
Исправление hobbit, :
Потому, что мне крайне не нравится принятый в Java/C# подход, когда интерфейсная часть класса в исходниках файла отсутствует. Это удобно для быстрого говнокодинга, но крайне неудобно для сопровождения. Да, там МОЖНО отдельно сделать интерфейс и породить от него класс, на деле же этим занимаются только когда в проекте это принято сверху, волевым решением.
Я вот ковырялся в исходниках сишарпного NBU Explorer, чтобы понять, как там этот NBU разбирается — занятие в программе с кучей класс и методов было на любителя. К автору программы претензий, разумеется, нет, он не обязан поощрять написание программ-аналогов (хотя если кто-то захочет написать и прислать автору патч для развития самого NBU Explorer, ему тоже будет несладко). Претензии к языку, который такой стиль исходников поощряет в качестве основного.
Как в жаве: .jar-архив содержит скомпилятые .class-файлы, из которых javac эффективно выковыривает интерфейс.
Вот только я хочу возможность читать интерфейс, имея только исходники. Иначе это уже метапрог какой-то.
Основная же проблема, которую должны решать модули (на мой взгляд) — это замена кошмарных препроцессорных костылей на синтаксические единицы языка, которые контролируются компилятором. Это 1) позволит радикально ускорить сборку; 2) исключить глупые, труднообнаруживаемые и зависящие от применяемых библиотек ошибки, связанные с разруливанием зависимостей; 3) для проектов низкой и средней сложности вообще отказаться от сборочной системы как отдельной по отношению к ЯП сущности (в Delphi/fpc это работает, например, там все зависимости разматываются непосредственно компилятором из главного модуля).
Решит ли эти проблемы реализация в C++20 — пока не знаю. Это для плюсов вообще новая концепция и можно ожидать, что она будет эволюционировать. Поэтому,
не могут сразу нормально и ДО КОНЦА проработать.
ИМХО, это предсказуемо.
Исходная версия hobbit, :
Потому, что мне крайне не нравится принятый в Java/C# подход, когда интерфейсная часть класса в исходниках файла отсутствует. Это удобно для быстрого говнокодинга, но крайне неудобно для сопровождения. Да, там МОЖНО отдельно сделать интерфейс и породить от него класс, на деле же этим занимаются только когда в проекте это принято сверху, волевым решением.
Я вот ковырялся в исходниках сишарпного NBU Explorer, чтобы понять, как там этот NBU разбирается — занятие в программе с кучей класс и методов было на любителя. К автору программы претензий, разумеется, нет, он не обязан поощрять написание программ-аналогов (хотя если кто-то захочет написать и прислать автору патч для развития самого NBU Explorer, ему тоже будет несладко). Претензии к языку, который такой стиль исходников поощряет в качестве основного.
Как в жаве: .jar-архив содержит скомпилятые .class-файлы, из которых javac эффективно выковыривает интерфейс.
Вот только я хочу возможность читать интерфейс, имея только исходники. Иначе это уже метапрог какой-то.
Основная же проблема, которую должны решать модули (на мой взгляд) — это замена кошмарных препроцессорных костылей на синтаксические единицы языка, которые контролируются компилятором. Это 1) позволит радикально ускорить сборку; 2) исключить глупые, труднообнаруживаемые и зависящие от применяемых библиотек ошибки, связанные с разруливанием зависимостей; 3) для проектов низкой и средней сложности вообще отказаться от сборочной системы как отдельной по отношению к ЯП сущности (в Delphi/fpc это работает, например, там все зависимости разматываются непосредственно компилятором из главного модуля).
Решит ли эти проблемы реализация в C++20 — пока не знаю. Это для плюсов вообще новая концепция и можно ожидать, что она будет эволюционировать.