Хочу провести классификацию сабжевых сущностей.
Чем отличаются эти сущности в тех ЯП, где они используются?
class — понятно, он включает все от namespace и дополнительно — возможность порождать объекты.
А если рассмотреть "static class", т.е. класс у которого только статические методы и поля?
Имеет ли смысл аналог конструкторов и деструкторов для глобальных пакетов ("конструктор" вызывается в начале программы один раз если какой-то пакет/библиотека подключается, "деструктор" — аналогично в конце программы)
Какие еще сущности подобного вида существуют, как они соотносятся друг с другом, особенно если рассматривать разные языки программирования? Какие аналоги понятия "namespace" есть в других ЯП?
Здравствуйте, x-code, Вы писали:
XC>Хочу провести классификацию сабжевых сущностей. XC>Чем отличаются эти сущности в тех ЯП, где они используются? XC>class — понятно, он включает все от namespace и дополнительно — возможность порождать объекты.
Класс — описывает тип данных (структуру, операции, иерархические связи между суб- и супер-классами).
Модуль — цельный блок взаимосвязанного кода (типов, глобальных объектов, функций).
Библиотека — множество модулей.
Пространство имён — упорядочивает поиск имён.
В принципе, эта сущность может быть пенпердикулярна матрёшке класс-модуль-библиотека (и в С++ так оно и есть; правда, там модулей нет).
Но здравый смысл подсказывает, что не нужно усложнять себе жизнь.
XC>А если рассмотреть "static class", т.е. класс у которого только статические методы и поля? XC>Имеет ли смысл аналог конструкторов и деструкторов для глобальных пакетов ("конструктор" вызывается в начале программы один раз если какой-то пакет/библиотека подключается, "деструктор" — аналогично в конце программы)
Централизованный код инициализации модуля есть и в VB, и в Паскале.
В С/С++ — как и всё, что сделано в этих языках, инициализация размазывается — и состоит из инициализации глобальных объектов.
Одновременно с этим существует инициализация единиц загрузки (.dll / .so), и в силу того, что писать dll можно на чём угодно, включая ассемблер, — она включает, но не исчерпывается, языко-зависимым кодом.
Что касается аналогии конструктор-деструктор / загрузка-выгрузка, то... ну, в общем, она есть. С той разницей, что модуль ведёт себя как синглетон.
XC>Какие еще сущности подобного вида существуют, как они соотносятся друг с другом, особенно если рассматривать разные языки программирования? Какие аналоги понятия "namespace" есть в других ЯП?
приветствую!
случайно наткнулся поиском на эту дискуссию, собственно, в моём случае как раз и нужно слегка "усложнить", а точнее чётко провести архитектурную параллель... а именно:
Здравствуйте, Кодт, Вы писали:
К>Класс — описывает тип данных (структуру, операции, иерархические связи между суб- и супер-классами). К>Модуль — цельный блок взаимосвязанного кода (типов, глобальных объектов, функций). К>Библиотека — множество модулей.
так вот, что касается понятия Package — насколько грамотно и "политкорректно" утверждать, что Пакет == Модуль (Package == Module) ?
впринципе, ИМХО, эти две сущности (пакет и модуль) есть суть одно и то же, просто некоторые языки суть этой сущности (закреплённой за этими названиями-именами) использую свой синтаксис.
кроме того:
1. насколько грамотно и "политкорректно" утверждать, что Пакет == Модуль (Package == Module) ?
2. если необходимо обеспечить некую иерархическую вложенность пакетных сущностей, как более правильно сказать:
а) есть модуль module1, внутри которого пакет с именем Package1, внутри которого Package2, что формирует namespace module1::Package1::Package2 (некий псевдо-синтаксис)
б) есть пакет Package1, внутри которого модуль с именем Module1, внутри которого Module2, что формирует namespace Package1::Module1::Module2 (некий псевдо-синтаксис)
какой из названий этих сущностей следует использовать для обозначения иерархической вложенности произвольной глубины одних "Пакетов" в другие?
Здравствуйте, zverb555, Вы писали:
Z>кроме того: Z>1. насколько грамотно и "политкорректно" утверждать, что Пакет == Модуль (Package == Module) ?
Это зависит от контекста.
Традиционно, модуль — это единица инкапсуляции, а пакет — единица деплоймента.
Они вполне себе ортогональны, то есть границы модулей и пакетов никак не связаны между собой.
Тем не менее, в дотнете, к примеру, модуль — это единица загрузки, а в сборку может входить несколько модулей.
Z>2. если необходимо обеспечить некую иерархическую вложенность пакетных сущностей, как более правильно сказать: Z> а) есть модуль module1, внутри которого пакет с именем Package1, внутри которого Package2, что формирует namespace module1::Package1::Package2 (некий псевдо-синтаксис) Z> б) есть пакет Package1, внутри которого модуль с именем Module1, внутри которого Module2, что формирует namespace Package1::Module1::Module2 (некий псевдо-синтаксис)
Если не уточнять контекст, то оба утверждения неправильны.
Namespace — это пространство имен, оно вообще ортогональны всему.
Z>какой из названий этих сущностей следует использовать для обозначения иерархической вложенности произвольной глубины одних "Пакетов" в другие?
Вложенность произвольной глубины обычно применяется только к namespace. Пакеты/модули, как правило, не формируют иерархий.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Вложенность произвольной глубины обычно применяется только к namespace. Пакеты/модули, как правило, не формируют иерархий.
Здравствуйте, zverb555, Вы писали: Z>собственно, как тогда их именовать?
Кого? Z>"вложенные" друг в друга "модули" ?
Как я уже сказал, "модуль" в широком смысле не участвует в иерархии.
Как правило, в конкретной платформе все термины имеют однозначную трактовку.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
Z>>собственно, как тогда их именовать? S>Кого?
ок, есть один большой модуль, для этого модуля мы хотим написать два модуля, то есть, как бы под-модули, например:
blog
|____archive
|________ search
здесь blog — как бы основной модуль, archive — "подмодуль" модуля blog, который реализует БД по управлению постами перенесёнными в архив, и search является "подмодулем" "подмодуля" archive который собственно реализует поиск в архиве
на java, эни будут называется subpackage (archive & search), однако, подобного названия для модулей(submodules), в вычислительной технике, я не встречал, разве что ВИКИ упоминает о подмодулях исключительно как о подмножествах множества в некоторых дисциплинах математического аппарата.
Z>>"вложенные" друг в друга "модули" ? S>Как я уже сказал, "модуль" в широком смысле не участвует в иерархии.
сорри, ввёл вас в непонятку, из-за неверного использования этого слова, здесь имеется ввиду просто отношение модулей(пакетов, компонент и т.д.), когда один модуль выступает в роли подмодуля другого
собственно, интересует правильные, грамотные названия "подмодулей" согласно рассмотренному выше примеру.
Так же, подскажите пожалуйста, существует ли такое понятие как "подкомпонента"
Перекуём баги на фичи!
