Пока оно сбоя не давало
Увы у меня прямо противоположный опыт. Если чего не спрячешь — сразу влезут и испортят, даже если есть подробная документация (Кто её читает?)
А исходя из необходимости иметь права доступа в языке не предоставляющем этих возможностей приходится прибегать к кривому методу, обходя стороной правильный подход с прототипами. Я сам за него, но увы не всегда получается. Язык предоставляет одно одеяло. Потянеш в одну сторону — права доступа, но не ООП. Потянеш в другую — ООП, но анархия — мать порядка.
Очень хочется верить, что когда — нибудь введут наконец классы как ActionScript и все будет в шоколаде.
Разделение данных, если они mutable объекты, вообще самоубийственный вариант, а вот с разделением функций согласен, более правильный подход, хотя доступ по цепочке прототипов, говорят, очень тяжелая по времени операция.
По поводу парсинга кода замыканий я читал, что собственно код не парсится повторно, просто данные объектов вызова функций сохраняются и используются как данные замыкания. При этом действительно используется лишняя память, но вот (опять же по слухам) доступ к переменным замыкания быстрее доступа к переменным цепочки прототипов, включая обращение к функциям.
Не всегда. К примеру мне дали задание (собственно из него и родилась идея) протестировать touchScroll плагин к jQuery. Внешняя у него только одна функция, которая подключает к элементу функционал плагина. А внутри добрый десяток сложных и ещё десяток простых функций, которые мне и надо было протестить. В основном тесты писались для тестирования, поскольку плагин сильно дорабатывался.
Пока я не вижу возможности доступа к локальным переменным при необходимости протестировать часть этого кода, например неэкспортируемую функцию.
Кроме того особый доступ в скрытый контекст необходим только, если вам необходимо протестировать что-то вырезанное из этого контекста. Mocking собственно и создает эту искусственную обрезку.
Спасибо, о таком варианте я не подумал. А вот в самой cmd использование return выдает ошибку. В любом случае я использовал свой подход для задания списка переменных и их получения одним вызовом функции. Тогда пустой объект наполняется переменными из списка.
И все же я не очень понимаю в чем реальные преимущества использования декорированных членов перед использованием скрытых переменных? Ну кроме нашего случая. Насколько я понимаю скорость и использование памяти если и отличаются, то незначительно. Что же тогда?
Попробовал ваш код в 3-х браузерах: IE 9, Chrome 10, FF4. Ни один не видит __parent__ и бросает исключение Uncaught TypeError: Cannot read property 'y' of undefined.
Я за и совершенно не спорю, что тест-код должен жить отдельно, только не представляю как. Если бы ваш трюк сработал, я бы с удовольствием переписал бы свою систему под него — это намного чище и правильней.
Использование прав доступа всегда необходимо, если ты работаешь более чем с одним человеком в группе. Бегать и отлавливать зверей из за того, что кто-то влез куда не надо и решил изменить неизменяемое, себе дороже.
Я пришёл к JS с C++/C# и отсутствие контроля доступа полностью выбивает меня из колеи. Поэтому я использую единственный метод «восстановить справедливость» — closure. Я видел это использование во множестве мест и в том числе в известных фреймворках.
По поводу добавления своих методов: Я новичок в Unit Test, но видел разные варианты. В идеале тестируется только открытый API, но на практике часто нужно лезть в кишки. В «правильных» системах компилятором/средой предусмотрен режим для тестов, в котором private становится доступным для определенных програмистом модулей как protected и позволяет субклассирование и переопределение. К сожалению JS этого делать не умеет, или я не знаю способа добиться этого от него. Пришлось придумать костыль.
Увы у меня прямо противоположный опыт. Если чего не спрячешь — сразу влезут и испортят, даже если есть подробная документация (Кто её читает?)
А исходя из необходимости иметь права доступа в языке не предоставляющем этих возможностей приходится прибегать к кривому методу, обходя стороной правильный подход с прототипами. Я сам за него, но увы не всегда получается. Язык предоставляет одно одеяло. Потянеш в одну сторону — права доступа, но не ООП. Потянеш в другую — ООП, но анархия — мать порядка.
Очень хочется верить, что когда — нибудь введут наконец классы как ActionScript и все будет в шоколаде.
По поводу парсинга кода замыканий я читал, что собственно код не парсится повторно, просто данные объектов вызова функций сохраняются и используются как данные замыкания. При этом действительно используется лишняя память, но вот (опять же по слухам) доступ к переменным замыкания быстрее доступа к переменным цепочки прототипов, включая обращение к функциям.
Кроме того особый доступ в скрытый контекст необходим только, если вам необходимо протестировать что-то вырезанное из этого контекста. Mocking собственно и создает эту искусственную обрезку.
cmdиспользованиеreturnвыдает ошибку. В любом случае я использовал свой подход для задания списка переменных и их получения одним вызовом функции. Тогда пустой объект наполняется переменными из списка.И все же я не очень понимаю в чем реальные преимущества использования декорированных членов перед использованием скрытых переменных? Ну кроме нашего случая. Насколько я понимаю скорость и использование памяти если и отличаются, то незначительно. Что же тогда?
Я за и совершенно не спорю, что тест-код должен жить отдельно, только не представляю как. Если бы ваш трюк сработал, я бы с удовольствием переписал бы свою систему под него — это намного чище и правильней.
Использование прав доступа всегда необходимо, если ты работаешь более чем с одним человеком в группе. Бегать и отлавливать зверей из за того, что кто-то влез куда не надо и решил изменить неизменяемое, себе дороже.
По поводу добавления своих методов: Я новичок в Unit Test, но видел разные варианты. В идеале тестируется только открытый API, но на практике часто нужно лезть в кишки. В «правильных» системах компилятором/средой предусмотрен режим для тестов, в котором private становится доступным для определенных програмистом модулей как protected и позволяет субклассирование и переопределение. К сожалению JS этого делать не умеет, или я не знаю способа добиться этого от него. Пришлось придумать костыль.