OberonCore

Пока сюда, потому что точно не понимаю, куда приткнуть.
(Надо по ББ темы и форумы переформатировать как-то, а то уже непонятно куда про что писать.)

Так вот идея произрастает из дискуссии в Telegram по поводу левых функций в интерфейсе Kernel для работы с UTF8. Им там однозначно не место! Но суть не в этом.

Чтобы отсечь сразу ненужный диспут: UTF8 широко сейчас применяется на практике, в том числе и нами. Но это формат обмена с внешним миром.

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

А раз так, то почему бы не вывести, наконец, UTF8 из недр BlackBox, то есть не довести юникодизацию до нормального состояния, с использованием штатного CHAR вместо SHORTCHAR, где он ещё остался?

Вылизывать грязь надо, да.

Плюсую. У меня нет в использовании проприетарных старых модулей, которые без исходников. Все можно перекомпилировать. У кого есть, отзовитесь?
А то когда пишешь Kernel.Utf8Name оно как-то не oberon way: смешивается суть сущности с форматом ее представления; обычно у нас это разделяется: сущности - имя, представлению - тип. И вообще, да простит меня Евгений Темиргалеев, цифры в именах - это.. ну, на мой вкус читать неудобно, по меньшей мере )

В целом я не против. Лишь бы работало хорошо. Но почему так раздражает Utf8 в ядре? Может переименовать его MakeShortCharString или как угодно еще?
Это один из лучших способов решить задачу, при этом не лезя в компилитор и т.д.

Не обязалельно использовать эту реализацию из ядре вообще где-то в модулях пользователя! Это лучше бы в докментации даже прописать. А использовать для преобразования надо Strings. При этом с Strings надо убрать зависимость от ядра и сделать там другую реализацию Utf8. Мы так и планировали, но потом про это Йозеф забыл.
А современный фреймворк без Utf8 - это нонсенс как раз.

Это промежуточное решение, очевидно же. CHAR -- правильное по смыслу решение. И да, пора уже лезть в компилятор.

Из интерфейса её убрать надо, а не в документации прописывать.

Вот это правильно.

Вот именно, фреймворк. Для рантайма это инородная сущность. И, кстати, Strings это библиотека, а не фреймворк. Так что и там спорно. Отдельный модуль для работв с utf8 в составе фреймворка -- это да. Это хорошо.

DIVIDE ET IMPERA в IT-версии:

"По умолчанию разделяем, если можно разделить.
Если не разделяем, то доказываем почему нельзя разделять."

Правильное место для UTF8 -- библиотека.

Надо чистить и упрощать всё, что можно и возможно.
В том числе и превентивно.

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

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

Давайте только разделим две вещи.

Реализацию механизмов ядра.

И присутствие Utf8 в Блэкбоксе.

Присутствие Utf8 нужно в кросс-платформенной сборке, так как большая часть привязок использует Utf8 для передачи всевозможных строковых аргументов для библиотек Gtk2 и им подобным. Также как и в Linux и им подобных системах Utf8 повсеместно используется для хранения текстовых данных различных конфигурационных файлов системы, пользователя и т.п. Так что Utf8 надо в Блэкбоксе оставить. Вынести в отдельный модуль из Strings - не возражаю, но и не поддерживаю. Модули плодить тоже не очень позитивно. В Strings Utf8 может жить в вполне логично, раз это операции над строками.

Иван, я же специально оговорил в первом сообщении. Может не внятно выразился. Utf8 нужен, мы его сами широко используем. Но по внешнму контуру. Внутри ему делать нечего.

Там операции именно над строками КП, т. е. над ARRAY OF CHAR. UTF8 формат внешний, поэтому в отдельный модуль -- вполне себе правильно.

Заголовок вводит в заблуждение, и сейчас также — неоднозначное уточнение.

Utf8 нужен в Блэкбоксе из коробки. Пусть и в виде отдельного модуля, но в стандартном дистрибутиве.

Показалось (может ошибся), что кто-то делит на 2 слоя - "внутри" и "снаружи", а кто-то на три - "ядро", "стандартные библиотеки", "дополнительные модули" - в зависимости, видимо, от решаемых практических задач. Какой-то общий взгляд на систему "сверху" выработан уже - или нет? Хочется понять общую идею

Ну и я об этом.

Я не совсем понимаю, предлагается изъять процедуры из Kernel или совсем избавиться от UTF-8 в бинарниках?

Избавиться от UTF8 в бинарниках.

Ну, это уже радикальные изменения. Потянет на 2.0.

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

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

Как их уберешь? Загружать же модули надо, связывать по именам. Да еще метаинформация.

А разве есть общая кодовая база?