Comments 14
1. чем не устроил вариант base2 и другие велосипеды?
2. колько стоит в твоей реализации делегирование? covex-nn.ya.ru/replies.xml?parent_id=1745&item_no=1698&with_parent=1#reply-covex-nn-1745 — тут base, prototype и resig показали себя не слишком хорошо
3. на тему пропертей: groups.google.com/group/jfix-javascript-framework/browse_thread/thread/2def43a808fbc9e0
2. колько стоит в твоей реализации делегирование? covex-nn.ya.ru/replies.xml?parent_id=1745&item_no=1698&with_parent=1#reply-covex-nn-1745 — тут base, prototype и resig показали себя не слишком хорошо
3. на тему пропертей: groups.google.com/group/jfix-javascript-framework/browse_thread/thread/2def43a808fbc9e0
1. base2 делает очень много, мой взгляд, лишних телодвижений. Велосипед Резига откровенно не доделан. В свой велосипед я собрал минимум того, что мне нужно.
2. Если тебе правда интересны такие тесты, я попозже измерю. Но: ты же не меряешь, например, скорость $.each и while, хотя и ежу понятно, что первый медленнее второго. А если у твоей системы основное время работы составляет создание объектов, может тебе стоит посмотреть на техники, позволяющие уменьшить количество объектов?
3. По поводу пропертей, в вышеприведенном примере property и getProperty — это просто чтобы показать как работает наследование и перекрытие, а не чтобы продемонстрировать какую-то технику работы с проперти. Если тебя смущает getProperty() — замени его на doFoo().
В последнее время слышу очень много разговоров по поводу наследование vs агрегирование/делегирование. Для меня это не взаимоисключающие парадигмы, а взаимодополняющие, каждая из которых применяется там, где она лучше подходит.
2. Если тебе правда интересны такие тесты, я попозже измерю. Но: ты же не меряешь, например, скорость $.each и while, хотя и ежу понятно, что первый медленнее второго. А если у твоей системы основное время работы составляет создание объектов, может тебе стоит посмотреть на техники, позволяющие уменьшить количество объектов?
3. По поводу пропертей, в вышеприведенном примере property и getProperty — это просто чтобы показать как работает наследование и перекрытие, а не чтобы продемонстрировать какую-то технику работы с проперти. Если тебя смущает getProperty() — замени его на doFoo().
В последнее время слышу очень много разговоров по поводу наследование vs агрегирование/делегирование. Для меня это не взаимоисключающие парадигмы, а взаимодополняющие, каждая из которых применяется там, где она лучше подходит.
1. так что же тебе нужно?
2. там проблема не в создании объектов, а в том, что каждый вызов метода становится дорогой операцией
2. там проблема не в создании объектов, а в том, что каждый вызов метода становится дорогой операцией
1. мне нужен минимум инструментов, позволяющий работать с наследованием
Померял твоей «пиписькомеркой»:

То, что измеряется в этих тестах, слишком далеко от реальной жизни. Как только методы начнут не просто делегировать вызовы своему предку, а выполнять еще какие-то действия (ведь именно за этим они перекрывают базовые методы), то тут же этот разрыв начнет резко падать. А так это средняя температура по больнице. Плюс еще тесты некорректны — очень сильно скачет разброс результатов от запуска к запуску.
Померял твоей «пиписькомеркой»:

То, что измеряется в этих тестах, слишком далеко от реальной жизни. Как только методы начнут не просто делегировать вызовы своему предку, а выполнять еще какие-то действия (ведь именно за этим они перекрывают базовые методы), то тут же этот разрыв начнет резко падать. А так это средняя температура по больнице. Плюс еще тесты некорректны — очень сильно скачет разброс результатов от запуска к запуску.
А при чём здесь jQuery? А обёртка для связки прототипов, задания базового конструктора и прочий дополнительных полезных слотов занимает 4-15 строк.
Если на проекте в качестве основного фреймворка используется jQuery, то и все остальное, расширяющееся базовый функционал, я предпочитаю оформлять в jQuery-style. Вас же не смущает, что в jQuery есть $.extend или $.makeArray?
А можно увидеть ваши 4-15 строк, делающий все перечисленное в статье?
А можно увидеть ваши 4-15 строк, делающий все перечисленное в статье?
> А можно увидеть ваши 4-15 строк, делающий все перечисленное в статье?
Самый простой и классический пример (паттерн).
Естественно, можно оформить в нужном виде (например, свойством функции или ещё как), но внутренности — есть одна из реализаций, того, что Вам нужно. Можно наследоваться, вызвать одноименные методы и базового конструктора. То, что у Вас названо статическими свойстами — можно так же положить в прототип, или сделать свойствами коструктора.
Самый простой и классический пример (паттерн).
function inheritePrototype(child, _super) { var __inheritance = function () {}; __inheritance.prototype = _super.prototype; child._super = _super; child.prototype = new __inheritance(); child.prototype.constructor = child; } // пример function A() { this.state = 10; } A.prototype.test = function () { alert('A.test'); }; function B() { B._super.apply(this, arguments); } inheritePrototype(B, A); B.prototype.test = function () { B._super.prototype.test.apply(this, arguments); alert('B.test'); }; var b = new B(); b.test(); alert(b.state);
Естественно, можно оформить в нужном виде (например, свойством функции или ещё как), но внутренности — есть одна из реализаций, того, что Вам нужно. Можно наследоваться, вызвать одноименные методы и базового конструктора. То, что у Вас названо статическими свойстами — можно так же положить в прототип, или сделать свойствами коструктора.
да, похожий кусок есть и в моем коде, только этого недостаточно:
—
— конструктор разнесен с методами, это тоже неудобно и некрасиво
— как вы сами заметили, нет статики
Собственно мой код и крутится вокруг того, чтобы обеспечить некий syntax sugar. Что конкретно вы считаете в нем лишним?
—
B._super.prototype.test.apply(this, arguments);
— некрасиво и неудобно, я сам когда-то так делал. Гораздо удобнее писать this.__base()
для всех методов, а не думать постоянно о том, кто базовый класс и писать эту длинную однообразную простыню.— конструктор разнесен с методами, это тоже неудобно и некрасиво
— как вы сами заметили, нет статики
Собственно мой код и крутится вокруг того, чтобы обеспечить некий syntax sugar. Что конкретно вы считаете в нем лишним?
> B._super.prototype.test.apply(this, arguments); — некрасиво и неудобно… Гораздо удобнее писать this.__base()
да естественно, я лишь пример привел, можно хоть как подогнать под свои нужды, под синтаксис, который кажется удобным
> конструктор разнесен с методами, это тоже неудобно и некрасиво
да это мелочи всё, дописывается ещё «2-3» строками
> как вы сами заметили, нет статики
А что Вы подразумеваете под статикой?
> Собственно мой код и крутится вокруг того, чтобы обеспечить некий syntax sugar.
А я ничего против и не имею. Каждый создаёт свои обёртки, которые наиболее удобны для него. Наследование же в JS и так изначально есть, поэтому любая обёртка — есть обёртка, и является лишь синтаксическим сахаром, определяющим относительное удобство.
> Что конкретно вы считаете в нем лишним?
Да нет, лишним в подобных обёртках мало, что может быть, поскольку они относительные, и пишутся для удобства, увиденное через призму конкретных людей. Под «лишним» я больше имел в виду привязку к jQuery, но Вы уже ответили, зачем он тут.
да естественно, я лишь пример привел, можно хоть как подогнать под свои нужды, под синтаксис, который кажется удобным
> конструктор разнесен с методами, это тоже неудобно и некрасиво
да это мелочи всё, дописывается ещё «2-3» строками
> как вы сами заметили, нет статики
А что Вы подразумеваете под статикой?
> Собственно мой код и крутится вокруг того, чтобы обеспечить некий syntax sugar.
А я ничего против и не имею. Каждый создаёт свои обёртки, которые наиболее удобны для него. Наследование же в JS и так изначально есть, поэтому любая обёртка — есть обёртка, и является лишь синтаксическим сахаром, определяющим относительное удобство.
> Что конкретно вы считаете в нем лишним?
Да нет, лишним в подобных обёртках мало, что может быть, поскольку они относительные, и пишутся для удобства, увиденное через призму конкретных людей. Под «лишним» я больше имел в виду привязку к jQuery, но Вы уже ответили, зачем он тут.
> да это мелочи всё, дописывается ещё «2-3» строками
Да это понятно, что мелочи — просто из кучки таких мелочей в итоге и вырастает чуть побольше
> А что Вы подразумеваете под статикой?
Конкретно тут я имею ввиду свойства типа, а не его экземпляра. Тоже мелочь, а приятно :)
Да это понятно, что мелочи — просто из кучки таких мелочей в итоге и вырастает чуть побольше
> А что Вы подразумеваете под статикой?
Конкретно тут я имею ввиду свойства типа, а не его экземпляра. Тоже мелочь, а приятно :)
Привет, спасибо за решение.
Подскажи, как ты работаешь с данным примером.
Опять этот scope…
Подскажи, как ты работаешь с данным примером.
Опять этот scope…
var Test = $.inherit(
{
__constructor: function() {
$('body').on('click', 'a', this.onLinkClick);
// or
// var self = this;
// $('body').on('click', 'a', $.proxy(this.onLinkClick, this));
},
onLinkClick: function() {
? доступ к this Test
? доступ к this 'a'
return false;
}
});
Sign up to leave a comment.
Плагин для jQuery, реализующий наследование