На очередном собрании Генеральной Ассамблеи ECMA (http://www.ecma-international.org/memento/GA.htm) официально утверждён (http://www.ecma-international.org/news/index.html) стандарт ECMAScript 2015 (http://www.ecma-international.org/ecma-262/6.0) (PDF (http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf)), более известный как ECMAScript 6 или "ECMA-262 6th edition".ECMAScript 6 продолжает линейку стандартов, определяющих базовые функциональные возможности JavaScript, реализованные для всех web-браузеров. Прошлый стандарт ECMAScript 5 был принят в 2009 году, а позапрошлый в 1999 году. Долгое время развитие стандарта было заморожено из-за трудноразрешимых разногласий среди производителей браузеров, одни из которых выступали за внесение значительных изменений в JavaScript, а другие настаивали на сохранении полной семантической совместимости.
Основные нововведения ECMAScript 6:
- Поддержка классов и деструкторов. Например (https://github.com/GoogleChrome/samples/tree/gh-pages/classe...):
<font color="#461b7e">
class Polygon {
constructor(height, width) {
this.name = 'Polygon';
this.height = height;
this.width = width;
}sayName() {
log('Hi, I am a ', this.name + '.');
}
}let p = new Polygon(300, 400);
</font>
- Шаблоны строк, предоставляющие удобные средства для форматирования строк. Шаблоны строк являются строковыми литералами, допускающими встраивание выражений. Выражения определяются в размещённом внутри строки блоке ${...}, который может включать как отдельные переменные (${name}), так и выражения (${5 + a + b})). Например, в результате выполнения "var message = '1 + 1 = ${1 + 1}'" в переменную будет записана строка "1 + 1 = 2";- Поддержка лексических объявлений переменных (Lexical Declarations (https://github.com/GoogleChrome/samples/tree/gh-pages/lexica...)), позволяющих ограничить текущим блоком область видимости ключевых слов, через их повторное определение при помощи выражения let вместо var (пример (https://github.com/GoogleChrome/samples/blob/gh-pages/lexica...));
- Тип Symbol (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), применимый для идентификаторов свойств объектов;
- Генераторы, позволяющие организовать эффективное выполнение функций в асинхронном режиме. Генераторы представляют собой специальные функции, генерирующие итераторы. Использование выражения yield для генератора, позволяет приостановить его выполнение и вернуть управление вызвавшей генератор функции. Особенность генераторов состоит в том, что последующие вызовы будут использовать предыдущее состояние и продолжат выполнение кода генератора с того места, где он был приостановлен.- Оператор 'let (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)' для определения локальной области видимости переменной, ограниченной пределами текущего блока;
- Объект WeakSet (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), позволяющий определить множество из объектов, в котором применяются эффективные с точки зрения потребления памяти структуры, использующие сборщик мусора для удаления неиспользуемых объектов (объект удаляется, если на него больше не осталось ссылок, кроме ссылки из текущей коллекции);
- Cтруктурs данных Map (https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ma...) и Set (https://people.mozilla.org/~jorendorff/es6-draft.html#sec-se...), упрощающих (http://updates.html5rocks.com/2014/08/Collecting-and-Iterati...) работу со специфичными типами коллекцией. Map позволяет определять коллекции наборов в формате ключ/значение, при том, что в качестве ключа и значения могут выступать любые выражения JavaScript. По аналогии Set позволяет задать множество любых выражений JavaScript;
URL: https://mail.mozilla.org/pipermail/es-discuss/2015-June/0432...
Новость: http://www.opennet.me/opennews/art.shtml?num=42450
Замечаю в последнее время как Джависты переходя на JS, тащят с собой весь свой легаси-абстрактный-бред вроде DAO с кучей не делающего ничего кода
А как у них может получаться тащить его с собой, они что переписывают этот код на JS, или считают удобным как-то запускать яву из яваскрипта?
GWT
да, переносят свой мега-абстрактный код на JS,
Фабрики там другую хрень, без понимания а нужна ли она в JS, в динамическом языке
Их нужность зависит не от языка, а больше от размеров проекта. В смысле - это устоявшийся, показавший совю применимость метод создания большого софта. Ка в плане написания так и способа думать о нём так, чтобы голова не взрывалась. И когда в браузер приходит что-то соответствующих объёмов - приходится всё это дело применять.В сущности, чем больше проект - тем больше вреда от всяческой динамичности и больше пользы - от явно описанного всего и вся.
> Замечаю в последнее время как Джависты переходя на JS, тащят с собой
> весь свой легаси-абстрактный-бред вроде DAO с кучей не делающего ничего кодаНет, не переходят, но добавляют в свой инструментарий ;-)
Кхм, по моему DAO одна из самых естесственных вещей среди прочих паттернов, Вы так или иначе будете его использовать при работе с данными, а называть можете как угодно )))
>>Поддержка абстракции массивов (Array comprehensions), дающих возможность создания нового массива на основе другого массива;Эту python-фичу в следующую версию планируют. ES7, правда её обещают выпустить гораздо оперативнее чем ES5 -> ES6, поживём увидим.
>>This is an experimental technology, part of the Harmony (ECMAScript 7) proposal.
Что, целочисленных типов так и не ввели? Зря. В Lua вон уже есть.
>Что, целочисленных типов так и не ввели? Зря. В Lua вон уже есть.Разработчик LuaJIT сказал, что для новой версии Lua ничего делать не будет: лэнгвич форкд, все в лес. Так что уже неважно, чего там в lua есть: важно, что последними версиями пользоваться проблематично на текущий момент.
С такими map, для которых get/set надо писать, пусть они пройдут лесом, а дальше полем. Покосят травы, покурят и оставят IT кому-нибудь другому.
Я что-то не понял щито тебя не устраивает? В обычных map тоже get/set есть и что?
Или это ты так примера с ClearableWeakMap испугался? Так это пример как прикрутить сбоку то, что не сильно-то и нужно.
Меня бесит это убогое джавовское многословие. Нормальный вариант использовал бы квадратные скобки. Я в курсе, что в JS так пропертя JS-объекта адресуются - но по-моему это решаемый вопрос. А ещё лучше - если бы мапу не вводили вообще, а наделили её свойствами пустой объект, который {}. И для set сделали бы интерфейс как для булевой мапы, т.е. чтобы можно было писать if (mySet['x'])... А так - единственным преимуществом JS как языка (ну, кроме того, что в вебе ему альтернатив нет) была относительная компактность. И они её зачем-то гробят.
И как предлагаешь объявлять WeakMap если наделить пустой объект свойствами обычного Map? А так у нас общий синтаксис между ними и даже Set и WeakSet, и он никак не перегружает обычные объекты мусором, который там даром никому не нужен.Кстати, с текущим синтаксисом has можно сделать вот так:
let a = new Set(['a','b']), b = ['a','c','b'];
console.log(b.map(a.has,a)); // >> Array [ true, false, true ]В реальных же недостатках то, что нужно указывать контекст работы, что делает такой вызов этих функций существенно менее гибким, чем хотелось бы. Например, нельзя сделать так:
let a = new Set(['a','c']), b = new Set(['b','d']), c = {one:a.has,two:b.has};
c['one']('a'); //TypeError: has method called on incompatible Object
Можно, конечно, сделать c = {one:x => a.has(x),two:x => b.has(x)}, но проще уже сделать c = {one:a,two:b} и потом вызывать c['one'].has('a');
Да и в предыдущем примере без контекста (",a") код падает с ошибкой.
Да масса вариантов, как объявлять - один хрен это магия движка, а не библиотечные классы. Например, obj = WeakMap.transform(obj);Впрочем, в свете сегодняшней новости всё это мелочи. Недолго джаваскрипту жить осталось, чему я не передать как рад.
а если историю про Dart вспомнить? подвижка конечно хорошая, но лишь бы до масс дошло
Разница очень проста. Дарт - это был только гугл. Здесь - гугл, мозилла и майкрософт.
cинтакcиc не юзабельный
О, там совсем круто - оно даже в JSON не экспортируется обычным JSON.stringify. Я уже представляю новую версию jquery, которая будет костылить преобразование, скармливая свой replacer... Ну вот неужели они вообще никак не задумывались о том, как оно будет применяться?
А то, что WeakMap и WeakSet оперируют объектами и то, что у объектов могут быть приватные свойства, которые JSON.stringify всё одно потеряет, тебя не смущает? Оно не предназначено для экспорта в JSON. Более того, если тебя угораздит объявить WeakSet объектами, на которые никто более не ссылается (при обратной сборке из JSON именно это и случится ведь), то после первой же сборки мусора он у тебя станет пустым.
Конечно смущает. По уму - должен быть штатный механизм, позволяющий прибить к объекту (а не к сериализатору) логику сериализации.
Штатного метода сериализации объектов не существует хотя бы потому, что они могут находиться в неопределённом состоянии, ожидая возврата данных извне, или состояние может зависеть от времени и возможно, что его нельзя просто поднять из снапшота, а нужна какая-то реинициализация. Т.е. корректный сериализатор/десериализатор может написать только сам автор объекта. Потому и решили не заморачиваться.Ну а в случае с WeakMap/WeakSet, как я уже говорил, восстановление из снапшота просто не имеет смысла. На объекты должны существовать ссылки извне, а иначе они будут автоматически выброшены на этапе сборки мусора.
Дык, я о чём? Именно автор объекта. И этот сериализатор должен быть автоматом задействован - благо, как - давно понятно - если у объекта объявлен соответствующий метод - допустим, serialize - то вызывать его. Если нет - то валимся с ошибкой, если не указан replacer. Вот это было бы корректным поведением, защищающим от ошибок по невнимательности. Для Map приемлемым решением была бы сериализация в JSON-объект, для Set - в массив или в какой-нибудь специализированный вариант JSON-объекта.
Для Weak вариантов - восстановление-то смысла не имеет, а вот сериализация - вполне. Ну да, это думать надо - ну так вот из подобного и складывается удобство языка.Ну ладно, теперь это будет реализовано (поведение-то совершенно очевидное) в очередном jQuery, делов-то. С кучей проверок типов и вообще наверняка неоптимально. Ну да тем, кто на JS пишет, не привыкать.
Не очень понимаю, зачем нужны классы, если они и так де-факто присутствуют. Javascript же prototype-based уже. Чем class newClass{constructor()} удобнее, чем function Class(){}? Неужели только тем, что первый метод - буквальнее? Все равно расширять, добавлять методы и т.п. придется через someClass.prototype. Или у этих новых классов есть какие-то еще крутые фичи?
Не понимаю зачем нарушать дзен функционального минимализма и превращать JS в монстра типа PHP.Помогите разобраться, чего я недопонял?
Строго говоря смысла делать new func тоже нет.Можно (и даже нужно) писать так:
let Polygon = {
create: function(height, width) {
let self = Object.create(this);
self.name = 'Polygon';
self.height = height;
self.width = width;
return self;
},
sayName: function() {
return 'Hi, I am a ' + this.name + '.';
}
}let p = Polygon.create(300, 400);
console.log(p.sayName());Это то, как изначально задумывалось работа с объектами в JS.
А new func только проблемы создаёт. Особенно если случайно забыть написать new. При таком же подходе это просто невозможно.
> Секта свидетелей жабы, ваши вызовы функций обросии жиром со всех сторон…А теперь создадим новый объект и расширим его, добавив функцию площади:
let AreaPolygon = Object.create(Polygon);
AreaPolygon.area = function(){return this.height * this.width};let p = AreaPolygon.create(300,400);
console.log(p.sayName());
console.log(p.area());
ok.а как в вашем примере переопределить метод-функцию класса-объекта, при это вызвав этот же метод родителя?
пример псевдокод:
AreaPolygon () {
sayName: function() {
return "It's " + super().sayName() + " & AreaPolygon";
}
}
> ok.
> а как в вашем примере переопределить метод-функцию класса-объекта, при это вызвав этот
> же метод родителя?Не уверен, что это корректный способ, но лично я сделал бы вот так:
AreaPolygon.sayName = function() {
return Polygon.sayName.call(this) + " My area is " + this.area() + " of square something."
}Хотя, конечно, можно было бы сделать AreaPolygon.parent = Polygon и потом просто дёргать this.parent.sayName(). Зависит от того нужно ли тебе свойство parent или нет.
Впрочем, с наследованием новых свойств от объекта-родителя наличие/отсутствие такого полня проблемы не создаёт:
Polygon.setName = function(name) {this.name = name}
p.setName('Rectangle'); // p тут объект класса AreaPolygon
console.log(p.sayName())
твой пример не работает, ну а трансляторы генерируют в два раза больше кода если в стиле ES5https://babeljs.io/repl/#?experimental=true&evaluate=true&lo...
У меня в консоли фокса так:
<<
let Polygon = {
create: function(height, width) {
let self = Object.create(this);
self.name = 'Polygon';
self.height = height;
self.width = width;
return self;
},
sayName: function() {
return 'Hi, I am a ' + this.name + '.';
}
}let AreaPolygon = Object.create(Polygon);
AreaPolygon.area = function(){return this.height * this.width};let p = AreaPolygon.create(300,400);
AreaPolygon.sayName = function() {
return Polygon.sayName.call(this) + " My area is " + this.area() + " of square something."
}Polygon.setName = function(name) {this.name = name}
p.setName('Rectangle');
console.log(p.sayName())>> "Hi, I am a Rectangle. My area is 120000 of square something."
А пример с parent — похоже я что-то напутал. Всё одно нужно вызывать через "sayName.call(this)"
Кстати, мой код может не работать из-за let в Хроме. Там есть ограничения где он сейчас работает.
var Polygon = {
create: function(height, width) {
let self = Object.create(this);
self.name = 'Polygon';
self.height = height;
self.width = width;
return self;
},
sayName: function() {return 'Hi, I am a ' + this.name + '.'},
setName: function(name) {this.name = name}
}var AreaPolygon = Object.create(Polygon);
AreaPolygon.predoc = Polygon;
AreaPolygon.area = function(){return this.height * this.width};
AreaPolygon.sayName = function() {
return this.predoc.sayName.call(this) + " My area is " + this.area() + " of square something."
}var ap = AreaPolygon.create(300,400);
ap.setName('Rectangle');console.log(ap.sayName())
Да выше работает, но удобнее один раз указать родителя для объекта и потом на него ссылаться.
А вот если объект вместо Ява-стайл сеттеров и геттеров, то тут становится уже сложнее, по крайне мере навскидку решение мне не приходит в голову:var Polygon = {
create: function(height, width) {
let self = Object.create(this);
self.name = 'Polygon';
self.height = height;
self.width = width;
return self;
},
get pname() {return 'Hi, I am a ' + this.name + '.'},
set pname(name) {this.name = name}
}
...Есть что предложить?
Вот такое вот получилось:var AreaPolygon = Object.create(Polygon);
AreaPolygon.p = Polygon;
AreaPolygon.area = function(){return this.height * this.width};
Object.defineProperty(AreaPolygon, 'pname', {
set: function(name) {this.p.__lookupSetter__('pname').call(this,name)},
get: function() {
return this.p.__lookupGetter__('pname').call(this) + ' My areas is '+this.area()+' square something.'
},
configurable:true}); // configurable - возможность изменять/переопределятьvar p = AreaPolygon.create(100,200);
p.pname = 'Rectangle';
console.log(p.pname);>> "Hi, I am a Rectangle. My areas is 20000 square something."
ага, интересно. Единственное на сайте developer.mozilla.org/ru/docs/Web/JavaScript
__lookupGetter__ объявлен устаревшим и не эквивалентно работающим в разных браузерах, рекомендуют getOwnPropertyDescriptor
var AreaPolygon = Object.create(Polygon);
AreaPolygon.p = Polygon;
AreaPolygon.area = function(){return this.height * this.width};Object.defineProperty(AreaPolygon, 'pname', {
set: function(name) {
name = ' BIG ' + name;
Object.getOwnPropertyDescriptor(this.p, 'pname')['set'].call(this, name)
},
get: function() {
return Object.getOwnPropertyDescriptor(this.p, 'pname')['get'].call(this) + ' My areas is '+this.area()+' square something.'
},
});var p = AreaPolygon.create(300,450);
p.pname = 'Rectangle';
console.log(p.pname);>> Hi, I am a BIG Rectangle. My areas is 135000 square something.
Есть так же в Object.defineProperty(obj, 'key', {
__proto__: nullно функциональность __proto__ и его полезность опробовать не получилось.
> __lookupGetter__ объявлен устаревшим и не эквивалентно работающим в разных браузерах, рекомендуют getOwnPropertyDescriptorНадо будет запомнить. Спасибо. Кстати, вместо ['set'] и ['get'] можно писать просто .set и .get. Если возникнет необходимость передать неопределённое множество параметров, то вместо .call(this,arg1,arg2,...) можно использовать .apply(this,arguments).
> Есть так же в Object.defineProperty(obj, 'key', {
> __proto__: null
> но функциональность __proto__ и его полезность опробовать не получилось.Им рекомендуют без крайней нужды не пользоваться в виду проблем с производительностью: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
К тому же при данном подходе к созданию объектов у них нет прототипов и свойство obj.prototype отсутствует.
ок, благодарю полезный тред получился.
А вот вариант твоего кода без классов:
var Creature = {
create: function(name) {
var self = Object.create(this);
self.type = name;
return self;
},
descr: function() {
return " GIANT " + this.type;
}
}
var Fish = Object.create(Creature);
Fish.create = function(name) {
var self = Creature.create.call(this, '6 meter long '+name);
self.name = name;
return self;
}
Fish.descr = function() {
return "It was" + Creature.descr.call(this);
}var fish = Fish.create("shark");
console.log(fish.descr());
Он конечно немного жирнее будет, но не так же, как это сделал Babel.
>[оверквотинг удален]
> self.name = name;
> return self;
> }
> Fish.descr = function() {
> return "It was" + this.parent.descr.call(this);
> }
> var fish = Fish.create("shark");
> console.log(fish.descr());
> Он конечно немного жирнее будет, но не так же, как это сделал
> Babel.ага, не увидел сразу твой ответ, сам примерно так написал выше.
AreaPoligon.sayName=function(super) { return function() { return "It's" +super()+"& AreaPolygon"; }}(Polygon.sayName);
навскидку:
- нельзя вызвать напрямую, без new - частая и тупая ошибка с function Class.
- геттеры/сеттеры там же
- наследование через extends, так что prototype не при делах.
Плюс всякие расширенные возможности вроде итераторов.Если коротко - то да, буквальнее. Всегда хорошо, когда синтаксис совпадает с семантикой, меньше голова мусором забивается.
Ребята, спасибо!P.S.: Про extends - действительно, напоминает монстра PHP.
Минимализм хорош в минималистичных программах, а когда у тебя кода столько, что минифицированным получается два мегабайта - то лучше когда как пишется, так и читается.
Я конечно понимаю что js применяют где попало и не совсем по назначению, но всё таки 2Мб. наводит на нехорошие мысли.p.s. С тем что лучше как пишется так и читается, полностью согласен :)
Посмотри, сколько весят какие-нибудь гуглодоки, или морда групвари. Да и на обычных сайтах бывает - особенно на чём-то вроде газет, где тянется куча стороннего кода - партнёры, реклама, трекеры и т.д. Просто если оно тащится не одновременно объём не слишком заметен, но в общем кодовая база, которая должна как-то совместно работать немаленькая.
Что-то у меня сильное подозрение, что теперь они в седьмой версии смогут с чистой совестью задепрекейтить прототипы, так как их никто не будет использовать кроме пары упрямцев. У них было ровно два применения, насколько я видел - рискованные извращения с существующими объектами вроде того, что творил Prototype и, собственно, эмуляция классов. Или есть ещё какие-то примеры где оно действительно надо?
Для этого нет никаких причин. Prototype- и Class based OOP - две разные парадигмы. Каждая из них имеет плюсы и минусы и будет использована умным программистом в соответствии с задачей. Если, конечно, он умеет пользоваться инструментом и руки растут откуда надо.Навскидку: http://programmers.stackexchange.com/questions/110936/what-a...
И как справедливо замечено по ссылке, "the main advantage of prototype-based OOP its that objects & "classes" can be extended at runtime".
Еще:
http://stackoverflow.com/questions/816071/prototype-based-vs...
http://stackoverflow.com/questions/879061/what-are-the-advan...
Ну, об этом "advantage" я упоминал - и в конце концов стало общепризнанным, что Prototype.js, который на этом построен - плохая штука. Как бы не в 99% случаев любые фокусы вроде "extended in runtime" - это поиск проблем в поддержке. И вот то, что в этом ответе перечисляется - как раз оно. Это аргументы хакера, который в одиночку колдует над хитрым кодом, понятным только ему, причём понятным полностью.Я так понимаю, что JS перерос прототипную модель. Когда тебе нужен сравнительно мелкий скрипт - можно написать какой угодно гениальный код. Но когда у тебя большое приложение или куча third party компонент (а сейчас на сайте десяток чужих библиотек подтянуть - норма, причём они постоянно меняются) - игры с прототипами становятся слишком рискованными.
Эдак Вы дойдёте до утверждения, что любое порождение процедуры ли, объекта или просто выполнение eval - моветон. Но это не так. Существуют задачи, решение которых существенно упрощается при таком подходе. Например, это задачи символьного исчисления, программирования AI.> ... то, что в этом ответе перечисляется - ... это аргументы хакера, который в одиночку колдует над хитрым кодом, понятным только ему ...
Область применения пораждает пользователей языка, а пользователи - требования к нему. Я тут хочу заметить, что языки производятся, исходя из требований, которые диктуются не областью применения и даже не сложностью решаемых задач. Они диктуются пользователями языка и их возможностями осваивать и применять технологию.
Если бы все программисты могли бы быть хакерами, высококлассными it-специалистами, то сейчас бы у нас было засилье лиспов и т.п., как наиболее мощных по выразительности языков, ныне существующих. А тут - имеем, что имеем. Поэтому когда Вы говорите "общепризнанно, что xxx - плохая штука", надо ясно понимать, что этот подход был "не оправдан для данной области применения". Ничто не гарантирует, что этот же подход не найдёт применения в другой области.
> Эдак Вы дойдёте до утверждения, что любое порождение процедуры ли, объекта или
> просто выполнение eval - моветон. ...До того что нужно заменить js на java с ограниченным набором core библиотек.
>> Эдак Вы дойдёте до утверждения, что любое порождение процедуры ли, объекта или
>> просто выполнение eval - моветон. ...
> До того что нужно заменить js на java с ограниченным набором core
> библиотек.Ох, да делайте, что хотите с этой Вашей ненаглядной явой. Только мне не сватайте.
Вот насчёт "Существуют задачи, решение которых существенно упрощается при таком подходе. Например, это задачи символьного исчисления, программирования AI" - можно подробнее? Это, собственно, то, о чём я спрашивал - есть ли реальные применения, где прототипы таки дают хороший выигрыш?> Область применения порождает пользователей языка, а пользователи - требования к нему.
Именно. И, соответственно, требования диктуются именно областью применения. А под неё уже подбираются программисты, желающие и способные в ней работать. Если у нас большая объектная модель (допустим, тот же гуглодок) - то нужно что-то, что даст возможность эту объектную модель реализовать с вменяемой эффективностью - в смысле стоимости разработки и поддержки, и чтобы на выходе было что-то, чем можно пользоваться.
И именно область применения поменялась, объёмы кода выросли, появилась необходимость в такой же поддержке, как и для "взрослых" приложений. И все требования, отсюда вытекающие.
Ладно, я, кажется, погорячился с предсказанием - в свете сегодняшней новости скорее JS через пару лет в основном уйдёт из веба.
> Вот насчёт "Существуют задачи, решение которых существенно упрощается при таком подходе.
> Например, это задачи символьного исчисления, программирования AI" - можно подробнее? Это,
> собственно, то, о чём я спрашивал - есть ли реальные применения,
> где прототипы таки дают хороший выигрыш?Ну, тут весь вопрос, выигрыш в чём именно Вас интересует. В производительности - обычно нет. В выразительной силе и возможностях - да. Именно благодаря возможности генерировать код в рантайме появились возможность символьных вычислений и CLOS. Макросы чтения и записи, как логичное развитие этой идеи.
Вообще говоря, порождение объекта как прототипа и генерация кода на лету - явления родственные. Поэтому я мог бы предложить Вам как пример, для начала, смотреть на Maxima, где эти возможности, должно быть, очень широко используются.
Если же Вас интересует именно вопрос прототипирования объектов, то я видел применение данного подхода в ДОЗОР СМАП [1]. Там при анализе сообщений объекты новых типов с произвольным набором полей, порождаются на лету. Довольно увлекательное зрелище. К сожалению, продукт закрытый, но вообще говоря, в проекте используется много GPL-лицензированного кода, так что при желании можно извернуться и получить исходники. Надеюсь.[1] http://solarsecurity.ru/products/solar_dozor/
>> Область применения порождает пользователей языка, а пользователи - требования к нему.
> Именно. И, соответственно, требования диктуются именно областью применения. А под неё уже
> подбираются программисты, желающие и способные в ней работать. Если у нас
> большая объектная модель (допустим, тот же гуглодок) - то нужно что-то,
> что даст возможность эту объектную модель реализовать с вменяемой эффективностью -
> в смысле стоимости разработки и поддержки, и чтобы на выходе было
> что-то, чем можно пользоваться.Чтобы на выходе было что-то, чем можно пользоваться, всегда можно нанять стайку мартышек. И средства реализации большой объектной модели - это вовсе не то, на чём она зиждится. Чтобы построить хороший большой программный комплекс нужны не программисты - это дело десятое. Прежде всего нужен архитектор. Грамотный, скурпулёзный, и желательно - один.
> И именно область применения поменялась, объёмы кода выросли, появилась необходимость в
> такой же поддержке, как и для "взрослых" приложений. И все требования,
> отсюда вытекающие.Я пока что отношусь к JS, как к языку для модификации DOM-а в моём браузере. Впрочем, может Вы и правы? Транслируют же в JS всякие странные вещи, типа игры Quake. Возможно, он способен на большее.
> Ладно, я, кажется, погорячился с предсказанием - в свете сегодняшней новости скорее
> JS через пару лет в основном уйдёт из веба.Это вряд ли. Очень много кода написано. Не выбросят же его. Так и потянется легаси через десятилетия.
> Если бы все программисты могли бы быть хакерами, высококлассными it-специалистами, то сейчас
> бы у нас было засилье лиспов и т.п.,JavaScript - это Lisp(Scheme) с синтаксисом похожим на Java.
A company called Netscape was founded in 1994 and created one of the first web browsers. They recruited Eich in 1995, because they wanted him to create a programming language for that web browser. The lure for him was that he would be able to base the language on Scheme (a Lisp dialect). Scheme’s influence led to JavaScript having closures. Another influence was the prototype-based programming language Self which is responsible for JavaScript’s prototypal inheritance (some of the elegance of this approach is hidden by JavaScript’s muddled adoption of it). Next, Java got included in the browser. It quickly gained popularity and influenced Netscape’s decisions regarding JavaScript.
>> Если бы все программисты могли бы быть хакерами, высококлассными it-специалистами, то сейчас
>> бы у нас было засилье лиспов и т.п.,
> JavaScript - это Lisp(Scheme) с синтаксисом похожим на Java.Спасибо, не знал. Впрочем, если весь JS - это синтаксический сахар для того, чтобы быть похожим на C-подобные языки, типа Java; то я бы предпочёл осуществить преобразование JS в sexp-ы и уже напрямую с ними работать. Смотреть на Java-подобный код мне очень не удобно.
Надо полагать, этот сахар был сделан для того, чтобы завоевать широкую аудиторию C-программистов привычным синтаксисом, а также упростить себе задачи оптимизации компиляции, обеспечив себя плюсами лиспав (макросами, AST и т.д.). Почему бы и нет.
> Если бы все программисты могли бы быть хакерами, высококлассными it-специалистами, то сейчас
> бы у нас было засилье лиспов и т.п., как наиболее мощных
Ну на ходу перековыривать прототипы это действительно полный ахтунг. А вот растягивать ленивую инициализацию миксинов очень даже удобно. На классах все что связано с миксинами будет менее удобно делать.В яваскрипте просто тормозов маловато, а самодисциплины не у всех хватает. Если взять исходники на руби, можно увидеть что там авторов тоже часто заносит в космос. По аналогичной причине.
Ну вот для больших проектов это отсутствие тормозов - лишний риск.Что до миксинов - да, объектную систему ввели хиленькую, а миксины чтобы в ней были - нужно либо множественное наследование либо их поддержка в явном виде. Лениво, впрочем, ни так, ни так не будет, хотя я не очень понимаю, зачем - но вполне возможно, что где-то и нужно.
> Например, в результате выполнения "var message = '1 + 1 = ${1 + 1}'" в переменную будет записана строка "1 + 1 = 2";Новый класс уязвимостей, javascript инъекции?
Новый? А XSS разве не javascript injection?
Осталось подождать каких-то лет 15-20, что бы у большинства пользователей были браузеры которые поддерживают шестерку. А то ведь браузеры как правило обновляют только когда винду переустанавливают... Oh shit! IE8.. IE9, IE10, IE11!
Вы из какого года? Chrome + firefox это уже большинство браузеров. А до поддержки ECMAScript 6 они сами обновятся.
Большинство - не все. В требованиях любого коммерческого продукта - поддержка IE как минимум 10. Это в лучшем случае. А по факту - практически везде нужно поддерживать IE8.
> Большинство - не все. В требованиях любого коммерческого продукта - поддержка IE
> как минимум 10. Это в лучшем случае. А по факту -
> практически везде нужно поддерживать IE8.девятка уже два года даже гуглом не поддерживается. восьмёрка -- три года.
ну, нахрена сайту в 2015 году поддерживать устаревший веб-браузер, на котором я даже gmail запустить не могу?
более того: нахрена такой браузер пользователям? вот они и ставят хром.
да и вообще ie 8-9 -- это windows xp, vista и необновлённая семёрка без сервис-пака. эти все три системы уже давно EOL. добро пожаловать в 2015 год.
Тем не менее их используют и отключив их поддержку можно нажить себе проблем.
Смешной вы человек из каменного века :) ишака вспомнили.Мы делаем так:
< h1 > Данная версия браузера не поддерживается! Используйте браузер Firefox версии 17 и выше.< / h1 >
За домашних пользователей можно не беспокоиться. Но проект над которым мы недавно работали - предназначен для врачей прежде всего, а у них в больницах еще много где стоят машины с ХР на борту и IE8. Потому что по какой-то таинственной причине администраторы больниц запрещают ставить сторонний софт. Примечание: я говорю не об этой стране. Как это не было бы удивительно - но в США, даже в той же Калифорнии, в больницах XP+IE - не редкость.
Ну, значит для специализированных применений новые фичи пока не подойдут. Делов-то.
> а у них в больницах еще много где стоят машины с ХР на борту и IE8. Потому что по какой-то таинственной причине администраторы больниц запрещают ставить сторонний софтудачи им при следующем security-аудите. с такой полиси они его с треском провалят.
https://babeljs.io/
Напишут интерпретатор ECMAScript 6 на ECMAScript 5 сейчас это модно...
Фрактал ненужностей продолжает расти.
Одно могу сказать - PHP явно не хуже JS/ES6.
В смысле -- одинаково хреновые? Согласен.
Отличная новость. Не знаю как в клиентском js, а для разработчиков под ноду классы, нейспейсы и прочие плюшки очень пригодятся.