Вот в C# например функции должны принадлежать классу.
значить любой класс это модуль?
Зачем столько всего ? сборка, пространство имен, класс, модуль (F# конечно же, в C# официально модулей нет).
зато теперь еще понятие file (для области видимости) ввели.
Каким критериям должен соответствовать программный модуль в мультипарадигменном ЯП?
Здравствуйте, Разраб, Вы писали:
Р>Каким критериям должен соответствовать программный модуль в мультипарадигменном ЯП?
Ничего не знаю про C#, но по аналогии с другими языками, по-видимому, внутри модуля могут существовать локальные классы, которые за пределами модуля не видны. И это удобно, поскольку позволяет структурировать содержимое модуля по классам, и в то же время не позволять внешним наблюдателям сувать свои руки внутрь модуля мимо его официально определенных интерфейсов.
Б>В нормальных языках сделано так: файл = модуль, директория = пакет. Б>Никаких пространств имен, сборок и прочих. Просто и удобно
Только православные каменные топоры, и никакой безбожной кодогенерации (с разделением класса на автоматический и рукописный файлы)?
Здравствуйте, Osaka, Вы писали:
O>Только православные каменные топоры, и никакой безбожной кодогенерации (с разделением класса на автоматический и рукописный файлы)?
1. В нормальных языках кодогенерация не нужна.
2. Не понял, что здесь невозможного. Рукописный импортирует сущности из сгенеренного файла, выставляет нужное наружу.
К классу можно применить операцию "инстанциация", при этом в куче будет выделена память под переменные класса, инициализирована указателем на таблицу виртуальных методов и прочим RTTI, и возвращёт указатель на неё (и, возможно, будет вызыван "конструктор").
То, что получится, называется "объект". И самое главное, что таких объектов можно создать миллионы (если памяти хватит).
Разумеется ещё есть обратная операция "деструкция", про которую спрашивают в форуме "политика", но это неважно.
А у модуля нет операции "инстанциация".
Операция же "загрузка" есть и у класса и у модуля, это верно. В этот момент выполняемый код класса или модуля перемещается из внешней памяти в оперативную (и, возможно, происходит инициализация статических переменных, или вызов статического конструктора).
(и, возможно, существует парная операция "выгрузка", но в core выгружать ассембли стало труднее, чем было в mono)
Таким образом, класс может обладать качествами модуля (например в Java, когда загружается по RMI). Но возможно у модулей есть что-то ещё, другие качества, которых нет у класса. В этом случае чтобы записать в онтологии понятия "класс" и "модуль", надо будет ввести ещё одно понятие, базовое и для класса и для модуля.
A nested type has access to all of the members that are accessible to its containing type. It can access private and protected members of the containing type, including any inherited protected members.
Здравствуйте, Эйнсток Файр, Вы писали:
Pzz>> Ничего не знаю про C#
ЭФ>В классе могут быть вложенные классы с разными видимостями. Так что тоже можно всё скрыть, что не нужно.
У тебя в модуле могут быть вспомогательные классы, логически не относящиеся ни к одному из экспортируемых классов, чтобы их туда вкладывать.
Не, ну можно, конечно, завести класс просто ради неймспейса — ранний Qt так и делал, когда в C++ еще неймспейсов не завезли. Но это же извращение, не?
Р>Вот в C# например функции должны принадлежать классу. Р>значить любой класс это модуль?
Так считает Бертран Мейер
Вот в этой книжке https://habr.com/ru/articles/140284/ он так написал
На мой взгляд — это неверный подход. Р>Зачем столько всего ? сборка, пространство имен, класс, модуль (F# конечно же, в C# официально модулей нет). Р>зато теперь еще понятие file (для области видимости) ввели.
Это перебор.
Вообще файл != модуль. Р>Каким критериям должен соответствовать программный модуль в мультипарадигменном ЯП?
ИМХО лучшая конструкция модуля в Обероне (Компонентный паскаль)
Модуль — это программная единица. Программа состоит из модулей.
Которые либо собираются в одну программу, либо динамически подгружаются во время работы при необходимости
Класс — это, в первую очередь, новый тип объектов в программе.
Программу можно рассматривать как среду обитания множества объектов.
Которые в этой среде рождаются, как-то взаимодействуют с другими объектами и помирают.
Но эта парадигма не доведена до логического конца (возможно, в Смоллтоке ?)
Поэтому и имеем то, что имеем.
Сама программа не является таким объектом для операционной системы.
Единица работы ОС — процесс.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>Это перебор. LVV>Вообще файл != модуль.
Ну почему, тут видимо нужно различать модуль с т.з. исходного и двоичного кода.
Те же .netmodule C# благополучно вымерли в корке.
Но в ЯП базирующихся на исходниках типа Ди или Питона файл это именно модуль, который импортируется в другой модуль.
В шарпах понятие модуля более относится к двоичному коду, что на мой взгляд неверно,
двоичный код это конечный продукт, тут правильней было бы использовать термин компонент.
LVV>>Это перебор. LVV>>Вообще файл != модуль. Р>Ну почему, тут видимо нужно различать модуль с т.з. исходного и двоичного кода. Р>Те же .netmodule C# благополучно вымерли в корке.
Не... В Компонентном паскале модуль — это конструкция языка программирования.
Который при трансляции превращается в двоичный модуль (аналог динамической библиотеки)
Р>Но в ЯП базирующихся на исходниках типа Ди или Питона файл это именно модуль, который импортируется в другой модуль.
Файл — это понятие операционной системы.
И, на мой взгляд, путать их вредно.
Я ж могу в питоне любой текстовый файл обозвать name.py и сделать import name
Это не есть правильно.
Конструкция модуля должна явным образом поддерживаться в языке.
Р>В шарпах понятие модуля более относится к двоичному коду, что на мой взгляд неверно, Р>двоичный код это конечный продукт, тут правильней было бы использовать термин компонент.
Что такое компонент пока никто всерьез не определил.
Микросервис — это компонент.
динамическая библиотека — это компонент
класс — это тоже компонент...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>Что такое компонент пока никто всерьез не определил.
Компонент это такая штука, у которой есть внешние интерфейсы.
LVV>Микросервис — это компонент. LVV>динамическая библиотека — это компонент LVV>класс — это тоже компонент...
Всё сходится.
(у динамической библиотеки — интерфейс это то, что позволяет её загрузить)
LVV>>Что такое компонент пока никто всерьез не определил. ЭФ>Компонент это такая штука, у которой есть внешние интерфейсы.
В связи с этим у меня вопрос: почему до сих пор нет компонентного программирования ?
Всерьез, а не на терминологическом уровне.
Ведь любой конторе ВЫГОДНО собирать продукт из готовых компонентов,
а не нанимать дорогостоящих программеров, которые с большим количеством косяков (которые потом будут разгребать другие люди) чего-то там напишут.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>> В связи с этим у меня вопрос: почему до сих пор нет компонентного программирования ? ЭФ>Потому что это устаревший похдход. Будущее за искинами бесшовно сшивающими программы разных производителей.
Те же яйца, только вид сбоку ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Р>Каким критериям должен соответствовать программный модуль в мультипарадигменном ЯП?
Модуль — минимальный работоспособный объект, независимо от языка, количества классов или библиотек.
Сборка — набор модулей.
Загружаемый модуль извне(не входящий в сборку) — плагин.
Пространство имен — это синтаксические границы внутри языка.
Будет ли эта граница совпадать с границами модуля — это по усмотрению разработчика.
Здравствуйте, LaptevVV, Вы писали:
LVV>В связи с этим у меня вопрос: почему до сих пор нет компонентного программирования ? LVV>Всерьез, а не на терминологическом уровне.
Всерьез компоненты уже давно есть.
Обычно компоненты взаимодействуют по сети, через http api.
Внутри языков готовые компоненты тоже есть — это библиотеки и фреймворки.
LVV>Ведь любой конторе ВЫГОДНО собирать продукт из готовых компонентов, LVV>а не нанимать дорогостоящих программеров, которые с большим количеством косяков (которые потом будут разгребать другие люди) чего-то там напишут.
Именно. Как только появляется потребность в "компоненте", он появляется в том или ином виде
