внедрив энергопроизводящие хлоропласты из водорослей в клетки хомяков хлоропласты, включенные в клетки животных, могут оставаться стабильными и непрерывно вырабатывать энергию независимо от условий окружающей среды
То есть хомячок допустим умер, а хлоропласты продолжают производить энергию. Вот как зомби-апокалипсис начнется - с зомби-хомячков.
Ну так это в другом абзаце было. Вы говорили про выражение "в соответствии с предложенным вами же критерием", я ответил в этом контексте. То есть вы вырываете фразы из контекста и пытаетесь что-то этим доказать.
Можем послать экземпляру этого класса сообщение #bark? Где тут контроль типов?
В наборе операций, которые можно сделать с объектом. Что вы можете послать и обработать, а что будет выдавать ошибку. По вашим же словам это является частью контроля типов.
В Smalltalk-е классы нужны именно для того, чтобы создавать новые объекты
Метод new можно прекрасно поместить вне класса, классы для этого не нужны. Можно сделать один класс Object с произвольным набором полей, как это сделано в начальных версиях JavaScript и PHP. Создавать новые объекты можно и с ним. Раз есть разные классы, значит они зачем-то нужны.
У вас по существу есть что сказать?
Я уже давно это сказал и неоднократно. Покажите пожалуйста пример кода на вашем гипотетическом языке, тогда я вам покажу сходства с ООП на сегодняшний день, сходства с моим примером на JavaScript, и возможные проблемы с этим кодом, которые люди стараются избежать использованием типизации. Потому что объяснения абстрактными словами вы не понимаете.
это неудобно людям, которые "haven't understood the concepts of smalltalk enough"
Вариант "have understood the concepts of smalltalk enough and do not like them" дает такой же результат. Но вы без всяких аргументов отказываетесь его рассматривать. Это говорит о том, что ваша логика неправильная.
О чём, например, свидетельствует очень низкий уровень интереса к попыткам привнести типы в Smalltalk
В изначально нетипизированном Smalltalk к типизации низкий уровень интереса, а в изначально нетипизированных JavaScript и PHP высокий. Уже два примера против одного. О чем это свидетельствует? Например, о том, что Smalltalk интересен малому количеству людей, и те, кому нужна типизация, используют другие языки. Это подтверждается большей распространенностью языков с типизацией. И даже среди использующих Smalltalk нашлись люди, которые захотели сделать Strongtalk.
Вы действительно считаете, что на вопрос "а классы они разве не типы?" допустимо отвечать "..."?
Нет. Поэтому я и не отвечал на этот вопрос таким образом. Я вообще на него не отвечал. Я отвечал на ваше утверждение про назначение типов и классов.
я уже дал ответ, обозначив назначение классов и типов. Как я понимаю, что-то в этом вас не устраивает? Что именно?
Я уже сказал - по общепринятым определениям ваши утверждения про назначение типов и классов неверны. Назначение типов и классов зависит не от вашего мнения, а от авторов языков программирования, которые их туда добавили. По известной информации их назначение не такое, какое говорите вы.
Утверждение про типизацию легко опровергается в соответствии с предложенным вами же критерием "Назначение классов — ограничивать программиста в выполнении операций над экземплярами этого класса. Если у класса нет метода "bark", то вы не сможете сделать с ним такую операцию." [Добавим обработчик для сообщения bark]
Ну так если вы добавили обработчик, значит вы сами решили не ограничивать, не так ли? Давайте теперь уберем код вашего метода. Будет ли ваш класс все еще выполнять выполнять операцию bark? Если не будет, значит вы ограничили вызывающий код в выполнении операций над экземплярами этого класса, не так ли?
Где тут контроль типов?
Мое утверждение про классы было "Назначение классов — ограничивать программиста в выполнении операций над экземплярами этого класса". Там нет выражения "контроль типов". Какие операции вы разрешили, такие он и будет делать. Как вы их разрешили, в рамках данной дискуссии совершенно неважно. Например, в PHP есть магический метод __call, он работает аналогично вашему примеру.
Не создание своих клонов, случайно?
Создание экземпляров нужно для любых типов данных, а не только для произвольных структур. Просто для некоторых (например integer) в языках есть встроенная поддержка. Поэтому нет ничего удивительного в том, что этот метод должен где-то быть. Ничего не мешало авторам Smalltalk сделать создание новых экземпляров integer тоже через new, просто видимо они посчитали это неудобным.
какой минимальный набор примитивов позволит "вырастить" полноценную объектную систему? О, да вы ещё и предсказываете будущее?
Нет, в вашем комментарии, на который я отвечал, есть фраза "там было бы минимум синтаксиса, если бы он вообще был".
Может быть попробуете, если не понимаете, сначала уточнять?
Я так сделал 2 комментария назад, вы отказываетесь отвечать на этот вопрос. "Ок, тогда можете подробнее объяснить, чем ваш гипотетический язык отличается от современного ООП?"
- можете подробнее объяснить? - Тут я удалил свои пояснения — захотите, спросите. Только я — вслед за вами :D — предсказываю, что вы не попросите комментариев
Я их уже попросил. Но вы опять сделали противоположное. Видимо, конструктивное обсуждение вам неинтересно.
и сделаете (неверный) вывод, о том, что это эквивалентно тому самому JS
Для программиста ваш код отличаются только синтаксисом. Как он работает на низком уровне, никакой роли для сложности поддержки не играет. Или по крайней мере ваш код это не демонстрирует. Поэтому да, в контексте сложности поддержки он эквивалентен, а именно это является причиной появления типизации и современного ООП.
Тут простая логическая цепочка - людям удобно ограничивать тип переменной (статически или динамически), иногда в качестве типа им нужны произвольные структуры данных (классы), они хотят переиспользовать уже заданные структуры (наследование).
- тогда можете подробнее объяснить - Очень кратко: ... Такой необъектной конструкцией, например, является возврат из метода — она не ложится на концепцию "посылки сообщений". - Во-первых, вы опять не поняли, о чём я говорил.
Ну так кто ж виноват в том, что вы решили ответить кратко?) Я вас просил объяснить подробнее.
то скажите, какой метод будет вызван здесь? object someMessage.
Если это Smalltalk, то не знаю, я с ним не работал. Насколько я понял из информации в Интернете, то обработчик либо someMessage, либо doesNotUnderstand. Вы опять вместо конструктивного обсуждения переводите разговор на другие темы, загадки какие-то загадываете.
а о том, чтобы в случае синхронной обработки сделать возврат именно сообщением. В таком случае, кто должен быть получателем этого сообщения и как он должен это сообщение обрабатывать
Я именно для этого случая и привел пример с вычислением синуса. Это вам надо подумать о том, как вы будете получать сообщение с результатом, чтобы использовать его в следующих вычислениях некоторого алгоритма.
Это вам в качестве подсказки к вопросам по примеру выше.
На эту подсказку я вам и намекал примером синуса. И именно поэтому уже неоднократно просил написать примеры кода. Потому что я вижу, что вы не видите сложностей, которые при этом возникнут.
class A {
function someAlgorithm(x) {
// y = sin(2*x) * 4;
tmp1 = x * 2;
tmp2 = Math.sin(tmp1);
tmp3 = tmp2 * 4; // <
return tmp3;
}
}
class Math {
function sin(x) {
// ... вычисление ряда для синуса
return res;
}
}
Теперь подумайте, как с посылкой соoбщений вместо return продолжить выполнение с точки tmp3 после вычисления синуса. Покажите, как будет выглядеть этот код. Если у вас многопоточное выполнение, как остановить выполнение в A на точке tmp2?
Я сам отвечать на эти вопросы не буду, хотя знаю ответ, потому что вы опять скажете, что я вас не так понял.
Отличаются от чего?
Это вас надо спрашивать, потому что это вы их привели как аналогию. Я лишь объясняю в тех терминах, которые вы предпочитаете использовать. При этом мои объяснения не зависят от того, что конкретно вы имели в виду, я умею работать с абстракциями. Отличаются от однопоточного монолита с библиотеками вместо микросервисов.
никакой тайпчекер не может запретить послать микросервису, пусть даже в рамках поддерживаемого микросервисом протокола, любое сообщение
Ну то есть мы все-таки пришли к коду, который я написал в первом комментарии - послать любому объекту любое сообщение без проверки типов. Поэтому непонятно, что вы пытались доказать на протяжении всего обсуждения. Отключить тайпчекер и не использовать типизацию можно даже в монолите, в этом у микросервисов отличия нет, о чем я и сказал. Надеюсь, вы еще не запутались в аналогиях.
и микросервис уже сам решит, как именно его обрабатывать: например, выдать ошибку или вызвать "основную" бизнес-логику.
Как я и сказал, это уже возможно в существующих языках. Можно делать в любом объекте метод send и обрабатывать там сообщения как захотите. У микросервиов тут нет отличия от не-микросервисов, что бы вы под этим ни подразумевали.
микросервис в принципе может поддерживать несколько протоколов для обмена сообщениями.
Если вы говорите именно про язык протокола, а не про язык программирования микросервиса, то тут опять же нет никаких отличий от не-микросервисов. Никто вам не мешает вызывать метод не так a.method(arg1, arg2), а вот так a.http('POST', 'method', JSON.stringify({'arg1': arg1, 'arg2': arg2})), где метод "http" своими механизмами будет вызывать метод "method". Просто при выполнении в одном процессе это не нужно.
Я тоже в курсе, что задавать вопросы проще, чем на них отвечать.
Не вижу никакой сложности ответить "В ООП на сегодняшний день делается так, а я хочу сделать вот так" и привести пример кода на несколько строк. Я так делал, это несложно. Если вам сложно привести примеры для своих собственных представлений о языке, то так и говорите. Совершенно незачем вместо этого пытаться принизить собеседника выражениями вида "Вы опять ничего не поняли, но объяснять я вам не буду".
То есть, вы не знаете, что я имел ввиду под "на сегодняшний мейнстримовым ООП", но при этом вы заявляете
Понятие "мейнстримовый" означает широко распространенное использование, а не ваше личное мнение. Я достаточно знаком с мейнстримовым ООП, чтобы понять примеры кода. Я предполагал, что вы достаточно умный человек, чтобы использовать термины в соответствии с общепринятым значением и не называть словом "мейнстримовый ООП" конструкции ассемблера.
Не знаете, о чём речь, но утверждаете, что что я получу именно это, так получается?
Да, потому что в вопросе "Есть ли у переменных типизация" только 2 варианта ответа, независимо от того, что вы имели в виду. И потому что есть причины, по которым люди пришли к типизации в виде современного ООП. Кроме того, я сказал это лишь в 4 комментарии, чтобы пояснить мою точку зрения и не ходить вокруг да около, так как вы сами на протяжении 4 комментариев отказываетесь отвечать, о чем речь.
и поэтому могу заявлять, что мои идеи про "дистиллированный ООП" от этого будет отличаться
Ну а я по вашим уклончивым ответам вижу, что вы не видите сложности, которые при это возникнут. Либо игнорируете их, о чем я и написал в первом комментарии.
будьте добры обосновать своё мнение. Сможете, или будете опять уходить от ответа?
Я уже его обосновал в рамках той информации, которую вы захотели сообщить. Хотите более подробных ответов, приводите более подробную информацию. Я совершенно не против вам ответить, и не буду уходить от ответа, как это делаете вы. Даже одного примера кода с вычислением синуса будет достаточно - код метода sin и код его вызова в середине некоторого алгоритма.
но делать это под руководством человека, который даже не собирается вникать в суть происходящего
Я с самого начала пытаюсь вникнуть в суть происходящего, но вы не хотите отвечать. В этом комментарии вы снова вместо обсуждения по существу решили придираться к формулировкам. В первом комментарии я сразу перешел к сути своих возражений и привел пример кода. А вы могли сказать "Ваш пример кода неправильный, правильный вот такой", но сами не захотели.
Так вы приведете примеры, как выглядит ваш гипотетический язык и чем он отличается от ООП, чтобы можно было обсуждать конструктивно, или конструктивная дискуссия вас не интересует?
Или какую цель вы перед собой в этом обсуждении ставите?
Показать вам, что ваш гипотетический язык либо будет так же сложен для других людей, как код без типизации, который я привел, либо он будет являться формой современного ООП. При этом в обоих вариантах то, что вы хотите сделать, уже есть в том или ином виде в существующих языках. При этом я допускаю, что предполагаю неправильно, просто считаю это вероятность небольшой.
Я не очень понимаю, что вы имеете ввиду под "современным" ООП.
Это вы употребили фразу "И в ООП (особенно в его настоящем виде, а не в том изуродованном, который на сегодняшний день стал мейнстримом)". "Современным" это синоним вашего выражения "на сегодняшний день". Поэтому у вас и надо спрашивать, что вы имели в виду.
- Ок, тогда можете подробнее объяснить - Очень кратко, так как вряд ли вас интересуют детали моих смутных фантазий.
Вообще-то про детали я и спрашивал.
- построить бы новый (абсолютно) чистый ОО-"язык" - чем ваш гипотетический язык отличается от современного ООП? - Вижу, как минимум, следующие направления дистилляции: ...
Описанное далее не является ответом на заданный вопрос. То есть опять уход от ответа. Если вы попробуете привести примеры, как это может выглядеть, то придете либо к моему примеру на JavaScript без типов, либо к ООП в том виде, который на сегодняшний день стал мейнстримом.
какой минимальный набор (необъектных) примитивов позволит "вырастить" полноценную объектную систему?
Как раз на это я привел пример кода. Там в синтаксисе используется минимум примитивов. Только типы все равно нужны, иначе любое сообщение будет просто набором байт. А без синтаксиса для задания строкового литерала вы даже распознать его не сможете.
Такой необъектной конструкцией, например, является возврат из метода — она не ложится на концепцию "посылки сообщений".
Вызов метода с аргументами и возврат результата из метода это один из вариантов реализации посылки сообщений. Другой вариант это использовать очереди сообщений, но тогда вместо конструкции возврата придется добавлять конструкции для работы с очередями, в том числе для ожидания результата. Примеры - Erlang или async/await. Без возврата результата в каком-то виде любой результат вычислений нельзя будет использовать, в том числе поместить в переменную.
В чём-то это может напоминает микросервисную архитектуру
Микросервисы отличаются только тем, что каждый микросервис работает в отдельном процессе. Вы конечно можете послать сообщение для вычисления синуса другому процессу, но вам будут нужны конструкции для ожидания результата. Event loop с async/await в JavaScript это однопоточная имитация такой параллельной работы. Или сообщения между процессами в Erlang, там многопоточность обеспечивается на уровне виртуальной машины.
Вы задавали вопросы? В вашем сообщении выше их не заметил.
Отвечать можно не только на вопросы, но и на утверждения, просьбы и возражения. Вы сделали утверждение "Я ответил, что у классов и типов разное предназначение". Я с ним не согласен. Я на него ответил возражением и привел примеры. Вы могли сделать то же самое в ответ на мои утверждения, если вы с ними не согласны.
В основном вы высказывали разные предположения о непреодолимых трудностях применения на практике "нормального" ООП.
Если под "нормального" вы имеете в виду Smalltalk, то я не говорил о непреодолимых трудностях. Я в курсе, что он существует и используется. Я сказал, что отсутствие типизации создает трудности. Они преодолимые, но людям обычно это неудобно, поэтому они добавляют типизацию там, где возможно.
Только желательно в форме вопросов
Ну ок. По каким причинам вы считаете, что у классов и типов разное предназначение, если класс это пользовательский тип, и они изначально именно для задания пользовательских типов и создавались? Приведите пожалуйста ссылки на источники, в которых поддерживается ваша точка зрения. (<- обратите внимание, это не вопрос, но на это высказывание можно ответить)
Олмстед поступила на онлайн-курсы педагогики в Центральном методистском университете. В начале осеннего семестра Олмстед отправила письменное домашнее задание по курсу, один из трёх конспектов по прочитанному, которые нужно было писать каждую неделю.
Тут не говорится про защиту, надо было только написать. Если нужно защищать, непонятно зачем вообще сдавать работу письменно, и тем более проверять на уникальность и ИИ, можно защитить просто с черновика.
Назначение классов — создавать объекты ("экземпляры соответствующего класса"). Назначение типов (данных) — ограничивать программиста в выполнении операций над значениями этого типа.
Назначение у них одинаковое, класс это пользовательский тип данных. Они изначально именно для этого и создавались. Создавать экземпляры разных классов, не имея контроля типов, бессмысленно и никому не нужно. Зачем создавать экземпляр класса User, если его можно передать в метод, который принимает тип Date?
Эти утверждения взаимозаменяемые. Назначение классов — ограничивать программиста в выполнении операций над экземплярами этого класса. Если у класса нет метода "bark", то вы не сможете сделать с ним такую операцию. Назначение типа — создавать экземпляры типа int. Создать экземпляр данных типа int без использования типа int невозможно.
Ок, тогда можете подробнее объяснить, чем ваш гипотетический язык отличается от современного ООП?
С моей точки зрения ООП недостает одной конкретной вещи - сужение ответственности вида "Rectangle -> Square", и соответствующие преобразования "r as Square". С обычным наследованием сужение ответственности в наследнике создает неудобства, и поэтому есть принцип подстановки Лисков, который это запрещает. Но это расширение возможностей ООП, а не что-то принципиально другое.
Когда до преподавателей наконец-то дойдет, что математически невозможно создать бесконечное количество уникальных и хороших текстов на заданную тему? После некоторого количества они будут либо похожие, либо плохие, либо далеко от темы. Чем больше текстов пишут студенты, тем больше их попадает в программы антиплагиата, тем меньше шансов у следующих студентов написать текст, который не похож ни на один из них.
Не знаю, что вы имеете в виду под слово "надоело", но вы мне написали только один комментарий с вопросами. Возможно, вы не следите, кому отвечаете. В ваших ответах другому собеседнику я не нашел описания других подробностей вашего "нового (абсолютно) чистого ОО-"языка"", поэтому возразил с учетом той информации, которую вы написали - обмен сообщениями с минимумом синтаксиса без классов.
О том, что процитировано в цитате - вы сказали, что хотите сделать язык без типизации, где любой объект может обработать любое сообщение, как в Smalltalk. Я сказал, что для этого не нужно изобретать новый язык, это легко сделать в JavaScript или любом другом языке с динамической типизацией. Только люди придумали TypeScript, потому что понимать и поддерживать такой код сложно для того, кто его не писал. И в умных книгах авторы по опыту советуют использовать типизацию где возможно.
Если же мы добавляем ограничения на структуру входящего сообщения, то это означает классы с набором полей, а это означает наследование, и получается современный ООП.
Я так пишу. И множество моих знакомых так пишет.
Ну так вы-то сокрушаетесь о том, что другие так не пишут, и используют современный ООП, а не как в Smalltalk-е.
я бы хотел взять за основу идею ООП (объекты и сообщения) там было бы минимум синтаксиса, если бы он вообще был но пока не доказана невозможность такого, 1% оставляет надежду.
Это давно уже есть.
var obj = {
send(anyMessage) {
console.log('do something with:', anyMessage);
let anyValue = ['abcd', 1, {data: 'data'}][Math.floor(Math.random()*3)];
return anyValue;
}
};
var r1 = obj.send('test');
var r2 = obj.send(2);
var r3 = obj.send(new Date());
console.log('response:', r1, r2, r3);
/*
do something with: test
do something with: 2
do something with: Date Tue Oct 29 2024 ...
response: Object { data: "data" } abcd 1
*/
Только почему-то так никто не пишет. Наверно по каким-то причинам людям это кажется неудобным?
Я думаю, права должны распространяться только на то, что человек сделал сам. Чем больше делает инструмент, тем меньше прав на результат имеет человек.
То есть представим, что он сказал тот же промпт группе художников, и они нарисовали ему эту картину. Имеет ли он право считаться автором изображения? Нет. А автором промпта да. При этом права на изображение могут принадлежать ему, если есть такой договор с художниками.
Уже есть понятие "производное произведение", в данном случае это оно и есть. ИИ сгенерировал, автор сделал его обработку. Решение может быть например таким. Для любого финального изображения указывается одно или несколько исходных, сгенерированных ИИ, при этом промпт автор может не раскрывать. На финальное изображение автор получает права, на исходные нет. Исходные регулируются условиями компании-производителя ИИ, обычно это свободный доступ для всех. Также так будет виден вклад автора.
С промптами отдельный вопрос. Чем он короче, тем больше вероятность, что другой человек может его случайно повторить. Тут примерно как с циклом по счетчику, большинство программистов напишет его одинаково, и скорее всего с переменной i, он не может быть объектом авторского права. Но программа в целом может. Тут надо учитывать разные факторы.
То есть хомячок допустим умер, а хлоропласты продолжают производить энергию. Вот как зомби-апокалипсис начнется - с зомби-хомячков.
А сможете сформулировать, в чем разница? В обоих случаях это JSON с данными, для которого нужен интерпретатор.
Первый код это измененная форма этого кода.
Это тоже конфиг или уже код?
Каким боком это low-code, если это самый настоящий код?
Тогда это тоже low-code.
Ну так это в другом абзаце было. Вы говорили про выражение "в соответствии с предложенным вами же критерием", я ответил в этом контексте. То есть вы вырываете фразы из контекста и пытаетесь что-то этим доказать.
В наборе операций, которые можно сделать с объектом. Что вы можете послать и обработать, а что будет выдавать ошибку. По вашим же словам это является частью контроля типов.
Метод new можно прекрасно поместить вне класса, классы для этого не нужны. Можно сделать один класс Object с произвольным набором полей, как это сделано в начальных версиях JavaScript и PHP. Создавать новые объекты можно и с ним. Раз есть разные классы, значит они зачем-то нужны.
Я уже давно это сказал и неоднократно. Покажите пожалуйста пример кода на вашем гипотетическом языке, тогда я вам покажу сходства с ООП на сегодняшний день, сходства с моим примером на JavaScript, и возможные проблемы с этим кодом, которые люди стараются избежать использованием типизации. Потому что объяснения абстрактными словами вы не понимаете.
Вариант "have understood the concepts of smalltalk enough and do not like them" дает такой же результат. Но вы без всяких аргументов отказываетесь его рассматривать. Это говорит о том, что ваша логика неправильная.
В изначально нетипизированном Smalltalk к типизации низкий уровень интереса, а в изначально нетипизированных JavaScript и PHP высокий. Уже два примера против одного.
О чем это свидетельствует? Например, о том, что Smalltalk интересен малому количеству людей, и те, кому нужна типизация, используют другие языки. Это подтверждается большей распространенностью языков с типизацией.
И даже среди использующих Smalltalk нашлись люди, которые захотели сделать Strongtalk.
Нет. Поэтому я и не отвечал на этот вопрос таким образом. Я вообще на него не отвечал. Я отвечал на ваше утверждение про назначение типов и классов.
Я уже сказал - по общепринятым определениям ваши утверждения про назначение типов и классов неверны. Назначение типов и классов зависит не от вашего мнения, а от авторов языков программирования, которые их туда добавили. По известной информации их назначение не такое, какое говорите вы.
Ну так если вы добавили обработчик, значит вы сами решили не ограничивать, не так ли?
Давайте теперь уберем код вашего метода. Будет ли ваш класс все еще выполнять выполнять операцию bark? Если не будет, значит вы ограничили вызывающий код в выполнении операций над экземплярами этого класса, не так ли?
Мое утверждение про классы было "Назначение классов — ограничивать программиста в выполнении операций над экземплярами этого класса". Там нет выражения "контроль типов".
Какие операции вы разрешили, такие он и будет делать. Как вы их разрешили, в рамках данной дискуссии совершенно неважно. Например, в PHP есть магический метод __call, он работает аналогично вашему примеру.
Создание экземпляров нужно для любых типов данных, а не только для произвольных структур. Просто для некоторых (например integer) в языках есть встроенная поддержка. Поэтому нет ничего удивительного в том, что этот метод должен где-то быть.
Ничего не мешало авторам Smalltalk сделать создание новых экземпляров integer тоже через new, просто видимо они посчитали это неудобным.
Нет, в вашем комментарии, на который я отвечал, есть фраза "там было бы минимум синтаксиса, если бы он вообще был".
Я так сделал 2 комментария назад, вы отказываетесь отвечать на этот вопрос.
"Ок, тогда можете подробнее объяснить, чем ваш гипотетический язык отличается от современного ООП?"
Я их уже попросил. Но вы опять сделали противоположное. Видимо, конструктивное обсуждение вам неинтересно.
Для программиста ваш код отличаются только синтаксисом. Как он работает на низком уровне, никакой роли для сложности поддержки не играет. Или по крайней мере ваш код это не демонстрирует. Поэтому да, в контексте сложности поддержки он эквивалентен, а именно это является причиной появления типизации и современного ООП.
Тут простая логическая цепочка - людям удобно ограничивать тип переменной (статически или динамически), иногда в качестве типа им нужны произвольные структуры данных (классы), они хотят переиспользовать уже заданные структуры (наследование).
Ну так кто ж виноват в том, что вы решили ответить кратко?) Я вас просил объяснить подробнее.
Если это Smalltalk, то не знаю, я с ним не работал. Насколько я понял из информации в Интернете, то обработчик либо someMessage, либо doesNotUnderstand. Вы опять вместо конструктивного обсуждения переводите разговор на другие темы, загадки какие-то загадываете.
Я именно для этого случая и привел пример с вычислением синуса. Это вам надо подумать о том, как вы будете получать сообщение с результатом, чтобы использовать его в следующих вычислениях некоторого алгоритма.
На эту подсказку я вам и намекал примером синуса. И именно поэтому уже неоднократно просил написать примеры кода. Потому что я вижу, что вы не видите сложностей, которые при этом возникнут.
Теперь подумайте, как с посылкой соoбщений вместо return продолжить выполнение с точки tmp3 после вычисления синуса. Покажите, как будет выглядеть этот код. Если у вас многопоточное выполнение, как остановить выполнение в A на точке tmp2?
Я сам отвечать на эти вопросы не буду, хотя знаю ответ, потому что вы опять скажете, что я вас не так понял.
Это вас надо спрашивать, потому что это вы их привели как аналогию. Я лишь объясняю в тех терминах, которые вы предпочитаете использовать. При этом мои объяснения не зависят от того, что конкретно вы имели в виду, я умею работать с абстракциями.
Отличаются от однопоточного монолита с библиотеками вместо микросервисов.
Ну то есть мы все-таки пришли к коду, который я написал в первом комментарии - послать любому объекту любое сообщение без проверки типов. Поэтому непонятно, что вы пытались доказать на протяжении всего обсуждения.
Отключить тайпчекер и не использовать типизацию можно даже в монолите, в этом у микросервисов отличия нет, о чем я и сказал. Надеюсь, вы еще не запутались в аналогиях.
Как я и сказал, это уже возможно в существующих языках. Можно делать в любом объекте метод send и обрабатывать там сообщения как захотите.
У микросервиов тут нет отличия от не-микросервисов, что бы вы под этим ни подразумевали.
Если вы говорите именно про язык протокола, а не про язык программирования микросервиса, то тут опять же нет никаких отличий от не-микросервисов. Никто вам не мешает вызывать метод не так
a.method(arg1, arg2), а вот такa.http('POST', 'method', JSON.stringify({'arg1': arg1, 'arg2': arg2})), где метод "http" своими механизмами будет вызывать метод "method".Просто при выполнении в одном процессе это не нужно.
Не вижу никакой сложности ответить "В ООП на сегодняшний день делается так, а я хочу сделать вот так" и привести пример кода на несколько строк. Я так делал, это несложно. Если вам сложно привести примеры для своих собственных представлений о языке, то так и говорите. Совершенно незачем вместо этого пытаться принизить собеседника выражениями вида "Вы опять ничего не поняли, но объяснять я вам не буду".
Понятие "мейнстримовый" означает широко распространенное использование, а не ваше личное мнение. Я достаточно знаком с мейнстримовым ООП, чтобы понять примеры кода. Я предполагал, что вы достаточно умный человек, чтобы использовать термины в соответствии с общепринятым значением и не называть словом "мейнстримовый ООП" конструкции ассемблера.
Да, потому что в вопросе "Есть ли у переменных типизация" только 2 варианта ответа, независимо от того, что вы имели в виду. И потому что есть причины, по которым люди пришли к типизации в виде современного ООП.
Кроме того, я сказал это лишь в 4 комментарии, чтобы пояснить мою точку зрения и не ходить вокруг да около, так как вы сами на протяжении 4 комментариев отказываетесь отвечать, о чем речь.
Ну а я по вашим уклончивым ответам вижу, что вы не видите сложности, которые при это возникнут. Либо игнорируете их, о чем я и написал в первом комментарии.
Я уже его обосновал в рамках той информации, которую вы захотели сообщить. Хотите более подробных ответов, приводите более подробную информацию. Я совершенно не против вам ответить, и не буду уходить от ответа, как это делаете вы. Даже одного примера кода с вычислением синуса будет достаточно - код метода sin и код его вызова в середине некоторого алгоритма.
Я с самого начала пытаюсь вникнуть в суть происходящего, но вы не хотите отвечать. В этом комментарии вы снова вместо обсуждения по существу решили придираться к формулировкам. В первом комментарии я сразу перешел к сути своих возражений и привел пример кода. А вы могли сказать "Ваш пример кода неправильный, правильный вот такой", но сами не захотели.
Так вы приведете примеры, как выглядит ваш гипотетический язык и чем он отличается от ООП, чтобы можно было обсуждать конструктивно, или конструктивная дискуссия вас не интересует?
Показать вам, что ваш гипотетический язык либо будет так же сложен для других людей, как код без типизации, который я привел, либо он будет являться формой современного ООП. При этом в обоих вариантах то, что вы хотите сделать, уже есть в том или ином виде в существующих языках. При этом я допускаю, что предполагаю неправильно, просто считаю это вероятность небольшой.
Это вы употребили фразу "И в ООП (особенно в его настоящем виде, а не в том изуродованном, который на сегодняшний день стал мейнстримом)". "Современным" это синоним вашего выражения "на сегодняшний день". Поэтому у вас и надо спрашивать, что вы имели в виду.
Вообще-то про детали я и спрашивал.
Описанное далее не является ответом на заданный вопрос. То есть опять уход от ответа.
Если вы попробуете привести примеры, как это может выглядеть, то придете либо к моему примеру на JavaScript без типов, либо к ООП в том виде, который на сегодняшний день стал мейнстримом.
Как раз на это я привел пример кода. Там в синтаксисе используется минимум примитивов. Только типы все равно нужны, иначе любое сообщение будет просто набором байт. А без синтаксиса для задания строкового литерала вы даже распознать его не сможете.
Вызов метода с аргументами и возврат результата из метода это один из вариантов реализации посылки сообщений.
Другой вариант это использовать очереди сообщений, но тогда вместо конструкции возврата придется добавлять конструкции для работы с очередями, в том числе для ожидания результата. Примеры - Erlang или async/await. Без возврата результата в каком-то виде любой результат вычислений нельзя будет использовать, в том числе поместить в переменную.
Микросервисы отличаются только тем, что каждый микросервис работает в отдельном процессе. Вы конечно можете послать сообщение для вычисления синуса другому процессу, но вам будут нужны конструкции для ожидания результата. Event loop с async/await в JavaScript это однопоточная имитация такой параллельной работы. Или сообщения между процессами в Erlang, там многопоточность обеспечивается на уровне виртуальной машины.
Отвечать можно не только на вопросы, но и на утверждения, просьбы и возражения.
Вы сделали утверждение "Я ответил, что у классов и типов разное предназначение". Я с ним не согласен. Я на него ответил возражением и привел примеры. Вы могли сделать то же самое в ответ на мои утверждения, если вы с ними не согласны.
Если под "нормального" вы имеете в виду Smalltalk, то я не говорил о непреодолимых трудностях. Я в курсе, что он существует и используется. Я сказал, что отсутствие типизации создает трудности. Они преодолимые, но людям обычно это неудобно, поэтому они добавляют типизацию там, где возможно.
Ну ок. По каким причинам вы считаете, что у классов и типов разное предназначение, если класс это пользовательский тип, и они изначально именно для задания пользовательских типов и создавались?
Приведите пожалуйста ссылки на источники, в которых поддерживается ваша точка зрения. (<- обратите внимание, это не вопрос, но на это высказывание можно ответить)
Тут не говорится про защиту, надо было только написать. Если нужно защищать, непонятно зачем вообще сдавать работу письменно, и тем более проверять на уникальность и ИИ, можно защитить просто с черновика.
Вы слишком часто уходите от ответа.
Я не являюсь адептом типизации. Я совершенно не против поменять точку зрения при наличии аргументов, только вы раз за разом отказываетесь их излагать.
Назначение у них одинаковое, класс это пользовательский тип данных. Они изначально именно для этого и создавались. Создавать экземпляры разных классов, не имея контроля типов, бессмысленно и никому не нужно. Зачем создавать экземпляр класса User, если его можно передать в метод, который принимает тип Date?
Эти утверждения взаимозаменяемые.
Назначение классов — ограничивать программиста в выполнении операций над экземплярами этого класса. Если у класса нет метода "bark", то вы не сможете сделать с ним такую операцию.
Назначение типа — создавать экземпляры типа int. Создать экземпляр данных типа int без использования типа int невозможно.
Ок, тогда можете подробнее объяснить, чем ваш гипотетический язык отличается от современного ООП?
С моей точки зрения ООП недостает одной конкретной вещи - сужение ответственности вида "Rectangle -> Square", и соответствующие преобразования "r as Square". С обычным наследованием сужение ответственности в наследнике создает неудобства, и поэтому есть принцип подстановки Лисков, который это запрещает. Но это расширение возможностей ООП, а не что-то принципиально другое.
Может быть надо подумать о том, что сам метод проверки неправильный, потому и результат соответствующий? Сочинения за деньги и раньше писали.
Когда до преподавателей наконец-то дойдет, что математически невозможно создать бесконечное количество уникальных и хороших текстов на заданную тему? После некоторого количества они будут либо похожие, либо плохие, либо далеко от темы. Чем больше текстов пишут студенты, тем больше их попадает в программы антиплагиата, тем меньше шансов у следующих студентов написать текст, который не похож ни на один из них.
Не знаю, что вы имеете в виду под слово "надоело", но вы мне написали только один комментарий с вопросами. Возможно, вы не следите, кому отвечаете. В ваших ответах другому собеседнику я не нашел описания других подробностей вашего "нового (абсолютно) чистого ОО-"языка"", поэтому возразил с учетом той информации, которую вы написали - обмен сообщениями с минимумом синтаксиса без классов.
О том, что процитировано в цитате - вы сказали, что хотите сделать язык без типизации, где любой объект может обработать любое сообщение, как в Smalltalk. Я сказал, что для этого не нужно изобретать новый язык, это легко сделать в JavaScript или любом другом языке с динамической типизацией. Только люди придумали TypeScript, потому что понимать и поддерживать такой код сложно для того, кто его не писал. И в умных книгах авторы по опыту советуют использовать типизацию где возможно.
Если же мы добавляем ограничения на структуру входящего сообщения, то это означает классы с набором полей, а это означает наследование, и получается современный ООП.
Ну так вы-то сокрушаетесь о том, что другие так не пишут, и используют современный ООП, а не как в Smalltalk-е.
Это давно уже есть.
Только почему-то так никто не пишет. Наверно по каким-то причинам людям это кажется неудобным?
Я думаю, права должны распространяться только на то, что человек сделал сам. Чем больше делает инструмент, тем меньше прав на результат имеет человек.
То есть представим, что он сказал тот же промпт группе художников, и они нарисовали ему эту картину. Имеет ли он право считаться автором изображения? Нет. А автором промпта да. При этом права на изображение могут принадлежать ему, если есть такой договор с художниками.
Уже есть понятие "производное произведение", в данном случае это оно и есть. ИИ сгенерировал, автор сделал его обработку. Решение может быть например таким. Для любого финального изображения указывается одно или несколько исходных, сгенерированных ИИ, при этом промпт автор может не раскрывать. На финальное изображение автор получает права, на исходные нет. Исходные регулируются условиями компании-производителя ИИ, обычно это свободный доступ для всех. Также так будет виден вклад автора.
С промптами отдельный вопрос. Чем он короче, тем больше вероятность, что другой человек может его случайно повторить. Тут примерно как с циклом по счетчику, большинство программистов напишет его одинаково, и скорее всего с переменной i, он не может быть объектом авторского права. Но программа в целом может. Тут надо учитывать разные факторы.
Если вы про меня, то видимо вы так и не поняли, о чем идет речь. С фотографией это совершенно никак не связано.