Сабджект... Понятно, что от Object. Однако, FF и Opera после создания DOM-элемента (например, div) позволяют получить в этом элементе доступ к свойству constructor и constructor.prototype (сам элемент свойства prototype не имеет). Таким образом, можно расширить стандартные DOM-объекты. Рабочий пример:



Вопрос: если div наследуется от Object:

IE:



то почему, d не видит метода setContentFromObject? И вообще, можно ли получить доступ к конструктору (и его прототипу) DOM-элемента в IE?

P.S.: всех с наступающим Новым годом, коллеги! Здоровья, счастья, успехов, побед!

В IE <div> не наследует от Object. Проверьте:



Нет, нельзя. Используемая концепция COM как-раз подразумевает обратное - объекты находятся в физически разных модулях, взаимодействующих между собой лишь посредством определенных интерфейсов. Эта концепция реализована во множестве майкрософтовсих платформ, одной из которых является IE.

уй-ё.. Вот я лажанулся-то =) Мне реально показалось, что d instanceof Object == true, а не false (и я стал создавать тему =)))



объекты в разных модулях - это имеется в виду див и его конструктор? А что это за модули? И доступа к "определенным интерфейсам" тоже не получить, чтобы связаться...

Спасибо, AKS =)

Нет, я имел ввиду jscript-объекты и элементы документа. Т.е. jscript'вский Object - это одна "песня",  и к узлам документа (к элементам, в частности) эта "песня" не имеет никакого отношения.


Доступ к интерфейсам Вы как-раз имеете. Т.е. Вы имеете в своем распоряжении некий API (интерфейс программирования приложений), позовляющий Вам получить доступ средствами одного языка программирования (в данном случае речь о jscript) к объектам, написанным на другом языке программирования. 
А вот какую функциональность предоставили Вам "гениальные" майкрософтовские кодеры - это уже другой вопрос. Получилось так, что они решили не давать Вам доступ к конструктору элемента, о котором Вы писали. Можно даже резюмировать следующим образом - все, что касается "происхождения" элементов документа, просто-напросто "скрыли в черном ящике". 
Однако винить в чем-либо разработчиков IE было бы совершенно нелепо. Они используют "привычный" для своих продуктов технологический стандарт COM, и им незачем от него отказываться (программисты, как известно, о-о-очень редко отказываются от того, что, как они любят выражаться, "итак работает" ;) ).

ну да, в общем получается для расширения DOM-объектов в IE надо пихать эту функцию (расширения) в метод получения объекта (т.е. хранить расширенные методы для каждого объекта индивидуально; ну и помечать, что объект уже расширен, чтобы не делать холостых операций каждый раз), в то время как в FF и Opera все это можно хранить в прототипе конструктора, что намного "легче" (по весу объектов, т.к. в последнем случае они ссылаются на нужный прототип):

dsCode, можно сделать несколько проще. Используя специфичные для IE HTML компоненты, можно добиться почти того же самого, что и в случае с FF/Opera (даже определить геттеры/сеттеры для элементов):
html (с кодом для FF, в котором специально написал геттер isHidden):

htc (для IE):

Это сообщение отредактировал(а) cruelangel - 2.1.2008, 19:43

прошу прощения, что долго не отвечал, я в отъезде (до сих пор) =)

AKS, cruelangel, спасибо за ответы. Кстати, насчет htc и behavior в стиле я как-то и не знаю вообще (и последней конструкции в частности - ...'*', 'behavior: expression(...) ...). Расскажите, если не трудно, что это значит для IE, ну и "пару ссылок" почитать тоже было бы неплохо =)

И еще вопрос - есть ли разница, если геттер/сеттер объявлен как "обычный метод" или через __defineGetter__ (он, вроде, доступен только в Gecko)? И если нет, то зачем эти __defineGetter__ / __defineSetter__? Для красоты?

HTC Reference
Introduction to DHTML Behaviors
behavior Attribute
setExpression Method


Разница есть, конечно же. При создании такое свойство ("виртуальное" св-во, на самом деле это ведь метод), судя по всему, получает атрибут { ReadOnly }, т.к. "переписать" такое св-во не удастся. Ну и использовать их проще - var a = myObj.get; myObj.set = a * 2;
Чаще всего можно встретить писанину, в которой показывают, как геттеры/сеттеры использовать для доступа к "приватным" св-вам. Только для ECMAScript 3 "возня" с "приватом" не столь актуальна. 
Можно, естественно, "поручить" геттерам/сеттерам и более сложную логику, что-нибудь, вроде такого:

Но, поскольку, геттеры/сеттеры пока поддерживаются только на ограниченном кол-ве платформ:

• Firefox
• Opera 9.5
• Safari 3

 особо на них рассчитывать не приходится - в других браузерах такой код станет причиной "вылета" ошибки...

AKS, ага, thx =) И еще парочка вопросов:

- часто ли кто использует htc в своих разработках? Теоретически для IE можно было бы расширить прототип ActiveXObject'a и использовать нужные методы. Или так не получилось бы и надо обязательно через htc - расширять прототип ActiveXObject'a, а потом копировать в функцию element'a (себе: вот лень самому написать проверить, надо здесь писать, да? =)))? Но вообще, конечно, понятно - от ActiveXObject'a много кто наследуется (и инстанцируется), а не только какой-то там div, поэтому "засорять" его (ActiveXObject) только для div'a - тоже мало смысла.

- насчет геттеров/сеттеров - значит единственное отличие - это ReadOnly атрибут - т.е. если не будет сеттера и написать a.b = 3 вылезет ошибка, что для этого свойства есть только геттер, а менять его нельзя, с этим понятно =) Ну и мини-вопрос - разницы между get b и __defineGetter__(...) нет, да? Я знал их и раньше, но никогда не использовал. Да собственно, и не вижу особой надобности на данном этапе. Единственное применение - какие-нибудь внутренние свойства какого-нибудь ядра (фреймворка), которое могут все использовать, но  менять свойства внутренних сущностей - нет.

Это сообщение отредактировал(а) dsCode - 8.1.2008, 15:09

Мне ничего не известно о подобной статистике. Можно обойтись одним только Jscript'ом, htc - это "навороты" немного из другой области.


Если только теоретически, поскольку расширяй-не расширяй - толку нет (элементы ничего не узнают об этих методах). Это я просто ради эксперимента его использовал, т.ч. не обращайте внимание.


Разница-то всегда должна быть, а иначе зачем разный синтаксис. __defineGetter__ можно использовать когда угодно (динамически, а не в момент инициализации объекта).

я имел в виду здешних участников форума =) ну да ладно


хех, тогда, конечно, какой смысл?! я-то думал, что они будут "видны". Тогда и смысла не было в расширении ActiveXObject.prototype  в примере с htc и можно было написать element.changeDisplayValue = function()  {...};. А вообще странно... почему не будут видны? prototype - есть, расширить можно, div - инстанс ActiveXObject'a и может достучаться (не напрямую, ибо - суть темы, а как инстанс) до (уже расширенного) прототипа..


а, ну здесь - да, конечно - да.

P.S.: и в очередной раз - спасибо, еще +1 =)

Это сообщение отредактировал(а) dsCode - 8.1.2008, 18:44

Неужели не уловили суть? ;)

представьте себе ;) наверно потому, что htc не знаю =) так что - разъяснения будут более полезны 

Просто в таком случае: element.changeDisplayValue = function()  {...};, для каждого элемента будет создаваться своя, всякий раз новая функция. И если элементов много (* { behavior:...} - т.е. вообще все эл-ты на странице), то это будет не простой процесс.
А если же создать один раз, разместив их в каком-либо "хранилище" в глобальной области видимости (я с дуру выбрал ActiveXObject.prototype ;) ), то js-функций будет создаваться значительно меньше (меньше занимаемая память, например). 
Единственное неудобство - надо явно создать "поля" у каждого элемента и присвоить им указатель на функцию. В случае с HTMLElement.prototype этого делать не надо, однако и доступ к методу будет дольше (у элемента нет такого метода - надо искать в prototype chain)...

а как это меньше? тогда уж по этой логике функция будет одна (в (с дуру) ActiveXObject.prototype) и свойство element.changeDisplayValue будет содержать ссылку на ActiveXObject.prototype.changeDisplayValue (а я вот забыл - или не ссылку? что происходит при присваивании функции? - копия или ссылка? (плохо, когда не знаешь, да еще и забудешь =)) А если копия - то так же "много" функций создастся)

Если верить спецификации, то это должна быть ссылка. Вообще любой идентификатор, будь то имя функции, переменной, свойства и т.д. - это должно быть "нечто" ссылочного типа (value of type Reference) в тот момент, когда вычисляется значение этого самого идентификатора. Однако, "ссылочный тип" преподносится спецификацией, как абстракция, и служит лишь для того, чтобы описать то, как должен "вести" себя движок при вычислении значений. А вот как это выглядит "изнутри" какого-либо отдельно взятого движка - это другой вопрос. Хотя, по простому говоря, кому захочется реализовать процесс присвоения св-в так, как-будто это ссылки, а "втихомолку" создавать копии?

ага, стало быть ссылка =) (ну то и было интуитивно ясно, надо было только уточнить (опять лень было мне написать подобный простой пример)). Ну и преимущества "хранилища, на которое все будут ссылаться" перед "... = function() {}" сразу проясняются. И тогда будет все-таки одна функция, а не "js-функций будет создаваться значительно меньше" =)

однако,



Я могу предположить только так: если даже это ссылка, а не копия - то при удалении оригинала происходит копирование всех свойств в "копию", либо на этапе присвоения (F.prop = 1;) происходит копия во все связанные объекты. Опять же, гадать как-то не правильно, поэтому кто знает, подскажите, как "на самом деле" =)

То, что Вы приняли за "удаление оригинала" - это не что иное, как присвоение нового значения идентификатору F. Причем Вы присвоили новое значение не имени функции, а одноименному свойству объекта Global. У функции имя осталось прежнее:

Пояснение из ECMAScript Language Specification Edition 3 (10.1.3 Variable Instantiation):

Сама функция F остается в памяти, т.к. есть идентификаторы, на нее ссылающиеся (это f). Вот если и его "обналлить", то появится шанс, что garbage collector "приберет к рукам" этот "бесхозный" объектик (но это еще на воде вилами писано, как говорится, т.к. происходит это лишь в определенных условиях).


Это сообщение отредактировал(а) AKS - 10.1.2008, 21:28

хм, получается в variable object (VO) для объектов (вернее, для не примитивных типов) есть привилегии. Т.е. если есть ссылки на какой-то объект, то удалить его (перезаписав новые данные в этот "слот" (с именем "F")) нельзя. Похожий пример:



Тогда еще вопрос - где в VO (описано ли это в спецификации?) хранится "копия" перезаписанного объекта? Ведь доступа к нему уже нет (именно к оригиналу, я имею в виду). В "слот" n записывается новый объект и свойства prop больше не имеет. Однако, m все еще (ведь это же ссылка, а не копия) цепляет его (prop) из "неизвестного места в VO".

С примитивами такая же история:






Судя по всему, хранится объект (или примитив), позволяя "цепляться" за себя, не в VO, а где-то в памяти (как выделяется память, сколько, и чего, и под какие конкретные цели - с этим я еще не знакомился). А в VO есть лишь св-во, являющееся ссылкой (pointer) на определенные данные (значение), занимающие определенную область памяти. Это св-во можно удалить или переопределить, тем самым давая понять сборщику мусора, что та область памяти, на которую ранее это св-во ссылалось, может быть освобождена. Однако, если изначально значение переопределяемого (удаляемого) св-ва было "сохранено" в каком-либо другом св-ве (или переменной), то, конечно же, объект (или что-то еще) из той области памяти будет продолжать "жить" дальше. 

с чего бы вдруг? разве они не по значению присваиваются (копируются)? Понятно, что m - 1, но здесь-то значение было именно скопировано. Или нет? Что, и примитивы по ссылке присваиваются? Не верится что-то..

А может и объекты, также как примитивы, копируются по значению (и получается что-нибудь, вроде описанного в 13.1.2 Joined Objects). Разве в этом разберешься без того, кто написал ECMAScript-движок.


Это сообщение отредактировал(а) AKS - 10.1.2008, 23:49

какой ещё экмадвижок?  сначала был яваскрипт, потом появился жскрипт, а потом люди собрались и решили стандартизировать язык. и назвали его экмаскрипт, который пока нигде полностью так и не реализован 

egao, на вопрос "какой ещё экмадвижок?", могу ответить то, что я имел ввиду реализацию ECMAScript Language, соответствующую (или претендующую на соответствие) спецификации языка.

dsCode, сегодня, перечитав кое-что (вот это, в частности), попытался собрать мысли "в кучу". Итак, вот как можно было резюмировать то, что "всплыло" на последнем этапе обсуждения:

• Числовые и логические значения копируются, передаются в качестве аргументов и сравниваются по своему значению. Когда такие значения копируются или передаются, то всякий раз создается новое пространство в памяти,  где будет "храниться" копия. И такая копия - это новая, отличная от оригинала сущность. Поэтому изменение оригинала никак не сказывается на копии, и наоборот.
• Объекты, массивы и функции, являясь сами по себе ссылкой на данные в памяти, копируются, передаются в качестве аргументов и сравниваются соответственно, как ссылки. В момент копирования или передачи ссылки создается указатель на оригинал, и он используется, как если бы это была копия. Если изменяется оригинал, то меняется и копия (и наоборот). Но это всегда одна и та же сущность, поскольку копия на самом деле является лишь такой же ссылкой на данные, какой является оригинал. При сравнении переменных, значением которых является ссылка на объект, проверяется являются ли они ссылками на один и тот же объект или нет.
• Со строками ситуация немного иная, чем с числовыми или логическими значениями. Строки копируются и передаются в качестве аргументов как ссылки. Таким образом, появляется возможность сократить расход памяти. При сравнении строк также есть отличия. Если сравниваются строковые объекты, то сравнение, как и положено объектам, будет производиться по ссылкам. Но если одна из строк (а уже тем более, если обе) – это примитивное значение, то сравниваться будут именно значения этих строк.

P.S. Убрал "строки сравниваются как ссылки" - сам же ниже уже написал, как варьируется сравнение.

Это сообщение отредактировал(а) AKS - 11.1.2008, 11:32

Совершенно неубедительно 

ksnk, а вот Вы объясните (по буквам), что происходит в вашем примере. 

Ok! Оспаривается утверждение, что 
 В этом случае конструкция x+=чего-то там должна бы, по идее, изменить этот самый x

AKS, ну первые два пункта и так всегда были ясны (это в каждой книжке по программированию пишут, не знаю, как насчет JavaScript, но думаю, эту идеологию они тоже вполне поддержали), смущало лишь то, что идентификатор затирается (переписывается новым значением), а старое значение остается в памяти, т.к. есть ссылки. А вот со строками получается new String('test') будет сравниваться с меньшими затратами, чем 'test'.

С какой стати? Вы ведь присвоили новое значение "копии" и ее же вернули. С объектом будет тоже самое, если возвращать новое значение, и не то же самое, если изменить знание "копии" (и, соответственно, оригинала):


Добавлено через 5 минут и 14 секунд

Не сразу понял, о каких затратах речь.  
Получается, что так. Если переменные указывают на объекты, то при их сравнении движок просто "полюбопытствует" - на одни объект указывают ссылки или нет. А вот чтобы сравнить их значения, придется "вынимать" эти значения из объектов.

Добавлено через 11 минут и 39 секунд

Мне тоже они казались совершенно очевидными, а вот оказалось так, что сформулировать знания не смог. 

x в моем примере по вашим словам - ссылка, а не копия...

Добавлено @ 12:18
Видимо, разумнее будет считать, что строки передаются "хитрым" образом... Типа по ссылке, но при изменении тут-же строится копия этой самой строки...  В общем - чтобы не заморачиваться с излишней "хитростью", можно вчерне считать, что по значению...

Это сообщение отредактировал(а) ksnk - 11.1.2008, 12:19

AKS, с примером я действительно лоханулся... у String'а, оказывается даже нет методов, изменяющих самого себя...

Это сообщение отредактировал(а) ksnk - 11.1.2008, 13:05

Кстати, заодно отвечая и на это:

могу написать следующее (на примере вашей var y=function(x){return x+=' one more string'};).
Давайте "разглядим", что такое x внутри функции. X - это ведь уже и не аргумент, это свойство variable object:

Можно предположить, что выглядит это так:

Итак, создано св-во, значением которого является ссылка на строку. А что происходит далее? А происходит то, что Вы присваиваете этому св-ву новое значение:

При этом сама оригинальная ссылка, которая "очутилась" в функции в качестве аргумента, к этим изменениям не имеет никакого отношения. Есть доступ только к св-ву variable object, и до тех пор, пока св-во тождественно ссылке, посредством этого св-ва можно было "управлять" тем, на что указывает ссылка (т.е. менять какие-нибудь св-ва объекта). 
Вот так я себе это представляю.
Вообще, про функции пишут, что все им передается по значению. Если это ссылка, то передается именно значение ссылки, вместо того значения, на которое указывает ссылка. Но мне кажется, все равно, как там и что передается. И я уже объяснил почему - потому что манипулировать мы можем лишь св-вами variable object. Присвоив новое значение мы просто-напросто теряем связь с оригинальным значением.


И поэтому непонятно, как доказать, что строки не копируются, как числа или булевы значения, а копируются ссылки на их значения, созданные единожды.
Вообще, я ведь только пересказал то, что пишут разработчики.

1. примитивные значения передаются и присваиваются по значению
2. комплексные объекты - по ссылке

что тут может быть непонятно?   

А в JavaScript есть примитивные значения?

всем все понятно, с чего ты взял? 

Вы, судя по всему, спрашиваете о том, чего именно не поняли Вы? Что ж, я Вам отвечу. Мы с ksnk полдня обсуждали тот факт, что строки копируются и передаются by reference. 

Copying, Passing, and Comparing Data:


А Вы, несмотря ни на что, пишите, что "примитивные значения передаются и присваиваются по значению". Вы просто упустили этот момент в силу своей невнимательности или Вы несогласны с этим? 
В любом случае, прошу Вас, ради бога, избавьте нас от своих "устало-мудрых" замечаний, вроде "чего вам всем тут непонятно".
А если уж Вам все понятно (после того, как здесь все обсудили), то ответьте на вопрос - чем отличаются ваши "комплексные объекты" от "некомплексных"?

 

Да, есть.

> Мы с ksnk полдня обсуждали тот факт, что строки копируются и передаются by reference. 

глупость какая. в цитате просто описываются принципы ленивого копирования.


> чем отличаются ваши "комплексные объекты" от "некомплексных"?

некомплексные, они же примитивные, объекты - это строки, числа и булы, которые в спеках называются примитивными значениями, а вот действительно примитивными значениями являются null и undefined



Это сообщение отредактировал(а) cruelangel - 11.1.2008, 19:48

Да-а-а... 
Что тут сказать? Я сам виноват – расслабился, забыл то, с кем имею честь.
А ведь следовало бы помнить, хотя бы по теме намбер или не намбер ?. В той теме, блуждая в трех соснах, Вы, тем не менее, с завидным упорством утверждали, что вообще нет примитивов, а есть лишь объекты. То, что Вам ответил Zeroglif, будет очень кстати и в этой теме:

Так вот, возвращаясь к тому, что прописано в ECMAScript Language Specification Edition 3, и добавляя к тому, что уже цитировал из спецификации в предыдущем сообщении, отмечу следующее. Есть четко сформулированные алгоритмы, например:

в которых явно описывается конвертация в примитивное значение (не объект!!!). Также есть, например, value properties of the Global Object, такие как NaN или Infinity, которые изначально по определению не являются объектами. Более того, в спецификации специально описана такая абстрактная операция, как ToPrimitive, чтобы помочь разъяснить семантику языка:

Все это говорит о том,  что Вы глубоко заблуждаетесь, называя объектами то, что объектами не является. Также глубочайшим вашим заблуждением является то, что Вы что-то называете комплексными/некомплексными объектами – в ECMAScript Language нет ни того, ни другого понятия. Ну и, наконец, несмотря на то, что Вам уже неоднократно объясняли суть дела, Вы по-прежнему пишите, что "...объекты - по ссылке (передаются и присваиваются)". 


Если то, что мы обсуждали, для Вас – глупость, то зачем Вы пытаетесь присоединиться к обсуждению? Только затем, чтобы назвать обсуждение глупостью? Но я ведь Вам на русском языке написал – найдите в себе силы отказаться от подобных высказываний! Произвести впечатление Вы сумеете лишь в том случае, если сможете отказаться от своей склонности к искажению фактов и от попыток прикрыть свою некомпетентность своими же досужими вымыслами и отвлеченными фантазиями.


В цитате черным по белому сказано: strings are copied and passed by reference. Где Вы увидели описание принципа "ленивого копирования"? Узрели между строк? 

Это сообщение отредактировал(а) AKS - 11.1.2008, 22:58

> Так вот, возвращаясь к тому, что прописано в ECMAScript Language Specification Edition 3

эту спецификацию писали люди, которые не понимают что такое объект. 


> Где Вы увидели описание принципа "ленивого копирования"? Узрели между строк?

да.

 

/** удаленный текст  */

Это сообщение отредактировал(а) dsCode - 12.1.2008, 00:19

улыбайтесь - это всех раздражает   

Хорошо. Давайте представим, что ваши заявления верны и ученые степени тех, кто писал ECMAScript Language Specification, не позволяют им осознать в полной мере, что такое объект в информатике. Они-то, будучи людьми весьма приземленными (т.е. "зашибленными" парадигмой объектно-ориентированного программирования), наивно полагают, что объект – это всего-навсего экземпляр какого-либо класса (конструктора, применительно к данному разделу). Вы, видимо, мыслите какими-то своими философскими категориями и считаете, что понятие "объект" значительно шире, чем кто-либо может себе это представить. 
Так вот у меня просьба – поделитесь хоть какой-нибудь полезной информацией на эту тему, которая бы указала нам на выход из тьмы неведения. И, пожалуйста, если это будут ссылки на статьи, пусть это будут статьи, написанные не Вами, а каким-нибудь другим автором. На самом деле, Вам давно уже надо было предложить хоть какие-то сведения в защиту своей точки зрения. А то пока получается так, что информативная ценность всех ваших сообщений равна нулю.


Я, в общем-то, предполагал, что Вы обладаете возможностями, которых нет у других (в данном случае – это умение видеть то, что скрыто от глаз остальных участников обсуждения). Теперь понятно, почему некоторые реплики Вам кажутся глупыми.


А на какую реакцию Вы рассчитывали? Заявляя о том, что здесь пишут глупости, о том, что авторы языка программирования ничего не знают об объектах, Вы должны были ожидать нечто подобное. Лично я не удивляюсь, если кто-нибудь напишет, что он вообще чуть не умер от смеха, читая Ваши высказывания.


Это сообщение отредактировал(а) AKS - 12.1.2008, 10:27

да пожалуйста:

http://ru.wikipedia.org/wiki/%D0%9F%D1%80%...%BD%D0%B8%D0%B5
http://ringill.livejournal.com/16796.html

egao, какая именно часть информации свидетельствует о несостоятельности авторов ECMAScript Language Specification?

а, тогда: http://stanonwork.blogspot.com/2007/07/blog-post.html

Это сообщение отредактировал(а) egao - 13.1.2008, 14:14

egao, Вы можете прокомментировать материал, на который ссылаетесь?

там приводятся исходные ооп принципы Алана Кея в которых нет ни слова о глупостях типа "объект - это экземпляр класса" и которым вполне соответствуют все "примитивные типы" яваскрипта кроме нуля и неопределённости.

каждый такой "примитивный тип" имеет некоторое состояние и принимает сообщения. при приёме сообщения он создаёт пустой комплексный объект, наследующий у соответствующего прототипа слоты, и пересылает сообщение ему.

Это сообщение отредактировал(а) egao - 13.1.2008, 16:12

а кто здесь писал подобные "глупости" применительно к JavaScript?


он создаёт ... объект, наследующий у соответствующего прототипа слоты

> а кто здесь писал подобные "глупости" применительно к JavaScript?

вы двое и писали.


> он создаёт ... объект, наследующий у соответствующего прототипа слоты 

тебя смущает, что один объект может создать другой?

Это сообщение отредактировал(а) egao - 13.1.2008, 16:07

покажи (только вот давай, по совести, положа руку на сердце, и не придираясь к словам). Если ты не в силах понимать сравнения, метафоры, то, пожалуйста, не надо утверждать, что я и AKS настолько тупые и непонятливые, что не знаем даже основ. Так что - покажи - где?


нет, ты опять все не так понимаешь, а, если и правильно понимаешь, то пытаешься запутать меня (и себя в первую очередь) (но безрезультатно пытаешься)  (да и вообще с дедукцией у тебя очень плохо, раз ты такие выводы делаешь ) Я выделил слово "создает", чтобы показать, что ты сам знаешь, как это работает, что над примитивом "при удобном случае" создается объект.

Это сообщение отредактировал(а) dsCode - 13.1.2008, 16:20

что "а, тогда"? по первым двум ссылкам есть что-то вразумитльное и членораздельное обосновать, что кардинально расходилось бы с нашими рассуждениями и ECMAScript? Или ты думаешь, можно просто так везде и всюду  кидаться словами типа "глупости" и "что тут (вам всем (тупые)) непонятно"?

Это сообщение отредактировал(а) dsCode - 13.1.2008, 16:36

> вы двое и писали.
> покажи

http://forum.vingrad.ru/forum/topic-120066/105.html
там в статье ты утверждаешь, что яваскрипт - не объектно ориентированный язык и приводишь способ эмуляции этой парадигмы посредством ввода объекта-класса.


> Я выделил слово "создает", чтобы показать, что ты сам знаешь, как это работает, что над примитивом "при удобном случае" создается объект.

объект сам по себе не создаётся. его создаёт другой объект, когда к нему приходит сообщение.


> что "а, тогда"?

там рассказывается о том, что при ооп понятие класса не просто необязательно, а даже вредно. это был ответ на тезис о том, что "разработчики яваскрипта наивно полагают, что объекты - это экземпляры классов или конструктора"

ну вот и все, не можешь ты ничего внятно и человеческим языком обосновать. Я ж просил - без придирки к словам, но ты, в силу того, что больше ничего не останется сказать - тупо проигнорировал мою просьбу =) Все поняли, что я имел в виду (объектно-прототипное программирование). И если бы ты все же умел "читать между строк"  (а там даже и не между строк, а явно было написано) - то я указал "не объектно-ориантированный в классическом понимании этой сущности, а объектно-прототипный" - все поняли, что я имел в виду (говоря кухонно-разговорным языком) что-то типа: "JavaScript не такой как C в этом плане" =) Но тебе, конечно, надо выдумать какую-нибудь глупость и, более того, потом, не парясь, сказать, что глупость говорил я =)))


и ничего там о вредности не говорится =) а лишь приводятся преимущества делегирования =)) (статья, кстати, неплохая). Кстати, JavaScript 2.0, как ты знаешь, будет иметь явное понятие класса.


своей глупостью ты указал на мою статью  а где "глупость" AKS'a?


по этому поводу тоже хорошо бы услышать объяснения

Это сообщение отредактировал(а) dsCode - 13.1.2008, 17:59

> не объектно-ориентированный в классическом понимании этой сущности, а объектно-прототипный

а не надо ставить всё с ног на голову. в классическом понимании, ооп - это принципы Алана Кея, ссылку на которые я дал выше. классово-ориентированное программирование и прототип-ориентированное программирование - это всего лишь поджанры ооп. второй более труъ ;-)


> говоря кухонно-разговорным языком: JavaScript не такой как C в этом плане

вот и говори кухонно-разговорным. не стоит употреблять термины смысла которых ты не понимаешь.


> своей глупостью ты указал на мою статью smile а где "глупость" AKSa? 

в конце моего последнего поста - его вольная цитата.

Это сообщение отредактировал(а) egao - 13.1.2008, 18:04

ладно, мне надоело перед тобой "метать бисер", туго до тебя что-либо вообще доходит (если доходит вообще). Опять же, из нас двоих - смысла не понимаю - не я . Все твои доводы - всего лишь дешевая игра на словах, и больше ничего =) Я оставляю тебя наедине. Разговор окончен.

Это сообщение отредактировал(а) dsCode - 13.1.2008, 18:43

> по этому поводу тоже хорошо бы услышать объяснения

что конкретно ты хочешь слышать?

Добавлено через 9 минут и 18 секунд
> Разговор окончен.

экий ты слабенький  всего одну страницу выдержал...

Вы понимаете, что:
- во-первых, любой имеет право не разделять принципы этого уважаемого человека;
- во-вторых, люди создают языки программирования для решения задач, о существовании которых этот уважаемый человек может и не подозревать.
Следуя вашей логике, любой программист, преследующий определенную цель доступными средствами, которые выходят за рамки вашего представления и сознания, "не понимает, что такое объект". Поэтому к создателям ECMAScript, как к невеждам, выдумавшим примитивы, я бы "сходу" присоединил создателей Java и Delphi. Да и вообще, почти всех остальных, ведь на вопрос "What does "object-oriented [programming]" mean to you?" Alan Kay ответил так:

Значит люди, создающие и работающие с другими языками программирования, кроме Smalltalk и LISP, "не понимают, что такое объект"?


Нет в ECMAScript понятия "принимает сообщения". Есть вызов метода.


Ничего "он" не создает! И, как я уже писал, нет в ECMAScript понятия "комплексный объект"!
 

Нет "наследования", есть механизм делегирования свойств и методов! Нет в ECMAScript понятия "слоты"!


И правильно сделал! На кой черт это надо "выдерживать"? Я вообще на будущее предлагаю dsCode присоединиться ко мне и прекратить всяческие дискуссии с Вами. С самого начала и до сих пор все то, что Вы писали и продолжаете писать в контексте данного раздела, посвященного ECMAScript – это чистейший вздор. Вы слабо представляете то, что происходит в ECMAScript. Более того, Вы просто не понимаете, что любые принципы, будь то принципы Алана Кея, или любого другого – это абстракция. У любой точки зрения найдутся как сторонники, так и критики, и даже непримиримые оппоненты. И поэтому я делаю вывод, что общаться с Вами – это лишь пустая трата времени!

dsCode, давайте оставим его наедине с его "неглупыми" мыслями - пусть рассуждает! Тем более он не один, их несколько - egao, dark-demon и cruelangel, а может быть и больше. У человека раздвоение (или "размножение") личности, и нам, я думаю, надо впредь постараться избегать общения с ним(и).   

Это сообщение отредактировал(а) AKS - 13.1.2008, 19:35

> во-первых, любой имеет право не разделять принципы этого уважаемого человека;

тогда пусть указывают, что их понимание ооп отличается от исходного.


> во-вторых, люди создают языки программирования для решения задач, о существовании которых этот уважаемый человек может и не подозревать.

что ж они тогда так похожи на симулу, которая появилась раньше и повлияла на формирование принципов ооп? 


> программист, преследующий определенную цель доступными средствами,
> которые выходят за рамки вашего представления и сознания, "не понимает, что такое объект".

если при этом он утверждает, что "объект - это экзэмпляр класса" - да. то, что в некоторых языках есть деление объектов на экзэмпляры и классы, вовсе не означает, что классы не являются объектами.


> Нет в ECMAScript понятия "принимает сообщения". Есть вызов метода.

нет там никакого "вызова метода", ибо там всё на английском языке написано.


>> он создаёт пустой комплексный объект
> Ничего "он" не создает!

а кто создаёт? дядя с улицы? я использую объектную нотацию применительно к числу: вызываю его метод, которому ничего не передаю, но результат выполнения которого зависит от значения. и не надо рассказывать как там всё это реализуется в интерпретаторе, микропроцессоре, триггерах и тп. к языку и уж тем более к парадигме программирования это ни в коем разе не относится. на уровне языка - примитивный объект имеет только один безымянный слот, а обработку сообщений делегирует создаваемому комплексному прокси-объекту.


> Нет "наследования", есть механизм делегирования свойств и методов!

наследование - это такое связывание объектов, что добавление поля или метода одному из них (родителю) автоматически добавляет его и другому (потомку), но не наоборот. наследование бывает прямым (родитель-ребёнок) и косвенным (предок-потомок), динамическим (можно менять связи по ходу выполнения программы) и статическим.
в яваскрипте наследование реализовано через делегирование обработки доступа к отсутствующим слотам объекту-прототипу


> Нет в ECMAScript понятия "слоты"!

а ещё там нет понятия "сопоставление с образом". значит ли это, что в яваскрипте нет регулярных выражэний?

Это сообщение отредактировал(а) egao - 21.1.2008, 01:13

наконец добрался до форума =)

Во избежание последующих недоразумений, вызванных придиркой к словам "особо одаренными индивидуумами", я подкорректировал пару фраз в своей статье.

AKS, 

а, кстати, я точно не знаю, что происходит в соответствии со спецификацией - создается ли объект для примитива (и затем уничтожается после проведения нужной операции) или же происходит преобразование типа примитива к объекту? А с другой стороны - что такое преобразование тогда? Это получается - уничтожение оригинала, создание новой сущности нового типа, но с данными старой сущности. Или нет?



или как это более точно рассказать?

Не будем рассказывать, будем цитировать (ссылаться, правда, придется на тех, кто, по мнению некоторых, не достаточно компетентен, но нам с Вами, думаю, будет достаточно ;) ):

Ну а создает этот объект-оберку, конечно же, не примитивное значение. "Порывшись" в описании интерфейса SpiderMonkey, можно найти кое-какие намеки:

Не важно, как точно/детально это реализовано в движке, важно, что это внешне (с точки зрения программиста) не выходит за рамки логики ECMAScript. C точки зрения этой логики и надо рассказывать, потому как она условно общая, а в движках всегда всё по своему:

JScript (цитируя Eric Lippert):



JavaScript (цитируя Brendan Eich):

AKS, Zeroglif, ага, thx =)

  
О-о-о (вздох облегчения)! Zeroglif жив-здоров! 

Zeroglif, где пропадал?