OberonCore :: - Аналог procedure of object в КП

Просто надо захотеть ее увидеть, для чего, в свою очередь, надо обязательо предположить, что не все, излагаемое коллегами является бредом сивой кобылы.
Если Вам это сделать затруднительно, ну или там проблемы со временем, то я, как уже отмечал выше - НЕ НАСТАИВАЮ.

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

А теперь попрошу задуматься над таким моим вопросом:
- а чем делегаты лучше-полезней-важнее... исключений... параллелизма в языке... векторно-матричных операций... шаблонов... ? По какому критерию именно их нужно добавить? Может, добавим всё? И куда денется совершенно уникальный язык вместе с "экосистемой" и культурой работы в его базисе?
Давно уже известно: - идя по пути добавления, крайне трудно остановиться, нет критериев. - введя что-то, убрать очень трудно.
- со временем в КП, наверняка, ещё что-то наоборот ужмётся. В плане ООП. Это был виток развития от Оберона, введение средств для построения компонентных каркасов. Виток успешен, обоснован, практичен. Но ещё не проходил через фазу критического упрощения, "экстракта"

Мне ЯВУ для другого нужен. Для лаконичного и надежного изложения своих мыслей, а не для записи их в виде ребусов.

Очень серьезные мотивы. И никакого отношения к Высоким Принципам не имеющие.
Обыкновенная (и правильная) боязнь, что у кого-то руки кривые.
Ну и конечно же - Вы мне Америку открыли... Да было бы Вам известно - это перманентное состояние любого КБ. Умение пойти по тонкой грани консерватизма и внедрения новых технологий - характеристика успешных предприятий

Всё верно и всё понятно Вы выше сказали.

Цитата:

Где декларировался приоритет только одного этого требования?
Просто "для лаконичного и надёжного изложения мыслей" люди придумывают языки более высокого уровня, чем императивные уровня КП, С++ и т.п. ФП и проч. Возможно, именно это Вам и нужно...

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

Но ведь как-то "оберонщики" обходятся без этого. Интересно, как :?:

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

Но ведь как-то "оберонщики" обходятся без этого. Интересно, как :?:

А вообще принципе - любая недоустранённая из систем, разработок, планов сложность - обязательно когда-нибудь выйдет боком. Об этом говорит Принцип Калашникова, который инженерный, в отличие от Оккама, который "теоретический".

А я так и не понял, об чем тут битва языков.

Но но ведь выше, сам же написал код, в котором одновременно используются две сущности для представления одного и того же: метод элемента как входной контакт разъема, и пару процедура+указатель на объект - как выходного контакта.

А там за него кто-то пишет компилятор. Навороченный. Со сложностью, "запаянной" в базовый софт.

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

В коде obj(Desk).player.Play(...) может ошибочно стоять наследник Desk-а (не специально, а вследствие описки по случаю многократно переписываемого кода), у которого у которого даже и player может быть, и метод Play на месте. Просто работать это будет в совершенно другом месте и контексте.
Защита пробита.

Info21 писал(а):

А я так и не понял, об чем тут битва языков.

Битва о том, надо ли в языке иметь процедурный тип, указывающий не только на простые глобальные процедуры, но и на на связанные с типом (т.е. методы). Переменным такого типа для работы не достаточно указателя на адрес процедуры, им надо ещё иметь скрытый указатель на экземпляр объекта. Чтобы можно было бы делать так:
VAR do: PROCEDURE {DELEGATE};
do := obj1.Do;
do(); (* вызывается obj1.Do *)
do := obj2.Do;
do(); (* вызывается obj2.Do *)

Зачем? Например, удобно делать обработчики событий без объявления промежуточных типов и обёрток. Типобезопасность не нарушается.

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

Перефразирую чуток свое же (ибо в репе таки чесал):

Galkov писал(а):

И вообразить нечто похожее на источнике от AO, или его расширении - не получается. Описка - отругает тебя компилятор, и всего делов

Так будем щупать Принцип Калашникова, или как :?:

Автор:	Илья Ермаков [ Среда, 22 Декабрь, 2010 11:33 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Цитата: Просто надо захотеть ее увидеть, для чего, в свою очередь, надо обязательо предположить, что не все, излагаемое коллегами является бредом сивой кобылы. Если Вам это сделать затруднительно, ну или там проблемы со временем, то я, как уже отмечал выше - НЕ НАСТАИВАЮ. Излагаемое является в контексте КП чистой утопией - "а вот если бы в КП были делегаты". КП есть такой, какой есть. Далее можно иметь два вердикта: - есть ли проблема, достойная внимания, в отсутствии в нём делегатов; - нет ли проблемы, достойной внимания. Кажется, я убедительно показал, что проблемы серьёзной нет. Я не берусь выносить вердикт по вопросу "лучше было бы всё-таки иметь в КП делегаты" ввиду отсутствия какой-то пользы в такой постановке вопроса. Может, и более ясное средство, а в реализации дешёвое. Но из-за этого никто не будет делать ревизии языка. А через N лет, когда ревизия будет, возможно, появятся делегаты. Однако вероятности в этом не очень много, потому что я не замечал у Оминк паттернов, в которых бы эти делегаты вылезали. А раз они не на виду - то и мысли о включении вряд ли возникнут. У меня паттерны, подобные показанному мной, проявлялись в системном софте, но там всегда выкручивался процедурными переменными.

Автор:	Alexey Veselovsky [ Среда, 22 Декабрь, 2010 11:35 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Да ладно, КП в ББ ведь не чистый, он ведь там с расширениями. Значит можно и ещё одно расширение прилепить если вдруг понадобится.

Автор:	Илья Ермаков [ Среда, 22 Декабрь, 2010 11:37 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Псевдомодуль? Но делегаты - не изолированное средство, оно сквозное. Они либо есть и "гуляют" по системе, либо их нет.

Автор:	Galkov [ Среда, 22 Декабрь, 2010 12:45 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Илья Ермаков писал(а): Кажется, я убедительно показал, что проблемы серьёзной нет. Вы убедительно показали, что можно решить любую задачу. Даже если если возникнут действительно какие-то заморочки в герметичности типов - можно придумать какую-нибуть процедурку работающею в SYSTEM и произнести магическую фразу: "в КП процедуры рулез". Но чего тут было показывать - это ясно с самого начала. Если это (синхронизовать объект и метод) в состоянии выполнить компилятор, то почему бы не выполнить в run-time... Ну подумаешь, что у всех белых людей это называется интерпретатором - они же в модульности ни фига не смыслят. Вы, действительно, очень убедительно показали, что читаемость языка (интерфейс пользователя) не является Показателем Назначения. По факту, а не по декларациям. Больших трудов стоило получить правду: Илья Ермаков писал(а): А теперь попрошу задуматься над таким моим вопросом: - а чем делегаты лучше-полезней-важнее... исключений... параллелизма в языке... векторно-матричных операций... шаблонов... ? По какому критерию именно их нужно добавить? Может, добавим всё? И куда денется совершенно уникальный язык вместе с "экосистемой" и культурой работы в его базисе? Давно уже известно: - идя по пути добавления, крайне трудно остановиться, нет критериев. - введя что-то, убрать очень трудно. - со временем в КП, наверняка, ещё что-то наоборот ужмётся. В плане ООП. Это был виток развития от Оберона, введение средств для построения компонентных каркасов. Виток успешен, обоснован, практичен. Но ещё не проходил через фазу критического упрощения, "экстракта" Очень серьезные мотивы. И никакого отношения к Высоким Принципам не имеющие. Обыкновенная (и правильная) боязнь, что у кого-то руки кривые. Ну и конечно же - Вы мне Америку открыли... Да было бы Вам известно - это перманентное состояние любого КБ. Умение пойти по тонкой грани консерватизма и внедрения новых технологий - характеристика успешных предприятий. Абсолютно консервативные предприятия умирают. Период полурапада - 8-10 лет. Все давно известно. Только IT-шники как всегда думают, что великие открытия совершают. Но можете не верить. Вот я заморочился с элементарным кодом (а может и Вы, я еще до конца не понял) - так в исполнении AO у меня к этому даже повода никакого нет. И я не призываю никого в это поверить. Не верите - не надо. Ибо сказано "Имеющий глаза - да увидит". Смотреть уже есть на что. А "распознавать паттерны" я и на асм-е смогу при необходимости. При этом, некоторые значительно понятнее будут, чем на КП. Мне ЯВУ для другого нужен. Для лаконичного и надежного изложения своих мыслей, а не для записи их в виде ребусов. И декларировалось-то именно ЭТО. Но теперь-то я знаю правду

Автор:	Илья Ермаков [ Среда, 22 Декабрь, 2010 17:47 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Всё верно и всё понятно Вы выше сказали. Цитата: Мне ЯВУ для другого нужен. Для лаконичного и надежного изложения своих мыслей, а не для записи их в виде ребусов. Где декларировался приоритет только одного этого требования? Просто "для лаконичного и надёжного изложения мыслей" люди придумывают языки более высокого уровня, чем императивные уровня КП, С++ и т.п. ФП и проч. Возможно, именно это Вам и нужно. Ваше желание иметь эффективную генерацию в код сегодня постепенно осуществляется. Вон Хаскеллевский компилятор показывает на некоторых задачках (правда, вполне конкретных) качество генерации лучше, чем С/С++. У нас же ещё принцип - иметь такой инструмент, который тривиален в реализации. Который лаконично и надёжно гарантирует, что будет происходить, а не просто "изложение мыслей". Я лично готов пожертвовать любой "лаконичностью" ради сохранения "тупости" инструментария.

OberonCore https://forum.oberoncore.ru/

Аналог procedure of object в КП https://forum.oberoncore.ru/viewtopic.php?f=29&t=2125	Страница 7 из 9

Автор:	Владислав Жаринов [ Четверг, 23 Декабрь, 2010 05:54 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Илья Ермаков в viewtopic.php?p=56023#p56023 писал(а): А теперь попрошу задуматься над таким моим вопросом: - а чем делегаты лучше-полезней-важнее... исключений... параллелизма в языке... векторно-матричных операций... шаблонов... ? По какому критерию именно их нужно добавить? Может, добавим всё? И куда денется совершенно уникальный язык вместе с "экосистемой" и культурой работы в его базисе? Илья Ермаков писал(а): Всё верно и всё понятно Вы выше сказали. Цитата: Мне ЯВУ для другого нужен. Для лаконичного и надежного изложения своих мыслей, а не для записи их в виде ребусов. Где декларировался приоритет только одного этого требования? Просто "для лаконичного и надёжного изложения мыслей" люди придумывают языки более высокого уровня, чем императивные уровня КП, С++ и т.п. ФП и проч. Возможно, именно это Вам и нужно... Вот что не помешало бы, если используем минимальный язык для конечного "человекочитаемого" программного описания - определить средство представления таких "неминимальных" вещей, как взаимодействие систем процессов, исключения и т.д., как язык более высокого уровня - и метод перевода с этого языка на конечный (ессно, с паттернами минимально-языковых конструкций)...

Автор:	Сергей Прохоренко [ Четверг, 23 Декабрь, 2010 10:15 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Драконограф писал(а): Вот что не помешало бы, если используем минимальный язык для конечного "человекочитаемого" программного описания - определить средство представления таких "неминимальных" вещей, как взаимодействие систем процессов, исключения и т.д., как язык более высокого уровня - и метод перевода с этого языка на конечный (ессно, с паттернами минимально-языковых конструкций)... Но ведь как-то "оберонщики" обходятся без этого. Интересно, как Если это есть в стандартной библиотеке, то по большому счету всё равно, где это будет: в самом языке или в стандартной библиотеке.

Автор:	Galkov [ Четверг, 23 Декабрь, 2010 11:09 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Сергей Прохоренко писал(а): Но ведь как-то "оберонщики" обходятся без этого. Интересно, как Смотрите, и увидите Вот Илья вспоминает Принцип Калашникова: "А вообще принципе - любая недоустранённая из систем, разработок, планов сложность - обязательно когда-нибудь выйдет боком.". Но но ведь выше, сам же написал код, в котором одновременно используются две сущности для представления одного и того же: метод элемента как входной контакт разъема, и пару процедура+указатель на объект - как выходного контакта. И никаких проявлений "чувства принципа Калашникова, заложенного в рефлексы" - не наблюдается. Типа: "... мы, волки, своим словам хозяева - сами слово даем, сами же его и обратно берем" В общем, как-то так. Примеров аналогичных-то применений полно по форуму...

Автор:	Info21 [ Четверг, 23 Декабрь, 2010 11:17 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
А я так и не понял, об чем тут битва языков. Вот Трурль умеет в одну строчку объяснить. Потом можно и поуточнять.

Автор:	Александр Ильин [ Четверг, 23 Декабрь, 2010 11:30 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Info21 писал(а): А я так и не понял, об чем тут битва языков. Битва о том, надо ли в языке иметь процедурный тип, указывающий не только на простые глобальные процедуры, но и на на связанные с типом (т.е. методы). Переменным такого типа для работы не достаточно указателя на адрес процедуры, им надо ещё иметь скрытый указатель на экземпляр объекта. Чтобы можно было бы делать так: VAR do: PROCEDURE {DELEGATE}; do := obj1.Do; do(); (* вызывается obj1.Do ) do := obj2.Do; do(); ( вызывается obj2.Do *) Зачем? Например, удобно делать обработчики событий без объявления промежуточных типов и обёрток. Типобезопасность не нарушается.

Автор:	Илья Ермаков [ Четверг, 23 Декабрь, 2010 11:41 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Цитата: Но но ведь выше, сам же написал код, в котором одновременно используются две сущности для представления одного и того же: метод элемента как входной контакт разъема, и пару процедура+указатель на объект - как выходного контакта. В случае с делегатами моя дальнейшая фраза не очень "контрастна", потому что реализация делегатов в компиляторе не сложна. Как раз потому, что случай "граничный", у нас такой горячий спор. Но, например, в случае шаблонов каких-нибудь или перегрузки контраст уже будет. Видите ли, этот "код, где две сущности" программист пишет сам. А там за него кто-то пишет компилятор. Навороченный. Со сложностью, "запаяной" в базовый софт. Лучше пусть программист вместо оператора "+" и шаблона напишет процедуры с длинным названием и несколько раз напишет подобный код, чем он получит проблемы усложнения семантики языка (например, вопросы импорта операторов - стоит только посмотреть на соотв. правила не на одну страницу даже в таком строгом языке, как Ада, чтобы расхотеть эти перегрузки; или совместное применение операторов и шаблонов в С++) и проблемы для разработчиков компилятора. Ведь проблемы разработчиков компилятора всегда бьют и по программисту. В виде ошибок, в виде малого числа надёжных вендоров, в виде невозможности при необходимости реализовать инструмент самому и т.п.

Автор:	Geniepro [ Четверг, 23 Декабрь, 2010 12:28 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Александр Ильин писал(а): Info21 писал(а): А я так и не понял, об чем тут битва языков. Битва о том, надо ли в языке иметь процедурный тип, указывающий не только на простые глобальные процедуры, но и на на связанные с типом (т.е. методы). Переменным такого типа для работы не достаточно указателя на адрес процедуры, им надо ещё иметь скрытый указатель на экземпляр объекта. Чтобы можно было бы делать так: VAR do: PROCEDURE {DELEGATE}; do := obj1.Do; do(); (* вызывается obj1.Do ) do := obj2.Do; do(); ( вызывается obj2.Do ) Зачем? Например, удобно делать обработчики событий без объявления промежуточных типов и обёрток. Типобезопасность не нарушается. Александр, да у Вас прямо талант объяснять! Я наконец понял о чём чешут языками в этой теме... Конкретно в данном примере возникает вопрос -- на что указывает do, если объект obj2 уничтожен? Или же его нельзя уничтожить, пока где-то висит ссылка на его метод Do? И ещё, вот конкретно в данном примере можно было бы вполне обойтись таким вариантом: Код:* VAR obj: SomeObject; obj := obj1; obj.Do(); (* вызывается obj1.Do ) obj := obj2; obj.Do(); ( вызывается obj2.Do *)

Страница 7 из 9	Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Автор:	Илья Ермаков [ Четверг, 23 Декабрь, 2010 12:50 ]
Заголовок сообщения:	Re: Аналог procedure of object в КП
Мы предлагаем систему, с рядом составляющих. В частности и в первую очередь, образовательных. Конкуренция - это хорошо, но когда конкурировать выходят тоже системы. Не имея альтернативной по комплексности и видению системы, выходить на равных правах спорить никогда не получится. Можно только указывать недостатки, но зачем обижаться, если далеко не все указания воспринимаются. В частности, они могут быть и справедливы, но их преодоление в рамках системы может быть нецелесообразным (потому что сбивает оптимальность по другим критериям). Поэтому такого рода указания на недостатки вообще не воспринимаются всерьёз, ибо смысла нет их воспринимать. Можно построить другую систему, в которой эти недостатки (с точки зрения критика) не будут присутствовать - ну так пусть сначала строят, а потом выходят сравнивать "в комплексе". А иначе горлопанство - "а вот у вас плохо" - "может, и плохо, но улучшение сделает только хуже" - "аааа, у них там плохо..." - но у "них-то" система, а против системы - только ополченцы с вилами, либо мастера-одиночки со специальными техниками "высшего пилотажа".