Народ, смотрю, недоволен регистрацией. Я и сам сомневался, стоит ли регистрироваться: всё-таки потеря времени, стоять, ждать пока пин придёт и т.п.
Вариант, при котором зарегистрировался бы без раздумий: новый пользователь имеет возможность заплатить сразу, любому оператору. В конце платежа, используя паузу когда должен выехать чек, выводится окно: «запомнить реквизиты платежа?» и поле для ввода телефона, если оплата была не про телефон. Потом уже приходит пин.
И ещё: когда оплачиваю вебмани, ввожу сумму, рядом высчитывается сумма с процентами. А мне иногда нужно перевести все деньги. Приходится высчитывать, сколько ввести, чтобы с процентами денег хватило. Хотелось бы иметь кнопку «перевести всё» или дополнительную возможность вводить сумму с процентами.
Значит мы просто изначально друг друга не правильно поняли.
Синглтон, конечно, отчасти фабрика, но для меня он всё-таки конкретный паттерн именно из клооп, потому и заговорил про клооп. Тем более, на фоне общей тенденции имитировать клооп в js.
khim, приведите, пожалуйста, пример, когда при удалении элемента порядок элементов нарушается в массиве, изначально отсортированном по правилам сравнения js.
И ещё, не могли бы Вы привести пример реальной поломки и её результатов из-за особенностей сортировки js, а не абстрактное «взрыв» или «ляжет»?
>Конкретно, пожалуйста, конкретно. Где, в каком месте и почему что-то там является извращением?
Какие проблемы решает настоящий синглтон?
В клооп если я хочу создать 1 объект, чтобы он был виден всем, я делаю его внешним статическим. Тогда я, во-первых, не могу подготовить что-то необходимое ДО его создания, во-вторых, рискую насоздавать несколько объектов. Могу создавать его динамически и передавать по ссылке нуждающимся, тогда я описываю лишние свойства, родитель должен быть обработан до других объектов. Выход — синглтон.
В js если я хочу создать такой объект, я просто создаю обычный объект — тогда, когда он мне нужен. При этом, он сразу виден из любого места, случайно пересоздать его при правильной архитектуре приложения невозможно. Т.е. проблем, решаемых настоящим синглтоном, в js нет.
Извращенем является первый же пример по моей ссылке — человек «решает» несуществующие проблемы.
>А в JS нет никаких синглтонов, но можно называть одиночные объекты «Одиночками».
В том-то и дело, что «в JS нет никаких синглтонов», потому, что эти объекты ничем не отличаются от остальных.
Но это, конечно, не мешает Вам городить сущности и называть вещи так, как привыкли в клооп.
>И кто там кого и куда «за уши тянет»?
Всякие попытки имитировать клооп в js, принесение паттернов из клооп — притягивание того, к чему просто привыкли, в другую среду, потому, что не понимают её и не хотят обучаться. «За уши» — потому, что не нужно, не лезет и выглядит нелепо.
Как правильно, Вы уже сами привели пример:
var obj = {a: 10, b: function () {}, c: 20};
Всё, уникальный объект некоторого «класса» в нужной видимости создан — обращайтесь.
Но это не применение синглтона :)
Применить его подобие может понадобиться в случае habrahabr.ru/blogs/javascript/48542/#comment_1259671, т.к. одна из фич паттерна — отложенное создание объекта, но по этому поводу я своё мнение уже высказал.
Понадобиться «синглтон» в js может только для создания объекта, зависимого от возможно неподгруженных сущностей. Эдак можно вообще все сложные объекты так создавать «для подстраховки». ИМХО, если такая ситуация возникла, скорее всего, нужно пересмотреть архитектуру приложения.
Считаете иначе — приведите пример, если не трудно.
«Прототипы тормозят» — это Вы, батенька, переоптимизировали. Прототипы не являются медленной альтернативой доступа к свойству, а вносят дополнительную, недоступную другими путями, функциональность, на что и тратится время.
Синглтоны же вообще костыли из мира классического ооп, который что-то сильно любят притягивать за уши к JS, где средства-то другие.
И начинает раздеваться.
Снимает рубашку, складывает её по швам, пуговки застегивает и кладет на стул.
Снимает майку, тоже складывает и укладывает рядом с рубашкой.
Ботиночки рядом поставил, носки снял, разгладил и рядом положил.
Брюки по стрелочкам и на спинку стула, трусы снимает, тоже по швам разгладил рядом с майкой положил и говорит:
— Знаете, доктор, вот посмотрите, у меня одно яичко чуть выше другого.
— Ну и что тут такого?
1. Зачем описывать, если поведение уже есть. Надстроить же вполне реально.
2. Корректно говорить, что будет работать медленнее. А вот будет ли тормозить — другой вопрос. Если вы всё проспали, то сообщу: в последнее время идёт прямо таки гонка движков. И неспроста, я замечу.
Пишу js-фреймворк, который является подобием флекса для x(ht)ml + js.
Чтобы немного ввести в курс дела, пейзажи типа такого (упрощённо и бессвязно):
var myAnchor = new DOM.html.A(...);
DOM.html.A.prototype.onclick = ...; // в любое время, а не только перед созданием dom-элементов, как в других фреймворках
DOM.app.Thumbnail= DOM.html.Img.extended(...); // а внутре пишем например так, чтобы запрашивалась отмасштабированная сервером картинка по реальным размерам блока
DOM.app.Div.onBorderWidth = ...; // css транслируется в свойства, т.е. в css можно придумывать собственные свойства, типа shadow:..., и они будут обрабатываться как .setShadow(...); побочный эффект — хаки браузеров легко и непринуждённо
DOM.app.Thumbnail.onRender = ...; // много разных хороших событий
DOM.app.User.onGoodDrop = ...; // и прочих маленьких радостей разработчика
Шаблонизатор клиентский.
Всё само оживает из обычного x(ht)ml, например, при загрузке страницы. Можно и кодом рулить.
Навигация через data binding с проведением через #.
Если js отключен, видна версия для печати/кпк/поисковика (она-то и разворачивается при наличии js).
Понятно, что подход в целом предполагает много реализаций элементов и библиотек и каждый будет норовить придумать лисапед и т.п., но, вообще-то, уже и так есть куча фреймворков и никто не жалуется.
Увлёкся.
Дык вот. Общий подход, как не трудно догадаться, располагает к пути, описанному в статье — свои элементы, полная, рулимая js-ом гибкость поведения и вида, здравствуй тот самый «X». Ан нет, всё упирается, как всегда, в ie. Например, как известно, можно заставить выводить xml в нужном визуале, приложив css. Но при этом ie создаёт свои head и body и всё в них по своему усмотрению раскладывает, хошь иначе — перемещай. Или: если основной неймспейс не html, в ie начинаются глюки с распознаванием префиксов html: элементов (а они нужны — это, как минимум, img, script, style, input). И т.п., все закидоны уже не припомню (хотя давно пора записывать и издавать книгой). Да они все какбе и лечатся, но, вдоволь накувыркавшись, решил поступить проще. На текущий момент страница — обычный html, даже не «Х». Кастомные элементы объявляются в своих неймспейсах, в вёрстке выделяются префиксами (связь — xmlns:app=«DOM.app», соответственно, элемент app:thumbnail это DOM.app.Thumbnail), это успокаивает html-парсер. Всё хml-ные dom-фишки, типа распознавания префиксов, понимание неймспейсов и т.п., тупо эмулируются, — на случай, если вдруг вся система изначально запляшет из xml, для разработчика ничего не меняется. Но вот о теме статьи — полном отрыве от html, пока можно только мечтать.
У меня с nic.ru была ситуация, когда из-за какого-то сбоя последние деньги на счету ушли на продление внеочередных доменов, в итоге два очередных освободились. Оперативно пополнить счёт не было возможности и в результате короткой переписки nic.ru мне эти домены просто подарил — сам оплатил на год.
У вас ситуация сложнее, но спокойствие и только спокойствие, уверен, всё разрулят.
С виду вроде хорошо, а изнутри торчат уши старого осла.
Навскидку, шибко не копаясь: прототипы DOM вроде открыли, а textNode забыт; всё ещё неясная генеалогия некоторых объектов (навроде currentStyle, у которого нельзя перечислить все свойства из-за отсутствия и невозможности назначить hasOwnProperty); перечислить атрибуты элемента всё ещё значительно быстрее регекспом по outerHTML; неймспейсы вроде добавили, а с незнакомыми тегами html-парсер что попало так и делает.
Больше на косметический ремонт по списку фич похоже, чем на капитальный. Потому, на мой взгляд, верить пока рановато.
(Побрюзжал вот.)
Молодцы!
А как вам такое предложение: после стоковых фотографий (например) в поисковиках так и хочется кнопочку «найти похожие». Но её нету. Хотя, чую, что сделать не сложно — ключевые слова-то есть.
А если взывает к представителю, например, греческого пантеона, то не нужно.
Вариант, при котором зарегистрировался бы без раздумий: новый пользователь имеет возможность заплатить сразу, любому оператору. В конце платежа, используя паузу когда должен выехать чек, выводится окно: «запомнить реквизиты платежа?» и поле для ввода телефона, если оплата была не про телефон. Потом уже приходит пин.
И ещё: когда оплачиваю вебмани, ввожу сумму, рядом высчитывается сумма с процентами. А мне иногда нужно перевести все деньги. Приходится высчитывать, сколько ввести, чтобы с процентами денег хватило. Хотелось бы иметь кнопку «перевести всё» или дополнительную возможность вводить сумму с процентами.
{
test.arguments[0] = 'world!';
}
function test©
{
alert©;
surprise();
alert©;
}
test('hi');
Синглтон, конечно, отчасти фабрика, но для меня он всё-таки конкретный паттерн именно из клооп, потому и заговорил про клооп. Тем более, на фоне общей тенденции имитировать клооп в js.
И ещё, не могли бы Вы привести пример реальной поломки и её результатов из-за особенностей сортировки js, а не абстрактное «взрыв» или «ляжет»?
Какие проблемы решает настоящий синглтон?
В клооп если я хочу создать 1 объект, чтобы он был виден всем, я делаю его внешним статическим. Тогда я, во-первых, не могу подготовить что-то необходимое ДО его создания, во-вторых, рискую насоздавать несколько объектов. Могу создавать его динамически и передавать по ссылке нуждающимся, тогда я описываю лишние свойства, родитель должен быть обработан до других объектов. Выход — синглтон.
В js если я хочу создать такой объект, я просто создаю обычный объект — тогда, когда он мне нужен. При этом, он сразу виден из любого места, случайно пересоздать его при правильной архитектуре приложения невозможно. Т.е. проблем, решаемых настоящим синглтоном, в js нет.
Извращенем является первый же пример по моей ссылке — человек «решает» несуществующие проблемы.
>А в JS нет никаких синглтонов, но можно называть одиночные объекты «Одиночками».
В том-то и дело, что «в JS нет никаких синглтонов», потому, что эти объекты ничем не отличаются от остальных.
Но это, конечно, не мешает Вам городить сущности и называть вещи так, как привыкли в клооп.
>И кто там кого и куда «за уши тянет»?
Всякие попытки имитировать клооп в js, принесение паттернов из клооп — притягивание того, к чему просто привыкли, в другую среду, потому, что не понимают её и не хотят обучаться. «За уши» — потому, что не нужно, не лезет и выглядит нелепо.
www.rsdn.ru/article/patterns/singleton.xml
«Применение cинглтона в js»: www.google.ru/search?q=javascript+singleton&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ru:official&client=firefox-a
и другие подобные извращения — притягивание за уши клооп к js.
Как правильно, Вы уже сами привели пример:
var obj = {a: 10, b: function () {}, c: 20};
Всё, уникальный объект некоторого «класса» в нужной видимости создан — обращайтесь.
Но это не применение синглтона :)
Применить его подобие может понадобиться в случае habrahabr.ru/blogs/javascript/48542/#comment_1259671, т.к. одна из фич паттерна — отложенное создание объекта, но по этому поводу я своё мнение уже высказал.
это не синглтон в понимании клооп.
Отсюда и непонимание про костыли и уши.
Считаете иначе — приведите пример, если не трудно.
Синглтоны же вообще костыли из мира классического ооп, который что-то сильно любят притягивать за уши к JS, где средства-то другие.
— Здравствуйте, — говорит.
И начинает раздеваться.
Снимает рубашку, складывает её по швам, пуговки застегивает и кладет на стул.
Снимает майку, тоже складывает и укладывает рядом с рубашкой.
Ботиночки рядом поставил, носки снял, разгладил и рядом положил.
Брюки по стрелочкам и на спинку стула, трусы снимает, тоже по швам разгладил рядом с майкой положил и говорит:
— Знаете, доктор, вот посмотрите, у меня одно яичко чуть выше другого.
— Ну и что тут такого?
— Как что? Неаккуратненько как-то.
Вот, например, prototype.js — тоже «улучшитель-расширитель», а смотри-ка — все пользуются.
2. Корректно говорить, что будет работать медленнее. А вот будет ли тормозить — другой вопрос. Если вы всё проспали, то сообщу: в последнее время идёт прямо таки гонка движков. И неспроста, я замечу.
Чтобы немного ввести в курс дела, пейзажи типа такого (упрощённо и бессвязно):
var myAnchor = new DOM.html.A(...);
DOM.html.A.prototype.onclick = ...; // в любое время, а не только перед созданием dom-элементов, как в других фреймворках
DOM.app.Thumbnail= DOM.html.Img.extended(...); // а внутре пишем например так, чтобы запрашивалась отмасштабированная сервером картинка по реальным размерам блока
DOM.app.Div.onBorderWidth = ...; // css транслируется в свойства, т.е. в css можно придумывать собственные свойства, типа shadow:..., и они будут обрабатываться как .setShadow(...); побочный эффект — хаки браузеров легко и непринуждённо
DOM.app.Thumbnail.onRender = ...; // много разных хороших событий
DOM.app.User.onGoodDrop = ...; // и прочих маленьких радостей разработчика
Шаблонизатор клиентский.
Всё само оживает из обычного x(ht)ml, например, при загрузке страницы. Можно и кодом рулить.
Навигация через data binding с проведением через #.
Если js отключен, видна версия для печати/кпк/поисковика (она-то и разворачивается при наличии js).
Понятно, что подход в целом предполагает много реализаций элементов и библиотек и каждый будет норовить придумать лисапед и т.п., но, вообще-то, уже и так есть куча фреймворков и никто не жалуется.
Увлёкся.
Дык вот. Общий подход, как не трудно догадаться, располагает к пути, описанному в статье — свои элементы, полная, рулимая js-ом гибкость поведения и вида, здравствуй тот самый «X». Ан нет, всё упирается, как всегда, в ie. Например, как известно, можно заставить выводить xml в нужном визуале, приложив css. Но при этом ie создаёт свои head и body и всё в них по своему усмотрению раскладывает, хошь иначе — перемещай. Или: если основной неймспейс не html, в ie начинаются глюки с распознаванием префиксов html: элементов (а они нужны — это, как минимум, img, script, style, input). И т.п., все закидоны уже не припомню (хотя давно пора записывать и издавать книгой). Да они все какбе и лечатся, но, вдоволь накувыркавшись, решил поступить проще. На текущий момент страница — обычный html, даже не «Х». Кастомные элементы объявляются в своих неймспейсах, в вёрстке выделяются префиксами (связь — xmlns:app=«DOM.app», соответственно, элемент app:thumbnail это DOM.app.Thumbnail), это успокаивает html-парсер. Всё хml-ные dom-фишки, типа распознавания префиксов, понимание неймспейсов и т.п., тупо эмулируются, — на случай, если вдруг вся система изначально запляшет из xml, для разработчика ничего не меняется. Но вот о теме статьи — полном отрыве от html, пока можно только мечтать.
У вас ситуация сложнее, но спокойствие и только спокойствие, уверен, всё разрулят.
Навскидку, шибко не копаясь: прототипы DOM вроде открыли, а textNode забыт; всё ещё неясная генеалогия некоторых объектов (навроде currentStyle, у которого нельзя перечислить все свойства из-за отсутствия и невозможности назначить hasOwnProperty); перечислить атрибуты элемента всё ещё значительно быстрее регекспом по outerHTML; неймспейсы вроде добавили, а с незнакомыми тегами html-парсер что попало так и делает.
Больше на косметический ремонт по списку фич похоже, чем на капитальный. Потому, на мой взгляд, верить пока рановато.
(Побрюзжал вот.)
А как вам такое предложение: после стоковых фотографий (например) в поисковиках так и хочется кнопочку «найти похожие». Но её нету. Хотя, чую, что сделать не сложно — ключевые слова-то есть.