Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Отлично, так JS намного больше похож на ООП язык, да и отладка станет полегче я надеюсь. Спасибо за обзор.
Честно говоря я не понимаю этого восторга. JavaScript в текущей реализации позволяет использовать ООП и введение "class" ничего по сути не меняет. Вместо того чтобы просто расширить возможности, товарищи пытаются сделать из него второй Java
Шутите? Нет, это правда, конечно.
JavaScript в текущей реализации позволяет использовать ООП. Через задницу. Далеко не в полную мощь. Чтобы воспользоваться такой мелочью как инкапсуляция в текущей реализации нужно истрахать себе весь мозг.
Большая часть ООП в текущей реализации это обходные пути, позволяющие использовать ООП.
JavaScript в текущей реализации позволяет использовать ООП. Через задницу. Далеко не в полную мощь. Чтобы воспользоваться такой мелочью как инкапсуляция в текущей реализации нужно истрахать себе весь мозг.
Большая часть ООП в текущей реализации это обходные пути, позволяющие использовать ООП.
Полностью согласен. А еще если вернуться к проекту на js месяца через два-три и ужаснуться: "Что это тут написано, и как оно вообще работает?"
ООП != "инкапсуляция, наследование, полиморфизм".
Забавно смотреть на человека, который готов истрахать себе весь мозг, но взлететь на автомобиле:)
Забавно смотреть на человека, который готов истрахать себе весь мозг, но взлететь на автомобиле:)
Видимо вы превратно понимаете термин "инкапсуляция".
Инкапсуляция, это собрание данных и обрабатывающего их кода в одном месте, а отнюдь, не private-protected-public
Инкапсуляция, это собрание данных и обрабатывающего их кода в одном месте, а отнюдь, не private-protected-public
Не все с вами согласны (и я из их числа). Обратите внимание на "скрыть реализацию объекта от пользователя". Это важно)
Обсуждать хороша ли реализация ООП в языке, в котором сокрытие данных осуществляется через одно место (т.е. не штатными средствами), на мой взгляд, непродуктивно.
Обсуждать хороша ли реализация ООП в языке, в котором сокрытие данных осуществляется через одно место (т.е. не штатными средствами), на мой взгляд, непродуктивно.
Мммда... сам говорю, что обсуждать непродуктивно, но обсуждаю)
Маладца.
Маладца.
Сокрытие данных, там, где это необходимо, легко осуществляется через замыкания (штатное средство), а private-protected-public - путь языков со статической типизацией, не JS. Реализация полиморфизма через duck-typing - все хорошо.
На что обратить внимание? Я вам приведу десятки текстов где написано по разному и сам отредактирую википедию.
Главное, не то, что где-то написано, а главное те принципы, которые позволяют программировать объектно-ориентированно, то есть ориентироваться в своем коде на объекты. Сокрытие данных, это дополнительная фишка, местами достаточно удобная, но к самому ООП никакого отношения не имеющая.
Есть отличные ООП-языки, не позволяющие делать сокрытие вообще ни через одно место (например, Python), но это не мешает быть им предельно удобными и мощными в ООП-плане.
Главное, не то, что где-то написано, а главное те принципы, которые позволяют программировать объектно-ориентированно, то есть ориентироваться в своем коде на объекты. Сокрытие данных, это дополнительная фишка, местами достаточно удобная, но к самому ООП никакого отношения не имеющая.
Есть отличные ООП-языки, не позволяющие делать сокрытие вообще ни через одно место (например, Python), но это не мешает быть им предельно удобными и мощными в ООП-плане.
Согласен, погорячился. Настолько я убежден в том, что сокрытие данных провоцирует на хороший стиль программирования, что очень расстраиваюсь, когда пишу на языке, на котором этого нельзя.
Я почти всегда когда свойство новое объявляю, делаю его private. Мне такое сокрытие позволяет "отловить" необходимость рефакторингов в будущем. Сразу становится видно, что класс лезет не к своим данным и необходимо менять архитектуру.
К чему я, собственно: дело не в определениях, конечно, но мне действительно нехватает этого в языках, которые "полностью реализуют ООП". Рад, когда удается выбрать для проекта язык, который провоцирует писать в хорошем стиле.
Я почти всегда когда свойство новое объявляю, делаю его private. Мне такое сокрытие позволяет "отловить" необходимость рефакторингов в будущем. Сразу становится видно, что класс лезет не к своим данным и необходимо менять архитектуру.
К чему я, собственно: дело не в определениях, конечно, но мне действительно нехватает этого в языках, которые "полностью реализуют ООП". Рад, когда удается выбрать для проекта язык, который провоцирует писать в хорошем стиле.
причем интересно, прототипы чтоли останутся? зачем делать такую мешанину..
согласен на все 100.
Мне уже заминусовали за это карму, но я не знаю ни одного класса задач и мне не привели ни одной задачи, где ООП JavaScript 1 (прототипирование) имело бы какие-либо преимущества перед "классическим ООП".
А если таких преимуществ нет или класс задач ничтожно мал, то нет смысла использовать что-то другое и лучше отказаться от этого и перейти к подходу, к которому все привыки и который представляется людям естественным решением.
А так, конечно в JavaScript есть ООП, просто оно другое и... возможно стань prototype подход популярнее классического с классами и пр. мы бы плевались на какой-нибудь язык с классами без прототипирования. Так что на данный момент прототипный подход представляется менее удобным.
А если таких преимуществ нет или класс задач ничтожно мал, то нет смысла использовать что-то другое и лучше отказаться от этого и перейти к подходу, к которому все привыки и который представляется людям естественным решением.
А так, конечно в JavaScript есть ООП, просто оно другое и... возможно стань prototype подход популярнее классического с классами и пр. мы бы плевались на какой-нибудь язык с классами без прототипирования. Так что на данный момент прототипный подход представляется менее удобным.
Классы в JS2 по сути меняют подход к программированию. Там не просто добавлено новое слово class, а сами классы стали статичными, к примеру, методы нельзя переопределять и такие свойства (метод по сути то же свойство) могут хранить только функции. В дополнение, появляются специальные атрибутов, которые определяют видимость и прочие свойства, например, readonly. Можно вернуться и к старому, и добавлять/удалять свойства на лету - но класс такого объекта должен быть помечен как dynamic (динамический). Меняется способ наследования. Добавляется множество ограничений. И т.д. и т.п.
... не пройдет и каких-нибудь пяти-семи лет, как всё это будет правильно поддерживаться всем распространёнными браузерами, ага.
http://www.mozilla.org/projects/tamarin/
Adobe подарила Mozilla foundation исходники AS3 VM :)
Adobe подарила Mozilla foundation исходники AS3 VM :)
Если это обращение к Web 2.0, тогда после него логичней запятая, чем тире.
=))) угу, осталось только дождаться, пока такие игроки как IE это прочитают и внедрят =)
оффтопик:
мне одному не нравятся «дефолтовые» названия переменных foo и bar в англоязычных примерах кода?
мне одному не нравятся «дефолтовые» названия переменных foo и bar в англоязычных примерах кода?
>обзор новых возможностей уже доступен...
Много лет уже доступен.
И JS2.0 это уже не столько для браузеров язык.
Много лет уже доступен.
И JS2.0 это уже не столько для браузеров язык.
очень хорошо:)
ах, респект. с удовольствием прочитал overview.pdf
Интересно посмотреть на связку JS2 и Silverlight. Из этого может выйти что-нибудь неплохое :)
забавно наблюдать развитие JavaScript )
Сейчас мне это очень напоминает развитие ActionScript в Flash. До ActionScript 2, как раз использовались конструкции такого типа:
:)
Потом появился ActionScript 2 и тут появились class Foo, покеты и т.д. - эмуляция ООП
Интересно - JavaScript 3 тоже будет походить на ActionScript 3? :)
Если да, то это уже очень приближено к синтаксису Java...
Сейчас мне это очень напоминает развитие ActionScript в Flash. До ActionScript 2, как раз использовались конструкции такого типа:
function Foo() {
this.a = "a";
this.b = "b";
}
var myFoo = new Foo();
:)
Потом появился ActionScript 2 и тут появились class Foo, покеты и т.д. - эмуляция ООП
Интересно - JavaScript 3 тоже будет походить на ActionScript 3? :)
Если да, то это уже очень приближено к синтаксису Java...
Спасибо, я вообще-то в курсе :)
Я к тому, что какими темпами развиваются братья, точнее интересно наблюдать их темп по скорости. ActionScript к стандарту ECMA идет малость быстрее :)
На своем веку я пережил три версии ActionScript (то что было до Flash 5 за язык наверно можно не считать). По ходу дела, сталкиваясь с JavaScript кардинальных изменений я не заметил, хотя в вопросах JavaScript, я не компетентен, что бы утверждать это на все 100. Честно, года полтора назад я был удивлен, что оказывается в JavaScript есть понятие
А еще я вспомнил историю, еще в тот момент когда только начинал учить Flash. В какой-то книжке, уже не помню какой, было сказано что ActionScript и Flash сам по себе, должны упростить жизнь web-разработчикам создающие анимацию на своих сайтах (типа забудьте JavaScript - не нужно кодить что бы создать "афигеннную менюшку", есть же flash!). :)
Да... Упростили (серьезно упростили, "web-разработчики" заполнили все flash баннерами и "афигеннными менюшками", мне честно как flash-разработчику больно было на это смотерть). И кстати больно смотреть как хабралюди, по большей своей части не любят flash, хотя и есть за что.
Теперь ActionScript 3 на голову выше своего старшего брата :)
И уже наверно проще на JavaScript чем на ActionScript 3 (имею в виду синтаксис и абстракцию подхода) :) А ведь начинал JavaScript раньше...
Я к тому, что какими темпами развиваются братья, точнее интересно наблюдать их темп по скорости. ActionScript к стандарту ECMA идет малость быстрее :)
На своем веку я пережил три версии ActionScript (то что было до Flash 5 за язык наверно можно не считать). По ходу дела, сталкиваясь с JavaScript кардинальных изменений я не заметил, хотя в вопросах JavaScript, я не компетентен, что бы утверждать это на все 100. Честно, года полтора назад я был удивлен, что оказывается в JavaScript есть понятие
prototype.А еще я вспомнил историю, еще в тот момент когда только начинал учить Flash. В какой-то книжке, уже не помню какой, было сказано что ActionScript и Flash сам по себе, должны упростить жизнь web-разработчикам создающие анимацию на своих сайтах (типа забудьте JavaScript - не нужно кодить что бы создать "афигеннную менюшку", есть же flash!). :)
Да... Упростили (серьезно упростили, "web-разработчики" заполнили все flash баннерами и "афигеннными менюшками", мне честно как flash-разработчику больно было на это смотерть). И кстати больно смотреть как хабралюди, по большей своей части не любят flash, хотя и есть за что.
Теперь ActionScript 3 на голову выше своего старшего брата :)
И уже наверно проще на JavaScript чем на ActionScript 3 (имею в виду синтаксис и абстракцию подхода) :) А ведь начинал JavaScript раньше...
AS2 только синтаксичиский сахар, ничего нового. AS3 - и есть ECMAScript 4 ( aka JS 2.0) за исключением мелочей, т.к. девятый флеш вышел до утверждения стандарта :)
Вот уж интересно во что может вылится JavaScript 2.0 :) Если и с первым интернет изменился в сторону глобального усложнения...
Большое спасибо за обзор, очень интересно :)
Все, конец шаманству! Буду вспоминать с грустной улыбкой :))
пишу на жаваскрипт, "стандартное" ООП не вкуриваю вообще... но вроде то, что выходит у меня из клавитуры, другие называют объектным подходом....
ну сделают ООП в жс более "стандартным"... разницы та... работать быстрее все равно не будет...лучше бы стандартизовали совмещение жс с штмлем - дабы не только производители браузеров жс движки писали...
ну сделают ООП в жс более "стандартным"... разницы та... работать быстрее все равно не будет...лучше бы стандартизовали совмещение жс с штмлем - дабы не только производители браузеров жс движки писали...
Извините, а кто их тогда будет писать?
не только производители браузеров
былобы лучше если бы жаваскрипт был встраиваемым в браузеры, дабы одну и ту-же реализацию можно было бы поставить на разные браузеры...
былобы лучше если бы жаваскрипт был встраиваемым в браузеры, дабы одну и ту-же реализацию можно было бы поставить на разные браузеры...
Вам не кажется, что тогда к полной неразберихе с браузерами добавится полная неразбериха с имплементацией чужих движков? И потом, это же не такой плагин, который будет разрабатывать одной компанией, типа флеша или сильверлайта — это ж будет ад.
Да, несомненно, было бы лучше.
И чтобы отрисовывающий движок был тоже один.
И браузер был бы один.
Но к чему эти благие пожелания?
И чтобы отрисовывающий движок был тоже один.
И браузер был бы один.
Но к чему эти благие пожелания?
Почему один? Много. Хочется получить больше уровней в разработке - как в свое время софт отделился от железа... как софт поделился на прикладные программы и операционные системы... как появились скриптовые языки в прикладных программах и т.п. Веб и так достаточно слоожен... а дальше он бдует только сложнее и сложнее.
А ад у нас будет в любом случае :)
А ад у нас будет в любом случае :)
>class Bar {
this.a = "a";
this.b = "b";
}
Это что за структура? Мутант из класса и конструктора?
this.a = "a";
this.b = "b";
}
Это что за структура? Мутант из класса и конструктора?
Я очень подозреваю, что как и в ActionScript 2.0 будет лишь банальная подмена понятий.
Людям не привычно видеть "function" там где должно быть "class" - вот и ввели синоним "class" для "function". Но результат-то ничуть не изменился!
Людям не привычно видеть "function" там где должно быть "class" - вот и ввели синоним "class" для "function". Но результат-то ничуть не изменился!
Кажется автора статьи немного напутал. Должно было быть что-то вроде.
class Bar {
var a = "a";
var b = "b";
}
class Bar {
var a = "a";
var b = "b";
}
Наконец-то... теперь можно будет по-человечески писать все что угодно... Остается только надеятся на достойную реализацию и большую стандартизованность, чем нынешний JS... да ждать выхода в свет :-)
ура!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Web 2.0, встречай JavaScript 2.0!