ООП: худшее, что случалось с программированием

у вас вполне процедурный код

это в процедурном то коде создаются функции первого класса, да еще и с замыканиями изменяемыми потенциально?

Всё ещё больше моего варианта в вашем стиле

А код можно в студию? или это тот что был без registerTool и тп?

по-прежнему никак не мешает сделать так

Он не мешает потому что код находится в одном файле, и у всех функций есть доступ к состоянию. В реальном проекте разумеется 1) будет разбит на файлы или 2) может лежать в замыкании, но смысла в этом особо нет.

any имеется и как там с типобезопасностью

ну так вы попробуйте использовать registerTool и узнаете что все в порядке.

И даже меньше строчек чем у вас, да и код меньше и проще.

Код меньше и проще?) Сам себя не похвалишь, как говорится..

И еще - мне не нужно описывать доп класс или структуру, я создал инструмент прямо в рантайме без дополнительных типов. Ну это так, к слову.

По поводу задачи - вы доказывали что мол в ПП/ФП нельзя сделать так, как в ООП - я вам доказал что можно. И без классов, без наследованния, без всех перечисленных в статье проблем. Код простой, понятный любому. Так кто проиграл в споре?

ООП: худшее, что случалось с программированием

Так в каком стиле мои примеры кода? ПП вы назвать отказываетесь, ФП тоже. И уж явно не ООП, как тогда? Вы сливаетесь с вопроса похлеще самого убогого школьника.

ООП: худшее, что случалось с программированием

Это элементы ФП, но отдельных элементов ФП недостаточно, чтобы назвать язык функциональным

И как же одним словом назвать парадигму программирования, которая не привязана к каким то очень урезанным стилям - математическому, процедурному и тп, а использует их все в зависимости от задачи? И при этом используя только структуры и функции - без классов.

Я решил назвать это функциональным программированием. Не согласны - ок. Только предложите свое логичное название или не спорьте тогда.

ООП: худшее, что случалось с программированием

@Psychosynthesis Переписал вод все требования, см. ответ выше.

@michael_v89и получилось еще меньше, и ничего себе - даже без switch и дублирования инициализации.

@Chaos_Optimaи даже setActiveTool вернул с проверкой.

ООП: худшее, что случалось с программированием

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

Я лишь в очередной раз выкинул весь ненужный мусор что у вас был. Если нужно регистрация сторонних инструментов, то нужно вернуть registerTool (Playground), и делать через обобщения, что даже было указано в статье:

Код с регистрацией инструментов через обобщения

type CollectState = { radius: number, items: number[] }
type InstancerState = { items: string[] }
type Tool<TState> = {
  createInitialState: () => TState
  processPick: (state: TState) => void
  update: (state: TState, i: number) => void
}

const collectItems = (items: number[], radius: number) => {
  for (let i = 0; i < radius; i++) {
    items.push(i)
  }
  console.log(`\tadded items in radius ${radius}`)
}

const collect: Tool<CollectState> = {
  createInitialState: () => ({items: [], radius: 0}),
  processPick: ({items, radius}) => {
    console.log('From ToolCollectInRadius')
    collectItems(items, radius)
    console.log('\t', items.join(','))
  },
  update: (state, i: number) => {
    state.radius += i
  },
}

const align: Tool<CollectState> = {
  ...collect,
  processPick({items, radius}) {
    console.log('From ToolAllign')
    collectItems(items, radius)
    console.log(`\talign ${items.length} items`)
  },
}

const instancer: Tool<InstancerState> = {
  createInitialState: () => ({items: []}),
  processPick({items}) {
    console.log('From ToolInstancer')
    items.forEach((item) => console.log(`\tspawn item: ${item}`))
  },
  update({items}, i: number) {
    items.push(i.toString())
  },
}

const state: {
  activeTool?: string
  tools: Record<string, { tool: Tool<any>, state: any }>
} = {
  tools: {}
}

const registerTool = <T,>(key: string, tool: Tool<T>) => {
  state.tools[key] = { tool, state: tool.createInitialState() }
}

const setActiveToolKey = (key: string) => {
  if (!state.tools[key]) return
  state.activeTool = key
}

const processClick = () => {
  const {activeTool, tools} = state
  if (!activeTool || !tools[activeTool]) return

  tools[activeTool].tool.processPick(tools[activeTool].state)
}

const updateTool = (i: number) => {
  const {activeTool, tools} = state
  if (!activeTool || !tools[activeTool]) return

  tools[activeTool].tool.update(tools[activeTool].state, i)
}

registerTool("collectInRadius", collect)
registerTool("align", align)
registerTool("instancer", instancer)

setActiveToolKey('collectInRadius')
updateTool(8)
processClick()

setActiveToolKey('align')
updateTool(15)
processClick()

setActiveToolKey('instancer')
updateTool(10)
processClick()

setActiveToolKey('collectInRadius')
processClick()

setActiveToolKey('instancer')
updateTool(100)
processClick()

Что должен написать пользователь вашей системы?

Как думаете сработает? Я вот сильно сомневаюсь.

Дополнительно помимо того что вы должны каким-то образом узнать какие функции нужно перегружать (в случае С++ сам компилятор подскажет)

Вы слишком много сомневаетесь, просто не разбираетесь в ФП. Пользователь моей системы вызовет registerTool и ему компилятор подскажет что реализовать не меньше вашего.

По поводу больше\меньше кода. Ваши две функции

На обобщениях получилось еще лучше. Всего 99 строчек кода.

Вы правда думаете что ваше решение лучше?

Уверен что лучше. А вы?

Вот кстати и от меня задачка, давайте ка добавим еще один пример инструмента, посмотрим как вы его на ООП сделаете (Playground).

registerTool("custom", {
  createInitialState: () => ({
    ...collect.createInitialState(),
    instancer: instancer.createInitialState(),
    instancer2: instancer.createInitialState(),
  }),
  processPick: (state) => {
    console.log('From Custom')
    collect.processPick(state)
    collect.processPick(state)
    align.processPick(state)
    instancer.processPick(state.instancer)
    instancer.processPick(state.instancer2)
  },
  update: (state, i) => {
    collect.update(state, i)
    collect.update(state, i)
    instancer.update(state.instancer, i)
    instancer.update(state.instancer2, i)
  }
})
setActiveToolKey('custom')
updateTool(15)
processClick()

ООП: худшее, что случалось с программированием

Я добавил определение процедурного стиля, и оно сильно более ограничено чем мое определение ФП.

От прямого вопроса ушли, слив засчитан.

ООП: худшее, что случалось с программированием

1. Я добавил определение процедурного стиля, и оно совсем отличается от моего Фп. Что в нем не так?

2. В примерах я возвращаю из функций новые функции с замыканием - это ПП?

ООП: худшее, что случалось с программированием

Еще раз - вы утверждаете что мои примеры где я из других функций "возвращаю динамически созданные функции с изменяемым замыканием" - это процедурное программирование? Ответить можете на прямой вопрос?

ООП: худшее, что случалось с программированием

Меня не устраивает общепринятое определение, и я выдумал более логичное.

ООП: худшее, что случалось с программированием

Я в примерах возвращаю динамически созданные функции с изменяемым замыканием. Это по вашему процедура? И кто тогда не разобрался?

ООП: худшее, что случалось с программированием

Почитайте секцию определений - ФП у меня это не математический стиль ФП.

ООП: худшее, что случалось с программированием

При чем тут вообще строгая типизация?

ООП: худшее, что случалось с программированием

Секцию определений я смотрю вы пропустили.

ООП: худшее, что случалось с программированием

1. Прикрутить их нужно тогда уж к интерфейсу, содержащему поля имен.

2. В решении опять присутствуют статические методы. А это ФП - без него получается никак.

ООП: худшее, что случалось с программированием

В моих примерах используется динамическое создание функций с замыканиями, и их возвращение из других функций. Это по вашему ПП?

ООП: худшее, что случалось с программированием

В моих примерах используется динамическое создание функций с замыканиями, и их возвращение из других функций. Это по вашему ПП?

ООП: худшее, что случалось с программированием

В моих примерах используется динамическое создание функций с замыканиями, и их возвращение из других функций. Это по вашему ПП?

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

ООП: худшее, что случалось с программированием

Они могли быть реализованы и как параметры функции без проблем. Команда реактор нашла еще более удобное решение, которое успешно используется.

ООП: худшее, что случалось с программированием

В своей статье я четко даю понять что считаю ООП - наличие классов с наследованием и тп. А связывание данных и методов теми же замыканиями - не считаю. В Си классов нет, точка.

ООП: худшее, что случалось с программированием

Если вы внимательно почитаете еще раз, то речь там идет о методах классов. И в них нет ничего хорошего.

То что есть в Го и то что вы привели на Расте - по сути метод интерфейса, и по моей терминологии и близко не является ООП. И плохого в этом только то, что 1) появляется два способа вызова функций, через точку и без 2) в популярных редакторах первый - с автокомплитом, второй без.

А вот Zig как раз по сути ООП-шный (мусор), если там есть методы, и методы конкретного типа а не интерфейса (полиморфизм подклассов).

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