Полиморфизм? - Можно кормить Зайку мясом?

Шел 2024-й, на ЛОРе ретарды всё так же не могли понять, что такое типизация…

Если я правильно понял: Типизация - это у древних языков программирования, в которых низкий уровень Абстракции

Устанавливай обрезанный линукс с телеграмом, не отвлекайся.

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

Всё верно. ООП - это для старпёров из гуманитарного техникума

Да что ж вы так любите на чёрно-белые группы делиться? У одних ООП — это серебряная пуля, и программирование без объектов для лохов. В других наоборот ООП ненужно и для лохов.

У ООП есть сферы применения, где оно удобно. А есть такие, где оно только мешает и парит мозг. Вторых больше, но и первые существуют в достаточном количестве и важности. Все эти парадигмы, приёмы, паттерны — это не священное писание, это инструмент, который можно использовать, чтобы упростить себе жизнь, когда они её упрощают, и не используют, когда не упрощают. Причём использовать можно как полностью, так и частично, и даже комбинируя. Зачем этот фанатизм в обе стороны?

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

Модуль - это уже объект со свойствами. Вне концепции ООП понятия модулей не существует

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

Вне концепции ООП понятия модулей не существует

Вот это новости. И давно так?

Лет как 30

In [1]: import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

In [2]: type(this)
Out[2]: module

In [3]: isinstance(this, object)
Out[3]: True

И в ноде так же…

> var Util = require('util')
undefined
> Object.prototype.toString(null, Util)
'[object Object]'

Или ты о каких модулях? О тех, что в Си? - То не модули

Лет как 30

Modular programming per se, with a goal of modularity, developed in the late 1960s and 1970s, as a larger-scale analog of the concept of structured programming (1960s). The term «modular programming» dates at least to the National Symposium on Modular Programming, organized at the Information and Systems Institute in July 1968 by Larry Constantine

Или ты о каких модулях? О тех, что в Си? - То не модули

О тех, что в Modula и Standard ML, например.

А почему те, что в Си — не модули?

А почему те, что в Си — не модули?

потому что в С++20 пришлось все-таки изобрести модули, чтобы в си появились модули. Ну то есть те что были модули не очень то были модулями. Или новые модули, это сверхмодули?

А почему те, что в Си — не модули?

Потому что там при коНпеляции «код вставляется», и тож самое C#/Java. Это сродни похапе, где написал require "foo";, и у тебя «код поДставился». Модуль - это что-то функциональное, в пистоне - готовый паттерн-синглтон, те ты можешь в нем переопределять переменные, манки-патчингом заниматься… ну и в ноде так же

Потому что там при коНпеляции «код вставляется»

Какой код куда вставляется?

и тож самое C#/Java.

WUT? ClassLoader для тебя шутка что ли? Какой код куда «подставился»?

Модуль - это что-то функциональное

Что значит «функциональное»? Как в Хаскелле? Как лямбды? При чём тут ООП тогда?

ты можешь в нем переопределять переменные, манки-патчингом заниматься… ну и в ноде так же

Это в каком определении модульности написано «можно заниматься манки-патчингом»? И при чём тут ООП тогда?

потому что в С++20 пришлось все-таки изобрести модули, чтобы в си появились модули. Ну то есть те что были модули не очень то были модулями. Или новые модули, это сверхмодули?

Речь шла про Си, а не Си++, но в любом случае, а новые модули --- это модули или не модули?

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

Ваша программа устарела, товарищ. Сегодня модно делать composition over inheritance. Новые модно-молодежные ЯП вообще не имеют наследования.

Как говорилось в известном фильме - «У каждого свои недостатки» (С).

А разве статический полиморфизм нынче не в моде?

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

Речь изначально пошла про ООП вообще.

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

А в некоторых языках для этого есть слово namespace.

class Animal
  def initialize
    @alive = true
  end

  def feed(food)
    raise "Not implemented"
  end 
  
  def kill()
    @alive = false
    p "Dead"
  end
end

class Crocodile < Animal
  def feed(food)
    if food.is_a?(Meat) 
      p "eating #{food}"
    end
  end
end

class Bunny < Animal
  def feed(food)
    if food.is_a?(Vegetable) || food.is_a?(Grain) 
      p "eating #{food}"
    end
  end

  def kill()
    raise "You shouldn't kill bunnies"
  end
end

Допишите кто-нибудь, мне лень:)

Обычно функциональщики катят бочку на ООП. Вот цитата из книги автора Erlang:

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

Речь изначально пошла про ООП вообще.

а это бессмысленно, потому что мы можем открыть мануал по тому же питону и прочитать определение

A module is a file containing Python definitions and statements. The file name is the module name with the suffix .py appended. Within a module, the module’s name (as a string) is available as the value of the global variable name.

вот и все, любой отдельный файл - это модуль. Попробуем натянуть это на C# с их partial классами и фигня получится.

Я думаю, что недостаток…

демагогия это

1. Заявка - я думаю «А» - говно, а «Б» - конфетка. Имею право думать
2. Обоснование - что-то что не имеет отношения ни к А ни к Б, и вообще не понятно что имел в виду автор, «ну это как там его у них, ну вы поняли»
3. Яркий образ - банан, горила, всё пропало, смерть, геноцид
4. Профит

Модуль - это уже объект со свойствами

И что с того? Любая ассоциативная структура данных — это объект со свойствами, ООП со всеми его наворотами тут вовсе не обязателен.

Несостоятельный, хватит тявкать. Ты на вопрос забыл ответить.

Смысл тут такой что setX легко найти текстовым поиском

Зачем искать текстовым поиском то, что не вылазит за границы одного метода? Зачем делать сеттеры тому, для чего не нужна внутренняя доп.логика? Просто потому, что тут так заведено.

Сколько можно жевать этот ооп тупняк.

Какие новые?

Это каноничный пример ненужности ооп. Проблема вот в этом: // .... Просто, как человек, делаешь Polygon - shape в общем случае, а это говнище частных случаев сносишь. Гуишники, который тут упоминали, пришли к тому же самому. Они делают почти все через div, меняя ему свойства на нужные.

У ООП есть сферы применения, где оно удобно.

Где, например.

Все эти парадигмы, приёмы, паттерны — это не священное писание

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

Полиморфизм

Не. Это крестовые шаблоны.

Виртуальные функции в крестах жто тоже полиморфизм. И на шаблонах тоже можно делать полиморфизм. Это довольно широкое понятие.

Но если шире брать, то оно скорее про метапрограммирование.

Нет. Хотя крестовые шаблоны это метапрграммирование в тч

Язык программирования это инструмент написания рабочих программ. А смыслы выражать это к теоретикам

Нет ничего практичнее хорошей теории(с)

Вообще какие то кривые ответы.

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

Инкапсуляция - фича не в ограничении доступа, а в сгребании в кучку полей и методов.

Однако доступ к ним всё равно можно получить.

В крестах тоже можно, есть как минимум три возможности.

Где, например.

Везде, где многое завязано на объектах, их свойствах и действиях. Например, игрушка в жанре roguelike rpg.

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

Ну для кого-то и «Властелин колец» — священное писание. Я про нормальных людей скорее. А так да, пытался. Безуспешно. Поэтому я всегда отговариваю начинающих кодеров первым языком учить Java или C# — приводит к необратимому повреждениб мозга довольно часто. С JavaScript похожая проблема, но не на почве ООП.

Какого ещё одного метода? Если не вылазить за один метод то это будет локальная переменная метода, а не поле объекта. Сеттеры полезны там, где поле более-менее публичное и может меняться из любого места программы, но эти места надо уметь быстро перечислить. И кстати это не только в ООП, обычные глобальные переменные в си-модуле так же можно делать static и в геттеры-сеттеры обёртывать.

У ООП есть сферы применения,

Везде, где многое завязано на объектах,

Какое-то масло-масляное, вы уж извините.

Независимо от парадигмы не выйдет. Потому что в парадигме «Дождался команду - выполнил - вывел в stdout - goto 0» ООП не с руки.

Почему? Команды можно сделать классами и объединить в иерархию. А ещё команды могут работать с объектами, описанными классами.

Шёл 2024 год…

Я удивлён, почему Вы не спрашиваете как искать информацию в Интернете, раз бумажные книги более не доступны? Это было бы намного полезнее для Вас, на мой взгляд.

Сколько можно жевать этот ооп тупняк.

Каждый раз как в первый.

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

И, что характерно, те же самые зубры (пусть и уже с иными никами) приходят со своими ответами… И жуют, и жуют… А могли б взять на поруки какого-нибудь школьника/студента (передать максимально свои знания, в универе/лабах не то), но это сложна. Поэтому надо продолжать жевать. Уже скоро (относительно) их сменят другие ники, и повторится всё как встарь.

Странно, что с годами участников дискуссии больше не становится, это какой-то предел?

Команды можно сделать классами и объединить в иерархию.

Можно. Но это будет искусственное образование. Всё равно что глаголы превратить в имена существительные.

Можно кормить Зайку мясом?

Что-то вдруг вспомнился древний боянище про мыша. Ну тот, который заканчивается словами «впрочем, он, наверно, сдохнет… но идея хороша!».

Но это будет искусственное образование.

Любая абстракция является искусственным образованием.

Всё равно что глаголы превратить в имена существительные.

В китайском почти любое слово может выполнять роль глагола или роль существительного. Для них, наоборот, выглядит искусственным, когда 火 в роли существительного и 火 в роли глагола даже не однокоренные: «огонь» и «жечь».

Если команды можно комбинировать, то классы становятся почти необходимы. Например, если есть команда типа

обработать-файлы {селектор-файлов} {обработчик-файла}

то селектор-файлов и обработчик-файла — это классы команд с интерфейсом, ожидаемым командой обработать-файлы.

Если команды можно комбинировать, то классы становятся почти необходимы.

Именно что «почти». И да, к счастью, в программировании используется не китайский, а английский язык. Допускаю, китайцы думают иначе - что ж, пусть дерзают, посмотрим чей кунг-фустиль лучше.

Я же написал пример команды, которая принимает аргументами команды, являющихся потомками определённых классов.

Наличие классов позволяет избежать некоторых ошибок.

Каких ошибок позволяет избежать наверчивание классов на селектор файлов и обработчик файла вместо типов?

Каких ошибок позволяет избежать наверчивание классов на селектор файлов и обработчик файла вместо типов?

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

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

В программировании разнообразие гораздо больше, чем в естественных языках. Есть Ruby и Common Lisp, где все переменные содержат объекты. Даже если те объекты являются функциями или числами. Есть Haskell, где все переменные содержат функции от одного или нуля аргументов.

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

Не спорю, всё это есть - ну, вот, давайте смотреть, кто из этих языков победит обычное процедурное семейство языков

А они воюют? Для меня это звучит примерно как: кто победит, отвёртка или молоток.

Пишут на них всех. И даже на ассемблерах.

Полиморфизм? - Можно кормить Зайку мясом?

Можно (если пьяный за рулём).

А они воюют?

Так вы же предлагаете процедурные вещи в классах ваять, не я

Я указываю, что кто-то может наваять и это не будет ошибкой.

Также и в обратную сторону. Графический интерфейс не обязан быть на ООП.

Графический интерфейс не обязан быть на ООП

желаю тебе поработать с таким