OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 16 Июнь, 2021 20:53

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




Начать новую тему Ответить на тему  [ Сообщений: 169 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 9  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 05 Январь, 2008 19:50 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Так вот, если брать компилируемые реализации ФЯ, то автовывод типов - это всё равно, что превратить каждую обычную функцию в template.


А это плохо? Не надо судить о темплейтах по C++ ;)

Илья Ермаков писал(а):
Таким образом, ставьте сразу крест не только на динамическом расширении системы,


Почему? Для "динамической расширяемости по оберону" необходимо просто зафиксировать тип конкретной функции. Т.е., мы теряем часть возможностей языка в угоду "динамической расширяемости по оберону", но ничего не теряем по сравнению с самим обероном (изначально обделенным). Но это если нам нужна именно "динамическая расширяемость по оберону" и никакая другая. У меня есть подозрение, что системам, написанным на хаскеле, она нафиг не нужна и проблемы расширяемости решаются по-другому :)

Илья Ермаков писал(а):
но и даже на раздельной компиляции.


Аналогично. Смотря что подразумевать под компиляцией ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 19:54 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Не забывайте про сборку мусора... Close будет вызываться только для вполне определённого типа внешних ресурсов (и то - либо "общих" (типа БД), либо весьма ограниченных (сокет), т.к. закрытие, например, файла, открытого на чтение, можно спокойно переложить на сборщик мусора, подбирающий объект типа File и вызывающий его финализатор).


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 20:03 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
ну, я же сказал - "открытого на чтение", подразумевая, что в SHARED MODE...


Сегодня он открыт на чтение, а завтра на запись и уже совсем другим программистом (который не читал книжек, а только обероновские форумы). А по лбу граблями получите вы ;)

Илья Ермаков писал(а):
Например, документы в BlackBox открываются именно в таком режиме. Может быть открыто несколько Files.File на один документ разными модулями (на самом деле там возвращается один и тот же, он ищется среди уже существующих объектов данного типа), а закрывается только сборщиком мусора...


И ради чего? Чтобы не терять файловые ресурсы при каком нибудь ASSERT в момент загрузки документа, потому что нет FINALLY? ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 20:51 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9418
Откуда: Россия, Орёл
Vlad писал(а):
И ради чего? Чтобы не терять файловые ресурсы при каком нибудь ASSERT в момент загрузки документа, потому что нет FINALLY? ;)


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 23:59 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
AVC писал(а):
Конечно, есть альтернативный способ -- на каждый "чих" добавлять синтаксическую конструкцию.
Вот-вот, об этом я и толкую.
В мейнстримных языках синтаксические конструкции добавлять трудно, делается это комитетами раз в 10 лет.
В функциональных и метаязыках это просто.
В оберонах же предлагается путь мейнстримных языков -- расширение языка, приводящее к новым диалектам. Причём тру-оберонщики этим расширениям всячески противятся, так как пугаются возможных осложнений из-за этих расширений...

AVC писал(а):
коммандеры и меню основаны на вызовах процедур по имени
Эта... А с каких это пор вызов процедур по имени стал называться метпрограммированием? 8-о


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 01:06 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Так вот, если брать компилируемые реализации ФЯ, то автовывод типов - это всё равно, что превратить каждую обычную функцию в template. Т.к. потенциально множество типов, с которыми функция может работать, бесконечно и не зафиксировано жёстко в определении самой функции.
Совершенно неверно!

В таких языках, как тот же Хаскелл (у которого самая правильная, на мой взгляд, организация системы типов), тело функции явно и очень строго ограничивает типы аргументов и результата.
Конечно, есть такие функции, как map или filter, у которых ограничения очень широкие, но таких функций не так уж и много, да и то это возможно лишь из-за простоты самих этих функций.
Возьмём map:
Код:
map f [] = []
map f (x:xs) = (f x) : (map f xs)
Что мы видим в реализации этой функции? А то, что первый аргумент -- некая функция, тип которой не указан, а значит может быть в самом общем случае таким:
Код:
f :: a -> b
т.е. f принимает значение любого типа (обозначенного как a) и возвращает значение любого типа (обозначенного как b), причём эти два типа могут и совпадать.

Второй аргумент -- список значений неуказанного типа, обозначаемого, ну например, как a. Функция map применяет первый аргумент к элементам второго аргумента, и результаты склеивает в список-результат.
Отсюда делается вполне логичный автовывод, что тип функции map таков:
Код:
map :: (a -> b) -> [a] -> [b]
т.е. первый аргумент -- функция с типом (a -> b), второй аргумент -- список значений типа a, результат -- список значений типа b...

Да, типы тут могут быть самыми разными, но строго определено, что первый аргумент -- функция от одного параметра, и ничто иное, а второй аргумент -- список значений, которые можно подать на вход первому аргументу. Результат же функции map -- список значений того типа, который возвращается первым аргументом.

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

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

Возьмём для простоты такой пример:
Код:
inc x = x + 1
Как Вы уже догадались, функция inc просто возвращает число, которое на единицу больше аргумента. Здесь используется операция (+) -- метод класса типов Num. Число 1 не содержит дробной части, поэтому может быть как целым, так и вещественным, и никак не ограничивает множество типов значений, которые могут обрабатываться методом (+). Поэтому аргумент функции inc должен иметь тип, являющийся представителем класса чисел Num, и тип функции inc таков:
Код:
inc :: (Num a) => a -> a
Что означает, что и параметр функции inc, и её результат имеют один и тот же тип, являющийся экземпляром класса Num.

Более сложный пример:
Код:
square r = pi * r * r
Да-да, эта функция просто вычисляет площадь круга, задаваемого радиусом r. Я намеренно не использовал операцию возведения в степень, что бы упростить пример. Так вот, тут уже используется константа pi, тип которой pi :: (Floating a) => a. Эта константа на самом деле полиморфная функция (а точнее -- метод класса Floating), у которой нет параметров, а результат может иметь значение любого типа, для которого определёна реализация интерфейса класса типов Floating.

Операция (*) является методом класса Num; в определении класса Floating указана его зависимость от класса Fractional, который в свою очередь зависит от класса Num. Эти зависимости означают, что на типы аргументов метода (*) в данном случае накладываются ограничения -- они должны быть экземплярами не только класса Num, но так же и классов Floating и Fractional. Так как ограничение на класс Floating автоматически ведёт к ограничениям на классы Num и Fractional, то они опускаются из описания выведенного транслятором типа функции square:
Код:
square :: (Floating a) => a -> a
Это не является угрозой для надёжности программы, так как Вы не сможете указать, что какой-то тип принадлежит к классу Floating, не указав при этом его принадлежность к классам Fractional и Num...

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

Собственно, я хочу сказать, что современные функциональные языки с автовыводом типов имеют строгую статическую типизацию, даже более строгую, чем у того же Оберона, но при этом более гибкую. Строгость и гибкость могут сочетаться! :о)

Илья Ермаков писал(а):
Таким образом, ставьте сразу крест не только на динамическом расширении системы, но и даже на раздельной компиляции.
А вот этот момент я не понял. В Хаскелле вполне нормальная система раздельной компиляции. Не хуже, чем в Оберонах...

Способ создания расширяемых программ на Хаскелле я ещё не изучал, есть какая-то библиотека hsplugin, всё не дойдёт у меня дело до неё добраться…


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 01:46 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Вообще-то, в Хаскелле считается правилом хорошего тона указывать тип глобальных функций, особенно если они экспортируются из модуля.

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

А вот типы анонимных функций (лямбд) указывать нельзя, можно только указывать типы их результатов. (Правда, с расширениями GHC это тоже можно)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 02:51 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Geneipro...а ошибиться в определении функции в вашем хаскеле нельзя?
а то у вас прям любое выражение прожевывается...и выводится какой-то тип функции.
вообще все дубово...я правда хаскеля не знаю... :shock:
проектирование системы начинается обычно с верхнего уровня, и потому сначала, на некоей стадии, определяются прототипы функций с типизированными параметрами, и типом результата, потому вывод типа параметров и результата...по телу функции...это оно конешно дааа!
просто интересно когда это нужно???
проще ошибиться в реализации функции, и потому ошибка перейдет на прототип. и куда верней, написать безошибочный прототип, а потом проверять компилятором соответствие реализации прототипу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 03:33 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Vlad писал(а):
И ради чего? Чтобы не терять файловые ресурсы при каком нибудь ASSERT в момент загрузки документа, потому что нет FINALLY? ;)

Простое и вполне нормальное решение для открытия файла в разделяемом режиме.


Ага, такое простое, что поддержку такого поведения пришлось вшить в рантайм ;)

Илья Ермаков писал(а):
Кстати, можно и на запись тоже - все читатели будут видеть просто старую версию.


Ага, чтоб никто не догадался :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 03:56 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
merk писал(а):
Geneipro...а ошибиться в определении функции в вашем хаскеле нельзя?
а то у вас прям любое выражение прожевывается...и выводится какой-то тип функции.


Любое не прожуется.

merk писал(а):
вообще все дубово...я правда хаскеля не знаю... :shock:


Ознакомьтесь. Если до этого воевали с плюсовыми шаблонами, то озарение гарантировано :)

merk писал(а):
проектирование системы начинается обычно с верхнего уровня, и потому сначала, на некоей стадии, определяются прототипы функций с типизированными параметрами, и типом результата, потому вывод типа параметров и результата...по телу функции...это оно конешно дааа!
просто интересно когда это нужно???


Кроме верхнего уровня еще до фига работы :) Автовывод типов как раз помогает, когда вам совершенно все равно с какими типами вы оперируете, но при этом вы не хотите получить полную лажу в рантайме. Если функция кладет яблоки в корзину и возвращает корзину яблок, то вы не хотите ее переписывать когда вам захочется складывать в корзину апельсины. С автовыводом типов вам не нужно заводить абстрактную корзину, в которую можно складывать абстрактные фрукты - вы всегда знаете, что лежит в корзине, а главное компилятор тоже знает и не позволит вам отдать полученную корзину апельсинов туда, где раньше ожидалась корзина яблок.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 04:25 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Если функция кладет яблоки в корзину и возвращает корзину яблок, то вы не хотите ее переписывать когда вам захочется складывать в корзину апельсины.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 05:11 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
merk писал(а):
а может операция "+" для апельсина и для яблока ваще имеют разную семантику? если их можно переопределять то вместо корзины апельсинов может получиться бочка, которую грузить нужно?
опасно.


Ну извините, с тем же успехом можно назвать операцию read, а в реализации форматировать винчестер. Автовывод типов гарантирует только соответствие входных/выходных типов операциям, которые над ними производятся. При реализации самих операций приходится включать голову, без этого пока никак :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 05:20 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
merk писал(а):
а ошибиться в определении функции в вашем хаскеле нельзя?
Ну Вы же знаете, программирование -- это процесс внесения ошибок в программу... ;о)

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

merk писал(а):
вообще все дубово...я правда хаскеля не знаю...
Так познакомьтесь, он не так сложен, как оберонщики пытаются его представить... Если уж Вы создавали сложные программы на С++, то изучения Хаскелла для Вас -- плёвое дело... ;о)

merk писал(а):
проектирование системы начинается обычно с верхнего уровня, и потому сначала, на некоей стадии, определяются прототипы функций с типизированными параметрами, и типом результата
Никто не может запретить Вам делать так же в Хаскелле.
Но тут уже в дело вступают привычки. Кому-то удобнее конструировать функции без всяких аннотаций типов, кто-то наоборот -- сначала укажет тип функции, а потом пытается добиться, что бы сконструированная функция соответствовала этому типу.

merk писал(а):
потому вывод типа параметров и результата...по телу функции...это оно конешно дааа!
Ну это ещё что! Вот последний писк моды среди функциональщиков сейчас -- указать требуемый тип функции и заставить систему доказательства теорем автоматически сконструировать тело этой функции.
пока эта технология ещё на стадии становления, но уже можно в не самых сложных случаях получить результат... :о)

merk писал(а):
просто интересно когда это нужно???
В функциональном программировании очень распространённоя практика -- использовать маленькие анонимные функции, тип которых либо невозможно указать, либо можно, но тогда теряются преимущества таких функций -- краткость и наглядность их записи.
Ну и вообще, утомительно указывать типы кучи маленьких очевидных функций... ;о)

merk писал(а):
проще ошибиться в реализации функции, и потому ошибка перейдет на прототип. и куда верней, написать безошибочный прототип, а потом проверять компилятором соответствие реализации прототипу.
Опять же повторю -- при желании Вы вполне можете указать типы функций.

Автовывод типов -- очень и очень строг, так что ошибиться не проще, чем в других статически типизированных языках. А по сравнению с шаблонами С++ -- так и вовсе гораздо труднее...

merk писал(а):
а там при выводе типов... производится сопоставление по имени (обозначению) метода(операции)? невзирая на реализацию этого метода? а может операция "+" для апельсина и для яблока ваще имеют разную семантику? если их можно переопределять то вместо корзины апельсинов может получиться бочка, которую грузить нужно?
опасно.
Это да, жизнь вообще штука опасная, от неё умерают... :о(

Семантику для операций указывает программист, когда создаёт реализации интерфейсов классов типов для нужных ему типов... Откуда компилятору знать, хорошие ли намерения у программиста?

Да, и переопределять функции/методы в Хаскелле нельзя, можно только создавать реализации для новых типов. При этом другие реализации затронуты не будут.

Кстати, классы типов могут содержать и дефолтные реализации методов, типа указываем, что операция а == и эквивалентна выражению not (a /= b), а операция a /= b эквивалентна выражению not (a == b). Далее, когда Вы создаёте для какого-то своего типа реализацию класса типов Eq (значения, которые можно сравнивать на равенство/неравенство), Вы можете опустить реализацию одной из этих операций. Она будет автоматически вычисляться с помощью другой... Часто это может сократить объём работы.
Но, естественно, по крайней мере одну из этих операций Вы должны реализовать, иначе при работе программы возникнет зацикливание, а этого компилятор не позволит...

Есть кстати ещё так называемые зависимые типы (dependent types), которые накладывают ещё более строгие ограничения на реализацию тела функций. Эти типы в идеале призваны принципиально исключить возможность логических ошибок программиста. Но это тоже пока ещё на стадии исследований и разработок...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 05:34 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
merk писал(а):
средство бесспорно полезное...если конечно просто не делать класс типа, корзины фруктов, и не складывать туда апельсины и яблоки, что есть фрукты по базовому классу.
Вообще-то в контейнер, в типе которого указано, что все его элементы имеют один и тот же тип, просто так не получится положить значения разных типов, пусть даже они и относятся к одному и тому же классу типов.

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

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

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

Кстати, Хаскелл не является объектно-ориентированным языком, и в нём просто нет "базовых классов". Классы в нём могут иметь зависимости от других классов, но это не иерархии наследования как в ООП...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 13:25 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9418
Откуда: Россия, Орёл
Geniepro писал(а):
Да, типы тут могут быть самыми разными, но строго определено, что первый аргумент -- функция от одного параметра, и ничто иное, а второй аргумент -- список значений, которые можно подать на вход первому аргументу. Результат же функции map -- список значений того типа, который возвращается первым аргументом.
Где тут могут быть проблемы? Эта функция проста и сверхнадёжна. И даже у такой простой функции типы аргументов и результатов строго ограничены, хотя при этом она полиморфна...

Как Вы будете модуль с этой функцией раздельно компилировать, если Вы не знаете типов размеров элементов этого списка? Когда компилируется целиком программа, то все варианты использования функции уже известны, и будет сгенерировано столько её реализаций, сколько нужно для конкретной программы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 13:30 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9418
Откуда: Россия, Орёл
Geniepro писал(а):
Так познакомьтесь, он не так сложен, как оберонщики пытаются его представить... Если уж Вы создавали сложные программы на С++, то изучения Хаскелла для Вас -- плёвое дело... ;о)

Вот-вот, я уже не раз говорил, что Хаскелл - это С++ для функциональщиков :-) И аргумент "Hello world написать очень просто", между прочим, не катит :-) Если язык позволяет такие навороты и сферических коней, какие я видел у Душкина, то с этим языком что-то не то.. В том смысле, что интеллектуальная зараза он :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 15:32 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Как Вы будете модуль с этой функцией раздельно компилировать, если Вы не знаете типов размеров элементов этого списка?

такая функция не может быть раздельно скомпилирована. это просто шаблон функции. ее актуализация будет неявно генериться при компиляции того модуля, где ее используют.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 16:04 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9418
Откуда: Россия, Орёл
merk писал(а):
такая функция не может быть раздельно скомпилирована. это просто шаблон функции. ее актуализация будет неявно генериться при компиляции того модуля, где ее используют.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 16:44 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Для того, чтобы "неявно генериться", нужно иметь либо исходник (и забыть о раздельной компиляции и динамической загрузке тем более), либо иметь компиляцию в какое-то промежуточное представление, из которого можно "раскрутить" шаблоны (как обеспечиваются шаблоны в C#, насколько я понимаю).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 18:36 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2411
Откуда: Россия, Томск
merk писал(а):
актуализации генерятся компилятором при компиляции того модуля, где такие функции используются. после компиляции они становятся обычными локальными в модуле функциями с именами-сигнатурами.

А что будет, если изменить реализацию функции? Модуль-клиент уже скомпилирован и фактически в нём будет работать старый вариант?
merk писал(а):
а при запуске все происходит как обычно, поскольку запускаются уже откомпилированые модули, то есть раздельная загрузка работает.

Что толку от загрузки такого модуля, если реализация функции не в нём, а вкомпилирована в клиенты?

Один модуль скомпилировали с одной реализацией, другой - с другой, третий - с третьей. В результате функция вроде бы одна, и везде только используется, но на самом деле их сколько угодно с одним именем. Зачем такие "модули", спрашивается, если весь их код заинлайнен и размазан по всем клиентам?

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


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

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


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

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


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

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