Минусы ООП

@Regrin1 · Регистрация: 10.08.2021

Студворк — интернет-сервис помощи студентам

Я слышал много критики в адрес ООП. Говорят, что оно приносит больше сложности чем упрощает и такой код труднее читать.
Насколько обоснованны эти заявления? Приводятся цитаты Дейксры, Торвальдса и Рэймонда в которых они говорят об ООП не самые лестные вещи. Я понимаю, что апелляция к авторитету - не аргумент, но сомнение во мне уже заложилось...

@OpXiv · 24.08.2021, 11:44

Delphi кстати сейчас воплощает идеологию GO структур
https://docwiki.embarcadero.co... ed_Records

Есть Initialize и есть Finalize тот же конструктор и деструктор, а так же ещё куча других методов

Delphi
1
2
3
4
5
procedure ParByValue (rec: TMyRecord);
procedure ParByConstValue (const rec: TMyRecord);
procedure ParByRef (var rec: TMyRecord);
procedure ParByConstRef (const [ref] rec: TMyRecord);
function ParReturned: TMyRecord;

Полное отсутствие ООП. И полная отвага

@Curry · 24.08.2021, 15:25

Сообщение от Regrin1

Я уже жалею, что начал эту тему.

Не жалейте. Вы задали вопрос, и, в общем то, получили ответ. А дальше начинается флейм в холиварах. Он гораздо менее опасен чем ковид. Ничего страшного.

Сообщение от korvin_

Тем что они описывают абстрактный тип, а не объект, и "связываются статически"

Т.е. эти модули как template class в С++? Там тоже можно подставить любой тип, лишь бы вызываемые в шаблонном классе методы в нём были.

Сообщение от korvin_

И ещё 100500 сигнатур из разных модулей разных разрабочиков, ничего не знающих друг о друге.

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

Сообщение от korvin_

Ага, но это два разных интерфейса. Delphi я уже смутно помню.

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

Delphi
1
2
3
4
5
6
7
8
9
10
11
12
13
function TMainForm.ExecDialog(AFormClass: TFormClass):TModalResult;
begin
  with AFormClass.Create(Application) do // создаётся объект типа наследуемого от TForm
    try
     ExecDialog:=showModal;
    finally
     free;
    end;
end;
// ....
     TMyForm = class(TForm)
// ....
  MainForm.ExecDialog(TMyForm); // Указываем тип производный от  TForm, не от   TFormClass.

@ft4l · 24.08.2021, 16:00

Сообщение от Regrin1

приносит больше сложности

Множественное наследование ещё вроде упрощать может иногда.
Или без этого приходится лепить классы над классами цепочками за цепочками )) кучи лишних сущностей.

В список языков, поддерживающих множественное наследование, входят: Io, Eiffel, C++, Dylan, Python, некоторые реализации классов JavaScript (например, dojo.declare), Perl 6, Curl, Common Lisp (благодаря CLOS), OCaml, Tcl (благодаря Incremental Tcl)[1], а также Object REXX (за счёт использования классов-примесей).

Трейты вот в php завезли , наверно после этой статьи в вики ,)) не хватало наверно.
...Но что-то глянул на то-же Trait в Rust что-то оно там как-будто совсем другой смысл имеет...

@korvin_ · 24.08.2021, 17:14

Сообщение от Curry

Т.е. эти модули как template class в С++? Там тоже можно подставить любой тип, лишь бы вызываемые в шаблонном классе методы в нём были.

Наверное. Мало имел дела с шаблонами в плюсах. В них, вроде, даже не нужно сигнатуру описывать, или даже невозможно, пока концепты не завезут.

Сообщение от Curry

Если бы они ничего не знали друг о друге, то разработчики модулей типа List_stack не знали бы какие функции требуются в модуле Main и наоборот.

Разработчики модуля List_stack и не знают. Также как и разработчики какого-нибудь jackson или gson ничего не знают о тысячах проектов на, в которых используются их библиотеки. Также как оператор равенства ( = ) : t -> t -> bool для какого-то типа t ничего не знает о том, где будет использоваться, кроме своей сигнатуры и семантики.

Сообщение от Curry

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

Это позволено.

Кликните здесь для просмотра всего текста

F#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
 
module Pair :
  sig
    type t
    val of_int : int -> t
    val ( = ) : t -> t -> bool
  end
  =
  struct
 
    type t = { x : int ; y : int }
 
    let of_int i = { x = i ; y = i }
 
    let ( = ) a b =
      a.x = b.x && a.y = b.y
 
  end
 
module Ext = struct
 
  module Pair =
    struct
      include Pair
 
      let ( <> ) a b =
        not (a = b)
 
    end
 
end
 
 
 
let main_std () =
  let a = Pair.of_int 1
  and b = Pair.of_int 1
  and c = Pair.of_int 2 in
  Printf.printf "%B %B\n" (a = b) (a = c)
 
let main_ext () =
  let open Ext in
 
  (* same part *)
  let a = Pair.of_int 1
  and b = Pair.of_int 1
  and c = Pair.of_int 2 in
  Printf.printf "%B %B\n" (a = b) (a = c)
  (* same part end *)
 
  ; Printf.printf "%B %B\n" (a <> b) (a <> c)
 
let _ =
  main_std () ;
  main_ext ()
 
 
 
(* type compatibility *)
 
let std_pair x =
  Pair.of_int x
 
let ext_pair x =
  let open Ext in
  Pair.of_int x
 
let _ =
  let a = std_pair 1
  and b = ext_pair 1 in
  Printf.printf "%B\n" (a = b) (* same type *)

Сообщение от Curry

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

Кому проще? Что тебе мешает это делать хоть в Ocaml, хоть в Go?

Go
1
var _ MyCoolInterface = (*YourCoolStruct)(nil) // explicit interface compatibility check

Сообщение от Curry

А именно, данные отдельно, функции отдельно

Расскажи об этом OpXiv )

Сообщение от Curry

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

Ты уверен? Пойду The Art of the Metaobject Protocol перелистаю.

Сообщение от Curry

Delphi
1
2
3
4
5
6
7
8
9
function TMainForm.ExecDialog(AFormClass: TFormClass):TModalResult;
begin
  with AFormClass.Create(Application) do // создаётся объект типа наследуемого от TForm
    try
     ExecDialog:=showModal;
    finally
     free;
    end;
end;

Но как тут обратиться к методам и свойствам созданного объекта TMyForm? Тут же вроде доступны будут только методы и свойства TForm (типа того же ShowModal)?

Добавлено через 11 минут

Сообщение от korvin_

Но как тут обратиться к методам и свойствам созданного объекта TMyForm? Тут же вроде доступны будут только методы и свойства TForm (типа того же ShowModal)?

Хотя не, туплю, это здесь не нужно.

@OpXiv · 24.08.2021, 17:38

Сообщение от korvin_

Расскажи об этом OpXiv )

А я считаю это глупостью от балды. Если у нас есть класс, он должен в себе содержать метод, из которого можно по this обратиться к созданному экземпляру. Или self к описанию класса. Без доп объявления на каком то внешнем методе, информации к какому структурированному классу он принадлежит как в GO.

Например, разрешено ли в GO такое ???

Go
1
2
3
4
5
6
7
func (Class_1) Func1() string {
    return "Hello!"
}
 
func (Class_2) Func1() string {
    return "Mazaf...!"
}

Как мне бегло найти все структурированные методы в общем пространстве "одного модуля"? Если есть пару таких структурированных классов, и в каждом по 10 методов. И какой то ЛАЛКА разбросал их вообще рандомно)))

@korvin_ · 24.08.2021, 17:45

Сообщение от Curry

А именно, данные отдельно, функции отдельно (хоть и объединённые в интерфейсы), возможностей больше.

Curry, вот видишь, что умный человек говорит:

Сообщение от OpXiv

А я считаю это глупостью от балды. Если у нас есть класс, он должен в себе содержать метод, из которого можно по this обратиться к созданному экземпляру. Или self к описанию класса. Без доп объявления на каком то внешнем методе

Сообщение от OpXiv

как в GO.

В C++ и Delphi так же, только this/self есть. )

Сообщение от OpXiv

Например, разрешено ли в GO такое ???

Go
1
2
3
4
5
6
func (Class_1) Func1() string {
    return "Hello!"
}
func (Class_2) Func1() string {
    return "Mazaf...!"
}

Конечно. А где не разрешено?

Сообщение от OpXiv

Как мне бегло найти все структурированные методы в общем пространстве "одного модуля"?

Воспользоваться IDE.

Сообщение от OpXiv

И какой то ЛАЛКА разбросал их вообще рандомно

Ну ты не будь ЛАЛКОЙ и не разбрасывай. )

@Curry · 24.08.2021, 18:31

Сообщение от korvin_

Разработчики модуля List_stack и не знают. Также как и разработчики какого-нибудь jackson или gson ничего не знают о тысячах проектов на, в которых используются их библиотеки.

Да, хотя бы в одну сторону информация должны быть доступна. А значит создание интерфейсов (трейтов, классов типов) возможно и оправдано, особенно для библиотек.

Сообщение от korvin_

Также как оператор равенства ( = ) : t -> t -> bool для какого-то типа t ничего не знает о том, где будет использоваться, кроме своей сигнатуры и семантики.

Оператор равенства (==), но не суть. А суть в том что был создан класс типов Eq который включает в себя описание (==), и это позволяет, с одной стороны, реализовать (==), для многих типов, с другой, накладывать constrains на типы аргументов функций показывая что с чем может работать, и помогает разумно, без излишеств, проектировать, нежели при подходе с отдельными сигнатурами функций. Интерфейсы (и т.д), это реализация соглашений взаимодействия между отдельными разработчиками, между отдельными частями программы. // К. О.

@OpXiv · 24.08.2021, 18:54

В Delphi дженерики тоже есть. Правде неудобные, но пользоваться можно

https://docwiki.embarcadero.co... f_Generics

https://docwiki.embarcadero.co... g_Generics

Добавлено через 2 минуты
Надеюсь их и в PHP добавят

https://wiki.php.net/rfc/generics

@korvin_ · 24.08.2021, 19:27

Сообщение от Curry

Да, хотя бы в одну сторону информация должны быть доступна.

В какую сторону должна быть доступна информация в случае с jackson?

Сообщение от Curry

А значит создание интерфейсов (трейтов, классов типов) возможно и оправдано, особенно для библиотек.

Ещё раз: разработчики Jackson должны подключить себе интерфейсы из моего проекта?

Сообщение от Curry

Оператор равенства (==), но не суть.

В Ocaml это ( = ), но не суть.

Сообщение от Curry

и это позволяет, с одной стороны, реализовать (==), для многих типов

Я и так могу реализовать ( = ) для многих типов. Без тайп классов.

Сообщение от Curry

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

На отдельную функцию нельзя, да. Только на модуль.

Сообщение от Curry

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

Без излишеств --- это же без миллионов тайпклассов монад/комонад/лифтов/линз и прочих зигохистоморфных препроморфизмов, да?

Сообщение от Curry

Интерфейсы (и т.д), это реализация соглашений взаимодействия между отдельными разработчиками, между отдельными частями программы. // К. О.

Молодец, К. О. Расскажи, какое соглашение должны были реализовать разработчики Jackson для моей программы?

@Curry · 24.08.2021, 20:10

Сообщение от korvin_

В какую сторону должна быть доступна информация в случае с jackson?

Если jackon - либа (пакет, крейт, сборка) и не проектировалась под конкретное приложение, то авторы её, будем думать, знают для чего их либа, и как её следует использовать, т.е. у неё есть её API выраженный в интерфейсах.

Сообщение от korvin_

разработчики Jackson должны подключить себе интерфейсы из моего проекта?

нет

Сообщение от korvin_

Я и так могу реализовать ( = ) для многих типов. Без тайп классов.

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

Сообщение от korvin_

Без излишеств --- это же без миллионов тайпклассов монад/комонад/лифтов/линз и прочих зигохистоморфных препроморфизмов, да?

Да, без тех, которые нам не потребуются для решения данной задачи. Так что, если для типа ХХХ написана реализация какого то класса типов или трейта YYY из пакета/крейта NNN, а он нам не нужен, то мы такой пакет и не подключаем. Гораздо лучше чем добавлять все функции, для всех возможных, случаев, в ООП класс.

@OpXiv · 24.08.2021, 20:20

В общем объективных реальных минусов нигде нет. Проблемы начинаются лишь в головах тех, которые не привыкли.

Вот вы правша. А тут пришёл левша, и давай затерать как левой рукой удобно кушать. Так правша возьмёт дробаш, и отстрелит ему левую руку. Принудительно заставив кушать с правой.

@korvin_ · 24.08.2021, 21:14

Сообщение от Curry

Если jackon - либа (пакет, крейт, сборка) и не проектировалась под конкретное приложение, то авторы её, будем думать, знают для чего их либа, и как её следует использовать, т.е. у неё есть её API выраженный в интерфейсах.

Или не выраженный, но не суть. Ты же знаешь про инверсию зависимостей?
Типа вот я пишу приложение:

Code
1
2
3
ComponentA -> Jackson
ComponentB -> Jackson
...

теперь я хочу избавиться от прямой зависимости:

Code
1
2
(ComponentA -> FromJSONInterface) <- Jackson
(ComponentB -> ToJSONInterface) <- Jackson

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

Сообщение от Curry

нет

Как они тогда реализуют требования моего приложения? Очевидно никак.

Конечно, в общем случае, интерфейс библиотеки может не совпадать с интерфейсами, которые требуют мои компоненты и мне придётся писать какой-то bridge (хз как там в паттернах это называется), но в случаях, когда совпадают --- не придётся. В этом и отличие. Я уже приводил пример, повторю: SWT, два компонента, TextField, ComboBox, оба имеют метод getText, одинаковый как по сигнатуре, так и по семантике, но авторы SWT не предоставили каой-нибудь интерфейс Textable { getText() : String }. Как мне однообразно обработать объекты TextField и ComboBox? Без костылей --- никак. А если это компоненты из разных библиотек, SWT и Swing (их можно совмещать в одном приложении), которые в общем случае не обязаны знать друг о друге и иметь общую зависимость в виде единого набора интерфейсов?

Сообщение от Curry

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

Так и не нужно их все описывать, достаточно описать модуль.

Сообщение от Curry

Да, без тех, которые нам не потребуются для решения данной задачи. Так что, если для типа ХХХ написана реализация какого то класса типов или трейта YYY из пакета/крейта NNN, а он нам не нужен, то мы такой пакет и не подключаем.

Спасибо, кэп.

Сообщение от Curry

Гораздо лучше чем добавлять все функции, для всех возможных, случаев, в ООП класс.

Это вообще к чему? Мы уже целую страницу про ООП не говорим

Добавлено через 1 минуту

Не по теме:

Сообщение от OpXiv

В общем объективных реальных минусов нигде нет. Проблемы начинаются лишь в головах тех, которые не привыкли.
Вот вы правша. А тут пришёл левша, и давай затерать как левой рукой удобно кушать. Так правша возьмёт дробаш, и отстрелит ему левую руку. Принудительно заставив кушать с правой.

Да, кстати, иди уже кушать и на тихий час, не мешай взрослым дядям разговаривать.

@OpXiv · 24.08.2021, 21:26

Сообщение от korvin_

не мешай взрослым дядям разговаривать.

А это уже оффтоп не по теме. Вы ударяетесь уже в извращения самых крупных извращенцев.

@korvin_ · 24.08.2021, 21:38

Curry, и ещё вот такой момент:

есть у меня три компонента, требующие такие зависимости:

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
component A
  requires Repo {
    Get (ID) -> User
  }
 
component B
  requires Repo {
    Get (ID) -> User
    Put (User) -> ID
  }
 
component C
  requires Repo {
    Put (User) -> ID
  }

теперь я реализую репозиторий:

Code
1
2
3
4
component Repo {
  Get (id: ID) -> User { ... }
  Put (user: User) -> ID { ... }
}

всё, могу использовать. Компилятор позаботится о соответствии Repo нужным требованиям.

В Java интерфейсы "складываются", т.е. методы с одинаковыми сигнатурами из разных интерфейсов считаются одним методом. Типа

Code
1
2
3
4
5
6
component Repo implemets
  A.Repo, B.Repo, C.Repo
{
  Get (id: ID) -> User { ... }
  Put (user: User) -> ID { ... }
}

А для Haskell/Rust мне придётся реализовывать m*n тайпклассов/трейтов? Типа:

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
component Repo implemets A.Repo
{
  Get (id: ID) -> User { ... }
}
 
component Repo implemets B.Repo
{
  Get (id: ID) -> User { ... }
  Put (user: User) -> ID { ... }
}
 
component Repo implemets C.Repo
{
  Put (user: User) -> ID { ... }
}

Нет, спасибо.

@Curry · 24.08.2021, 22:22

Сообщение от korvin_

Ты же знаешь про инверсию зависимостей?

Угу. При её использовании обычно применяют шаблоны "фабрика", "фабричный метод".
Что же про конкретную библиотеку о которой вы пишите, то я не знаю даже в каком языке она используется, что бы влезать в её нюансы.

Сообщение от korvin_

Я уже приводил пример, повторю: SWT, два компонента, TextField, ComboBox, оба имеют метод getText, одинаковый как по сигнатуре, так и по семантике, но авторы SWT не предоставили каой-нибудь интерфейс Textable { getText() : String }. Как мне однообразно обработать объекты TextField и ComboBox? Без костылей --- никак.

А началось с обсуждения достоинств и недостатков ООП, применения модулей. И вы переходите к жалобам на то как криво SWT сделана. В нормальных либах таких проблем нет. Несколько лет назад я сделал простенький GUI на Haskell, поверх SDL, так у меня виджеты, для которых это имеет какой то смысл, реализуют

Haskell
1
2
3
4
-- | Для экземпляров этого класса типов можно назначить установку и извлечение некоего текста.
class TextProperty a where
    setText :: MonadIO m => a -> T.Text -> m ()
    getText :: MonadIO m => a -> m T.Text

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

Сообщение от korvin_

Так и не нужно их все описывать, достаточно описать модуль.

Я писал про ограничения налагаемые на тип конкретного аргумента (аргументов) функции. Если вы уподобите каждый класс типов/трейт/интерфейс модулю, то так и будет.

Добавлено через 13 минут

Сообщение от korvin_

В Java интерфейсы "складываются", т.е. методы с одинаковыми сигнатурами из разных интерфейсов считаются одним методом.

Так может быть, если это методы без реализации. Но если в нескольких интерфейсах/классах типов/трейтах есть функции с одинаковыми именами и сигнатурами, и, из вашего конктекста, я понимаю что это одно и тоже (их же "легально" складывать), значит ошибка на уровне проектирования интерфейсов, не стоит их дублировать, но создать отдельный интерфейс для get, для put, а их уже использовать как зависимости для component A,B,C.
Как говориться don't repeat yourself.

@korvin_ · 24.08.2021, 22:36

Сообщение от Curry

Угу. При её использовании обычно применяют шаблоны "фабрика", "фабричный метод".

Это не связано. Возможно, но не необходимо.

Сообщение от Curry

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

Java, но для моего примера это не имеет значения.

Сообщение от Curry

А началось с обсуждения достоинств и недостатков ООП, применения модулей.

Я описал разницу, не навязывая применение одного подхода во всех ситациях.

Сообщение от Curry

И вы переходите к жалобам на то как криво SWT сделана.

Я привожу пример.

Сообщение от Curry

В нормальных либах таких проблем нет.

Как бы в Хаскелле/Расте были бы реализованы такие библиотеки? Как были реализованы кроссбиблиотечные интерфейсы? И давай без примеров примитивного (простого) Show, не раздувай стандартную библиотеку на все 100500 случаев.

Сообщение от Curry

Несколько лет назад я сделал простенький GUI на Haskell, поверх SDL, так у меня виджеты, для которых это имеет какой то смысл, реализуют

Молодец, а какой-нибудь HaskellQt тоже реализует твои тайпклассы?

Сообщение от Curry

Т.е. сведение таких элементарных вещей к одному интерфейсу представляется очевидно необходимым для нормального проектирования либы.

Теперь увеличь количество либ в N раз.

Сообщение от Curry

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

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

Добавлено через 2 минуты

Сообщение от Curry

Как говориться don't repeat yourself.

Ну вот в Go я могу не повторять себя бессмысленными письменами типа

Code
1
impl I for T { ... }

:lol:

@Curry · 25.08.2021, 16:21

Сообщение от korvin_

Как бы в Хаскелле/Расте были бы реализованы такие библиотеки?

Какие библиотеки?

Сообщение от korvin_

Как были реализованы кроссбиблиотечные интерфейсы?

На https://www.stackage.org/ и https://crates.io/ десятки тысяч библиотек. Большинство с друг другом взаимодействуют. И через класса типов/крейты. Исходники доступны. welcome to reading.

Сообщение от korvin_

какой-нибудь HaskellQt тоже реализует твои тайпклассы?

Qt даже не ООП-шный, а гипер-ООП-шный, идеологически не совместим с haskell.
Несколько отвлекаясь от темы (~~здесь палата №6~~ холивары, здесь можно). Мне усиленно кажется что для реализации механизма сигналов-слотов не нужно было городить препроцессор, это реализуется на чистых плюсах (хотя и не пытался так сделать). При чём в Qt (по крайней мере 4.х и 5.1 которыми я пользовался) можно было отправить сигнал объекту у которого нет соотвествующего слота, и выяснялось это только в рантайме, исключением. На плюсах можно было бы и в компайлтайме проверять, через множественное наследование. Я в курсе что множественное наследование гораздо больше народу не одобряет чем ООП, но в данном случае, это было бы лучше чем препроцессор. Ну, да, препроцессор ещё туда всякие foreach-и добавляет, но это мелочи.

Сообщение от korvin_

Теперь увеличь количество либ в N раз.

Сообщение от korvin_

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

Ну что ж делать если они такие ... альтернативно продвинутые.
Объединяйте их костылями. В Java же завезли рефлексию. Выковыривайте методы getText по имени в рантайме, к примеру.

Сообщение от korvin_

Ну вот в Go я могу не повторять себя бессмысленными письменами типа

А если вернётесь к голым С, то вам понадобится ещё меньше "бессмысленных письмен".

@korvin_ · 02.09.2021, 13:49

Сообщение от Curry

Объединяйте их костылями. В Java же завезли рефлексию. Выковыривайте методы getText по имени в рантайме, к примеру.

Она там изначально была. Но да, так и сделано было, рефлексо-костылём.

Сравнивать Ocaml'овские модули с тайп-классами и трейтами всё же не совсем корректно, их нужно сравнивать с Хаскелльными и Растовыми модулями.

Например, подключил ты какой-то модуль реализации стека:

Haskell
1
import qualified Stack = ListStack

и далее используешь его. Потом решил перейти на другую реализацию:

Haskell
1
import qualified Stack = ArrayStack

Если их сигнатуры совпадают, то пользовательский код соберётся. Утиная типизация модулей, только без явного описания сигнатур.

Сообщение от Curry

А если вернётесь к голым С, то вам понадобится ещё меньше "бессмысленных письмен".

Наоборот, устану типы приводить.

Новые блоги и статьи Все статьи Все блоги /
Запустил конкурс "тем и промптов для текстовых квестов созданных почти чисто ИИ" Adler 06.10.2026 Всем привет! За последние три-четыре дня я создал более 16 текстовых квестовых игр используя преимущественно по одному запросу к ИИ на игру. Мне так понравилось смотреть все ветки/ сцены во всех. . .	ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .	Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .
Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .

@Regrin1 Автор канал по Лиспу 25 / 23 / 2 Регистрация: 10.08.2021 Сообщений: 357

	Минусы ООП 21.08.2021, 07:06. Показов 8969. Ответов 97 Метки ООП (Все метки) Я слышал много критики в адрес ООП. Говорят, что оно приносит больше сложности чем упрощает и такой код труднее читать. Насколько обоснованны эти заявления? Приводятся цитаты Дейксры, Торвальдса и Рэймонда в которых они говорят об ООП не самые лестные вещи. Я понимаю, что апелляция к авторитету - не аргумент, но сомнение во мне уже заложилось... 0

@OpXiv 193 / 140 / 36 Регистрация: 19.11.2020 Сообщений: 881
	24.08.2021, 18:54
	В Delphi дженерики тоже есть. Правде неудобные, но пользоваться можно https://docwiki.embarcadero.co... f_Generics https://docwiki.embarcadero.co... g_Generics Добавлено через 2 минуты Надеюсь их и в PHP добавят https://wiki.php.net/rfc/generics 0

@OpXiv 193 / 140 / 36 Регистрация: 19.11.2020 Сообщений: 881
	24.08.2021, 20:20
	В общем объективных реальных минусов нигде нет. Проблемы начинаются лишь в головах тех, которые не привыкли. Вот вы правша. А тут пришёл левша, и давай затерать как левой рукой удобно кушать. Так правша возьмёт дробаш, и отстрелит ему левую руку. Принудительно заставив кушать с правой. 0