Модули vs namespace's

На сколько я знаю, в Паскале uses работает так только с неймспейсами, а для классов - то же самое, только через type.

Предлагаю систематизировать все обсуждённое ранее.

Желательно систематизировать также что есть Я вот синтаксиса сегодняшних namespaceов не знаю

2 лайка

Синтаксис неймспейсов такой же, как у модулей.

namespace NS1;
  Type A = class
  End;
End.

Имя неймспейса должно быть полным, то есть, если в неймспейс NS1 нужно вложить NS2, то код будет такой:

namespace NS1.NS2;
  Type B = class
  End;
End.

Подключить неймспейс к библиотеке или программе можно директивой IncludeNameSpace 'name.pas'

Library My;
{$IncludeNameSpace 'NS1.pas'}
End.

А имя namespace и имя файла как то связаны?

Может ли быть в namespace секция implementation? finalization?

В любом ли месте файла можно подключать namespaces?

Имя файла должно совпадать с именем неймспейса. Про остальное - к @ibond.

Я выше показывал структуру пространства имён. Правда, меня смущает, что они, на данный момент, очень сильно похожи, в плане синтаксического описания, на модули. И по функционалу. Образцовый пример их реализации можно найти в языке C#, впрочем Вы знайте.

Нет. Не может. namespace имеет структуру как в C#. никакого разделения описания и реализации нет. никаких ограничений на имя файла нет. пространства имен сквозные, но один файл может содержать только одно пространство имен. компиляция трехпроходная: сначала классы, потом поля и описания методов, потом тела методов. подключение через {$includenamespace}. подключать можно только в программах и библиотеках, но не в модулях (это понятно). {$includenamespace} можно вбивать руками, либо через проекты автоматически.

1 лайк

Вложенные namespace тоже поддерживаются

namespace MyProject.Models; end;

1 лайк

Вы хотите сказать, что приведенное мною описание пространства имён ошибочно?

Это достаточно весомый аргумент против таких пространств имён.

Тоже является аргументов против такой реализации пространств имён. К примеру, пространство имён System, может быть подключено как к модулю, так и к программе. Никаких ограничений, связанных с невозможностью подключения к модулям, для уже существующих пространств имён нет. Так почему ставятся данные ограничения в этой реализации пространств имён? Вы можете привести причины, по которым реализация сделана именно так, как сделана?

1 лайк

Несколько пространств имен в одном файле это антипаттерн и лишнее усложнение.

System находится в сборке. А я говорю про includenamespace в модуле. Модуль (unit) и namespace нельзя смешивать (да и зачем).

Да, в том, что это усложнение Вы правы. Но разве это повод запрещать описывать несколько пространств имён в одном файле?

Насколько понимаю, сам модуль неявно образует пространство имён. Вы в язык лишь добавили явные пространства имён. Что мешает в одном модуле позволить размещать, например, несколько явных пространств имён (возвращаясь к выше поставленному вопросу)?

Если так, то в двух разных файлах нельзя в одно именованное пространство имен что-то поместить.

Еще один вопрос, который меня мучает.

Все пространства имен .NET нужно подключать явно в секции uses чтобы пользоваться именами из них. Нужно ли подключать в uses наши пространства имен?

В смысле? У меня это работает:

namespace My
{
    public static class Program
    {
        public static void Main()
        {
            System.Collections.Generic.IEnumerable<byte> s;
        }
    }
}

Я не подключал System.Collections.Generic, но пользоваться IEnumerable всё равно даёт…

Оно переопределено

Для стандартизации кода - да.

Нужно.

А если модули оставить для совместимости, но вместо них использовать неймспейсы?

Это же C#.

Админ не это имел ввиду. Вы здесь подписали полное имя класса, поэтому using не нужен, а чтоб писать просто IEnumerable нужно писать using.

Это стандартная путаница. Пространства имен это всего лишь область в программе, где не может быть двух одинаковых имен. То есть, пространства имен не содержат код.

Модули же содержат код. Кроме того, модуль вводит пространство имен, совпадающее с именем модуля.