Комментарии 93
Такими темпами роста скоро придется переучиваться многим js-программистам. Не только им, по идее, это в придачу может подстегнуть Opera и Firefox к реализации аналогичного функционала. Ушел щупать…
Нормальные классы, модули, итераторы, приватные свойства! Сколько раз уже обещали это в JS все кто только могут. Но пока нигде не видать :( А ведь если бы это все было, то, пожалуй, JS можно было бы назвать лучшим языком в своем роде.
а там есть ненормальные классы? =)
это называется EcmaScript 4, реализация которой — ActionScript 3, JScript.NET.
В том как сейчас есть своя таинственная прелесть этого языка :)
А зачем нормальные классы и самое главное, приватные свойства?
Для лучшей читабельности исходников сложных проектов.
Например, если открыть исходник какого-либо модуля на JS, очень сложно понять его API, во-первых, потому что прототипы каких-либо его объектов могут быть расширены в любом месте кода, во вторых из за того, что мало ясно, что предназначено для внутреннего пользования, а что — для внешнего. С четко регламентированным синтаксисом классов, модулей и приватных функций это проще.
Например, если открыть исходник какого-либо модуля на JS, очень сложно понять его API, во-первых, потому что прототипы каких-либо его объектов могут быть расширены в любом месте кода, во вторых из за того, что мало ясно, что предназначено для внутреннего пользования, а что — для внешнего. С четко регламентированным синтаксисом классов, модулей и приватных функций это проще.
Для этого достаточно внутренние методы и свойства именовать с подчёркиванием
_methodА можно запихивать функции внутрь других функций. А можно писать в JSDoc'е перед ними /** @private */. А можно писать комментарий вначале — «не трогать!». В том то и проблема, что все делают по разному, а хочется, чтоб везде все было одинаково. Просто и понятно.
Подчёркивание в имени — стандартный способ. Его же используют и в других динамических языках.
Ну я на самом деле больше ратую за традиционные модульность и классы. С подчеркиванием вначале приватных свойств еще жить можно :)
Ну то есть ООП в JS нужен только из-за вопросов консерватизма. Чтобы мол было «как в Java и .Net»? Давайте тогда и остальные ООП подходы выбросим ;).
Да есть там ООП. Просто способов описания «классов» слишком много. И их код выглядит как-то не очень, они больше похоже на хаки… Поэтому я и предлагаю остановится на одном очевидном способе, который зарекомендовал себя в всех Явах, Сях++, Питонах и т. д.
… и больше не развивать языки :).
Просто синтаксис задавания классов слишком фундаментален, что бы было куда его развивать. Оператор присваивания тоже был придуман много лет назад, и как-то до сих пор никто не решил от него отказаться.
А вот другие, более прикладные вещи, конечно надо развивать, более того, в JS многие вещи и развиты больше чем в других языках.
А вот другие, более прикладные вещи, конечно надо развивать, более того, в JS многие вещи и развиты больше чем в других языках.
Только вы так и не объяснили, зачем вам нужны классы. jQuery прекрасно работает и без них.
Ну так и исходник jQuery для неподготовленного человека практически не читаем. Далеко не все поймут, где там какие функции куда запихиваются, и что где происходит. А если бы код выглядел, например, как описание класса jQuery-коллекции в традиционном синтаксисе, то все было бы просто и понятно с первого взгляда.
jQuery я привёл как пример внешнего API, которое нормально работает без классов и т. п.
Код jQuery и в классическом ООП был бы сложен, так как она сильно оптимизирована по размеру и скорости.
Код jQuery и в классическом ООП был бы сложен, так как она сильно оптимизирована по размеру и скорости.
Ну jQuery лучше оставить как есть, ибо сейчас там в коде есть такие выкрутасы, которые традиционным ООП-языкам не снились и в страшном сне, и оттого она такая маленькая и производительная.
Но в более высокоуровневых модулях, на мой взгляд, подобное лучше не применять, чтоб каждый мог открыть исходники и сразу понять: вот это модуль, который отвечает за то-то, называется так-то. В нем есть 4 класса, каждый из которых отвечает за то-то и то-то.
Но в более высокоуровневых модулях, на мой взгляд, подобное лучше не применять, чтоб каждый мог открыть исходники и сразу понять: вот это модуль, который отвечает за то-то, называется так-то. В нем есть 4 класса, каждый из которых отвечает за то-то и то-то.
Таких библиотек куча, например, github.com/evilmartians/visibility.js
Открываем ваш модуль, и сразу видим
Как должно быть: модуль должен только лишь объявлять какой то объект, который я могу при желании импортировать в свой код, под произвольным именем и только после этого использовать. И для этого необходим какой-то стандартный механизм, чтобы каждый не изобретать что-то новое. Что-то подобное как раз и предлагается в «новом» явасрикпте.
window.Visibility = {/*...*/}. То есть у меня уже забит глобальный объект Visibility и мне никуда от этого не деться. Я не смогу использоваться 2 модуля с одинаковым названием.Как должно быть: модуль должен только лишь объявлять какой то объект, который я могу при желании импортировать в свой код, под произвольным именем и только после этого использовать. И для этого необходим какой-то стандартный механизм, чтобы каждый не изобретать что-то новое. Что-то подобное как раз и предлагается в «новом» явасрикпте.
Приватные методы и свойства удобны для реализации модульности, изоляции. В крупных проектах, где отдельные группы разработчиков работают на разных уровнях, это может быть проблемой. Технически, снаружи путём перебора свойств, можно добраться черти куда и поломать там все.
Конечно JS позволяет реализовать приватные методы через замыкания, но это не всегда удобно и читабельно.
Конечно JS позволяет реализовать приватные методы через замыкания, но это не всегда удобно и читабельно.
Достаточно просто указать, что эти свойства внутренние. Например, через подчёркивание в имени.
Вы рассматриваете идеальную ситуацию, когда умный сказал глупому:
-«не бери».
Тот не взял.
В жизни, когда десяток другой программистов работаем над большим проектом, обязательно найдется персонаж, который вместо того, чтоб сделать запрос на доработку функционала «ядра», возьмет и сочинит пару костылей. И после того как у него заработает, не факт, что не упадет в другом месте.
ИМХО, получить ошибку от интерпретатора в данном случае будет гораздо лучше.
-«не бери».
Тот не взял.
В жизни, когда десяток другой программистов работаем над большим проектом, обязательно найдется персонаж, который вместо того, чтоб сделать запрос на доработку функционала «ядра», возьмет и сочинит пару костылей. И после того как у него заработает, не факт, что не упадет в другом месте.
ИМХО, получить ошибку от интерпретатора в данном случае будет гораздо лучше.
Он точно так же может и захачить объект, дописав или переписав динамически методы.
обязательно найдется персонаж, который вместо того, чтоб сделать запрос на доработку функционала «ядра», возьмет и сочинит пару костылей
Этот же персонаж в Джаве рефлексией может получить приватные свойства. И что теперь?
Ну я не думаю, что рефлексия есть распространенная технология среди junior разработчиков.
На мой взгляд, это разные уровни сложности: рефлексия java(вообще любая рефлексия) и «посмотреть в firebug и перебрать по цепочке».
На мой взгляд, это разные уровни сложности: рефлексия java(вообще любая рефлексия) и «посмотреть в firebug и перебрать по цепочке».
Тут не стоит вопрос «возможно ли вообще?», технически возможно везде, тут скорее «насколько легко ?»
Итераторы есть в CoffeeScript, как и синтаксис нормальных классов.
Да, но это целый дополнительный язык, на котором надо все переписывать, который надо изучать, который надо поддерживать и т. д. В больших проектах от него будет больше проблем, нежели пользы.
Переписывать ничего не надо — в нём можно так же легко использовать JS код. И это не отдельный язык, а просто альтернативный синтаксис. Так что изучение занимает пару дней.
И компилировать его надо для всех браузеров, + var в кофескрипте нет. Нет, кофескрипт не юзабелен.
Кстати, я не нашел, собираются ли разработчики Хрома реализовать альтернативный синтаксис функций вида (x) -> x*x. В кофескрипте, вроде-бы они есть.
Кстати, я не нашел, собираются ли разработчики Хрома реализовать альтернативный синтаксис функций вида (x) -> x*x. В кофескрипте, вроде-бы они есть.
В том-то и дело, что var нет, так как CoffeeScript сам его ставит. То есть вы никогда не забудете его написать.
Для всех браузеров в отдельности компилировать не надо — достаточно один раз откомпилировать. Если у вас серьёзная разработка, то так и так есть минимизация и сборка статики — так что ещё один шаг с компиляцией не доставит никаких проблем. В Ruby on Rails это вообще работает из коробки и прозрачно для разработчиков.
Для всех браузеров в отдельности компилировать не надо — достаточно один раз откомпилировать. Если у вас серьёзная разработка, то так и так есть минимизация и сборка статики — так что ещё один шаг с компиляцией не доставит никаких проблем. В Ruby on Rails это вообще работает из коробки и прозрачно для разработчиков.
> В том-то и дело, что var нет, так как CoffeeScript сам его ставит. То есть вы никогда не забудете его написать.
В sctict mode я его тоже никогда не забуду поставить. Зато могу контролировать область видимости.
> Для всех браузеров в отдельности компилировать не надо — достаточно один раз откомпилировать.
Я к тому, что ни один браузер не хавает Coffee по умолчанию, и никогда не будет. И да, я всегда хотел узнать, но никогда не получал ответа :) Как отлаживать программу на Coffeescript? Вот, допустим, я пишу на JS у меня возникла ошибка. Смотрю в консоль, ошибка в строке XX. А как с этим обстоят дела в Coffee?
В sctict mode я его тоже никогда не забуду поставить. Зато могу контролировать область видимости.
> Для всех браузеров в отдельности компилировать не надо — достаточно один раз откомпилировать.
Я к тому, что ни один браузер не хавает Coffee по умолчанию, и никогда не будет. И да, я всегда хотел узнать, но никогда не получал ответа :) Как отлаживать программу на Coffeescript? Вот, допустим, я пишу на JS у меня возникла ошибка. Смотрю в консоль, ошибка в строке XX. А как с этим обстоят дела в Coffee?
С отладкой сейчас: вы смотрите строку, где произошла ошибка и открываете её в CoffeeScript. CS — просто альтернативный синтаксис, там сразу понятно, какая строка JS за какую в CS отвечает.
С отладкой через год: в Хроме уже начали реализовывать поддержку технологии, когда в отдельном файле указывается каким строкам JS’а какие строки в других файлах соответствуют. Это не только для CoffeeScript, но и чтобы нормально отлаживать обусфуцированные и сжатые файлы в production (когда баг не повторяется локально).
С отладкой через год: в Хроме уже начали реализовывать поддержку технологии, когда в отдельном файле указывается каким строкам JS’а какие строки в других файлах соответствуют. Это не только для CoffeeScript, но и чтобы нормально отлаживать обусфуцированные и сжатые файлы в production (когда баг не повторяется локально).
> С отладкой сейчас: вы смотрите строку, где произошла ошибка и открываете её в CoffeeScript. CS — просто альтернативный синтаксис, там сразу понятно, какая строка JS за какую в CS отвечает.
То есть оно не убирает переносы и не добавляет новые?
Тот же пример:
То есть оно не убирает переносы и не добавляет новые?
Тот же пример:
outer = 1
changeNumbers = ->
inner = -1
outer = 10
inner = changeNumbers()var changeNumbers, inner, outer;
outer = 1;
changeNumbers = function() {
var inner;
inner = -1;
return outer = 10;
};
inner = changeNumbers();Здесь демонстрируется добавление новых строк. Вот возникла у меня ошибка в строке 5 скомпилированного кода, а в CS она соответствует строке 3. Или с этим всё в порядке? Возникла в третьей, значит в CS она же в третьей?В ES.Next такой альтернативный синтаксис только для однострочных функций. В CoffeeScript же всегда можно пистать меньше символов.
Можно, но можно и запутаться, где что.
Без фигурных скобок нифига не понятно. Плюс, я хочу чтоб функция ничего не возвращала (точнее андефайнед), в JS я просто пропускаю return XX, а в Coffee нужно писать
changeNumbers = ->
inner = -1
outer = 10
inner = changeNumbers()Без фигурных скобок нифига не понятно. Плюс, я хочу чтоб функция ничего не возвращала (точнее андефайнед), в JS я просто пропускаю return XX, а в Coffee нужно писать
changeNumbers = ->
inner = -1
outer = 10
undefined
inner = changeNumbers()Питонисты как-то понимают всё прекрасно на основе отступов :). Вопрос привычки, которая формируется за день программирования.
CoffeeScript про return наследует идею из Ruby, где всё возвращает значение. В любом случае (хотя я не понимаю, зачем вам нужна функция, которая всегда ничего не возвращает), вы привели редкую ситуацию — и лучше один раз в год написать undefined, чем каждый час писать лишний return.
CoffeeScript про return наследует идею из Ruby, где всё возвращает значение. В любом случае (хотя я не понимаю, зачем вам нужна функция, которая всегда ничего не возвращает), вы привели редкую ситуацию — и лучше один раз в год написать undefined, чем каждый час писать лишний return.
>>Переписывать ничего не надо — в нём можно так же легко использовать JS код.
Чем больше языков используется в проекте, тем сложней его поддерживать. Пусть даже один из них компилируется в другой.
Чем больше языков используется в проекте, тем сложней его поддерживать. Пусть даже один из них компилируется в другой.
Согласен, что лишний раз новый язык лучше не вводить. Но если преимуществ достаточно (отсутствие проблемы с забытым var, нормальные итераторы, более короткий синтаксис), то преимущества перевешивают недостатки. Мы перешли на CoffeeScript на русском Групоне и остались очень довольны, что используем его во всех остальных проектах. 37signals на basecamp’е тоже остались очень довольны.
Я еще раз говорю, нет проблем с забытым var в строгом режиме. Есть проблема CS, когда не знаешь, где объявлена переменная. Итераторы — дело времени, короткий синтаксис не должен быть в ущерб прозрачности кода.
А более удобный синтаксис и куча сахара, типа классов?
На JS тоже можно эмулировать классы.
Само собой. Просто код на CoffeeScript оказывается в 1,5—2 раза короче и сильно понятнее. Хотя бы потому что там есть string[0..5] вместо substring и substr (в которых постоянно путаешься).
Ничего понятного я там не увидел. Да и за годы разработки никогда не работал с substring и substr.
А как Вы вырезаете подстроку из строки?
Slice. А вообще, зависит от задачи: если нужно взять число из начала строки, то parseInt или parseFloat.
А как часто вы вырезаете строку из подстроки, чтобы выносить это в отдельный сахар? Давайте вообще ВСЁ вынесем в сахар — уберем методы и будем пользоваться только сахаром.
array.indexOf(elem) заменим на array?elem, array.slice(2,3) на array[2..5], а array.splice(2,3) на array[2..5]!. И так далее. Будет весело разбираться в кипе непонятных символов. Иногда лучше написать лишних 4 буквы, тем более, что операция крайне редкая.Да и итераторы появятся через год, а будут во всех браузерах через года 4.
Всё Ruby on Rails сообщество на него медленно переходит.
RoR сообщество кажется вечно на что-то переходит, сначала варианты деплоймента меняли, потом API на двух мажорных версиях меняли, теперь HTML/CSS/JS на DSL меняют. Мне даже интересно, что будет следующим.
Приложение 2-3 летней давности превращается Legacy, с которым работать уже not fun & not cool :)
Приложение 2-3 летней давности превращается Legacy, с которым работать уже not fun & not cool :)
Ура, молодцы. Умеют, могют. Теперь ждем двух вещей:
1. Experimental JavaScript features будет включен по умолчанию
2. Компилятор для морально устаревших браузеров в плане поддержки ES.Next (IE, Opera)
1. Experimental JavaScript features будет включен по умолчанию
2. Компилятор для морально устаревших браузеров в плане поддержки ES.Next (IE, Opera)
Компилятор для морально устаревших браузеров в плане поддержки ES.Next (IE, Opera)
Хороший вброc.
Хороший вброc.
Это не взброс, это факт.
1) Термин «морально устаревший» как бы субъективен, вы выдаёте ваше отношение за «факт».
2) ES.Next (это который Harmony?) как бы ещё в разработке, его никто не обязан поддерживать. Поправьте если ошибаюсь.
3) Если верить wiki en.wikipedia.org/wiki/ECMAScript см. «Conformance tests», то у Оперы как раз всё очень хорошо.
2) ES.Next (это который Harmony?) как бы ещё в разработке, его никто не обязан поддерживать. Поправьте если ошибаюсь.
3) Если верить wiki en.wikipedia.org/wiki/ECMAScript см. «Conformance tests», то у Оперы как раз всё очень хорошо.
Там большинство замечаний касаются не работы с JS. (Не будем считать за JS реализацию отдельных функций).
Про js написано что «там ужастный GC». Ну так, никто и не обещает его бысторой работы, обещают правильную. Добро пожаловать в web :)
Напомню, изначально говорилось, про то что Opera и IE не поддерживают в JS в той мере, в какой его поддерживает Chrome, при этом в укор ставилось что они не поддерживают фичи ещё не введённые в стандарт. Я уею дорогая редакция.
Про js написано что «там ужастный GC». Ну так, никто и не обещает его бысторой работы, обещают правильную. Добро пожаловать в web :)
Напомню, изначально говорилось, про то что Opera и IE не поддерживают в JS в той мере, в какой его поддерживает Chrome, при этом в укор ставилось что они не поддерживают фичи ещё не введённые в стандарт. Я уею дорогая редакция.
2. traceur.
Мне тут в голову пришла бредовая идея: вместо
использовать
Этот код так же будет запускаться моментально (возможно, даже, быстрее, так как функции приходится инициализироваться, а затем, запускаться), в глобальную область видимости ничего не попадет (благодаря let). Но, конечно, возвращаться ничего не будет.
(function(){
var x = 5, y = 10;
})();использовать
{
let x = 5, y = 10;
}Этот код так же будет запускаться моментально (возможно, даже, быстрее, так как функции приходится инициализироваться, а затем, запускаться), в глобальную область видимости ничего не попадет (благодаря let). Но, конечно, возвращаться ничего не будет.
Вообще фигурные скобки без ничего в JS воспринимаются как литерал объекта, так что такая запись, скорее всего, будет ошибочной.
а вот и нет :) Фигурные скобки воспринимаются в первую очередь как блок кода, а уже потом этот блок кода проверяется на соответствие синтаксиса литералу объекта. Другое дело, что сейчас (в сегодняшней реализации) блок кода штука бесполезная, никаких плюшек (ну, разве что, кроме фолдинга в редакторах) не сулящая.
Обзор вкладок Mac
Проведите тремя пальцами вниз по трекпаду, чтобы увидеть все свои вкладки. Нажмите на уменьшенное изображение нужной вкладки, чтобы выбрать ее. Эта функция особенно удобна в полноэкранном режиме.
Sorry, this experiment is not available on your platform.
Будет ли доступна данная функция пользователям Windows?
Проведите тремя пальцами вниз по трекпаду, чтобы увидеть все свои вкладки. Нажмите на уменьшенное изображение нужной вкладки, чтобы выбрать ее. Эта функция особенно удобна в полноэкранном режиме.
Sorry, this experiment is not available on your platform.
Будет ли доступна данная функция пользователям Windows?
В прикладном плане, новость интересна тем, что это скоро появится на nod.js, а значит можно будет продуктивно использовать в разработке серверсайда. На клиентской стороне, для публичного web-а эти нововведения упрутся в некоторые отстающие браузеры.
const в Хроме давно есть в strict mode, хотя и работает оно специфически.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В Chrome (dev) реализованы будущие функции JavaScript