OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 14 Декабрь, 2017 12:59

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 93 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 12 Октябрь, 2017 16:15 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1427
Тогда я совсем перестал понимать что представляют из себя интерфейсы в модуле 3.

Partial Types - это же просто раскидать по файлам.
Это и в Go можно (просто немного иначе).

А интерфейсы у объектов то есть? Или там модуль - это объект?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 12 Октябрь, 2017 19:49 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 410
Интерфейс ОБЪЕКТА в М3 это подтип некоторого типа, то есть тип содержит все, определенные для него подтипы. Тип в М3 можно сужать, образуя подтип(интерфейс например), который служит для тогоже, что и интерфейсы в других яп, для инкапсуляции, для создания иерархий и тп, и открывать -revelation, для реализации. Какие подтипы будут включены в окончательный тип определяется сборочным скриптом. Клиенты в дальнейшем импортируют конкретный интерфейс и видят только то, что позволено. Инкапсуляция без протечек.Интерфейс - это часть, объектного типа, находящаяся в интерфейсном модуле, понятно, что один интерфейс могут разделять множество объектных типов. Интерфейс, еще раз - это подтип, он сужает видимость типа, но сам по-себе это такой же тип данных и его можно использовать и передавать в него объекты совместимых типов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 12 Октябрь, 2017 21:50 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1427
Kemet, кусок кода нужен для ясности

add:
сам нарыл: http://www.angelfire.com/tx4/cus/shapes/modula3.html


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 13 Октябрь, 2017 06:20 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 410
ilovb писал(а):
Partial Types - это же просто раскидать по файлам.

Нет, не только раскидать, в этом мало смысла. Смысл в инкапсуляции. Получившиеся "частицы типа" это же суть интерфейса к объекту. Можно объявить переменную с таким partial type. И использовать только предоставленный интерфейс( вернее частицу ), хотя там и лежит экземпляр полного типа.
То есть partial types позволяют сужать доступ, разделять на логические части.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 13 Октябрь, 2017 20:10 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
prospero78 писал(а):
Динамические языки, аля питон -- обладают строгой типизацией. Если это целое -- то это целое, и никакая не строка. Но если сделаем принудительное приведение -- опля -- и уже строка!) И этим динамическая типизация страшна.

В дополнение, часто в скриптовых языках увлекаются "гибкостью" и перегружают операции в стиле "a*n", где a - строка, n - число. Ошибся с типами, подразумевая умножение двух чисел, в результате нет ошибок (исключений) и образуется строка, т.к. "умножение" вызывает ф-цию аля replicate -- "ab"*3 => "ababab" (возможно при сохранении результата, т.е. при присваивании, обнаружится несостыковка. дай Бог).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 13 Октябрь, 2017 20:23 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
Предлагаю взглянуть на эту работу:
CZ: Multiple Inheritance Without Diamonds

Там разобраны основные популярные техники (но не все) организации интерфейсов как обобщённых алгоритмов, а именно: множественное наследование, "trait" (абстрактные типы, "типажи" как в Rust, классы типов как в Haskell, протоколы, прототипы, интерфейсы), "mixin" ("подмешивания", "примеси"). Указаны ключевые проблемы, и предложен свой вариант реализации множественного наследования с предохранением от классических граблей от "ромбов". Прежде всего -- проблемы с конструкторами данных. Ну и с именами конфликтующих элементов, хотя здесь принципиально решений всяких много, а то даже шире -- как в Scala с "path-dependent types", здесь кратко пример (если концепция незнакома):
http://danielwestheide.com/blog/2013/02 ... types.html

В двух словах. Выделяются две семантические языковые роли у типа-класса: как единица (повторного) использования и как единица создания экземпляров-объектов. Абстрактные классы лишь в первой роли, однако могут содержать свои данные (ессно и операции), но не могут вызывать конструкторы данных и "требуют" организацию инициализации у своих потомков. Введено два ключевых слова: require -- понятие лишь субтипа, extends -- в т.ч. и субкласс (т.е. и возможность создания экземпляров). Имеется некий контроль типов (недопущение ромбов-субклассов), определена политика диспетчеризации мультиметодов (особенно см. гл.5 "Example: Abstract Syntax Trees").
В общем, техника максимально близка к "классическому" ("статическому") ООП.

В IT также имеется и "динамическое" ООП. В качестве примера (диалект ML для генерации С++):
objects: http://felix-lang.org/share/src/web/tut ... index.fdoc
polymorphism: http://felix-lang.org/share/src/web/tut ... index.fdoc

Первая ссылка -- вариант ОПП в "прототипном" стиле (аля JavaScript, решений для Lua и т.п.). Фактически -- абстракция над записями (record или структуры), позволяющая динамически создавать/удалять "потомков". Только одиночное наследование -- каждый тип подразумевается как роль, объект в целом обладает множеством ролей. Интерфейсы как в Java, или аля как было в COM. Возможна не только "реализация" интерфейса в типе, но и "преобразование" типа для интерфейсной переменной (в общем случае её можно понимать как структуру с указателями на функции). Интерфейс может быть определен (составлен) без оглядки на реальные структуры объектов, их иерархию и т.д. (там даже есть примеры, когда в одной подсистеме (программе, или аля DLL) объекты "живут" по-своему согласно своим типам, а в другую подсистему передаются для взаимодействия уже под нужными интерфейсами согласно местной "точки зрения" в данной системе). Чтобы не было "случайных утиных" типов требуется явное приведение типа (разработчик "номинативно" подтверждает семантику).

По второй ссылке выше -- классы типов аля Haskell (ну и там попутно примеры насчёт полиморфизма с ограничениями типов, включая понятие множества типов). Или же это trait-и без данных согласно статейке выше про проект CZ. Ключевое -- только статическая диспетчеризация типов. Здесь, в отличие от понимания интерфейса, уже семантически подразумевается возможность указания реализации по умолчанию, ограничений (в т.ч. и как "серый или белый ящик", когда в интерфейсах возможны лишь требования как к "чёрному ящику"). Т.е. здесь классы -- единицы использования или реализации (но без своих данных), интерфейсы выше -- некие единицы взаимодействия.
Фактически, в данном случае классы всего лишь обвёртки над статической перегрузкой функций по типам. В целом там все функции перегружаются по типам и арности, в отличие от того же Haskell-я. Но последствие -- затруднителен автоматич. вывод типов -- фактически приходится указывать сигнатуры типов функций явно (что даже хорошо в масштабных проектах, или же без сигнатуры подразумеваются абстрактные типы-"generic"-и), внутри функций локальные автоопределения типов вполне возможны.

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

Однако конкретно в данном случае в классах типов имеются универсальные недостатки, впрочем как и во многих популярных языках/платформах с trait-ами, не имеющих данных (а те, которые имеют -- абстрактные классы, разобранные в CZ, в той же статье указано и о проблемах trait-ов без данных). На примере того же Rust -- ниже ссылка на предложение ввести в trait-ы виртуальные поля данных:
https://github.com/nikomatsakis/fields- ... -traits.md

Кроме конкретных технических нюансов данной платформы (некоторые проблемы с типизацией, "borrow checker") в целом без виртуальных полей возникает потребность явно вводить всякие функции-"accessor"-ы (и соответственно их реализовывать), к тому же семантически необходимо их как-то всё-равно выделять и разруливать политику public/ptotected или private, понимая, что касается именно реализации, а что именно доступа со стороны клиентов будущего типа.
Т.е., растут аппетиты, хочется чего-либо аля "mixin", как во всяких скриптовых языках или вот на примере языка D -- текст примерчика (просто под руку попался) выложили в каментах к статье опять же вокруг Rust-а:
https://habrahabr.ru/post/309968/#comment_9808142

Но в D есть некая каша -- "binding" полей косвенный через совпадение имён (может и есть какое-то явное управление), наблюдается прямая инициализация собственного состояния (однако нюансов не знаю, возможно автоматом ничего не исполняется в плане вызова конструкторов). В статейке про CZ хорошо разложено, почему инициализацией должны управлять только лишь "единицы создания экземпляров" -- иначе множественное наследование не разрулить. Отсюда, кстати, не получится соблазн -- иметь "типаж" (trait) как абстрактный тип, но при случае он же может быть и полноценным типом (т.е. trait как полноценный готовый type). Однако реализация (использование) trait-а м.б. тривиальной -- добавить инициализацию.
Поэтому в целом логично, если в trait-ах будут лишь виртуальные структуры. Правда, язык должен быть по-удобнее, в дополнение к стилю (аля как предлагается в Rust):
Код:
trait Trait {
    field1: Type1,
    field2: Type2;

    fn foo();
}
...
impl Trait for Type {
    field1: self.foo.bar,
    field2: self.baz
}

не помешают и прочие стили параметризации аля ML, напр., как "аргументы":
Код:
trait Trait(field1: Type1, field2: Type2) {
    fn foo();
}
...
struct Type {
    ...
    impl Trait(self.foo.bar, self.baz) {
        fn foo() => ...
    }
}

(trait-ы рекурсивно по своей иерархии передают параметры или инициализируют их явно, типы-кортежи для вирт. полей или параметров, ессно, могут определяться отдельно). Нужны и прочие фишки, как partial-определение типов (подключение функционала по потребности).
Кстати, стоит принципиально отличать подобные "типажи" от "наследования" в виде "embedding" как в Go ("композиция" со включением полей плюс автоматом полученный интерфейс наружу с неким разруливанием имён):
https://github.com/luciotato/golang-not ... ter/OOP.md

В общем, такая общая картина.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 13 Октябрь, 2017 20:26 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
У меня об Обероне слабые представления, особенно насчёт runtime-meta системы. Не знаю, насколько удобна или целесообразна потенциальная реализация неких интерфейсов, к примеру, по мотивам "фасетов" ранее здесь в теме. Если в языке нет базовых конструкций, то, скорее всего, придётся строить что-то вроде "прототипного" ООП на процедурах и структурах, может быть в стиле множественного наследования как в CZ выше.

В качестве, как минимум, "математической постановки" есть смысл взглянуть на вариант "структурной типизации" в виде "row polymorphism" (последняя статья про реализацию "записей" с поддержкой множества вариантов "полей" -- те же "гибкие объекты"):

Objects and Aspects: Row Polymorphism
Row Polymorphism Isn't Subtyping
Extensible records with scoped labels


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 14 Октябрь, 2017 11:33 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1049
Откуда: СССР v2.0 rc 1
Безусловно, всё это сделать в Обероне можно. Он достаточно прост для таких задач.
Вопрос только, зачем? Простота -- залог здоровья. Борис, на самом деле, хорошие темы цепляет. Только, имхо, не может вылезти из колеи толстых и наглых))


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Октябрь, 2017 18:47 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
prospero78 писал(а):
Вопрос только, зачем? Простота -- залог здоровья.

Так ведь абстрактные операции и нужны для упрощения реализации сложных вещей. Их проблематика была разобрана ранее здесь в теме в рамках этой публикации:
viewtopic.php?f=30&t=6131&start=20#p102274
viewtopic.php?f=30&t=6131&start=40#p102355

Там речь об универсальных сообщениях и их специализации для конкретных объектов (типов). Иными словами -- перегрузка операций (со всеми семантическими оттенками, напр., операция draw может быть как у типа Shape, так и у Cowboy. Или же интерфейс Stack может отличаться в зависимости от семантики реализации (bounded или unbounded) и т.д.).

Как раз в тему, обратил внимание по соседству на проект oberonjs и на предлагаемые там расширения:
https://github.com/vladfolts/oberonjs/wiki/Eberon

Показательна пара моментов. Во-первых, для ООП введено понимание методов, конструкторов, SELF и SUPER -- уже облегчение перегрузки операций в потомках. Не помешает "расширение" (наследование) и самих экземпляров-объектов (не только типа), как было представлено выше в рамках Felix:
http://felix-lang.org/share/src/web/tut ... index.fdoc

А если ввести и подобные интерфейсы (по той же ссылке выше), то, как минимум, в ряде случаев ликвидируется типовой недостаток предлагаемого стандартного паттерна "generic message bus", как он указан, напр., здесь:
https://github.com/vladfolts/oberonjs/w ... -Narrowing

Из-за упрощения, как я понимаю, в Оберон-е не введены "перечисления", и, по сути, определен паттерн "открытых перечислений". В таком случае у компилятора нет возможности контролировать операции тестирования (и приведения) типа -- все ли учтены варианты (особенно после рефакторинга типов), как в рамках классического "pattern matching" во многих языках. "Интерфейсы" же ещё на этапе компиляции контролируют типобезопасность (имеется ввиду, прежде всего, применение объектов "интерфейсного" типа в подобных случаях).

И обращает внимание в проекте oberonjs введенный тип STRING:
https://github.com/vladfolts/oberonjs/w ... on-Strings

Именно отсутствие удобных средств перегрузки операций вынуждает подобные решения реализовывать на уровне языка или компилятора, а не как библиотеки. На сегодня в IT уже отшлифованы принципы переопределения, в т.ч. и в случаях сложных правил, к примеру, как для математических функций/операторов. Напр., в Julia -- удобные соглашения или стандартные операции приведения/оценки типов -- паттерн "сonversion and promotion" (плюс понимание абстрактных классов или интерфейсов, типажей и т.п.):
https://docs.julialang.org/en/stable/ma ... promotion/

Подкрепляются возможности прочими приёмами полиморфизма, как множества типов, функции типов -- опять же на примере выше в рамках Felix:
http://felix-lang.org/share/src/web/tut ... index.fdoc

Перегрузки опасны неявные, непреднамеренные. К примеру, в некотором scope пользовались функцией аля:
f(x: double): double => ...

, которая может принимать и int. Затем после изменений косвенно в scope попадает новая функция вида:
f(x: int): int => ...

, которая незаметно "перетянет" на себя "int"-применение. Однако в целом в IT решения известны, в том же Pascal-е для явности требуется указание "overload" (как и "override"), или же в Felix выше перегрузки контролируются через "open" и "close" (прежде всего для "классов типов". И в целом видится, что использование принципа "закрытия" (close) позволяет контролировать "безопасность" -- к примеру, "закрывать" (в сборочных файлах) для определенного пространства имён модулей некоторые группы перегрузок, в т.ч. какие-то "системные" или "виртуальные" -- не давать возможность использования "опасных финтов").

В общем, профит от абстрактных типов есть, причём вполне не сверхсложно и, главное, контролируемо.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Октябрь, 2017 22:41 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2448
Откуда: Россия, Ярославль
Жаль, что я не веду статистики со ссылками, но каждый раз вижу, как открытая возможность улучшить "что-то" в Обероне порождает улучшательский раш у аудитории, и уже не спастись, коготок увяз, каждый пункт сообщения о языке подвергается пересмотру с учетом современных тенденций и обязательно приводит к упрощению, улучшению, облегчению и вообще. Еберон, проект-издёвку (кто помнит историю создания, тот понимает) уже приводят в пример, мда.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Октябрь, 2017 19:05 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
Я не пользователь Оберон-платформы, не в курсе, что Еберон -- "издевательство" над Обероном (хотя странно как-то, но мне неизвестны политические заморочки и в таковы не лезу).
Выше были лишь доводы насчёт абстрактных типов в целом, и особенно с полной поддержкой со стороны компилятора (и их семантическая первичная проблематика не зависит от конкретного языка).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Октябрь, 2017 19:15 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
Кстати, насчёт библиотечного решения как runtime-полиморфизма (или "фасетов" здесь ранее) -- вспомнилась "классика" -- мультиметоды в lisp, а в Clojure ещё и упрощённые "классы типов" (интерфейсы-типажи или там это "протоколы") реализованы. Здесь кратко обо всём:
http://alexott.net/ru/clojure/clojure-intro/#sec15

Там по ссылке ещё указано примечание по поводу реализации методов по умолчанию:
http://fulldisclojure.blogspot.com/2010 ... ocols.html

Если есть возможность (ну и потребность) с помощью каких-то хаков выстраивать подобные декларации, то стоит обратить внимание -- принципы давно опробованы, API устоявшееся и т.д.

И заметил уточнения, что конкретно имелось ввиду под "утиностью":
viewtopic.php?f=12&t=6127&p=102197#p102186

В таком стиле, как в Go, отсутствует строгая статическая типизация в интерфейсах, о чём, видимо, и был здесь спор ранее. Согласно примеру по ссылке, если интерфейсы определены независимо (и пусть хоть в разных модулях), то это не только технически, но и, прежде всего, семантически разные интерфейсы (если явно не определено иное). Ранее здесь в статейке вокруг "Lagoonа" на таком моменте акцентировалось -- конкретный пример со Stack -- некоторые операции с одинаковой сигнатурой, но в целом интерфейсы подразумевают разную политику стека, т.е. разную семантику (и для операций определяются разные требования/ограничения):
http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf

Для безопасной утиной типизации необходимо решение как в Haskell -- если функция определена в интерфейсе (классе типа), то она там насмерть прикрепляется -- в ином интерфейсе (или вне интерфейсов) другой функции с таким именем быть не может (что вынуждает заниматься именами, обычно прикручивать всякие суффиксы). А если необходима гибкость перегрузок (как в Felix здесь по ссылкам выше в сообщениях), то необходимо всегда явно указывать конкретику (что именно и где наследуется, реализуется, явное приведение типа и т.д., для чего нужны и соответствующие облегчающие синтаксические средства).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 20 Октябрь, 2017 21:25 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
Жаль, что отличные идеи не приживаются в Оберон-платформе -- речь о соседней теме насчёт обобщённых типов:
viewtopic.php?f=30&t=5366

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

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

Также необходима какая-то модуляция для параметров, т.к. одни и те же параметры разделяются для некоего множества деклараций. В общем, пример на Rust -- "ассоциированные типы" по мотивам ML:
http://rurust.github.io/rust_book_ru/sr ... types.html

Причём упрощения, имеющиеся в Rust, и даже терминология: тип, типаж -- что там сверхсложного-то? Даже концепция "типажей-объектов" -- оперирование "интерфейсами" через указатели -- отлично вписывается в концепцию дженериков, предлагаемые для Оберона:
http://rurust.github.io/rust_book_ru/sr ... jects.html

В итоге бы, согласно дискуссии в соседней теме, можно было бы поступать примерно по таким мотивам (псевдо-код поближе к ML для краткости):
Код:
Определяем типаж с функцией для оценки какой-то толерантности в численных алгоритмах:

trait Tolerance[t] {
    fn check_tol(x: t): bool;
}

Пусть будет некий алгоритм, который использует функцию check_tol,
и этот факт фиксируется в виде требования для параметра типа,
который должен быть также "наследован" и от абстрактных вещественных чисел

fn some_algo[t](v: vector[t]): t where AbstractFloat[t], Tolerance[t];
fn some_algo(v) => ...;

Пусть в другом модуле, использующем алгоритм выше,
уточняется типаж в виде добавления реализации
ф-ции check_tol по умолчанию.
Здесь параметр tol -- как виртуальное поле данных

partial trait Tolerance[t](tol: t) {
    fn check_tol(x: t): bool => (x == 0) or (x <= tol);
}

Теперь "открываем" типаж для двух необходимых типов
(const_spec -- какая-то константа)

open trait Tolerance[double](0.001);
open trait Tolerance[complex](const_spec);

Можем использовать алгоритм аля:

var
  v: vector[double];
  d: double,
...
d = some_algo(v);

Конечно же, кому необходим такой функционал может выкрутиться через "умные макросы":
viewtopic.php?f=30&t=5366&start=20#p100049

Как раз выше были ссылки на решения в Clojure с отточенным API, но в итоге "лисп" и получится, причём вряд ли такой удобный как в оригинале, будет нечто:

macro.deftrait(:Tolerance);
macro.deftrait_fn(:Tolerance, :check_tol);

и т.п., где-то будет реализована процедура check_tol с какими-то спецтипами, внутри check_tol свои макросы и ..., в общем пока трудно представить картину.

Вместо "шаблонного языка", муторного в стиле C++, для оценки типов и манипуляций с ними есть отличные решения: функции типов -- на примере ранее упоминавшегося здесь Felix (диалект ML для скриптинга и кодогенерелки на C++):
http://felix-lang.org/share/src/web/tut ... sm_01.fdoc
множества типов:
http://felix-lang.org/share/src/web/tut ... sm_02.fdoc

Для компенсации отсутствия "pattern matching"-а и операторов вида if, case, возвращающих значения (т.е. не как statement), достаточно популярных типовых функций вида iif, decode (известных в скриптовых языках, SQL и пр.). К примеру:
Код:
Пусть typedef -- как функция типа, только в рамках формул вида:

typedef mytype(a: type): type =
  decode(a,                // с чем сопоставляем
         int, my_rec1,     // вариант и результат
         float, my_rec2,   // ...
         my_rec3           // иначе
  );

Можем задавать тип:

var n: mytype(int);


Подобные compiletime-вычисления необходимы в разных местах (к примеру, определение констант и т.п.). "Вариативные шаблоны", видимо, возможны как в C++ (параметры с многоточием), но как-то по-проще (лишь вариант с перегрузкой функции):
https://ru.wikipedia.org/wiki/%D0%92%D0 ... 0%BE%D0%BD

В статье про "умные макросы" в качестве примера предлагается для задач вокруг SQL использовать специальные текстовые инъекции (вида типового embedded SQL). Однако с дженериками гораздо гибче можно выстроить API (и это именно обычные языковые средства) в стиле:

sql_statement := sql.build(...).from(...).select(...);
if (...) then sql_statement.where().add(...);

А если бы ещё была бы перегрузка операторов, то вместо:
sql_statement.where().add( sql_val.GrEq(other_val) )

было бы нормальное:

sql_statement.where().add( sql_val >= other_val )


Жаль, что в большинстве случаев подобные техники воспринимаются здесь как "улучшательский раш" да "издёвка".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 20 Октябрь, 2017 22:21 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1015
PSV100 писал(а):
Я не пользователь Оберон-платформы

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 20 Октябрь, 2017 23:43 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7726
Откуда: Троицк, Москва
Философия тут не виноватая.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 21 Октябрь, 2017 13:42 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2448
Откуда: Россия, Ярославль
PSV100 писал(а):
Жаль, что отличные идеи не приживаются в Оберон-платформе <...> Жаль, что в большинстве случаев подобные техники воспринимаются здесь как "улучшательский раш" да "издёвка".

Жаль, что многие умные люди раздают эпитеты "отличные" любой мимолётной фигне. Вот правда, вы что, Господь Бог? Откуда лично ваш ограниченный мощностями разум знает наверняка, что эта идея Отличная (от чего отличная, бгг) и с ней будет только Лучше? Что за самоуверенность?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 21 Октябрь, 2017 14:02 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 410
Пётр Кушнир писал(а):
Откуда лично ваш ограниченный мощностями разум знает наверняка, что эта идея Отличная (от чего отличная, бгг) и с ней будет только Лучше? Что за самоуверенность?
Ну ведь чей-то ограниченный мощностями разум считает возможным самоуверенно и безапелляционно заявлять что это идея плохая. С чего вдруг?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 21 Октябрь, 2017 15:09 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2448
Откуда: Россия, Ярославль
Это ты к чему сейчас сказал? Типа, "сам дурак" или что? Я спросил за слова "отличная" у конкретного человека, ты можешь спросить за слова "плохая" у конкретного человека. В любом случае, твоя позиция будет более проигрышная, потому что "тут" в своих рассуждениях "все" руководствуются принципом Калашникова, который был озвучен и растолкован сто раз, а может, даже больше. И рассуждения вдоль этого принципа приводят к выводу "плохая"... рассуждать, руководствуясь принципом, много ума не надо, даже я могу... плечи титанов, вот это всё.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 23 Октябрь, 2017 19:24 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
Пётр Кушнир писал(а):
Жаль, что многие умные люди раздают эпитеты "отличные" любой мимолётной фигне. Вот правда, вы что, Господь Бог? Откуда лично ваш ограниченный мощностями разум знает наверняка, что эта идея Отличная (от чего отличная, бгг) и с ней будет только Лучше? Что за самоуверенность?

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

Однако смотреть лучше чуть внимательнее, поскольку:
viewtopic.php?f=30&t=5366&start=20#p100045
Пётр Кушнир писал(а):
Кажется, эти ваши generics вообще недостойны обсуждения. Особенно после эпичных выяснений в контексте языка Go нарот продемонстрировал, что "теория" дженериков в головах людишек укладывается в "пусть компилятор за нас код генерирует". В Go нет и не нужны. А уж в Обероне точно не нужны.

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

Насчёт "отличности". Предлагаемый в исходной статье полиморфизм для Оберона, как минимум, не требует переделки runtime и исходного компилятора, а также не навязывает однозначного "инлайнинга" кода. Это и техническая альтернатива (в своей основе) предлагаемым здесь решениям (автором этой темы насчёт абстрактных записей и методов, "фасетам"). Т.е. это технологическое решение как дополнительное расширение исходного Оберона.

Возникающая проблематика, если расширение включить как стандартный состав платформы. Речь о тех случаях, когда "шаблонная магия" не нужна (тем, кому она нужна -- прекрасно знают возникающие потребности, и таковы не на каждый чих, конечно же). Если необходимо воспользоваться результатами полиморфной разработки, то вряд ли требуется что-то тяжелее замены "array of integer" на "SpecVector[integer]".

Проблематика, если расширение не стандарт. Возникнет потребность взаимодействия "расширенного" кода с обычным, когда необходимо что-то притянуть для стандарта. Т.е. типовые задачи аля доступ к коду на С++ из кода на С. Решаемо, но с лишними заморочками.
А также ограниченные базовые возможности подталкивают (а, фактически, вынуждают) к возникновению альтернатив вида Активного Оберона и пр. Когда как даже такие фичи, как протоколы взаимодействия объектов (как в Zonnon-е, если не ошибаюсь) реализуются стандартными средствами типизации (т.е. без потребности лезть в компилятор и т.д.). Примеры (есть и на Haskell и др.):
на OCaml: http://www.di.unito.it/~padovani/Papers/FuSe.pdf
на Rust: http://munksgaard.me/laumann-munksgaard-larsen.pdf
на Scala: http://mrg.doc.ic.ac.uk/publications/li ... /paper.pdf

Когда тяжело явно манипулировать декларациями типов -- для услуг функции типов в каком-либо виде, вплоть до техник, обычно обзываемых как "type providers". К примеру, создаются compiletime-функции манипулирования теми же формулами в виде EBNF, если так удобнее.


Такова техническая проблематика. Прочие политические заморочки мне неведомы (лишь предположения).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 23 Октябрь, 2017 19:27 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
Trurl писал(а):
PSV100 писал(а):
Я не пользователь Оберон-платформы

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

Все рассуждения (и материалы) согласно темы -- её автор в стартовом посте предложил решение и конкретно спросил о возможных граблях.
Или же для вас приемлем, к примеру, такой конструктив, здесь же ранее:
viewtopic.php?f=30&t=6131&start=20#p102288
Valery Solovey писал(а):
...Как-то с полгода назад тема ООП уже подымалась. И тогда я через пару дней после того спора решил поделиться своими идеями по поводу фундамента ООП. Но решил, что эта тема здесь будет офтопом, поэтому открыл её на оберспэйсе. И то ли все были со мной согласны, то ли никому не было интерейсно, то ли я как-то невнятно мысль свою доносил, но никто со мной побадаться не захотел...

Разве это нормальная ситуация (особенно выделенное) на профильном форуме?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 93 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2017, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB