Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+160
for(var i = 0, l = requestParams.length; i < l; i++) {
var param_pair = requestParams[i];
key = encodeURIComponent(param_pair[0]);
val = param_pair[1];
if ( val && val.constructor.toString().match(/array/i) ) {
val = val.join('+');
}
// ...
}
Кусочек велосипеда, который заменяет функционал jQuery.ajax
Если вдруг наш параметр оказался массивом ... ну что ж еще с ним сделать кроме как соединить через "+". Обратите внимание на саму проверку.
Запостил: 
Elvenfighter,
05 Декабря 2012
Follow us!
Из вопиющих недостатков: нужны либо интерфейсы, либо множественное наследование.
Из того, что хотелось бы, но можно вытерпеть: метаклассы и больше правильно работающих инструментов позволяющих контролиовать наследование, наличие и отсутствие полей, специализация методов на более чем одном параметре, равноправие с встроенными классами, возможность группировать типы по произвольному признаку, ну и над всем этим ошибки которые бы позволили нормально определить причины несовпадений, отсутствующих методов и / или несовпадения типов на которых методы специализируются. Ну и можно еще дальше пойти, но пожалуй на один серьезный апдейт версии тут уже хватит.
В js прототипная объектная система, в нем не нужны классы. Но, тем не менее, они будут в es6, как сахар над конструктором+цепочкой прототипов http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_c lasses , да и сейчас каждый второй на своем велосипеде катается.
Множественное наследование не нужно, как раз из-за цепочки прототипов. Нужны примеси, а они есть в каждом втором "классовом" велосипеде.
Метаклассы - да, было бы вкусно, по идее с помощью Proxy из es6 можно нечто подобное реализовать, хотя не совсем.
Инструменты, позволяющие контролировать наследование? Чем instanceof, isPrototypeOf, getPrototypeOf не угодили?
Наличие и отсутствие полей? in и hasOwnProperty?
Специализация методов на более чем одном параметре? Не совсем понял, но если понял - совсем далеко от идеологии js.
Равноправие со встроенными классами? Это возможность установить внутреннее свойство [[Class]]?) Остальное, вроде, реализуемо. Зачем?)
А дальше - совсем размыто, вроде возможно все.
[font size=1]минусуйте за нубовоброс тока ответьте и не скучно по-википедийному[/font]
Несостоятельность системы была продемонстрирована еще при разработке четвертой версии экмаскрипта, но из политических соображений, типа тех же войн между вендорами, где все хотели протолкнуть свои наработки и узаконить баги как фичи нихрена не получилось.
В итоге вендорские войны окончательно победили здравый смысл, и решили приналечь на пропаганду вместо того, чтобы действительно что-то развивать в языке.
Можно добавлять извне любые свои методы ко всем классам и тем самым расширять их.
При плотном использовании могут превратить любой проект в лютый мозгоебский пиздец.
Или смысл в том, что методы классов можно менять по ходу работы?
Когда пытаешься получить у объекта свойство, а в самом объекте свойства не наблюдается, интерпретатор не отчаивается. Он пытается найти свойство в объекте-прототипе. Если и там свойства не нашлось, поиск происходит в прототипе прототипа. И так далее.
Если добавить в объект X какое-то свойство или функцию, они автоматически станут доступны всем объектам, которые прямо или косвенно ссылаются на X как на прототип. Это, например, позволяет модифицировать уже существующие "классы", причём новые методы сразу же станут доступны всем "экземплярам" класса.
И какие плюсы это даёт разработчикам? Может какие-то паттерны есть на этом основанные? Имхо что-то бесполезное, если ты не пишешь систему искуственного интелекта. Самомодификация кда не нужна
Копирование и слияние объектов. Не просто поэлементное копирование (возможно глубокое), а с сохранением цепочки прототипов, внутреннего класса (эти 2 есть в некоторых велосипедах), сохранением дескрипторов свойств (вполне реализуемо), приватами (а вот тут проблема). Если и частично эмулируемо - жутко медленно.
Ну и приватов/протектедов, именно приватов, а не замыканий, не хватает.
Приваты - возможно. Константы - возможно. Но это всё доп. модификаторы, а я думаю, что js нужно оставить его суть - как можно более простой язык.
Я бы еще крепко подумал и наверное не вводил туда прототипы.
>Из вопиющих недостатков: нужны либо интерфейсы
А в итоге получим некий аналог жабы или сисярпа. Не нужно.
>либо множественное наследование.
Динамические кресты со сборкой мусора. Не нужно.
Вообще пытаться писать в привычном ООП-стиле на js - вредно.
В общем js в нынешнем виде (тормознутого, но очень простого динамического языка) меня вполне устраивает.
Хотя, повторюсь, согласен - приваты и константы не помешали бы.
Интерфейсы или множественное наследование необходимы при иерархии наследования. Если у вас нет ни того ни другого, то вы никогда не сможете объединить два типа в один, при условии, что оба являются под-типами третьего, и есть еще четвертый тип, так же подтип третьего, который нужно исключить.
>Объектная системя Явы совсем не далеко ушла от жабоскрипта
Лолшто?! Ява появилась раньше js. И у них довольно сильные отличия в объектных моделях.
ЗЫ. БОльшая часть всего кода в мире написана на Коболе, а там вообще объектов вроде как и нет, на сколько я знаю (но могу ошибаться, а в Вики влом лезть). Так что, на это основании делать выводы о том как нужно строить объектные системы?
Подозреваю, что такого нет
Отказаться от "прототипа" - ок, и паблики, и приваты объявляем в конструкторе. Проблемы с наследованием, немного падает скорость создания.
Отказаться от "дешево" - есть обертки, по принципу похожие на вызов родительских методов у Резига, но тормозят код в разы.
В объектной системе не нужны классы? Да вы че, а водку без воды вы тоже можете?
Вы не понимаете разницу межу иерархией создаваемой наследованием и отношениями которые существуют между классами в настоящем мире. Объектная система нужна для того, чтобы моделировать эти отношения, а в жабоскрипте она это вообще никак не может сделать.
Для справки, метакласс - это фабрика классов, никаким боком к прокси не имеет отношения. Это схема как создавать классы, в языке где классов нет с ней нечего делать.
Равноправие нужно для того, чтобы можно было применять одни и те же механизмы ко всем объектам без исключения. В жабоскрипте очень часто приходится писать специальные обходные пути для работы со встроенными классами (которые кроме уебищного дизайна еще и помогают тем, что ведут себя неадекватно по сравнению с другими объектами, или у других объектов внезапно нельзя добиться тех же способностей, что есть и у встроенных классов).
Резюме: вы, очевидно, кроме жабоскриптовой системы ничего даже и невидели, а оценка осонванная на самолюбовании - да еще с такими понтами...
>Объектная система нужна для того, чтобы моделировать эти отношения, а в жабоскрипте она это вообще никак не может сделать.
Серьезно?)
Если под метаклассом вы подразумеваете именно фабрику классов, а не класс, инстансами которого являются классы - такое и сейчас легко реализуемо, иначе как бы "классовые" велосипеды писали?) Прокси как раз поможет создать исполняемые инстансы классов и, соответственно, конструкторы. Сначала загуглили бы, что за зверь такой Proxy в es6.
По поводу равноправия - приведите примеры.
Судя по всему, как раз вы возможности js мало представляете, что нижеприведенное синтетическое говно подтверждением и является. Книжки идите лучше почитайте.
Вот, в тему о различиях встроенных классов и пользовательского кода.
там прям с простых вещей показано как сделать MVC на js. + как реализовать всякое наследование и эмуляцию классов в реальной роботе не применял ещё.
Вреда, конечно, от чтения не будет, но не стоит переоценивать... К сожалению, чтобы понять устройство и быть хорошим разработчиком на жабоскрипте нужно, восновном, читать литературу по другим языкам, т.как хорошей литературы по жабоскрипту почти нет. А с другой стороны, всяких "практических пособий" и "самоучителей" - прорва, и они все, примерно одного пошиба, написаны любителями для любителей. В каком-то смысле, это печально, т.как люди, которые в теории могли бы что-то сделать для языка, испытывают к нему сильнейшую антипатию, а люди, которые продвигают язык игнорируют ученое мнение, да и вообще не обременяют себя мыслями о будущем языка и о том, какое действие это принебрежение возымеет в дальнейшем на развитие отрасли вцелом.
>про жабоскрипт написано очень мало книг, а хороших - так вообще всего одна, и та под сомнением
Жабаскрипт. Подробное руководство, Флэнаган
Жабаскрипт. Оптимизация производительности, Закас
Жабаскрипт. Шаблоны, Стефанов
Жабаскрипт. Профессиональные приемы программирования, Ризиг
Уже упомянутый Маккоу.
Остальное сводится к "не читал, но осуждаю".
Вы меня убедите? Ну вот задайте себе это вопрос? Вы вед, положа руку на сердце, не знаете о чем говорите, ну зачем лезть с вымышленными аргументами? - очевидно, же, что нет. Вы убедите кого-то из других читающих - окей, ну только может имеет смысл прямо аппелировать к другим читающим и оставить меня в покое?
ЗЫ. Мое предыдущее утверждение о том, что нет хороших книжек по жабоскрипту остается в силе после знакомста с вашим списком. Это все книжки - технические пособия, без затей и попытки анализа.
ХАМАС объявил победу над Израилем :) Ну а что им остается делать?
А еще фильм был такой, про короля Артура, и там эпизод был про черного рыцаря, вот, тоже в тему.
- Что вы выдумали. Вы не знали про метаклассы до того, как началась дискуссия, и ляпнули что-то невпопад, потом постарались исправится, но особо не вдаваясь в подробноси, ляпнули другую глупость.
- Вы прочитав и не поняв проблемы в моем пример объявили его "синтетическим говном", и сделали вывод никак не коррелирующий с проблемой. Если формулировать проблему по другому, давайте, вы расширите класс регулярных выражений в жабоскрипте и добавите negative lookbehind, например, или расширите класс HTMLImageElement, свяжете его с тегом <icon> и перегрузите свойство src так, чтобы можно было заргужать файлы в формате ICO. Так, понятнее проблема?
- Я какое-то время был активным участником конференции посвященной развитию жабоскрипта, и, по крайней об устройстве языка знаю из первых рук. Обвинять меня в незнании каких-то технических моментов жабоскрипта? ну, как бы смешно... Возможно, я что-то пропустил, или не обратил достаточно внимания, но будучи знакомым не только со стандартом и его историей, но и реализациями, и в том числе, написав инструменты по работе с языком (подсветку синтаксиса) могу с уверенностью сказать, что хорошо знаю язык. На уровне достаточном для того, чтобы преподавать, если бы мне этого хотелось.
- Но самое главное в этой... дискуссии другое. За объектной системой стоит математика, теория множеств, теория категорий, которые однозначно и в категорической форме описывают систему. Поэтому аппеляции к опыту, тому как это сделано в других языках и / или системах, как думает тот-то и тот-то - бессмысленны. Более того, ваше личное мнение по этому вопросу безразлично и не имеет никакого веса, как если бы вы вдруг изобрели самостоятельно новый вид прибавления. Ваше прибавление может быть либо таким же, как уже существующее, либо это чушь.
Вот и закончились десять минут.
а меж тем ругаете язык, что в нем, иносказательно, умножение действует как скалярное произведение, а не декартово.
вот скажите, для примера, какую задачу вы поручили сделать жабаскрипту, и как язык вас заставил сделать это криво? возможно, вы просто выбрали неудачный подход?
Заметте, я ничего абсолютно не говорил про то, как прибавление работает в жабоскрипте. Все, что вы по этому поводу написали - ваши догадки. Я говорил про прибавление, как операцию над мощностями множеств, это та самая алгебраическая операция, которую проходят в школе. Про Декарта я ничего не говорил, и ни о какой связи между ним и прибавлением мне не известно. Я использовал прибавление, как самую известную математическую операцию, которая не должна вызвать у читателя недоумений.
Задача; я тут недавно ссылку давал, ну, это как пример. Для тех, кто забыл, о чем там: нужна функция, которая принимает аргументом функцию и еще один аргумент и возвращает true если функция специализируется на втором аргументе (является методом второго аргумента). Задача решаемая, но не тривиальная, как оказалось.
Кроме того, в этом же топике я описал задачу, которую в принципе не возможно решить в жабоскрипте: эмуляция отношения "А является Б", когда нужно исключить третий тип, который является непосредственным подтипом того же родителя, что и два других. По определению иерархического наследования такая операция выходит за рамки всех отношений, которые можно с его помощью описать.
Или, другими словами, иерархическое наследование может описать только изоморфизм, но нам нужно описать гомоморфизм.
На интуитивном уровне это можно выразить как то, что объект одновременно может быть классифицирован в разные группы, при том, что группы (классы) будут в других отношения несовместимы. Пример я тоже приводил. Булочная, которая одновременно и магазин и дом. Но не каждый дом - магазин, и не каждый магазин - дом.
Более того, "изоморфизм" и "гомоморфизм" - не антонимы и могут относиться к одному объекту.
Подозреваю, что были нужны приставки "гомо" и "гетеро", или опять же ЯННП, просветите в латыни.
Судя по оценкам компетентных форумчан и руководствуясь здравым смыслам, вынужден уличить вас в словоблудии, которое претендует на наличие смысла только косвенно, ввиду использования мудрёных конструкций. При рассуждении же о тонких материях ООП в ЖС, вас сливают-таки собратья с более простым лексиконом, и это, увы, очевидно.
И что? Да, нам нужно наследование от двоих родителей, и нам нужно описать гомоморфизм. И в этом нет никакого противоречия. Нужно и то и другое, но эти вещи находятся в разных плоскостях. Линеаризация, как раз и призвана решить как создавать проекцию множественного наследования на одно измерение. Т.е. линеаризация позволяет рассматривать отношения объекта с другим объектом как пару, а не как отношение объекта и множества других объектов. Возвращаясь к сложению, точно так же, нет никакого требования с точки зрения математики, чтобы сложение производилось только с двумя аргументами, но мы можем думать о линеаризации, как о каком-то процессе, который виберет порядок сложения аргументов попарно. Точно так же мы можем говорить о гомоморфизме в контексте наследования. Это, в тривиальном случае - отношение между парой объектов, и во всех остальных случаях - взаимоотношение между объектом и группой объектов, которую мы каким-то образом упорядочили, и, теперь саму эту группу представляем как отдельный объект.
А теперь вернемся к контексту жабоскрипта, в котором ничего такого нет, и близко, и в течение десяти следующих лет не будет, и ни одна из мартышек заседающих в комитетах и на обсуждениях никогда даже не заикнется.
Кстати, раз уж тут речь зашла о том, что читать, а что не читать. Для меня интерес начался с этой статьи. Ну, не совсем, я начал разбираться с устройством объектной системы EIEIO, и наткнулся на "кастомизацию" CLOS. Решил почитать дальше, ну и т.д. Статья не имеет отношения к Лиспу вообще, автор скорее всего ориентировался на С++ когда ее писал, но она более научного, чем прикладного характера, и не относится к какому-то конкретному языку.
1. O RLY? Это у вас что ни слово - глупость. Proxy.createFunction, constructTrap. Мозгов не хватает из этого метакласс сделать?) Хотя да, вы то и фабрику конструкторов в js сделать не можете.
2. Такой проблемы при нормальном понимании языка не возникает. Особенно комментарий про es3 оттуда порадовал. Проверьте работоспособность того говнеца в старых браузерах на той же String, это эпик фэйл:)
3. Отец русской демократии! Но языка не знаете. Особенно про "уровень, достаточный что бы преподавать" понравилось. Помню, 2 года назад, еще до того как вплотную за него взялся, преподавал js, при том его почти не зная. Тем не менее, знал его лучше, чем остальные горе-преподаватели. Охотно верю, что это ваш уровень.
4. Вам безразлично мое мнение? Ну да, от безразличия ведетесь как ребенок. Теория множеств? Ну оочень много вы про неё тут писали.
А что же это тогда метоклас, если не фабрика?
Это именно череда фейлов из-за того, что не разбираешься.
Ничего. Когда я ради интереса начал знакомиться с этой хренью (частично - из-за гризманки), начал изобретать свои велосипеды для наследования и всего такого, но потом отпустило. И вполне так понравилось. Я встроил мозиллье двигло себе в программу даже, с хитроэкспериментальными целями. Правда, из-за недостатка времени пришлось забить хер.
Дискас.
С обсуждения предмета спора вы перешли на обсуждение личности спорщика.
Приехали…
Городить костыли вместо того, чтобы взять нормальный язык? NO WAY! Вместо того, чтобы начать решать реальную задачу, что тебе поставил заказчик, ты будешь тратить время на нагораживание костылей, вместо тго чтобы взять готовый язык. А теперь представь, что твоя костыльная система ООП попадется в поддержку другому программисту. Он пока не разберется - будет какое-то время лезть на стену.
а я считаю, что она одна из лучших:
1. краткая запись, известная как JavaScript Object Notation - где вы еще видели такую эстетику лаконичности и элегантности?
1.1. JSON как данные - по наглядности конкурирует разве что с yaml\haml, явно по читаемости выигрывает у разрекламированного xml и вообще всего sgml семейства
1.2. JSON as namespaces - отлично структурирует код, не засоряя глобальную область видимости
2. реализация функций:
2.1. как объектов, что позволяет писать в функциональном стиле
2.2. как замыканий с присущей им наследуемой областью видимости, что позволяет не пересыщать аргументами
2.3. лямбды, или анонимные ф.: event-driven просто песня.
3. все есть объект: опыт java показал, что примитивные типы имеют больше недостатков, чем достоинств (особенно разница в API массивов и коллекций, аргх!), да и методов нативных хватает (хотя у Ruby все равно получилось лучше)
4. есть новые ecmascript т.н. дескрипторы:
value - значение
writable - изменяемость
enumerable - итерируемость в for in
configurable - можно ли переопределять, удалять
5. динамическая типизация: все плюсы, присущие ей. особенно мне нравится тот факт, что всякие крестоблядские шаблоны и жабагенерики нам абсолютно не мешают, и вместо прямого значения переменной можно определить функцию, возвращающую значение. только, пожалуйста, не нужно злоупотреблять и использовать одну переменную для хранения всего образующегося мусора.
1. классы? они не нужны! можно пробовать использовать прототипы, но по мне, лучше использовать фабрики. да, хочется сперва определить класс объекта, но здесь лучше использовать подход через существование свойств, через hasOwnProperty или же typeof ... ==="undefined"
2. прототипное программирование: самый большой мой фейспалм-жпг. ну не обязательно расширять прототипы - вполне можно обойтись и без этого. можно! по крайней мере, я уже забыл, когда использовал свойство prototype или __proto__. и вам того же.
3. наследование? заменяем делегированием. можно и прототипы использовать, но мне не нравится это. через делегирование же можно и множественное наследование заменить.
4. область видимости (приватные члены): приватные члены (поля, методы) можно сделать, обьявляя их как переменные, которые будут доступны по this. внутри объекта и невидимы вне его
5. абстракция, интерфейсы - их нет, но и не надо, см. п.1.
итог, что надо помнить при программировании на JS:
1. язык скриптовый, интерпретируемый, и на нем НЕ НАДО городить сложные системы. тем более, что фреймворков уже полно, не надо ваять фреймворк на фреймворке. Может, для чего-то мощного подойдет строго типизированный и компилируемый язык. лучше простое делать просто, изящно, легковесно. все таки браузер - не эмулятор.
2. язык таки объектный, НЕ НАДО подгонять его под ООП и злиться, что это оч мучительно. Вместо этого подружитесь с объектами, не ограниченными классом, они хорошие, если гладить их по шерсти.
3. олдскульная процедурщина, хоть и более чем допустима, все же неэстетична. лучше попробуйте функциональщину.
Так вот, не смотря на то, что ЭЛисп в прямом смысле этого слова, интерпретируемый (жабоскрипт не всегда интерпретируемый, существуют версии, которые компилируются), обладает настоящей (пусть и далекой от идеала) объектной системой. Где имеет место быть и работа с фабриками (мета-классами) и с моделированием протокола (описанием методов и алгоритмов выбора самого подходящего метода). Эта система полностью описывает все возможные ситуации возникающие при применении правила "Х является У" к любым парам объектов (чего нет в жабоскрипте, например).
ЭЛисп в других отношениях мало чем отличается от жабоскрипта, практически те же основные типы данных, есть какие-то специфические для области применения конструкции (буффер, таблица символов, ср. жабоскрипт окно браузера, ДОМ). Использовать объекты в ЭЛиспе удобно! это решает проблемы хранения состояния, построения сложноструктурированных данных, да и не только. В ЭЛиспе, конечно, есть и много еще, чего в принципе нет в жабоскрипте (макросы, встроенный дебаггер и чуть больше встроенных типов), но это мелочи.
При всем желании... при прочих равных условиях, разница между этими двумя языками огромная. Жабоскрипт - просто выгребная яма в сравнении, где чуть более чем все сделано через жопу.
Питон? Аналогично, он может решать все те же задачи, что решает жабоскрипт, более того, это будет, как правило, сделано лучше. Объекты? - никому не мешают, никто их как-то не стесняется использовать. [лимит символов в сообщении]
Так вот, жабоскрипт такой потому что, да и существует вообще потому что: войны вендоров, всем откровенно насрать на то, как по-настоящему лучше. Делается так, чтобы в первую очередь были довольны производители браузеров. А то, что пользователи врезультате получают говно по полной программе - очевидно тех же производителей не волнует.
а еще он красив, лаконичен и последователен. я бы точно не хотел на его месте видеть тот же пхп. Lua - да, а еще лучше python или даже ruby, но да ладно.
и вот знаете, мне на работе достался web-проект на java (stripes,spring,jpa) и есесна там js (jquery+jquery ui). и знаете что? мне приходится больше писать на js, чем на java, а вот отлаживать - меньше. я научился писать на js так, чтобы особенности языка не мешали.
код получается легко и приятно читаем, по крайней мере, в данном случае его хватает.
з.ы. имхо, беда одна - на нем стали писать сложные системы. mvc, rcp, и весь тяжелый энтерпрайз упал на браузеры, которые, вообще, должны были бы показывать только текст и картинки.
встроенный дебаггер
o_O dragonfly, firebug, chrome debugger, даже для IE есть сторонняя приблуда, забыл как зовут - их нет?
макросы не нужны!
а еще для придир есть кофейскрипт
- ключевое слово: встроенный отладчик. С таким отладчиком можно общаться из кода. Можно предложить пользователю исправить ошибку, можно работать со стеком, извлекать информацию об использовании, покрытии, и т.п.
- Макросы не всегда используются так, как в препроцессоре С++. Правильно сделанные маркосы используются для других вещей. Я вот выше по тексту давал ссылку на маленькую систему макросов, которая парсит код написанный в определенной форме, строит из него внутреннее представление и генерирует уже работоспособный код:
превращается в:
Но, кроме этого, макросы позволяют вводить новые языковые сущности / структуры. Например, классы! Позволяют сделать синтаксис более выразительным. В примере выше, прячестя "неинтересная" техническая переменная, указывающая на хеш-таблицу. И не возникает проблем с любителями / нелюбителями сахара: кому надо - раскроет макрос. Другой момент: чтобы описать как происходит итерация, мне нужно указать это в трех разных местах (i 10), (>= i -10) и (decf i 2). Макрос это решает, переставляя нужные мне части в одно место.
Функции, особенно в контесте жабоскрипта не подходят для решения таких задач, потому что нет никакой возможности у программиста помочь рантайму соптимизировать и выбросить лишнее. Т.е. если я запихну создание объекта в функцию, вместо раскрытого макроса, я получу дополнительный вызов функции, дополнительные рассчеты в рантайме и т.д.
Елисп, к примеру, только в последней версии обзавёлся лексической областью видимости, присущей жабоскрипту изначально, что лично я считаю очень существенным недостатком для диалекта лиспа.
Но да не в этом суть. Я же не к тому это сказал, что там лучше, а тут хуже. Суть в том, что не смотря на то, что языки находятся в одной и той же весвой категории, при прочих равных, никого не смущает наличие в них объектной системы. И тут вдруг в жабоскрипте, оказывается, что объектная система - это плохо (естественно, без объяснений и аргументов, мотивируя только тем, что это, дескать, сложно мартышкам). После чего мартышки с пеной у рта бросаются отстаивать эту ничем не мотивированую позицию как единственно верную.
Насколько я знаю, такими требовательными могут предъявлять джва типа людей: гении, которые, безусловно, свои аргументы в результате подтиерждают достижениями в науке и созиданием своих собственных систем и языков, не имеющих тех недостатков, ну и второйтип: пустословящие. Это либо фанатики других систем, либо глупцы, надеющиеся сыскать уважения или самоутвердиться таким образом. Первого вы пока не доказали. Методом исключения...
Нет связи между "кому-то нравится" и "как правильно". Не нужно быть гением, для того, чтобы взять линейку и померять. Я в этой области ничего не изобрел, материалы, которые я читал, датированы иногда 199Х, иногда начало 200Х. Это информация существующая в свободном доступе. Я в этой области совсем не светило науки, просто прочитал материал и понял. Материал не так чтобы слишком сложный... Просто нужно отличать публицистику, от научной литературы.
Есть абсолютно резонные основания почему большинство ЯП использующихся в промышленности такие, какие они есть. Во многих, если не в подавляющем большинстве случаев, ОО и соответствие теории не играли ключевой роли в выборе и принятии решений (абсолютно оправдано). Есть масса других важных факторов. Точно так же, как многие языки пошли на компромис с математикой, ограничив целочисленные операции количеством регистров процессора. Иногда такие компромисы более оправданы, но иногда это были просто ошибки. Жабоскрипт не то, чтобы на непогрешимость никогда не претендовал, он даже на вменяемость не рассчитывал. Так, дотянуть бы до победного конца, хоть как-то. И это не смотря на очень ограниченный выбор базисных элементов. Но у него никогда не было настоящих конкурентов, поэтому он живет и здравствует и по сей день.
Но тут с какого боку не подступись - ничего хорошего, т.как если бы те объекты, которыми восновном оперирует жабоскрипт действительно реализовывали этот безумный стандарт, все было бы гораздо хуже. Ситуация перешла бы из стадии "обезьяна с бананом" к "обезьяна с гранатой".
Но стретьей стороны, это даже и замечательно, что этот стандарт никогда не будет реализован, и вся публицистика написаная про жабоскрипт так и останется в ранге дружеской шутки.
Вот что печально, так это то, что иногда хочется чего-то серьезного, а показывают только стендап комедии :|
> Первого вы пока не доказали
Ну почему. Вполне доказано другими тредами - фанатическая вера в Common Lisp. Да и в этом треде проскальзывает специализация на нескольких объектах аля мультиметоды, которая, емнип, в рантайме возможна только в CL.
В Дилане, на сколько я понимаю, придумали идею "запечатаных" классов. Т.е. как сделать так, чтобы программист мог сам указывать, предполагается ли динамическая диспечеризация, или нет. Вобщем, и удобно, и полезно... ну, как должно быть :)
Когда проектировался стандарт ЕС4, то там тоже говорили про "запечатаные" классы, даже если почитать Адобовскую документацию того времени, классы именно так и называли (в противопоставление прототипам). Тогда я вообще понятия не имел, о чем речь, но вот было интересно найти первоисточник, и понять, чего именно добивались. Т.е. концептуально, "запечатанные" классы рекламировались как возможнось на этапе компиляции решить, какой из методов вызывать, что существенно улучшило (примерно на порядок) производительность практически любого кода в пробной реализации ЕС4 (Тамарине).
Если вас интересует то, чем я занимаюсь в свободное от работы время. Рабочий проект показать не могу. FPA (Financial Planning Analyst) энтерпрайз система по управлению коммерческим предприятием... очень большая и совсем не интересная (разрабатывается в HP, Mercury).
Mercury - функциональный и статически типизированный логический язык программирования типа Prolog?
Поддерживаю.
В отличие от того же гумна, которое не способно придумать ничего оригинального, тут всегда в наличии свежие (пусть местами абсурдные и совершенно непонятные мне) идеи, но всегда интересно услышать альтернативное мнение.
При чем тут функциональный стиль? Реализация функций? Вы вообще вопрос читали? В контексте объектной системы функция - изначально более примитивная единица, ее реализация находится вне обсуждения этого вопроса, равно как вне обсуждения находятся разрядность процессора, хранение и представление данных на машинном уровне и т.п.
В жабоскрипте нет никакой ситемы. Система предполагает осознанный набор правил и вытекающих из них решений. Реализация системы - это инструменты, которые моделируют объекты, решают проблемы программистского характера связанные с передачей сообщений между объектами и предоставляют интерфейс для наблюдения за происходящим в объектах. Жабоскрипт неимоверно далек от того, что бы иметь такую систему, и он даже не двигается в нужную сторону. ЕС6 попытки чего-то там внедрить - галиматья скопированная из других языков без понимания механизмов побудивших создание этих инструментов в оригинале.
сериализации (JSON) к объектной системе?
именно так описываются объекты, те самые
> массивы, хеш-таблицы
это все объекты, а вот примитивов нет, они все Number. даже typeof null === "object"
> В нем вообще
нет объектов. Объектная система это правила
о том, как создавать объекты и протокол
общения между объектами
создать объект можно даже несколькими способами.
протокол общения стандартен, это функции-члены.
> При чем тут функциональный стиль?
еще один из плюсов языка, что он красиво реализуется.
вообще вы правы, утверждая, что в js все примитивно. да, примитивно - значит, просто и лаконично.
очевидно, js не тот язык, который бы вы хотели. но все же он прост и элегантен.
несмотря на то, что он, как и другие языки, особенно скриптовые, не идеален, но все же он весьма неплох и не заслужил такого какашкометания.
Опять же, не нужно путать понятия "ссылочный тип" и "объект". Объект подразумевает механизмы управления свойствами и механизмы специализации методов на объекте. Но ни того ни другого в жабоскрипте вообще не существует. Это можно построить из имеющихся материалов. Что-то можно, что-то сложнее. Но в самом языке ничего такого нет.
Сорри, вы просто не понимаете о чем говорите :( Я склонен винить в этом Яву, потому что благодаря этому извращению сама идея объектов превратилась в гиммик, а благодаря популярности, этот гиммик перерос в правило, оставив то рациональное, что было в идее объектов не у дел.
Ситуацию с Явой можно описать примерно так: ван Гог был замечательным художником -> кто-то решил, что желтый цвет в его картинах, это самое ценное, что в них есть (он сам писал о том, как долго этого добивался, ради этого он переехал на юг Франции и т.п.) -> кто-то услышал, что ценится только желтый цвет, и решил "улучшить", используя только желтый -> так получилась Ява. Если продолжить аналогию, то жабоскрипт, это следующая стадия ПГМ, когда про ван Гога уже никто и не помнит, а желтый заменили серым, потому, что видели только ч/б репродукции Явы.
поясните, пожалуйста
Специализация - это свойство метода указать (и конкретизировать) типы объектов к которым он применяется. Продолжая пример с булочной: возможны варианты методов, которые специализируются только на одном объекте, например, "закрыть магазин", у которого, возможно, нужна специализация на булочной, если реализация закрытия булочной требует отдельной процедуры, не такой же, как для всех магазинов. Специализация может быть на двух и более объектах, например, "привезти со склада товары", эта операция почти наверняка потребует более детальные специализации для булочной и склада муки, курятника, коровника и т.д.
Т.е. факт того, что одна и та же операция (или тип операции) применима к различным парам, тройкам и т.д. объектов и при этом требует отдельную реализацию как раз выражена через понятие специализации. Когда говорят метод специализируется на объектах А и Б, то имеют в виду, что существует конкретная процедура (возможно, отличная от более общей процедуры) выполняющая действие именно с типам объектов А и Б, но никакими другими.
Не уверен, что оно сильно нужно, не помню, чтобы мне такого не хватало.
совсем омодозрел.
Посоны, а модератор может быть настоящий! По крайней мере он умеет обходить 5-минутный лимит.
Это я тот гвест, что спалил фичу.
p.s. капча 7777
Сообщение "совсем омодозрел." было напечатано с кривым форматированием, вот так: [color=red]совсем омодозрел.[/color]. Потом guest предположил, что лур и модератор это одно лицо, а форматирование сбилось т.к. он пихал текст напрямую в базу. А я написал, что сейчас он придет, и потрет все эти посты, чтобы скрыть тайну.
P.S. Видимо это мой последний пост, т.к. придет модератор и удалит мою учетку.
http://rghost.ru/42099569
Мне та строчка тоже не понравилась - а вчера хотел же схоронить тред на пипе - для потомков.
>Офигеть, я даже не думал что такое будет.
Потому и обленился, только себе засейвил. А модер - то реально настоящий!
> через базу добавлено, не проходя bbcode.php
Логика хромает, в базе именно BBCODE хранится и превращается в Богатый Форматированием Текст при чтении, а не при записи
Пользователи, которые будут продолжать бессмысленное обсуждение ошибки при сохранении комментария в базу - получат бонусный кляп.
Думаю, на этот раз всем очевидно что я не шучу.
Даже не думал о таком варианте развития событий, зачем парсить каждый раз, если можно таки и сохранить этот самый богатый форматированием текст? Разве что для фичи "редактировать пост"?
капча 1234
ШГ, кстати.
А в CL, емнип, есть специализация по конкретным инстансам через eq...
CLOS'овская диспетчеризация мне нравится больше. Компоновка метода из кусков с before/after и сортировка по специфичности удобны и достаточно модульны.
@chorus: та не, он вполне кошерен, если юзать его правильным концом
@wxvxw: пф, учите матчасть, школьники
Ну и не забываем про пример божественного языка, как надо было сделать, в виде CL.
Чет молодцы пригорюнились... уже и пообсуждать нечего.