Компания Google представила (http://news.dartlang.org/2017/04/dart-123-better-strong-mode...) выпуск языка программирования Dart 1.23 (http://www.dartlang.org/), который позиционируется как язык структурированного программирования для Web, обладает похожим на Java синтаксисом, не требует явного определения типов и может использоваться для создания серверных и клиентских приложений. Для запуска внутри браузера код на языке Dart компилируется в представление JavaScript, для выполнения серверных приложений развивается специальная виртуальная машина Dart VM. Код связанных с языком компонентов распространяется под лицензией BSD.Для упрощения разработки на языке Dart поставляется SDK (http://www.dartlang.org/docs/sdk/), включающий в себя компилятор в JavaScript - dart2js (http://www.dartlang.org/docs/dart2js/), виртуальную машину Dart VM (http://www.dartlang.org/docs/standalone-dart-vm/), пакетный менеджер pub (http://pub.dartlang.org/), статический анализатор кода dart_analyzer (https://www.dartlang.org/docs/dart-up-and-running/contents/c...), набор библиотек, интегрированная среда разработки DartPad (https://dartpad.dartlang.org/) и плагины с поддержкой Dart для IntelliJ IDEA, WebStorm (https://www.dartlang.org/tools/webstorm/), Emacs (https://github.com/nex3/dart-mode), Sublime Text 2 (https://github.com/dart-lang/dart-sublime-bundle#readme) и Vim (https://github.com/dart-lang/dart-vim-plugin). Для выполнения и отладки приложений на языке Dart, без компиляции в JavaScript, предоставляется Dartium (https://www.dartlang.org/tools/dartium/) - специальная сборка браузера Chromium с интегрированной виртуальной машиной Dart VM. Дополнительные пакеты с библиотеками и утилитами распространяются через репозиторий pub (https://pub.dartlang.org/packages), который насчитывает 2567 пакетов, в том числе фреймворки для разработки web-приложений AngularDart (https://github.com/angular/angular.dart) и polymer.dart (https://www.dartlang.org/polymer-dart/).
В Dart 1.23 расширены (https://github.com/dart-lang/sdk/blob/master/CHANGELOG.md#1230) возможности режима "strong (https://www.dartlang.org/guides/language/sound-dart)" (обеспечивает строгую статическую типизацию): реализована возможность переопределения полей без использования @virtual, улучшена информативность сообщений об ошибках, изменены приоритеты при определении типа (приоритет теперь отдаётся (https://github.com/dart-lang/sdk/issues/27586) информации, выведенной из базовых типов, функций и методов). Проведена большая работа по оттачиванию унифицированного фронтэнда. Улучшено качество проверки и нормализации ввода в методе UriData.parse. В браузерных приложениях обеспечена возможность импорта dart:io.
URL: http://news.dartlang.org/2017/04/dart-123-better-strong-mode...
Новость: http://www.opennet.me/opennews/art.shtml?num=46438
и эти не осилили ООП на прототипах? Одна из немногих вещей, которая очень нравиться в JavaScript, не знаю почему её все так боятся.
> ООП на прототипахКакое же это ООП, когда _приватный метод дочернего класса способен перекрыть _приватный метод родительского класса просто по факту того, что оба имеют одно и то же название?
И где это противоречит ООП?
Инкапсуляция? Не, не слышал. Тебя легко завалить на собеседовании уже на первом вопросе.
Жаль, я давно не хожу на собеседования, т.к. обычно получаю прямые приглашения на работу.А теперь минутка матчасти:
1. В JS нет приватных методов.
2. "Инкапсуляция не является необходимым требованием объектно-ориентированного программирования" ©
3. К родительскому методу всегда можно получить доступ из экземпляра через "this.constructor.prototype".Еще вопросы, о великий рекрутер?
Наследуясь и определяя _приватный член, нужно креститься, чтобы не дай бог не перезатереть _приватный член родительского класса, о котором, разумеется, ничего не сказано в документации (оно и логично, зачем там упоминать о _приватных членах?) Эта проблема неактуальна только в неизменных хелловорлдах, когда с течением времени никто ничего не добавляет ни в базовые, ни в дочерние классы, а в т. н. "цепочке прототипов" не более двух-трех объектов.> В JS нет приватных методов.
А я думаешь просто так ставлю знак подчеркивания в слове _приватный?
> Инкапсуляция не является
"Заметим, что инкапсуляция является безусловно необходимым требованием для каждого объекта" ©
> А я думаешь просто так ставлю знак подчеркивания в слове _приватный?_приватные члены в JS -- это ещё более бестолковая вещь, чем _приватные члены в Python. В последнем для них хотя бы имена манглятся (как раз чтобы решить проблему с переопределением, кстати). В JS на уровне языка приватных членов нет. Всё. Точка. То, что вы к именам дописываете underscore -- это бесполезная попытка добавить в язык то, чего там нет.
Приватных членов нет, а нужда в них есть. Это как раз к вопросу о "не знаю почему её все так боятся" из коммента #4.
Ну так сделай себе замыкание и там себе сделай приватный член: https://jsfiddle.net/xa6dffnr/ .
А теперь то же самое, но с ключевым словом class.
Зачем? Сахар "class" пока убог и не все умеет, по сравнению с классическим синтаксисом. ООП фанатикам важнее обертка, а не содержание?
Назвался грибом...
> Приватных членов нет, а нужда в них есть. Это как раз к вопросу о "не знаю почему её все так боятся" из коммента #4.Нужда в них есть если вы хотите переиспользовать переиспользуемый код. Другими словами. Если ты делаешь либу основанную на другой либе в ООП стиле. Решение до жути простое. Не делай так. И будет тебе счастье, юный падаван.
> То, что вы к именам дописываете underscore
> underscoreСказал так, будто обсосал название любимой библиотеки. Фронтендщики любят обмазываться костылями, так как JS сам по себе без них убог.
В C нет ООП вообще, значит ли это, что разработчики ядра Linux "любят обмазываться костылями"? У меня уже жир с монитора течет из этого треда.
Сравни сложность ядра и фронтенда. И кстати, сложность фронтенда повышается искусственно благодаря рассаде десятков библиотек, которые тащат как в рот
Т.е. для сложных решений (типа ядра) ООП наоборот не нужно? Оооооооокей.
Ну, если ты так считаешь... Хорошо, буду знать.
В ядре нет ООП совсем. С подключением!
> underscoreПлинтус что-ли?
Не знаю, что там насчёт рекрутеров, но если нет хорошей инкапсуляции - про более-менее крупные приложения при вменяемых затратах можно забывать. Собственно, именно поэтому JS и стал проблемным - размеры приложений в вебе выросли, и у него оказалось слишком уж много енудобных теперь особенностей - от прототипов до динамики.
Бедные программисты C, а уж программисты ядра... и как они бедные выживают. Нет ничего бессмысленней, чем ООП ради ООП.
Да, именно по этой причине (а также некоторых других) так мало крупных приложений написано на C.
Это вы так пошутили?
В Си вполне вменяемое сокрытие данных, пригодное в том числе и при программировании в ООП стиле(да, это возможно и даже оправдано). Оно несколько портится другими возможностями языка, но это уже другой вопрос.
Ну вот так... Этот минус в сях перкрывается удобством работы с оборудованием и низкими накладными расходами. А что разрабатывать на сях дорого и так все в курсе.
Вся суть JS и его адептов в одном комментарии.
Начни с того, что не существует какого-то эталонного ООП. Есть множество ЯП с разными вариантами ООП. Потом открой хотя бы статью на wikipedia для ознакомления с тем, что и на инкапсуляцию есть разные взгляды и в разных ЯП она различна. Ну и закончить можешь на 'Because inheritance exposes a subclass to details of its parent's implementation, it's often said that "inheritance breaks encapsulation"'При этом за счет замыканий в js возможны действительно приватные методы/функции/свойства, которые не будут перекрыты потомками.
> inheritance breaks encapsulation10 Базовый класс все еще может предоставлять дочернему некий внутренний апи в виде protected-методов, которые последний может переопределить, все так же ничего не зная о деталях реализации.
> за счет замыканий в js возможны действительно приватные методы/функции/свойства
Ага, при этом в коде будут ужасные конструкции вроде myPrivateMethod.call(this, 42). Прям как в похапешном call_user_func_array. Про :: можешь ничего не говорить -- он в стандарт войдет не скоро, если вообще войдет, сейчас он существует только в бабеле.
Ну и расскажи, как ты посредством кейворда class собрался реализовывать приватные свойства (не функции), ассоциированные с инстансом. Через WeakMap? И ради чего все эти свистопляски? Неужели это и есть "осилить прототипное ООП"?
Ну и никакие замыкания не устроят тебе protected-члены. GOTO 10.
вот тут то и говорят - ООП головного мозга.
> не осилили ООП на прототипах
> [...аргументы, что на прототипах никакое не ООП...]
> вот тут то и говорят - ООП головного мозгаПонятненько.
можно вопрос задать?сменим тему, чтобы вы выбрали - писать картины или чертить чертежи ?
> сменим тему, чтобы вы выбрали - писать картины или чертить чертежи ?Встречный вопрос: какой язык вы бы выучили: русский или C++?
При знании русского с++ думаю не нужен, хотя аналогия тут немного не корректная.
Ну и собственно ответ на мой вопрос бы написали, а я бы конкретно обосновал бы мой вопрос и развернуто ответил бы к чему я его привел, думаю в конечном счете мы бы сошлись во мнениях.
Ох ты ж, как вежливо (честно). Редко тут такое встретишь, поэтому отвечу. Надеюсь, мой ответ не удалят до того, как вы его прочитаете.Во-первых, это я задал вам встречный вопрос, но спорили вы не со мной: я - другой аноним.
Во-вторых, я так понял, своим вопросом вы хотели показать оппоненту, что он ничего не понимающий гуманитарий (и должен бы выбрать вариант с картиной), а вы технарь на белом коне и со шпагой. Не люблю, когда слово "гуманитарий" используют в качестве ругательства, поэтому, заметив у вас опечатку ("что бы" в вашем вопросе должно писаться раздельно), хотел вас пристыдить в ответ, продемонстрировав собственное наблюдение, что технари (по крайней мере, те, кто себя такими считает), как правило, весьма безграмотны, и касается это как русского языка, так и технической составляющей их работы (среди наблюдаемых мной современных IT-"технарей" очень мало настоящих "инженеров"). Теперь прощу прощения, честно не ожидал настолько вежливой реакции с вашей стороны.
Ну и в-третьих, по сути. Для себя в качестве определения "ООП" я выбрал изначальное, АланКеевское, - "ООП система - это множество объектов, взаимодействующих посредством исключительно передачи друг другу сообщений". Всё, что можно в это вместить, я отношу к ООП. При таком раскладе, в ООП-стиле можно писать и на JS, и на C, и на Pascal. Осовремененные толкования ООП, которые часто касаются реализаций в конкретных языках, я не признаю. ООП без protected для меня всё равно ООП (я, кстати, отношусь к категории оюдей, о которой писал Страуструп: я считаю наследование всего лишь "деталью реализации", а не одним из столпов ООП, хотя и применяю его при возможности и необходимости). ООП как в C++, когда все закрытые атрибуты нужно перечислять в заголовочном (считай интерфейсном) файле и светить ими всему миру, - тоже ООП, хотя и не самое лучшее.
И, в-четвёртых, JS-код действительно ужасен. Но связано это не с ООП-шностью, а с изначальной ориентацией языка: небольшие скрипты для манипулирования DOM-деревом и написания обработчиков-однострочников для обработки DOM-событий. Теперь на нём пишут крупные системы, хотя сам язык для них не подходит. Однако браузеры больше ничего выполнять не умеют, а модифицировать сам язык сложно из-за необхдоимости сохранения совместимости с существующим кодом.
Ах, про вопрос-то забыл.Я бы выбрал чертежи. Но не просто чертить что скажут, а получать задачу, разрабатывать и рассчитывать параметры требуемой модели и после этого воплощать свои мысли в виде чертежа.
Для себя я мог бы и картины рисовать, но это были бы любительские произведения. Я часто рисую какие-то каракули, когда нужно отвлечься ненадолго, иногда просто геометрические фигуры, иногда абстрагированные предметы (типа "дом", "лицо", в стиле 3-летнего ребёнка).
Но серьёзно учиться рисовать, чтобы в результате получать то, что одним нравится, а другим нет, мне не понравилось бы. С чертежом всё проще - изображённое на нём либо работает либо нет, либо понятно либо запутанно, либо эффективно либо тяжело - и критерии эти достаточно объективны.
>[оверквотинг удален]
> задачу, разрабатывать и рассчитывать параметры требуемой модели и после этого воплощать
> свои мысли в виде чертежа.
> Для себя я мог бы и картины рисовать, но это были бы
> любительские произведения. Я часто рисую какие-то каракули, когда нужно отвлечься ненадолго,
> иногда просто геометрические фигуры, иногда абстрагированные предметы (типа "дом", "лицо",
> в стиле 3-летнего ребёнка).
> Но серьёзно учиться рисовать, чтобы в результате получать то, что одним нравится,
> а другим нет, мне не понравилось бы. С чертежом всё проще
> - изображённое на нём либо работает либо нет, либо понятно либо
> запутанно, либо эффективно либо тяжело - и критерии эти достаточно объективны.+100500 коментарий доставил, достаточно ясно выражена мысль.
я бы тоже (точнее также) выбрал бы черчение, как минимум в следствии того, что нужно учесть один факт - люди с нарушенной (не развитой) мелкой моторикой редко смогут научится писать картины (я считаю, что это фактически так и есть, сужу по себе)пс: Также нарушения мелкой моторики могут наблюдаться при СДВГ, при нарушениях зрения, дизартрии, аутизме, спиноцеребеллярной атаксии и др.
цитата отсюда https://ru.wikipedia.org/wiki/%D0%9C%D0%...
пс: так же не буду отрицать того факта, что многие программисты страдают одним из этих последствий нарушения, таких как СДВГ, аутизме, синдром Аспергера и тд.
> а вы технарь на белом коне и со шпагойа вы — технарь на белом коне и со шпагой
> Теперь прощу прощения
Теперь прошу прощения
> отношусь к категории оюдей, о которой писал Страуструп
отношусь к категории людей, о которых писал Страуструп
> и написания обработчиков-однострочников для обработки DOM-событий
и написание однострочников для обработки DOM-событий
Но опечатки и ошибки не так страшны, как стилистически ужасный слог. Текст перегружен множеством сложных предложений. При прочтении в глаза бросается нарочитое смакование высокопарными конструкциями, даже союз "хотя" встречается трижды! Вам бы в журналистику — вести независимую колонку собственного мнения, а лучше писать бульварное чтиво в жанре беллетристики. Ошибки перед печатью исправит корректор.P.S. не удивлюсь, если цикломатическая сложность вашего типичного кода превышает 10.
Извиняюсь за невнимательность, "Теперь прошу прощения" в этот список попало случайно.
> стилистически ужасный слог. Текст перегружен множеством сложных предложений.Спасибо. Сам за собой иногда замечаю такое, но думал, что со стороны не сильно заметно.
Бывает пока пишешь предложение, в голову приходят связанные мысли и их хочется разместить рядом.
От этого длина и сложность предложения и увеличивается. Значит, буду работать над этим :)> нарочитое смакование высокопарными конструкциями
Не совсем вас понял. Можно несколько примеров?
Отвечаю Анониму задавшему встречный вопрос:>>Ох ты ж, как вежливо (честно). Редко тут такое встретишь, поэтому отвечу. Надеюсь, мой ответ не удалят до того, как вы его прочитаете.
Вежливость, проявление уважения к собеседнику, культура речи, грамотность, разве это всё чуждо "анонимам" опеннета? Если так, судя по вашей реплике, то настоятельно рекомендую вам использовать псевдоним (аля никнейм), чтобы отделять себя от таковых "анонимов".
>>Во-первых, это я задал вам встречный вопрос, но спорили вы не со мной: я - другой аноним.
Оч приятно, мне в принципе всё равно с кем, "не спорить", а вести конструктивный диалог "анонимом". Мне оч интересно любое мнение, особенно когда дело доходит до абстрактного мышления (кому-то работы Да Винчи нравятся, кому-то Айвазовский - ООП оно абстрактно (ыыы об этом чуть ниже)).
>>Во-вторых, я так понял, своим вопросом вы хотели показать оппоненту, что он ничего не понимающий гуманитарий (и должен бы выбрать вариант с картиной), а вы технарь на белом коне и со шпагой.
Чур меня чур если вы так считаете, пусть рука моя отсохнет если я кину камень в огород гуманитария (сам по большей части гуманитарий - история, Философия, психология, и хочу взяться за юриспруденцию). Мой вопрос на выбор одного из двух - банальный тест на мышления, не побоюсь этого слова, но я выдвигаю гипотезу о том, что в этом тесте (вопросе) кто, грубо говоря "хейтит" ООП конечно же выберут черчение (но не факт - это пока гипотеза), а другие писать картины (изобразительное искусство). Почему так ? Всё скрывается в человеческом мышлении (вероятно даже в том, какое из полушарий мозга у человека развито лучше - этот факт медики, психологи - доказали). Есть ли какие либо жесткий стандарты изобразительного искусства, кроме как деления на категории (жанры)? - нет. Вернемся к Да Винчи, он был один из тех уников, у которого развиты были оба полушария, к примеру - Джокондо, его попытки изобрести механизмы всякие, факт того, что он использовал "правило золотого сечения" когда создавал портрет Джоконды. И опять таки кто такая Джокондо - не ясно, вывод - абстракция, кто вывел (нашёл, доказал или наткнулся), что он использовал "правило золотого сечения" ? - математики, не другие художники ведь, это и есть тот факт, что у него оба мышления было развито. Задам вот такой вопрос, можем ли мы найти ошибку в работе художника? - нет, так как любой неровный штрих может быть задумкой, а в работе чертежника ? - да - достаточно взять линейку. Что мы сравниваем ? по сути два разных "способа" мышления человеческого, и "споры" тут не уместны. Нужно это просто принимать (осознавать) и пользоваться их благами. Говорить о том, что за "квадрат Малевича" и цента не дам, а чертеж истребителя нового поколения бесценен - бессмысленно.
>>Не люблю, когда слово "гуманитарий" используют в качестве ругательства, поэтому, заметив у вас опечатку ("что бы" в вашем вопросе должно писаться раздельно), хотел вас пристыдить в ответ, продемонстрировав собственное наблюдение, что технари (по крайней мере, те, кто себя такими считает), как правило, весьма безграмотны, и касается это как русского языка, так и технической составляющей их работы (среди наблюдаемых мной современных IT-"технарей" очень мало настоящих "инженеров").
Не знать не стыдно, стыдно не учиться. Не хочу утрировать по поводу "граммарнаци", но как минимум в школе по родному языку были - пятерки. Причина ошибок в том, что лень после напечатания комента проверять его на орфографию или там грамматические ошибки, ну и спелчекер не идеален (думаю беда именно в этом, заранее прошу прощения за ошибки, и отмечу, что русский язык не мой родной (ошиблись не иврит :))), я даже знаком с теми кто на коментах и спелчекере в свои 30 лет научились грамотно писать :).
>>Ну и в-третьих, по сути. Для себя в качестве определения "ООП" я выбрал изначальное, АланКеевское, - "ООП система - это множество объектов, взаимодействующих посредством исключительно передачи друг другу сообщений".
Если честно, я не хотел затрагивать конкретно тему ООП, но был рад прочесть ваше мнение относительно ООП, ваша точка зрения уже как минимум доказывает факт существования именно "вашей мысли" (Алана Кэйя), но трактовать (воспринимать, реализовывать) ее можно по разному, так как в данной области (программинг, информатика), как я считаю, давать волю абстракционному мышлению нельзя (немного категорично получилось), тут по большей части должна быть математическая строгость и конкретность мышления. В математике ООП бы существовало бы как обычная гипотеза, и дело математиков ее доказать или опровергнуть, а перед тем как что-либо доказывать, нужно с начало это строго и конкретно сформулировать, по сути ООП и вся беда связанная с ним исходит из того факта, что оно строго и конкретно не сформулировано. Вы затронули понятие "сообщений (messages)" - единственный язык с которым я знаком и который вовсю оперирует этим понятием - Erlang (поправьте меня если не прав), а по сути сам Erlang - ЯП с функциональной парадигмой. У меня складываются такие жуткие ощущения, что "функциональщики" лучше разбираются в ООП, чем ярые ООПешники (моё личное мнение), всё потому, что "функциональщики" более математически подкованные. Не многие ООПешники знают о теории типов (к примеру), не многие хотят изучат ЯП (программинг) как науку, многие на все эти ЯП смотрят как на инструмент, который должен быть удобным (тут тема про "быстрое написание кода"). Пусть так и будет, каждому своё. Ну все, много написал про ООП, дальше не буду занесло уже меня.
>>Осовремененные толкования ООП, которые часто касаются реализаций в конкретных языках, я не признаю.
Мой совет, избавьте себя от категоричности, то, что земля крутится вокруг солнца, тоже долгое время не признавали, пока это в конце концов не доказали, заставьте думать себя иначе, к примеру (в моем случае), то, что пока еще не доказано или опровергнуто - имеет место быть (существует как мысль - гипотеза). Вот возьмите, чисто интереса ради, и формализируйте понятие ООП, напишите диссертацию по этому поводу, поделитесь, послушайте критику (ну вы поняли, научный подход), а может в итоге вы и есть тот человек, который поставит точку в "спорах" и "не понятках" в ООП (серьёзно, без всякого сарказма и иронии).
>>Страуструп: я считаю наследование всего лишь "деталью реализации", а не одним из столпов ООП, хотя и применяю его при возможности и необходимости
А можно спросить откуда (где Страуструп прочел) это "понятие" про столпы ООП и где наследование есть одним из них, кого он имел ввиду ? Алана Кэй-я? (Страуструпа читал давно и не помню).
>>хотя и не самое лучшее.Простите, вырвал из контекста, хочу просто отметить, что слова (понятия) вроде "лучшее", "плохое" не дают никакой строгой оценки, поэтому мне трудно понять, что под ними подразумевается, нет это не придирание к словам, просто допустим понятия "больше" или "меньше", "больше или равно", "меньше или равно" хорошо доказано в теории "большего и меньшего".
>>И, в-четвёртых, JS-код действительно ужасен. Но связано это не с ООП-шностью, а с изначальной ориентацией языка: небольшие скрипты для манипулирования DOM-деревом и написания обработчиков-однострочников для обработки DOM-событий. Теперь на нём пишут крупные системы, хотя сам язык для них не подходит. Однако браузеры больше ничего выполнять не умеют, а модифицировать сам язык сложно из-за необхдоимости сохранения совместимости с существующим кодом.
По большей части высказанного я с вами соглашусь, добавить мне как бы нечего.
пс: Спасибо, за развёрнутый ответ.
> лень после напечатания комента проверять его на орфографию или там грамматические ошибки, ну и спелчекер не идеаленЯ свой предыдущий проверил два раза, и всё равно в нём нашли ошибки :) Опечатки - это одно, а незнание, как писать правильно, - это другое. Нет ничего страшного в том, чтобы изредка допустить опечатку, так как суть сообщения всё равно остаётся понятной. Но бывает, что в сообщении из двух предложений содержится пять ошибок, - это начинает восприниматься как неуважение к собеседнику.
> Вы затронули понятие "сообщений (messages)" - единственный язык с которым я знаком и который вовсю оперирует этим понятием - Erlang (поправьте меня если не прав)
Я с Erlang не знаком, к сожалению, но просмотр статьи на википедии показал, что, скорее всего, это не то, что имел ввиду Алан Кей.
Рассмотрим для примера фрагмент кода на C++-подобном языке.
class Human_with_car {
Car car;
void get_to_work () {
// ...
car.turn(Car.RIGHT);
// ...
}
}Human_with_car john;
// ...
john.get_to_work();Строка "car.turn(Car.RIGHT)", в терминологии Кея, - это посылка объектом john (типа Human_with_car) объекту car (типа Car) сообщения turn() с одним аргументом направления (Car.RIGHT). А выполнение кода начинается с последней строки примера, в которой "текущий объект" передаёт объекту john сообщение get_to_work() без аргументов.
То есть сам термин "сообщение" в современных языках отсутствует, хотя по сути смысл тот же, что и изначально в SmallTalk, где этот термин использовался явно. В Erlang, насколько я понял, под сообщением понимают не такое, "смысловое", сообщение, не саму идею, а конкретную сущность, использующуюся для взаимодействия процессов.
Имхо, по терминологии Алана Кея, даже Интернет можно рассматривать как ООП-систему: хосты (сервера и клиенты) - это "объекты", а сетевые пакеты (ethernet, ip, tcp, и т.д.) - это "сообщения". Так что ООП-система - это не обязательно "программная" система.
> А можно спросить откуда (где Страуструп прочел) это "понятие" про столпы ООП и где наследование есть одним из них, кого он имел ввиду ? Алана Кэй-я? (Страуструпа читал давно и не помню).
Там, где я это нашёл, явных ссылок на кого-то он не делает. Да и имхо он - один из тех, кто имеют полное право делать подобные заявления ссылаясь лишь на себя самих и свой опыт. Но тройку "полиморфизм-инкапсуляция-наследование" очень часто можно было видеть в списке отличительных черт ООП, когда оно ещё только набирало популярность (не знаю, как сейчас).
Специально поискал этот фрагмент, просто процитирую. Книга "Язык программирования C++, 3-е издание", глава "24. Проектирование и программирование", пункт "24.2.2. Отказ от наследования".
Конец первого абзаца: "Распространённые причины отказа от наследования - не считая инерции - состоят в заявлениях, что "наследование - это деталь реализации", "наследование наружает сокрытие информации" и "наследование затрудняет взаимодействие с другими программами"".
Второй абзац: "Взгляд на наследование просто как на деталь реализации не учитывает, что иерархия классов может непосредственно моделировать ключевые взаимоотношения между понятиями в данной прикладной области. Такие взаимоотношения должны быть выражены в проекте явно".
> > > хотя и не самое лучшее.
На мой взгляд, не самое лучшее - значит содержит недостатки :) В данном случае недостаток в том, что пользователь класса смотрит интерфейс класса в .h-файле, но кроме интерфейса видит и приватные поля/методы, которые являются деталью реализации и, согласно принципу инкапсуляции, должны быть скрыты от всех, кроме разработчиков этого класса.
ООП - оно как религия, причем в худших ее проявлениях.
> ООП - оно как религия, причем в худших ее проявлениях.Вот а вы как ответили бы на мой выше указанный вопрос?
Я фотографирую.
отлично, значить вы любите всё готовое, где нуно тупо нажать на кнопочку.
Подготовка наполнения кадра с учетом комплиментарности цвета (связка модель-фон-аксессуары), конвертация RAW с цветокоррекций, ретушь через частотное разложение, и в финале правка светотени. Это все называется "нуно тупо нажать на кнопочку"? Сегодня вечер откровений какой-то!
> Это все называется "нуно тупо нажать на кнопочку"?Да так и есть, представьте художника, который также как и вы опишет весь процесс работы над той картиной, которую ещё не "нарисовал в голове", мысль моя понятна ? Суть моего вопроса в определении способа мышления (как указал выше в развёрнутом коменте, это моя гипотеза). В вашем выборе (фотографировать) это никак нельзя назвать абстрактным мышлением, это схоже на комбинаторный способ. Если вас, помимо фотографирования (процесса), ещё и интересует, то, что "под капотом" у самого фотоаппарата, тогда чем ваш выбор отличается от чертежа? тут я думаю можно провести аналогию.
>>Сегодня вечер откровений какой-то!
вам не интересно в следствии очевидности выше сказанного мною? тогда будьте добры поделитесь вашими умозаключениями по этому поводу мне будет интересно (заранее спасибо).
Повторю еще раз. Нет никакого эталона ООП. Его реализации весьма отличаются в разных ЯП. Проблема не в ООП js, а в людях с синдромом утенка, которые пытаются распространить принципы ООП первого понравившегося им ЯП на все остальные.
лол ничего себе карьерист
В JavaScript приватных методов в прототипах нет.
или публичные. Или публичные помеченные _
В прототипном ООП нет операции наследования. И приватных методов тоже нет.Но если так уж хочется - есть Тайпскрипт, он такое просто не скомпилирует. В рантайме через прототипы - да, и в typescript нем можно, конечно, но раз уж такой хитрый код написан, значит, так и надо (а бывает, когда надо - для ORM или для юнит-тестов). В Java ведь тоже можно через Reflection.
26.03.2015 Google отказался от включения Dart в состав браузера ChromeНо вы пишите, пишите...
Это не браузерный язык, но вы пишите, пишите...
> 26.03.2015 Google отказался от включения Dart в состав браузера Chrome
> Но вы пишите, пишите...А что толку от языка в одном браузере, когда надо поддерживать несколько. Всё равно придётся транслировать в JS и обрабатывать этими вашими вебпаками.
Он и без поддержки браузерами хорош сам по себе.
"Вы можете выполнить код Dart различными способами:
— Транслировать код Dart в JavaScript затем запустить код в современном браузере: Chrome, Safari 5+, и Firefox 4+ (другие браузеры будут поддерживаться позднее).
— Выполнить код Dart в виртуальной машине на стороне сервера
— Использовать Dartboard для написания и выполнения маленьких программ на Dart в окне браузера."
Те, кто не ставят открывающиеся и закрывающиеся фигурные скобки на один уровень, не способны создать хороший язык
Те, кто постят анонимно на опеннете, не способны создать хороший комментарий.
Регистранты не лучше.
Те, кто не ставят открывающиеся и закрывающиеся фигурные скобки на один уровеньПериодически являюсь членом жюри конкурсов по программированию. Часто вижу такое:
if (a[0] > a[1]) {
maxValue = a[0];
maxIndex = 0;
} else {
maxValue = a[1];
maxIndex = 1;
}Уверен, уж эти-то ребята создать хороший язык могут.
да не ври
ну так скобки то на одном уровне :)
if (a == b) {
c = true;
d = false;
}очень удобно!
Вот, вот. И не писать тупые возвраты из функций там, где они нафиг не нужны
Вот я пробовал всякие разные стили оформления кода, в итоге доверяю это дело стандартному форматировальщику из иде.
Если другие разработчики правят тот же код что и я, и так же пользуются стандартным форматировантем - то изменений визуально меньше и коммиты легче читать. Да и вообще на скорость написания кода положительно влияет.
>Для выполнения и отладки приложений на языке Dart, без компиляции в JavaScript, предоставляется Dartium - специальная сборка браузера Chromium с интегрированной виртуальной машиной Dart VM.А зачем, если есть лоадер для вебпак? https://www.npmjs.com/package/dart-loader
Чтобы отлаживать не оттранслированный код, постоянно пытаясь сопоставить его в голове с исходным, а, собственно, исходный.
А зачем вообще нужен этот вебпак, если и без него в целом неплохо? Нажать кнопку и восхититься побежавшим по экрану консольным строчкам, прибавляя ЧСВ фронтендным макакам?
Ахахаха, что это значит без него в целом неплохо? Вы вообще не в теме?Вебпак это бандлер, который собирает разрозненные куски кода, разметки, css'a и прочего фронтенд хлама в один жирный bundle.js, по ходу минифицируя, запуская транспилеры и прочее. Это чем-то напоминает классическую компиляцию, когда дерево проекта собирается и оптимизируется одним инструментом. Без него будет лапша и стыд в исходниках. Можно конечно использовать другие бандлеры, но по состоянию на сегодняшний день webpack является самым навороченным.
Я в курсе для чего нужны бандлеры. Лапша и стыд в исходниках уж точно не из-за отсутствия вебпаков, скорее из-за кривизны рук разработчиков. Да, где-то они нужны, но чаще необходимости в них нет. И да, прямо сейчас я ковыряю проект, в котором предыдущий разработчик минифицирует все это барахло не при деплое на сервере, а на своей машине, после чего коммитит в репозиторий. Уровень владения инструментами потрясает. И такое в моей практике постоянно.
намешал в кучу про дев, прод, неопытность другого разработчика и не забыл распетушить свое ЧСВ. А потом обижаетесь, почему вас веб-макаками называют. Вы не люди.
Такое впечатление, что ты не понял, что я написал. И кто из нас макака?
что за звуки издают эти две обезьяны?
проводят собеседование на вакансию синьёр жс девелопер
господа хелоуворлдщики, скромнее нужно быть
Тушите сеньора, горит походу
zzz
Другой разработчик, очевидно, не хочет, чтобы от него избавлялись, раз коммитит минификацию. Молодец, одним словом.
> Вебпак это бандлер, который собирает разрозненные куски кода, разметки, css'a и прочего
> фронтенд хлама в один жирный bundle.js, по ходу минифицируя, запуская транспилеры
> и прочее. Это чем-то напоминает классическую компиляцию, когда дерево проекта собирается
> и оптимизируется одним инструментом.Н-да. Очередноые откровения о работе капутеров от вебщиков.
Интересно, упаковка всего в архив типа zip у вас под типа инсталляцие проходит?
А dart ещё в webassembly не конпелируют?
как бы они хром в darts не перевели. И будут поставлять его с darts vm как машиной для исполнения.ох уж эти NIH-привычки у них...
и будут компилить жс в дарт
Коллеги, вы чего спорите, то? Гугл объявил, что у них офф.язык - это ts. Можно расходиться товарищи, а dart постепенно закaпывать.
http://angularjs.blogspot.ru/2017/04/official-languages-at-g...
Отличный пруф - страничка на блогспоте
так то это офф.блог angular.io. учите матчать шура.
А кто такой Гугл и почему меня должно интересовать его мнение?
> Коллеги, вы чего спорите, то? Гугл объявил, что у них офф.язык -
> это ts. Можно расходиться товарищи, а dart постепенно закaпывать.
> http://angularjs.blogspot.ru/2017/04/official-languages-at-g...Вы вообже сами то ходили по ссылке, которую указали?
Там наоборот разъясняется что Dart и TS это равноправные языки
Following my keynote at ng-conf 2017 that seemed to indicate that Typescript is now an official language at Google. + тот момент, что angular написан на ts, а не на dart о многом говорит. по сути было давно понятно, что гугл закaпывает дарт, еще со времен анг.конф и выступлений разработчиков с объяснением причин такого выбора.