Вы, кажется, не уловили сути статьи. Она в том, что есть вещи естественные для человека, а есть неестественные. И вот duck.sound - естественная. Потому что утка крякает. А не шум издать утка. Не мыслят люди так. ФП тут не при чем, оба примера вполне императивны. Мало того, если Вы когда-нибудь ныряли в чужой код, то должны различать "посмотреть все методы утки" и "посмотреть все функции на свете, которые принимают что-то типа утки". Первое легко, второе нереально.
С точки зрения процесса этот регистр immutable - это внешние константные для него данные (менять их в ядре ОС он не может, видит копию), и проблема ИМЕННО в том, что процесс увидел чужой стейт. Который должен был быть недоступен. Увы, иммутабельность не заменяет инкапсуляции - не всё то, что нельзя изменить можно видеть и использовать.
Вы не путаете "забыто" и "умерло"? Динозавры не забыты, но исчезли - не конкурентоспособны. Так и с ООП - оспорено множество раз, но живёт, а конкуренты - если они вообще без ООП - умирают. И я объяснил, почему - потому что ООП соответствует базису мышления человека. И да (и про это я там тоже написал) - реальное ООП неидеально и местами коряво. А теперь посмотрите на русский и английский язык - неидеальны и местами корявы. Посмотрите на понятийный аппарат среднего homo sapiens. На этот мир, вообще.
Можно, вообще, отдельно обсуждать наследование интерфейса и реализации, и второе часто делается именно композицией.
Тут проблема вот в чём. Если бы ортогональность унаследованных интерфейсов была гарантирована и гарантировала бы ортогональность реализаций, то мир был бы прекрасен. В реальности сам факт того, что нам надо совместить два интерфейса означает, что реализация будет не "сложить вместе две реализации", а как-то их связать.
Вот я тоже почитал и подумал - Вас именно эти слова, что ли, бесят? Ну - полиморфизм - это общепринятое сокращение для "одно и то же сообщение может быть по-разному обработана разными объектами" - почему это так раздражает-то?
Вот смотрите. Формально Вы совершенно правы - если всё вокруг народное immutable - инкапсуляцию можно отменить, верно?
Во-первых, неверно. Инкапсуляция, в том числе, скрывает трюки реализации, которые действительно знать нельзя. Мне один из сотрудников Микрософта рассказывал, что программисты просекли, что при старте процесса в Windows в каком-то регистре всегда лежит что-то полезное - какой-то дескриптор. И начали им пользоваться. А это значение там лежит случайно - валяется потому что последнее вычисление его использовало. Код скорректировали - и оно пропало. И Вы не представляете, на сколько денег влетел Микрософт, чтобы СИМУЛИРОВАТЬ это поведение для программ, которые от него сдуру зависят.
Отсюда некоторый максимализм, который иногда звучит в ООП - извне реализации даже классы желательно не использовать, только интерфейсы.
И вторая часть - ну, положим, мы такие заиньки, что трюки реализации ну никак не светятся. Не верится, но положим. Вот только есть беда - как обсуждаешь ФП формально, так в нём присваивания нет. А как реализация и конкретный код - так и сразу есть. И сразу - "это только критики ФП требуют от него идеального соответствия канонам, а мы, носители тайного знания, уже давно считаем, что присваивать можно". Это почти буквальная цитата из дискуссии.
Так что - можно бы в рай заменить инкапсуляцию иммутабельностью, да грехи не пускают.
Смотрите. Конкретизация до значений - это я немножко жёстко заявил, но дело в том, что наполнение поля значением тоже порождение дочернего класса, с некоторой точки зрения. Но можно не лезть в эти детали. Собственно, если трейты наследуются - то это ООП с множественным наследованием, а если не наследуются - это кабздец без реюза кода.
Можно практически всё, но зачем? Наследование - способ структуризации и представлений о предметной области, и связанных с ним применимых к ней алгоритмов. Представить себе мир, где объекты компонуются из необъятного моря трейтов легко, но они же не будут ортогональны. Придётся сделать трейт "украдены у Зины" и трейт "украдены у Люси", вместо трейта "украдены у кого-то" и его конкретизации.
Я делал в своё время в Яндексе иерархическую ОО БД, в которой иерархия была именно и только иерархией наследования. То есть в ветке дерева можно было либо заявить новое свойство, либо зафиксировать значение заявленного выше свойства. Оказалось, что иерархия наследования самодостаточна и позволяет заменить собой иерархию хранения.
Это, конечно, немного взрывало мозг, но логика была безупречна. (Она делалась для Маркета) - на каждом уровне иерархии появлялись поля, актуальные для данного обобщения. И, кстати, множественное наследование работало и позволяло из "принтеры" и "сканеры" родить "МФУ".
Предполагается, что уж определения с первой страницы букваря читатель знает. :) Читателю, который этого не знает и сам вопрос, наверное, не очень интересен...
Насчёт "какой-то инстанс" Вы правы, но это и есть введение класса, по сути. Мы не знаем конкретных свойств этого инстанса (значений полей и даже конкретного класса). Ну, то есть, даже не знаем, кухонный это тейбл, или верстак.
Пример, конечно, неудачный. Метод можно поместить куда угодно если он не трогает потроха класса и у нас вообще нет наследования. Что явно вырожденный случай. Если наследование есть, и оно предполагает разную реализацию печати для разных принтеров или для разных документов - то расположение метода очевидно.
Ну а разные процессы - это объекты обёрнутые в JSON-ы, вроде бы так.
Где и как у Вас фраза "время обладает ценностью" превратилась в "каждое действие должно приносить прибыль"?
И как Вы, вообще, живёте, если в Вашей голове вот такие семантические преобразования проскакивают без страха и упрёка? И как Вы дожили до взрослого возраста ни разу не услышав фразу "время - деньги"? И смотрели ли Вы в детстве "Сказку о потерянном времени"? Ну прям вот я просто смотрю на эту феерию и теряю дар речи.
Мне казалось, ASIO так и работает, нет? И является стандартом де факто для музыкальной индустрии.
Ну - значит, ждём новый ЯП...
дерево классов
- драйвер
-- сетевой драйвер
--- драйвер TCP
--- драйвер UDP
дерево классов
- драйвер
-- драйвер бытовой техники
--- драйвер пылесосов
--- драйвер кофеварок
двойной наследник - драйвер кофеварок по UDP
Вы, кажется, не уловили сути статьи. Она в том, что есть вещи естественные для человека, а есть неестественные. И вот duck.sound - естественная. Потому что утка крякает. А не шум издать утка. Не мыслят люди так. ФП тут не при чем, оба примера вполне императивны. Мало того, если Вы когда-нибудь ныряли в чужой код, то должны различать "посмотреть все методы утки" и "посмотреть все функции на свете, которые принимают что-то типа утки". Первое легко, второе нереально.
С точки зрения процесса этот регистр immutable - это внешние константные для него данные (менять их в ядре ОС он не может, видит копию), и проблема ИМЕННО в том, что процесс увидел чужой стейт. Который должен был быть недоступен. Увы, иммутабельность не заменяет инкапсуляции - не всё то, что нельзя изменить можно видеть и использовать.
Вы не путаете "забыто" и "умерло"? Динозавры не забыты, но исчезли - не конкурентоспособны. Так и с ООП - оспорено множество раз, но живёт, а конкуренты - если они вообще без ООП - умирают. И я объяснил, почему - потому что ООП соответствует базису мышления человека. И да (и про это я там тоже написал) - реальное ООП неидеально и местами коряво. А теперь посмотрите на русский и английский язык - неидеальны и местами корявы. Посмотрите на понятийный аппарат среднего homo sapiens. На этот мир, вообще.
:)
Можно, вообще, отдельно обсуждать наследование интерфейса и реализации, и второе часто делается именно композицией.
Тут проблема вот в чём. Если бы ортогональность унаследованных интерфейсов была гарантирована и гарантировала бы ортогональность реализаций, то мир был бы прекрасен. В реальности сам факт того, что нам надо совместить два интерфейса означает, что реализация будет не "сложить вместе две реализации", а как-то их связать.
Вот я тоже почитал и подумал - Вас именно эти слова, что ли, бесят? Ну - полиморфизм - это общепринятое сокращение для "одно и то же сообщение может быть по-разному обработана разными объектами" - почему это так раздражает-то?
Потому что Вас раздражает само слово ООП?
Вот смотрите. Формально Вы совершенно правы - если всё вокруг
народноеimmutable - инкапсуляцию можно отменить, верно?Во-первых, неверно. Инкапсуляция, в том числе, скрывает трюки реализации, которые действительно знать нельзя. Мне один из сотрудников Микрософта рассказывал, что программисты просекли, что при старте процесса в Windows в каком-то регистре всегда лежит что-то полезное - какой-то дескриптор. И начали им пользоваться. А это значение там лежит случайно - валяется потому что последнее вычисление его использовало. Код скорректировали - и оно пропало. И Вы не представляете, на сколько денег влетел Микрософт, чтобы СИМУЛИРОВАТЬ это поведение для программ, которые от него сдуру зависят.
Отсюда некоторый максимализм, который иногда звучит в ООП - извне реализации даже классы желательно не использовать, только интерфейсы.
И вторая часть - ну, положим, мы такие заиньки, что трюки реализации ну никак не светятся. Не верится, но положим. Вот только есть беда - как обсуждаешь ФП формально, так в нём присваивания нет. А как реализация и конкретный код - так и сразу есть. И сразу - "это только критики ФП требуют от него идеального соответствия канонам, а мы, носители тайного знания, уже давно считаем, что присваивать можно". Это почти буквальная цитата из дискуссии.
Так что - можно бы
в райзаменить инкапсуляцию иммутабельностью, да грехи не пускают.Смотрите. Конкретизация до значений - это я немножко жёстко заявил, но дело в том, что наполнение поля значением тоже порождение дочернего класса, с некоторой точки зрения. Но можно не лезть в эти детали. Собственно, если трейты наследуются - то это ООП с множественным наследованием, а если не наследуются - это кабздец без реюза кода.
Э. Стоп. Это общепринятое определение. Его можно тоже снести, но тогда надо свое предложить. Я такой задачи перед собой не ставил.
Можно практически всё, но зачем? Наследование - способ структуризации и представлений о предметной области, и связанных с ним применимых к ней алгоритмов. Представить себе мир, где объекты компонуются из необъятного моря трейтов легко, но они же не будут ортогональны. Придётся сделать трейт "украдены у Зины" и трейт "украдены у Люси", вместо трейта "украдены у кого-то" и его конкретизации.
Я делал в своё время в Яндексе иерархическую ОО БД, в которой иерархия была именно и только иерархией наследования. То есть в ветке дерева можно было либо заявить новое свойство, либо зафиксировать значение заявленного выше свойства. Оказалось, что иерархия наследования самодостаточна и позволяет заменить собой иерархию хранения.
Это, конечно, немного взрывало мозг, но логика была безупречна. (Она делалась для Маркета) - на каждом уровне иерархии появлялись поля, актуальные для данного обобщения. И, кстати, множественное наследование работало и позволяло из "принтеры" и "сканеры" родить "МФУ".
Предполагается, что уж определения с первой страницы букваря читатель знает. :) Читателю, который этого не знает и сам вопрос, наверное, не очень интересен...
Насчёт "какой-то инстанс" Вы правы, но это и есть введение класса, по сути. Мы не знаем конкретных свойств этого инстанса (значений полей и даже конкретного класса). Ну, то есть, даже не знаем, кухонный это тейбл, или верстак.
Слова "издревле" и "линукс" несовместимы. Издревле существует Bell Labs Unix. Основных понятий в нём два. Процесс и файл.
Это проблема реализации ООП в ++. Собственно, поэтому в Java и большинстве последующих языков перегрузку операторов отменили.
Пример, конечно, неудачный. Метод можно поместить куда угодно если он не трогает потроха класса и у нас вообще нет наследования. Что явно вырожденный случай. Если наследование есть, и оно предполагает разную реализацию печати для разных принтеров или для разных документов - то расположение метода очевидно.
Ну а разные процессы - это объекты обёрнутые в JSON-ы, вроде бы так.
Это уж точно. :)
Кто-то же должен подвести черту :)
Где и как у Вас фраза "время обладает ценностью" превратилась в "каждое действие должно приносить прибыль"?
И как Вы, вообще, живёте, если в Вашей голове вот такие семантические преобразования проскакивают без страха и упрёка? И как Вы дожили до взрослого возраста ни разу не услышав фразу "время - деньги"? И смотрели ли Вы в детстве "Сказку о потерянном времени"? Ну прям вот я просто смотрю на эту феерию и теряю дар речи.