Черт. Напрягает биндить в конструкторе.

+

https://github.com/tc39/proposals - ваще вот, тут про private пишут stage 1

ну статик пропертис вон еще что держит https://github.com/tc39/proposal-class-public-fields/issues/27

какую-то хрень обсуждают. Сделали бы уже тупо синтаксическим сахаром к SomeClass.staticField = 123

нельзя

все не так просто

нельзя потому что?

ну статик пропертис вон еще что держит https://github.com/tc39/proposal-class-public-fields/issues/27

Ну проперти судя по всему будут. Единственная полблемка - это Should we tweak the syntactic token to look less like assignment? (leading idea: :=)

Понял тебя, спасибо

нельзя потому что?

потому что, например, надо определиться как быть там с this

https://github.com/tc39/proposal-class-public-fields/issues/34

как с обычными функциями. То есть из скоупа выше

https://github.com/tc39/proposal-class-public-fields/issues/42

и тд

как с обычными функциями. То есть из скоупа выше

нельзя просто так взять и взять скоуп выше

потому что, например, надо определиться как быть там с this

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

сразу будет понятен скоуп

речь о пропертях, а не методах

паблик методы уже есть с es6

почему нельзя? babel же может

бабель может наивную реализацию как угодно сделать

class Foo { static singleton = () => new this; } var Foo = function Foo() { _classCallCheck(this, Foo); }; Foo.singleton = function () { return new undefined(); };

а движкам нужна спека

блин, ну реально же все просто

это так только кажется

у arrow-function нет своего this

он берет this родительский. Все, почему это поведение нельзя сохранить?

ты точно читал ишусы?)

я прочел тот, что ты скинул

я скинул про this как минимум 2

и еще есть 3 темы на esdiscuss

@chicoxyzzy спасибо за инфу

не за что

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

потому что язык говно

и поэтому мы вечно будем использовать babel)

@chicoxyzzy я помню ты выяснял что брать TS/flow. Для проекта на реакте в итоге что лучше?

так я давно уже за тс топлю

https://github.com/shockone/black-screen

и поэтому мы вечно будем использовать babel)

хз, больше особо крутых фич пока не планируется

из того, что можно транспильнуть

так я давно уже за тс топлю

https://github.com/kripken/emscripten :) (:

за wasm я тоже давно топлю. а асмжс не нужен особо

ну, собственно static fields для propTypes/defaultProps, async-await минимум год, object {...spread}

асинк эвэйт уже в es2017

из того, что можно транспильнуть

А что такое транспильнуть?

нет вроде

да

А что такое транспильнуть?

let foo = 123; -> var foo = 123

рест/спред может в 2018 попадет

а может и в 2017 успеет, хотя вряд ли

А что такое транспильнуть?

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

а может и в 2017 успеет, хотя вряд ли

А пайплайны когда?

|>

transpiler - компилятор из одного яп в другой

из исходников в исходники

а может и в 2017 успеет, хотя вряд ли

ну там рокету нарисовали) можно хотя бы надеяться)

рокета еще ничего не значит

значит что обсудят, не?

и для stage 4 надо еще чтобы два браузера заимплементили

а там es5 полностью только у эджа и ff

значит что обсудят, не?

да, в сентябре

в конце

ERROR: S client not available

если Себастьян сможет в сентбре приехать на митинг

жесть

ну, собственно static fields для propTypes/defaultProps, async-await минимум год, object {...spread}

А еще someMethod = () => {}

я в stage-0 посмотрел. А есть какая-то первая линия отсева бреда?) чтобы важное не задерживать?)

вложенные импорты от метеорца там самый пздц

А еще someMethod = () => {}

я не согласен тут, там вот реально больше вопросов, чем ответов) Потому Сережа и предлагал отделить static и обычные проперти

самое херовое что typed objects убрали совсем(

Ломов тоже из жс ушел

счастливый человек

будь я в комитете - я бы предложил импорты вообще заморозить, пока браузеры и нода их не имплементируют. Потому что это сейчас просто сахар для common.js)

и до 2020 ваще про модули забыть)

+

с другой стороны, сами загрузчики похоже все же уйдут из whatwg спеки в ecma262

То есть как то сделать а потом стандарт изобрести?

и они юзают ecma262

так что она им нужна-таки

То есть как то сделать а потом стандарт изобрести?

текущие импорты никак не тормозят работу whatwg

которые над загрузчиками работают

tc39 пока можно расслабиться

и надолго

нет, сделать то, что уже стандартизировали. А потом уже накручивать динамические импорты, если вообще это все еще нужно будет

также, прежде чем делать private/public (которые ИМХО нафиг не нужны), надо закончить все пропосалы по пропертям

так-то динамические импорты уже 100500 лет есть

можно тег скрипт вставить)

также, прежде чем делать private/public (которые ИМХО нафиг не нужны), надо закончить все пропосалы по пропертям

они все связаны

поэтому их рассматривают вместе

так у модулей свой скоуп)

чтобы не получилось как то говно, которое ща спешно убирают из спеки

а, еще давно вопрос был

так-то динамические импорты уже 100500 лет есть

Жсонп?