Comments 9
// === module1.js
export class First {}
export class Second {}
export class Third {}
// === module2.js
import { First } from './module1.js';
First.whatever();
// === module3.js
import * as namespace from './module1.js';
new namespace.Second();
// === module4.js
export * as namespace from './module1.js';Вылезайте из бункера, немцы ушли :-)
Основные фишки namespace в том, что они могут быть иерархическими, а реализацию одного пространства имён можно раскидывать по разным файлам. Модуль это просто вырожденный случай, где файл образует отдельный одноуровневый namespace.
Тот же Typescript поддерживает обе концепции, но по-моему на практике модули используются гораздо чаще.
Модуль это просто вырожденный случай, где файл образует отдельный одноуровневый namespace.
Учитывая что есть re-export-ы, вы можете организовать какую-угодно матрёшку любой вложенности и структуры. Dead code elimination вам за это спасибо не скажет, но тем не менее.
Тот же Typescript поддерживает обе концепции, но по-моему на практике модули используются гораздо чаще.
Потому что namespace-ы получились какими-то шибко неудобными и контринтуитивными.
Тот же Typescript поддерживает обе концепции, но по-моему на практике модули используются гораздо чаще.
А все потому что в документации они так явно и пишут:
we recommended modules over namespaces in modern code
А неймспейсы так и остались, как историческое легаси
Вылезайте из бункера, немцы ушли :-)
Пусть сначала немцы капитулируют и признают, что CORS-ограничения на локальные файлы были ошибкой.
namespaceOne у вас объявлена как var, значит её легко переписать в любом месте кода, потеряв весь ваш якобы namespace.
Если уж колхозить что-то, то, IMHO, лучше так:
const namespaceOne = (() => {
class First {};
class Second {};
class Third {};
return { First, Second, Third };
})();Но, в целом, хватает и возможностей модулей.
Это из вики:
In computing, a namespace is a set of signs (names) that are used to identify and refer to objects of various kinds.
Namespace'ы дают возможность однозначно идентифицировать любой объект кода (класс, константу, функцию, метод, свойство) в рамках всего проекта (приложения) или даже глобально (в рамках всех объектов кода в пределах одного ЯП). Именно в этом и вся сложность - обеспечение уникальной идентификации (в пределах пакета/проекта/глобально).
То, что вы описали в данной публикации:
Теперь вы можете смело добавлять свой код в любой проект, в любое место просто взяв его {в фигурные скобки} и все - секундное дело.
это scope. Ограничение области видимости переменных. А var - способ пробиться за границы блочной видимости:
var namespaceOne = {First: First, Second: Second, Third: Third};Вы должны каким-то образом обеспечить уникальность всех var namespaceX в пределах вашего проекта, чтобы не получилось нечто типа такого:
{
class First {}
var namespace = {First};
}
{
class Second {}
var namespace = {Second};
}
{
const ns = namespace; // {Second}
}Вот это "каким-то образом обеспечить уникальность" и есть про namespace'ы (т.е., про идентификацию).
В общем, коллеги выше правы - используйте es-модули. У каждого модуля уже есть свой scope. А ещё у каждого модуля есть свой адрес, уникальный в пределах приложения.
Спасибо. Комментарии учитываются и отражаются на статье. Чтобы каша из топора была понаваристее.
Namespaces в JavaScript. Ставим точку в вопросе