Как стать автором
Обновить

Комментарии 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. А ещё у каждого модуля есть свой адрес, уникальный в пределах приложения.

Спасибо. Комментарии учитываются и отражаются на статье. Чтобы каша из топора была понаваристее.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации