Для прототипа wrapper можно создать, таким образом, и «холостые выстрелы» исчезнут. Прототип wrapper'a будет указывать на прототип родительского конструктора.
function A() { alerr('A'); }
A.prototype.fn = function () {};
function B() {
B.parent.apply(this, arguments);
alert('B');
}
// связка прототипов для делегирования
var __wrapper = function() {};
__wrapper.prototype = A.prototype;
B.prototype = new __wripper();
B.prototype.constructor = B;
B.parent = A;
var obj = new B(); // alert('A'), alert('B')
В то время, как, если бы не было wrapper'a — alert('A') «выстрелил бы в холостую» когда создавалась цепь наследования.
Да, просто термин «каскадирование» уже использован для описания прототипирования (http://ru.wikipedia.org/wiki/Прототипно_программирование). В принципе, частный случай в JS есть — когда свойства создаются прямо в объекте, либо, когда объекты создаются через «фабрику». А частный — потому что цепь прототипов все-таки присутствует.
> А чем она нестандартная, если для нее нужны лишь родные средства языка…?
Нестандартная, имеется в виду, что такая сущность конкретно не выделяется в JavaScript. Однако, «примесь» — это более общее теоретическое понятие, и, в принципе, может быть реализовано в JavaScript.
Главное, что понимать под ней и как будет выглядеть реализация. В Ruby, например, подмешивание не создает родные слоты в объекте — там создается хидден-класс, который вклинивается на первое место в цепи классов (т.е. свойство не найдется в самом объекте, затем будет искаться в подмешенном хидден-классе, затем в классе объекта, затем в родителе класса объекта и т.д.). Т.е. снова — делегация, а не каскадирование. С другой стороны, «примесь» можно рассматривать как расширение самого объекта, создавая родные слоты. В принципе, оба подхода можно реализовать в JS. Просто более точным было бы — «стандарт не описывает понятия примесь, но, этот теоретический механизм вполне реализуем в JS» (это не цепляние к словам, просто уточнение :)).
> Таким образом реализуется иерархия прототипов, или каскадное наследование.
Делегирующее. Каскадное — это, когда точная копия создается от прототипа, и новые объекты имеют свои собственные свойства (при этом прототип уже не нужен). Поэтому, в JS — делегирующее прототипное наследование.
> Примеси
Используя эту терминологию, лучше уточнить, что она не «стандартная» для JavaScript.
в Smalltalk — одна из реализаций объектной системы; любая иная реализация вправе вносить свои изменения, если они технически и идеологически обоснованы и отвечают тербованиями поставленых задач.
да и, у кого возникнет ощущение, что я отстаиваю PHP, оносительно других языков (Python, Ruby), скажу, что в настоящий момент уже давно не пишу на PHP, а занимаюсь только JavaScript'ом (и вместе с тем, Python и Ruby (их я практикую для себя, в свободное от работы время) мне нравятся больше, чем PHP); поэтому — я не отстаиваю PHP и его идеологию, мне просто интересна тенденция цепной реакции и холиворов на этой почве.
насчет того, что в PHP до сих пор (!) (или пока?) нет стандарта на имена built-in-функций/объктов — это да, плохо (как плохо и то, что язык не чувствителен к регистру)
насчет того, что функция может «портить» аргумент, работая с ним по ссылке и никак этот факт визуально не определить — тоже плохо (например, можно было бы помечать такие имена функций знаком восклицания в конце — obj.sort!), но с другой стороны — можно посмотреть всегда документацию и уточнить такие моменты (поскольку все случаи невозможно предусмотреть и где-то нужно, чтобы функция преобразовывала объект-параметр)
насчет неинтуитивных возвращаемых значений ('', 0, false) — да, тоже бы неплохо иметь хоть какой-нибудь конвеншн, но и в других языках, я не уверен, что с этим моментом все четко
по поводу, что такое ООП-язык и что такое не-ООП-язык — пожалуйста, все, кто утверждает об принадлежности или непринадлежности языка к ООП — придите сюда и четко изложите свои мысли и доводы, что такое настоящий ООП язык, откуда вы эти рамки взяли и с чего, вообще, взяли, что предложенное вами определение будет верным в последней инстанции? Можно будет взять различные фундаментальные труды и их определния, соотнести, что схоже, что нет (что должно быть обязательно, что — не обязательно, и почему) и т.д. Это будет конструктивней и инстересней, нежели твердеть с деловым видом об «убожестве» чье-то, довольно мощной, разработки.
А устраивать какие-то сомнительные холиворы (не являясь при этом создатилями ни PHP, ни Ruby) — вообще какая-то ерунда.
> Те кто думает что CakePHP — это «как RoR» сильно заблуждаются.
А причем здесь какие-то Рельсы и какой-то там КейкПХП?
Вы дали четкое определение «убого» относительно ПХП: «убого» это когда называют «магией ООП» засовывание кучи функций во враппер-класс. Вот мне и интересно — где «не убого»? Определенно же — Вы должны знать ответ на этот вопрос, раз так категорично определяете «убогость» PHP. Или я ошибся?
> Для примера можете взглянуть на реализацию коллекций ассоциаций
> не корректно сравнивать скорости поиска в [] и в {}
[] быстрее {} — если сравнивать сравниваемое (либо обращение по ключу, либо поиск значения). Если как здесь — поиск значения, когда ключ не известен и проверка наличия ключа (если это хэш — то вычисление хэша и получения индекса) — тогда — конечно (но сравниваются две абсолютно разные вещи).
function A() { alerr('A'); } A.prototype.fn = function () {}; function B() { B.parent.apply(this, arguments); alert('B'); } // связка прототипов для делегирования var __wrapper = function() {}; __wrapper.prototype = A.prototype; B.prototype = new __wripper(); B.prototype.constructor = B; B.parent = A; var obj = new B(); // alert('A'), alert('B')В то время, как, если бы не было wrapper'a — alert('A') «выстрелил бы в холостую» когда создавалась цепь наследования.
Да, просто термин «каскадирование» уже использован для описания прототипирования (http://ru.wikipedia.org/wiki/Прототипно_программирование). В принципе, частный случай в JS есть — когда свойства создаются прямо в объекте, либо, когда объекты создаются через «фабрику». А частный — потому что цепь прототипов все-таки присутствует.
> А чем она нестандартная, если для нее нужны лишь родные средства языка…?
Нестандартная, имеется в виду, что такая сущность конкретно не выделяется в JavaScript. Однако, «примесь» — это более общее теоретическое понятие, и, в принципе, может быть реализовано в JavaScript.
Главное, что понимать под ней и как будет выглядеть реализация. В Ruby, например, подмешивание не создает родные слоты в объекте — там создается хидден-класс, который вклинивается на первое место в цепи классов (т.е. свойство не найдется в самом объекте, затем будет искаться в подмешенном хидден-классе, затем в классе объекта, затем в родителе класса объекта и т.д.). Т.е. снова — делегация, а не каскадирование. С другой стороны, «примесь» можно рассматривать как расширение самого объекта, создавая родные слоты. В принципе, оба подхода можно реализовать в JS. Просто более точным было бы — «стандарт не описывает понятия примесь, но, этот теоретический механизм вполне реализуем в JS» (это не цепляние к словам, просто уточнение :)).
Делегирующее. Каскадное — это, когда точная копия создается от прототипа, и новые объекты имеют свои собственные свойства (при этом прототип уже не нужен). Поэтому, в JS — делегирующее прототипное наследование.
> Примеси
Используя эту терминологию, лучше уточнить, что она не «стандартная» для JavaScript.
в Smalltalk — одна из реализаций объектной системы; любая иная реализация вправе вносить свои изменения, если они технически и идеологически обоснованы и отвечают тербованиями поставленых задач.
— чье-то => чьей-то*
— создатилями => создателями*
насчет того, что функция может «портить» аргумент, работая с ним по ссылке и никак этот факт визуально не определить — тоже плохо (например, можно было бы помечать такие имена функций знаком восклицания в конце — obj.sort!), но с другой стороны — можно посмотреть всегда документацию и уточнить такие моменты (поскольку все случаи невозможно предусмотреть и где-то нужно, чтобы функция преобразовывала объект-параметр)
насчет неинтуитивных возвращаемых значений ('', 0, false) — да, тоже бы неплохо иметь хоть какой-нибудь конвеншн, но и в других языках, я не уверен, что с этим моментом все четко
по поводу, что такое ООП-язык и что такое не-ООП-язык — пожалуйста, все, кто утверждает об принадлежности или непринадлежности языка к ООП — придите сюда и четко изложите свои мысли и доводы, что такое настоящий ООП язык, откуда вы эти рамки взяли и с чего, вообще, взяли, что предложенное вами определение будет верным в последней инстанции? Можно будет взять различные фундаментальные труды и их определния, соотнести, что схоже, что нет (что должно быть обязательно, что — не обязательно, и почему) и т.д. Это будет конструктивней и инстересней, нежели твердеть с деловым видом об «убожестве» чье-то, довольно мощной, разработки.
А устраивать какие-то сомнительные холиворы (не являясь при этом создатилями ни PHP, ни Ruby) — вообще какая-то ерунда.
это во многих реализациях так
«вы только подтвердили убогость языка» — habrahabr.ru/blogs/php/47785/#comment_1229894
> Те кто думает что CakePHP — это «как RoR» сильно заблуждаются.
А причем здесь какие-то Рельсы и какой-то там КейкПХП?
Вы дали четкое определение «убого» относительно ПХП: «убого» это когда называют «магией ООП» засовывание кучи функций во враппер-класс. Вот мне и интересно — где «не убого»? Определенно же — Вы должны знать ответ на этот вопрос, раз так категорично определяете «убогость» PHP. Или я ошибся?
> Для примера можете взглянуть на реализацию коллекций ассоциаций
а что за коллекции ассоциаций?
а в Руби не так разве?
А Вы на каком уровне с Руби знакомы? Можно посмотреть сравнительные примеры «убогости» PHP и «неубогости» Ruby?
какая еще «убогость»? что за «ЭТО»? Что есть «не убогость»? Где нет «ЭТОГО»?
а что есть ООП? В Вашем понимании.
[] быстрее {} — если сравнивать сравниваемое (либо обращение по ключу, либо поиск значения). Если как здесь — поиск значения, когда ключ не известен и проверка наличия ключа (если это хэш — то вычисление хэша и получения индекса) — тогда — конечно (но сравниваются две абсолютно разные вещи).
в любом случае заносится, просто индексы не-числа не воздействуют на на свойство length
.ps:
> вы наверно не в курсе как данные в массиве хранятся
Zeroglif, ;) ;) ;) :D
ключ, подлежащий хэшированию и получению индекса — может быть любым — хоть '1', хоть 'test'
в Вашем же случае, это не только перестанет вести себя как массив, но еще и будет дублировать элементы