А кто сказал что в ES6 не должно присутствовать var?

Question

[copal]

Сегодня прочел статью frontender.info/const-immutability, в конце которой говорится что -

(var не должно использоваться в ES6)

Это правда?? Просто статья вызывает сомнения в авторе и в цитируемом утверждении...

Answer 1

[Сергей Протько]

90% переменных должны быть const, остальные let. Для var места не остается, хотя конечно его можно юзать, но это будет тоже самое что let. Их должно быть мало.

Comments

[Александр Таратин]

Сергей Протько Вы не в курсе случайно как обстоят дела с производительностью const и let в современных браузерах и nodejs (без использования транспилеров и с ними) ?

[copal]

const не может заменить var для примитивов, а let не является аналогом var, так как она действует только в своей зоне видимости и наверняка, а как иначе, реализует долее сложный механизм в отличии от var, как например arrow function отличается от обычной function. Использовать let как альтернативу var ведь глупо же, ровно так же как и arrow function писать везде из-за её короткого синтаксиса. В чем я не прав?

[copal]

был не прав, измерил скорость, она одинакова для всего..

[copal]

Александр Таратин: в chrome скорость одинаковая. Но если не использовать use strict, то const пятнадцать раз медленнее чем переменная.

[copal]

'use strict';

const REPEAT = 5;
const ITERATION = 100000000;
const DELAY = 3000;

function run(){
    for(var i = 0; i < REPEAT; i ++){
        console.log(`тест №${i}, затраченное время: ${test()}`);
    }
}

// var === 200
// const 200
// let 200

function test(){
    var startTestTime = new Date().getTime();
    
    for(var i = 0; i < ITERATION; i++){
        var prop = 999;
    }
    
    var finishTestTime = new Date().getTime();
    var elapsedTestTime = finishTestTime - startTestTime;
    
    return elapsedTestTime;
}

var delay = window.setTimeout;

delay(function(){
    clearTimeout(delay);
    run();
}, DELAY);

[Дмитрий]

Интересно, почему вы считаете что 90% переменным надо запретить право на изменение в дальнейшем? В моей практике переменные редко подвергаются динамическим изменениям, но это уж точно больше чем 10% случаев.

[copal]

Дмитрий Пищалка: возможно дело в том, что ПОКА константы нельзя делать свойствами объекта. То есть публичные свойства, которые нужно либо изменять, либо переопределять записываются как this, а в функциях же редко код локальные переменные меняются, по этому их можно было бы и константами записывать, но это напрочь убьет саму суть констант. То есть мое мнение, что теоретически можно было бы и больше 90% записывать как конст, но нафиг это нужно.

[Сергей Протько]

Дмитрий Пищалка: потому что надо стремиться к этому. Есть задачи где это недостижимо, есть задачи где можно в 100% случаев оперировать имутабельными штуками.

copal не нужно пихать все в объекты, это глупо. У вас есть модуль, маленькое изолированное простанство, у вас есть тело функций, маленькие изолированные пространства. Чем меньше мы состояния имеем - тем проще с системой работать. Вот и все. Погуглите "Uncle Bob - The failure of state"

[copal]

Сергей Протько: ну да, с сего момента начну все локальные переменные как школьник константами объявлять. Чего у локальные, даже сами функции буду сохранять в константы и потом их в качестве констант константам присваивать.
И к сожалению я не могу понимать не русифицированные данные в том виде в котором они бы могли принести пользу. Но я искренне надеюсь что функциональный подход вообще не использует события. А то есть чувство, что скоро начнут говорить о том, что знал много лет назад но говоря об этом все говорили что это ерунда.

[Сергей Протько]

copal: https://www.youtube.com/watch?v=7Zlp9rKHGD4

[copal]

Сергей Протько: извините, но это полная х*ня. Писать тысячу switch в которых тысячу if в языке с hash и map может только даун. И это относится и к рекурсиям вместо циклов. И все это безумие сравнить с кислородом и природным циклом тогда, когда известно слово коллапс и перенасыщение только ещё больше вызывает чувство, что сейчас выбежит карлик и закричит - повелись?! И мне без разницы что память дешевая, я не буду писать шлак только из-за того, что так можно.

Пусть хоть сам исус мне скажет чтобы я за миллион долларов такой код стал писать, я его пошлю.

[copal]

Сергей Протько: сидеть и держать в голове все эти "крошки", которые можно по человечески собрать в одном правильном объекте и работать ни о чем не думая. Память выросла, так пользуйтесь объектами, создавайте типы - классы. Но нет, нужно писать как чмо строки вместо типа и говорить что сто switch круче обычного объекта-хеша. И все это говно прикрывать (для чего-то???) типизированным TS и закрывать глаза за говнокод в закулисье angular2.
Это у меня наболевшее! Целый день сижу и пытаюсь создавать vo не из классов, а из функций-фабрик которые объекты возвращают и так запутался с этими осколками, что забил и начал классами писать, если что уже потом оптимизирую.

[Сергей Протько]

copal: давайте вспомним зачем понадобились объекты. Объекты понадобились что бы "спрятать" мутируемое состояние и расположить поведение поближе к оному (гуглить про high cohesion). А если у нас нет состояния, достаточно обойтись модулями и функциями.

И да, классы это рак ООП.

[copal]

Сергей Протько: классы в контексте js, это единственный способ получить тип. Symbol пока меня не устраивает вообще по всем показателям. В таком виде в котором он есть, он бессмысленный.
Я не знаю природу появления объектов, но как по мне так другого и не нужно. Java + С# + TS с их ООП стилем мне хватит на столько, пока не надоест вообще писать. Код нужно писать так, чтобы не требовались комментария. Это компиляторы должны код оптимизировать и выявлять-устранять утечки, а не программисты. Я повторюсь, будь оно хоть тысячу раз модно, я не буду писать рекурсию там где можно использовать цикл, хотя люблю рекурсии, но считаю что их нужно использовать только для работы с деревьями и некоторые другие исключения. А писать if и особенно switch, который вообще не должен использоваться с break, breack как последняя необходимость этой конструкции, даже в ооп является плохим тоном.

[copal]

Сергей Протько: для примера кусок кода в котором функции не объявляют локальных переменных и это получается как само-собой разумеющееся. Но я даже в мыслях не хочу думать что map и hash я заменю if'ами. да и то, этих жутких строк можно было бы избежать будь в js на уровне религии типы как в java, тогда бы я на каждый компонент создал свой тип и избавился от этих map'ов. Но это js и приходится мерится.

const displayObjectSystem: System = new DisplayObjectSystem();
const hash: Map<Entity, EntityNode[]> = new Map<Entity, EntityNode[]>();

const components: {[name: string]: Component} = {};
components['ElementComponent'] = ElementComponent;
components['RectangleComponent'] = RectangleComponent;
components['CursorComponent'] = CursorComponent;

const alias: {[name: string]: string} = {};
alias['element'] = 'ElementComponent';
alias['currentPosition'] = 'RectangleComponent';
alias['nextPosition'] = 'RectangleComponent';
alias['cursor'] = 'CursorComponent';

function register(entity: Entity, node: EntityNode): void {
    if( ! hash.has(entity)){
        hash.set(entity, []);
    }

    hash.get(entity).push(node);
}



function getComponentInstanceByName(name: string): Component {
    return new (components[alias[name]] as Component)();
}

function lasyInstallEntityNode(name: string, entity: Entity): Component {
    if( ! entity.hasComponent(name)){
        entity.insertComponent(name, getComponentInstanceByName(name))
    }

    return entity.getComponentByName(name);
}



function buildDisplayObjectEntity(entity: Entity): Entity {
    entity.insertComponent('element', new ElementComponent());
    entity.insertComponent('currentPosition', new RectangleComponent());
    entity.insertComponent('nextPosition', new RectangleComponent());

    return entity;
}

function buildDisplayObjectNode(node: DisplayObjectNode, entity: Entity): EntityNode {
    node.element = lasyInstallEntityNode('element', entity) as ElementComponent;
    node.staticPosition = lasyInstallEntityNode('currentPosition', entity) as RectangleComponent;
    node.dynamicPosition= lasyInstallEntityNode('nextPosition', entity) as RectangleComponent;

    displayObjectSystem.nodes.push(node);

    return node;
}

let entity: Entity = new Entity();
let node: DisplayObjectNode = new DisplayObjectNode();
let node: EntityNode = buildDisplayObjectNode(node, buildDisplayObjectEntity(entity));

register(entity, node);

[Сергей Протько]

copal:

Это компиляторы должны код оптимизировать и выявлять-устранять утечки, а не программисты.

А как же локи, сокеты, ресурсы, пайпы, шаред мемори? Компилятор вам ничего не должен. Да и весьма просто можно сделать утечку памяти даже в языках со сборщиками мусора.

Что до свитчей и т.д. - есть такая штука как patternmatch. Распростаренное заблуждение что ООП придумали что бы избавиться от свитчей/if-в, на самом деле их просто "прячут".

[Сергей Протько]

copal:

Но я даже в мыслях не хочу думать что map и hash я заменю if'ами

тут скорее абстрактная фабрика нужна.

[copal]

Сергей Протько: это минимальная точка отправления после дня пыток с функциями-фабриками. Сейчас да, собрал все в class=>static=>фабрику, но опять палка о двух концах. TS говорит что фабрик должно быть много, хотя бы для каждого типа-интерфейса, но в js это будет выглядеть как копипаст, ведь типы исчезнут и останется куча одинаковых фабрик.

И я могу согласиться, хотя и точно не знаю, что if прячут и это хорошо, зачем я буду писать как компилятор. если автор оправдывается излишком памяти, так зачем ковыряться с функциями, нужно начинать плодить тип на каждый момент, как в java. сделали бы is оператор и interface. я за ооп.

[Сергей Протько]

copal: вы же понимаете что "класс" с одним статическим методом-фабрикой это как бы все та же функция?

У вас в голове какая-то идея-фикс на тему того, что все должно быть в контексте классов, хотя все внимание должно уходить на взаимодействие объектов. А так как функция - это объект, то не вижу ничего такого, что мы можем юзать чисто их. Тем более если у нас вообще нет состояния (только поведение).

С другой стороны я не вижу смысла писать в продакшен на каком-нибудь haskell, разве что мы не занимаемся математикой и т.д.

[copal]

Сергей Протько: да понимаю, но у меня нет идеи контекста класса, у меня паранойя развивается от мыслей что нет состояний. Все Ваши слова склоняют в сторону использовать функции, но как? Вместо Map, вместо for и while? Нет! использовать их без состояний, а где тогда будут состояния? Ведь даже тот же json, это уже состояния.

[Сергей Протько]

copal: json - это значение. Пока мы не мутируем значение - у нас нет концепции времени и следовательно какого либо состояния. Все как в математике.

Конечно же в реальности совсем без состояний никак, но можно идти на ухищрения. Например представлять состояние как коллекцию действий (event sourcing, flux, redux), или же заворачивать какие-то stateful штуки в монады. Но это уже усложнение большое.

Лично мне нравится идея совмещения ОО подходов и функциональщины (минимизация мутаций).

[copal]

Сергей Протько: я Вас не понимаю...

А так как функция - это объект, то не вижу ничего такого, что мы можем юзать чисто их.

Значит функция у Вас объект, а объект имеющий состояния у Вас не объект имеющий состояния. Или Вы забыли что свойства объекта есть его состояния?) Команды это список тасков, которые !хранит! этот список и выполняет последовательно. То есть json не вписывается в ту концепцию, на которую Вы мне дали ссылку.

[Сергей Протько]

copal: повторяю - если значения не меняются, то у нас нет состояния. Все имутабельно. И все объект. И все хорошо.

Answer 2

[Никита Конин]

Dr. Axel Rauschmayer сказал.

Если в кратце, то лучше использовать const везде где возможно, а для изменяемых переменных let. При этом поведение let и var отличается. Область видимости var ограничена функцией, область видимости let ограничена блоком. Поэтому лучше выкинуть var и использовать let из-за более предсказуемого поведения и меньшего риска допустить ошибку.