Я имел ввиду, что если посадить человека, не сталкивавшегося ранее с подобной задачей, за ваш интерфейс — то, каким бы он не был удобным, человеку он не будет интуитивно понятным. Только в процессе познания/сравнения с другими интерфейсами можно будет судить о его понятности.
Потому что это слово очень часто стало использоваться просто «чтобы было» — буквальное в каждом ТЗ и брифе. Причем когда спрашиваешь у авторов, что это значит в их понимании — практически никто не может толком ответить.
«Интуитивно понятно» человеку только как дышать, все остальное — применение ранее приобретенных навыков. Сам по себе интерфейс не может быть интуитивно понятным.
Я понимаю что блоки могут быть сворачиваемыми, только для этого необязательно чтобы у блока был id. И уж, тем более, не нужно завязывать на эти такие id верстку.
да, похожий кусок есть и в моем коде, только этого недостаточно:
— B._super.prototype.test.apply(this, arguments); — некрасиво и неудобно, я сам когда-то так делал. Гораздо удобнее писать this.__base() для всех методов, а не думать постоянно о том, кто базовый класс и писать эту длинную однообразную простыню.
— конструктор разнесен с методами, это тоже неудобно и некрасиво
— как вы сами заметили, нет статики
Собственно мой код и крутится вокруг того, чтобы обеспечить некий syntax sugar. Что конкретно вы считаете в нем лишним?
Если на проекте в качестве основного фреймворка используется jQuery, то и все остальное, расширяющееся базовый функционал, я предпочитаю оформлять в jQuery-style. Вас же не смущает, что в jQuery есть $.extend или $.makeArray?
А можно увидеть ваши 4-15 строк, делающий все перечисленное в статье?
1. мне нужен минимум инструментов, позволяющий работать с наследованием
Померял твоей «пиписькомеркой»:
То, что измеряется в этих тестах, слишком далеко от реальной жизни. Как только методы начнут не просто делегировать вызовы своему предку, а выполнять еще какие-то действия (ведь именно за этим они перекрывают базовые методы), то тут же этот разрыв начнет резко падать. А так это средняя температура по больнице. Плюс еще тесты некорректны — очень сильно скачет разброс результатов от запуска к запуску.
1. base2 делает очень много, мой взгляд, лишних телодвижений. Велосипед Резига откровенно не доделан. В свой велосипед я собрал минимум того, что мне нужно.
2. Если тебе правда интересны такие тесты, я попозже измерю. Но: ты же не меряешь, например, скорость $.each и while, хотя и ежу понятно, что первый медленнее второго. А если у твоей системы основное время работы составляет создание объектов, может тебе стоит посмотреть на техники, позволяющие уменьшить количество объектов?
3. По поводу пропертей, в вышеприведенном примере property и getProperty — это просто чтобы показать как работает наследование и перекрытие, а не чтобы продемонстрировать какую-то технику работы с проперти. Если тебя смущает getProperty() — замени его на doFoo().
В последнее время слышу очень много разговоров по поводу наследование vs агрегирование/делегирование. Для меня это не взаимоисключающие парадигмы, а взаимодополняющие, каждая из которых применяется там, где она лучше подходит.
Это не функция плохая — это разработчики плохие, раз не могут сделать так, чтобы кнопка всегда находилась в адекватном состоянии, в том числе, и после нажатия кнопки «назад».
Чтобы обойтись без document.write можно просто назначить с помощью javascript класс (например, .with-js) на элемент html и в дальнейшем уже писать стили с селекторами, опирающиеся на него (например, .with-js .script или .with-js .noscript)
<div class="block block-opened">Да это понятно, что мелочи — просто из кучки таких мелочей в итоге и вырастает чуть побольше
> А что Вы подразумеваете под статикой?
Конкретно тут я имею ввиду свойства типа, а не его экземпляра. Тоже мелочь, а приятно :)
—
B._super.prototype.test.apply(this, arguments);— некрасиво и неудобно, я сам когда-то так делал. Гораздо удобнее писатьthis.__base()для всех методов, а не думать постоянно о том, кто базовый класс и писать эту длинную однообразную простыню.— конструктор разнесен с методами, это тоже неудобно и некрасиво
— как вы сами заметили, нет статики
Собственно мой код и крутится вокруг того, чтобы обеспечить некий syntax sugar. Что конкретно вы считаете в нем лишним?
А можно увидеть ваши 4-15 строк, делающий все перечисленное в статье?
Померял твоей «пиписькомеркой»:
То, что измеряется в этих тестах, слишком далеко от реальной жизни. Как только методы начнут не просто делегировать вызовы своему предку, а выполнять еще какие-то действия (ведь именно за этим они перекрывают базовые методы), то тут же этот разрыв начнет резко падать. А так это средняя температура по больнице. Плюс еще тесты некорректны — очень сильно скачет разброс результатов от запуска к запуску.
2. Если тебе правда интересны такие тесты, я попозже измерю. Но: ты же не меряешь, например, скорость $.each и while, хотя и ежу понятно, что первый медленнее второго. А если у твоей системы основное время работы составляет создание объектов, может тебе стоит посмотреть на техники, позволяющие уменьшить количество объектов?
3. По поводу пропертей, в вышеприведенном примере property и getProperty — это просто чтобы показать как работает наследование и перекрытие, а не чтобы продемонстрировать какую-то технику работы с проперти. Если тебя смущает getProperty() — замени его на doFoo().
В последнее время слышу очень много разговоров по поводу наследование vs агрегирование/делегирование. Для меня это не взаимоисключающие парадигмы, а взаимодополняющие, каждая из которых применяется там, где она лучше подходит.
document.writeможно просто назначить с помощью javascript класс (например,.with-js) на элемент html и в дальнейшем уже писать стили с селекторами, опирающиеся на него (например,.with-js .scriptили.with-js .noscript)