unsupported features
 

Не секрет, что jQuery изначально нацелен на упрощение работы с DOM.
Но некоторые его методы из утилит, могут применяться и для обычных объектов.
Например, можно создать jQuery-объект из любого объекта, а не только из куску DOM, а потом повесить на него обработчик события, в после вызвать само событие.
Если копнуть чуть глубже, то обработчики событий для обоих типов объектов сохраняются через jQuery-вский механизм кэша - $.data, который можно применять для обоих типов объектов - только храниться будем чуточку по-разному.
И метод jQuery.unique может принимать как массивы DOM-элементов, так и просто массивы чего угодно.

Пока вроде все классно, но дальше начинается самое интересное.
Все эти утилиты(из ядра заметьте) на самом деле официально не поддерживаются.

Метод jQuery.unique хотя по факту работает с любыми массивами любых объектов, но официально работает только с массивами DOM-объектов.
Баги при работе с любыми другими типами объектов заворачиваются по wontfix, хотя ошибка более чем очевидна, и легко исправляется

Методы из серии $.data могут работать с любыми объектами(и таки даже в коде расписана соответствующая логика.
Но кейсы опять-таки заворачиваются, несмотря на опять-таки копеечный фикс.

Что вы думаете по этому поводу?

По-моему странно сделать функциональность на 99% для "нецелевой" платформы, а потом не развивать ее, дескать она unsopported

Gvozd,
Может быть послать им pull request, если вы знаете о чём там речь? Ссылки предоставленные пока не смотрел, но я так полагаю там просто баг репорты, а не патчи.

нет ничего странного - её развивает большое кол-во человек.

Видимо так и сделаю, но чуть позже.
Одна ссылка на мой последний репорт, и он таки без патча.
Вторая ссылка на документацию о jQuery.unique, где четко говорится что он "не предназначен" для работы с любыми не-DOM массивами
Кейс по нему я писал, и весьма подробно, но к сожалению анонимно, и теперь не могу его найти(возможно что его и удалили, а может просто не повезло с поиском). Зато все другие кейсы про работу не с DOM-массивами заворачивались именно по wontfix

То есть проблема в разногласиях внутри группы разработчиков?
В принципе я рассматривал это как возможную причину

Gvozd,
Очень часто во всевозможных проектах на гитхабе заворачивают патчи только потому, что кто слышал, что где то может не работать. Был у меня такой случай. Потом через эН времени, когда кто то другой послал такой же патч, его приняли.

Nekromancer,
Ок, буду иметь в виду.
На следующей неделе пошлю пул-реквесты
Если их отклонят, оформлю код тут, чтобы кто-то другой заинтересованный также мог послать реквест

Сегодня предложил им пул-реквест ( https://github.com/jquery/jquery/pull/1001/files)
Отклонили все по той же причине, плюс придрались к стилю кода.
Учитывая что в самом коде исправлены всего две строки, и там я постарался придержаться стиля подсмотренного в окружающем коде, то скорее всего проблема в стиле кода в тестах.

Nekromancer,
Вот только сейчас посмотрел тот тикет. Раз они такие принципиальные, сделай йорк с их проекта, там делай нужные фикс ы и потом распространяй/ используй его. Кстати, а зачем добавлять этот кеш в prototype?

Распространять особого смысла не вижу, ибо случай довольно специфичный.
Для собственного использования проще в поддержании выглядит фикс через оборачивание извне нужных методов - фикс навсегда, без необходимости пересборки, и для его работы не нужен человек умеющий пересобирать jQuery. Но это тема отдельного обсуждения внутри команды.
Есть набор объектов, некоторые свойства которых реализованы в виде гетеров/сетеров, а реальные значения хранятся в $.data объекта.
Это поведение свойств объектов задается в их конструкторе, а в их гетерах/сетерах содержится дополнительная внешняя логика.

Так вот если использовать объект с гетером/сетером в качестве прототипа для других объектов, то в них this будет указывать на конечный объект, а не на прототип, и это нормально.
А если использовать $.data(this), то в случае наличия у прототипа своего кэша, и отсутствия у целевого объекта, то кэщ возьмется от прототипа и будет общим.

Пол беды, что не удается использовать jQuery-вский кэш, ведь нетрудно создать свой, хотя и хотелось бы использовать существующий лаконичный интерфейс.
Но вторая половина беды начинается, когда на эти объекты надо навешивать обработчики событий(мне надо), ведь обработчики также хранятся в $.data.

Изобретать отдельную библиотеку для механизма событий у таких объектов , или копипастить jQuery-вскую, не кажется хорошей идеей

Gvozd,
У меня примерно такая же ситуация. Только я решил по другому. Я в конструкторах создал свойство (из других языков это будет static), например properties. Это объект, внём хранится описание всех этих геттеров/сеттеров. При наследовании они перетаскиваются на унаследованный конструктор через extend.

Далее, у кажого объекта почившегося из конструктор есть всегда прикриплённый как минимум один DOM элемент. По этому кеш от всех даных хранится в кеше для DOM объекта. Ну и события тоже, прямо на элемент вешаю.