[Oberon-07/11] RECORD&POINTER export.

[Kemet]

Блекбоксёры постоянно ставят в достоинство КП то, что в нём записи можно создавать не только в куче, но и на стеке, в отличие от Явы, где все объекты создаются только на куче.
Этим они объясняют высокую производительность свой шины сообщений.

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

Экспорт же записи только через указательный тип не позволит использовать такие записи на куче и сводит на нет это преимущество оберонов перед явой.

Для этого и предназначены opaque типы. Там, где нужны статические объекты в стеке - нужно использовать записи, естественно, экспортируя тип записи.

[valexey_u]

"за сценой", дополнительно - не  забудьте
1. Вирт и так ограничил по максимуму язык
2. Мы не имеем четкого представления куда идет эта реализация
3. УЖЕ получается не совсем то, что хотелось (в частности , строгости и непротиворечивости).
4. Любое ограничение уменьшает выгоду от простоты языка и накладывает трудно прогнозируемые ограничения на область использования
5. Мы пока еще неспособны аргументировать введение ограничений на хорошем уровне.

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

[DddIzer]

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

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

[valexey_u]

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

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

Гм. А как на счет вот такого примера:

Код: [Выделить]

MODULE M;
TYPE
 R  = RECORD foo* : INTEGER END;
 P* = POINTER TO R;
END M.


[akron1]

Гм. А как на счет вот такого примера:

Код: [Выделить]

MODULE M;
TYPE
 R  = RECORD foo* : INTEGER END;
 P* = POINTER TO R;
END M.


Репорт:
6.3 Record types

...
If a record type is exported, field identifiers that are to be visible outside the declaring module must
be marked.

Т.е., если тип-запись не экспортируется, то его поля не должны экспортироваться.

[valexey_u]

Гм. А как на счет вот такого примера:

Код: [Выделить]

MODULE M;
TYPE
 R  = RECORD foo* : INTEGER END;
 P* = POINTER TO R;
END M.


Репорт:
6.3 Record types

...
If a record type is exported, field identifiers that are to be visible outside the declaring module must
be marked.

Т.е., если тип-запись не экспортируется, то его поля не должны экспортироваться.

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

Соответственно я вижу тут две возможности (и нам надо выбрать одну из них)
1) Такая ситуация, как приведенном мное исходнике, является ошибочной, и мы должны получить ошибку компиляции (с указанием на то, что сам тип записи не экспортируется).
2) Такая ситуация не ошибочна, и мы к полям записи можем получить доступ через указатель, но при этом экземпляры записи вне данного модуля создавать не можем.

[Kemet]

Гм. А как на счет вот такого примера:

Код: [Выделить]

MODULE M;
TYPE
 R  = RECORD foo* : INTEGER END;
 P* = POINTER TO R;
END M.


Думаю, так:

Код: [Выделить]

MODULE N;
IMPORT M;
VAR
  p : M.P;
BEGIN
  NEW( p );
 p.foo := 1;
END N;


[akron1]

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

Код: [Выделить]

MODULE M;
TYPE
 R*  = RECORD foo*, foo2 : INTEGER END;
 P* = POINTER TO R;
END M.

DEFINITION M;
TYPE
 R  = RECORD foo : INTEGER END;
 P = POINTER TO R;
END M.

А если тип-запись не экспортируется, но при этом экспортируются его поля, то как тогда создать def? Ну, а если def-файлы в принципе не нужны, то тогда можно упростить правила и лепить метки экспорта где угодно.

[vlad]

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

Сейчас оно именно так и работает (пишет ошибку).

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

Возможно так правильнее - тогда можно использовать запись без NEW внутри модуля. Хотя практического смысла пока не вижу.

[Valery Solovey]

Тут говорится о валидности объявлений (declaration, процесса объявления новых типо), я же говорю и спрашиваю о экспорте и импорте. То есть не про объявления, это разные понятия.

В оберонах модификатор экспорта -- это часть декларации. Так в чём проблема-то?

На тип этот модификатор никак не влияет. То есть не входит в сигнатуру.

Не входит в сигнатуру типа, но входит в сигнатуру модуля.

[Valery Solovey]

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

Эту идею ещё стоит обдумать, но мне кажется, что не стоит разрешать делать NEW для импортируемых типов. А объявлять переменные можно разрешать для любых импортируемых типов.

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

То есть, указатель или запись влияют на поведение импорта только в этом ключе. А для доступа к полям, если они экспортированы, достаточно, чтобы хотя бы один типов указатель/запись были экспортированы.