var b = new Array;
b=['red','blue','red','yellow',['brown','white'],'black'];
alert(par(b));
function par(ar){
var ret ='';
for (i=0;i<ar.length;i++){
if (typeof(ar)=='array'){
ret+="["+par(ar)+"]";
}else{
ret+=ar+",";
}
}//end for
return ret;
}//end func
Вызов функцией самой себя в JS
Очень часто использую такой прием для обработки многомерных массивов ... функция получает массив в качестве аргумента, идет обработка циклом первого измерения, .... а в цикле проверка если текущий элемент массива - массив вызываем этуже функцию и передаем ей текущий элемент, а если не массив деаем с ним что положенно.
на ПХП все работало .... а вот реализовать танную тему на ЯС не получается .... вот код (общий случай)
я подозреваю что чтото напутал с областью видимости переменной.
Так как после вызова функцией самой себя ... элемент становится ундерфаиндом.
Вобщем помогите чем можете.
на ПХП все работало .... а вот реализовать танную тему на ЯС не получается .... вот код (общий случай)
Код:
я подозреваю что чтото напутал с областью видимости переменной.
Так как после вызова функцией самой себя ... элемент становится ундерфаиндом.
Вобщем помогите чем можете.
Все, нашел ошибку спасибо.
Во 1-х масивы могут иметь значение typeof = object
Во 2-х, не знаю критично ли это, но если испольовать вызов функции не как функцию а как вызов нового экземпляра класса .... вот код .... он вроде рабочий.
Во 1-х масивы могут иметь значение typeof = object
Во 2-х, не знаю критично ли это, но если испольовать вызов функции не как функцию а как вызов нового экземпляра класса .... вот код .... он вроде рабочий.
Код:
b=['red','blue',['red','yellow'],'black'];
var c=new par(b);
alert(c.ret);
function par(ar){
this.ar=ar;
this.ret ='';
for (i=0;i<this.ar.length;i++){
alert (typeof(this.ar));
if (typeof(this.ar)=='array' || typeof(this.ar)=='object'){
this.vv = new par(this.ar);
//alert ("||" + vv.ret + "||");
this.ret+= "||" + this.vv.ret + "||";
}else{
this.ret+=this.ar+",";
}
}//end for
//return this.ret;
}//end func
var c=new par(b);
alert(c.ret);
function par(ar){
this.ar=ar;
this.ret ='';
for (i=0;i<this.ar.length;i++){
alert (typeof(this.ar));
if (typeof(this.ar)=='array' || typeof(this.ar)=='object'){
this.vv = new par(this.ar);
//alert ("||" + vv.ret + "||");
this.ret+= "||" + this.vv.ret + "||";
}else{
this.ret+=this.ar+",";
}
}//end for
//return this.ret;
}//end func
Цитата: merlex
Во 2-х, не знаю критично ли это, но если испольовать вызов функции не как функцию а как вызов нового экземпляра класса .... вот код .... он вроде рабочий.
В JS нет ни классов, ни тем более экземпляров класса. Там совершенно другая НЕ ООП модель.
Цитата: alekciy
В JS нет ни классов, ни тем более экземпляров класса. Там совершенно другая НЕ ООП модель.
да ну ..... не ООП модель говориш.
возможно терминология "класс" не слижком подходит .... более точно сказать прототип.
более подробно мошно почитать здесь
http://www.experiment.net.ru/js2/?f=obj2.htm
кроме того тема не отом. так что на этом оффтоп закончим.
Цитата: merlex
более подробно мошно почитать здесь
Это типа ты мне советуешь это почитать? Да? :D
Вопрос не в том, что подходит термин или не подходит. А в том, что для данного понятие есть полне определенный термин который и следует использовать, а не примешиваеть терминологию принятую для другой объектой модели.
И это не оффтоп. Кроме тебя твой пост будут читать и другие люди. Кто из них поймет, что ты не прав, а кто ведь и за чистую монету примет. Поэтому лично я настаиваю на техническо грамотной рече.
Цитата: alekciy
Это типа ты мне советуешь это почитать? Да? :D
Вопрос не в том, что подходит термин или не подходит. А в том, что для данного понятие есть полне определенный термин который и следует использовать, а не примешиваеть терминологию принятую для другой объектой модели.
Вопрос не в том, что подходит термин или не подходит. А в том, что для данного понятие есть полне определенный термин который и следует использовать, а не примешиваеть терминологию принятую для другой объектой модели.
это типа, ссылка :-)
....а вчем вопрос если же про это пошла речь, см в названии темы.
Цитата:
для данного понятие есть полне определенный термин который и следует использовать, а не примешиваеть терминологию принятую для другой объектой модели.
Вобще-то для этой модели — прототипноориентированный ООП, так что фраза "совершенно другая НЕ ООП модель" неверна :)
merlex, если наслышаны о прототипах, сделали бы через них :) Определить метод par и переопределить для различных типов.
Цитата:
Там совершенно другая НЕ ООП модель.
Цитата:
Поэтому лично я настаиваю на техническо грамотной рече.
тоесть первая цитата, это чисто технически грамотное высказывание?
Цитата: merlex
тоесть первая цитата, это чисто технически грамотное высказывание?
Да. Не первый год идут споры о четком описании что есть ООП. Кто-то вообще не признает сам факт существования ООП. Но за годы практики сложился ряд отличительных признаков по которым и различают. И базовые тут понятие это класс и экземпляр класса которых в JS нет. Даже в приведенной тобою линке это отмечено. Поэтому считать JS объект ориентированным языком я не могу. Прототипо ориентированным еще куда ни шло, но ни как не ОО.
И потом. Посмотрим на JS фрейворки. В них стремяться привести язык к "общепринятой" форме ОО. Наверное писать на одном языке в стили другого не совсем правильно (как там было... С програмист на любом языке пишет С программы), но, имхо, именно такая реализация и подчеркивает тот факт, что JS не ОО язык. Взять тот же С++, в нем же ни кто не пытается "дотянуть" его до ОО языка ибо он и так есть ОО.
Можно конечно поискать ссылки опровергающие это (таже Mozilla позиционируют язык как ОО "object-oriented scripting language"), но можно найти и обратные. Поэтому так уж получается, что каждый сам для себя это определяет. Я отношу JS к ПО языку и рассматриваю его не как предок или наследник ОО концепции или противопоставляю его процедурному подходу, но рассматриваю его как один из параллельных подходов.
Со страниц Википедии:
Цитата:
Объектно-ориентированный язык программирования (ОО-язык) — язык, благоприятствующий объектно-ориентированному программированию.
Цитата:
Объектно-ориентированное программирование - парадигма программирования, в которой основной концепией является понятие объекта...
Цитата:
Язык Self, соблюдая многие исходные положения объектного программирования, ввёл альтернативное классам понятие прототипа, положив начало прототипному программированию, считающемуся подвидом объектного.
Цитата:
Прототипное программирование — стиль объектно-ориентированного программирования...
Ну и как Standard ECMA-262 сам себя позиционирует (4 Overview):
Цитата:
ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment.
Ну вот, развели холи вар тут понимаешь... Ладно, тоже с вики
Цитата:
JavaScript обладает рядом свойств объектно-ориентированного языка, но благодаря прототипированию поддержка объектов в нём отличается от традиционных ОО языков.
Теперь от себя. Я считаю что язык, которы может называться ООП языком должен поддерживать 3 основные парадигмы ООП, а именно:
1. Наследование.
2. Инкапсуляция
3. Полиморфизм.
Покажите мне это в JavaScript, тогда я соглашусь, что он ООП.
Цитата: shaelf
...язык, которы может называться ООП языком
Не "ООП язык", а ОО-язык, т.е. объектно-ориентированный язык программирования.
Цитата: shaelf
Покажите мне это (наследование, инкапсуляция, полиморфизм) в JavaScript, тогда я соглашусь, что он ООП.
Ну, во-первых, опять цитата из Википедии (Прототипное программирование):
Цитата:
...возможно наиболее общим местом критики против прототипного программирования является то, что сообщество разработчиков ПО недостаточно хорошо знакомо с ним, несмотря на популярность и распространённость JavaScript.
Ну а во-вторых - кто же Вам будет показывать, что в ECMAScript Language есть то, чего Вы в нем не увидели? Создатели языка или авторы спецификации? Уж если написано в спецификации, что это "object-oriented programming language", значит так оно и есть. Несогласны - попытайтесь доказать обратное.
Объектно-ориентированное программирование, это программирование, позволяющее ориентироваться на объекты :). Т.е. объект является базовой частью языка. В этом плане JS является полноценным ОО-языком. Даже более ОО-языком, чем, например, C++, который обычно приводят, как классический пример.
Наследование, инкапсуляция и полиморфизм, это всего лишь производные понятия от ООП. Однако, и они присутствуют в JS в полной мере.
Наследование, инкапсуляция и полиморфизм, это всего лишь производные понятия от ООП. Однако, и они присутствуют в JS в полной мере.
Цитата:
Посмотрим на JS фрейворки. В них стремяться привести язык к "общепринятой" форме ОО.
Это значит лишь одно из двух: либо авторы фреймворков не умеют в полной мере использовать всю мощь прототипной парадигмы, либо они ориентируются на людей, которые не умеют. Собственно, фреймворки они для того и создаются — для того, чтобы юзер мог не затуманивая себе голову быстро клепать стандартные приложения.
Однако, почему то все гуру JS спокойно обходятся средствами заложенными в сам язык. И даже я, далеко не великий жаваскрипщек делаю достаточно сложные вещи не пытаясь извращаться над языком.
Цитата: shaelf
1. Наследование.
2. Инкапсуляция
3. Полиморфизм.
В том и фишка, что там все это есть. Пусть в несколько другой форме организации, но есть. А вот чего уж не в классическом (наверное даже можно сказать сиплюсном) понимании, так это "класс" и "экзепялер класса". Но прошедшие годы определение этих понятий более менее устаканилось, и исходя из этого JS на ОО не тянет.
Цитата: vasa_c
Это значит лишь одно из двух: либо авторы фреймворков не умеют в полной мере использовать всю мощь прототипной парадигмы, либо они ориентируются на людей, которые не умеют.
Второе. Если бы это они не умели, то фрейворк нормальный не написали бы. А пишут они эти фрейворк для людей которые больше привыкли к классической парадигме ООП.
Кстати примеров обратных фрейворков из По в ОО я что-то не припомню. Может потому что не интерисовался этим вопросом, а может потому что их и нет.
Цитата:
Если бы это они не умели, то фрейворк нормальный не написали бы.
А разве уже был написан нормальный фреймворк? :-D
Цитата:
примеров обратных фрейворков из По в ОО
Это как?
Цитата:
А разве уже был написан нормальный фреймворк?
prototype, mootools
Цитата: vasa_c
Это как?
А так: в ОО языке сделан такой фреймворк который работает в ПО стиле. Есть такой? Я вот такой не знаю, хотя знаю примеры обратных фрейморков.
Цитата:
prototype, mootools
Об их нормальности можно долго спорить.
Цитата:
в ОО языке сделан такой фреймворк который работает в ПО стиле
На класс-ориентированном языке создать прототип-ориентированный фреймворк?
Цитата: vasa_c
На класс-ориентированном языке создать прототип-ориентированный фреймворк?
Да. Такой фрейворк который будет требовать использование в API прототип-ориентированного стиля.
Судя по твоим долгим допыткам таковой все же есть? :confused:
Javascript является объектно-ориентированным языком основанном на прототипах.
Правда, в силу не понятных причин об этом все давно забыли. Кстати, в JS есть возможность создавать классы, конструкторы классов, методы классов и устанавливать свойства классов:
А вот вам наследование классов и переопределение методов и свойств:
[quote=shaelf]
Теперь от себя. Я считаю что язык, которы может называться ООП языком должен поддерживать 3 основные парадигмы ООП, а именно:
1. Наследование.
2. Инкапсуляция
3. Полиморфизм.
Покажите мне это в JavaScript, тогда я соглашусь, что он ООП.
[/quote]
Надеюсь я был убедителен? ;)
В ответе, я использовал примеры из книги:
"Полный справиочник по Javascript" (Второе издание). Авторы: Томас Пауэлл и Фриц Шнайдер.
Правда, в силу не понятных причин об этом все давно забыли. Кстати, в JS есть возможность создавать классы, конструкторы классов, методы классов и устанавливать свойства классов:
Код:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTDxhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Prototype</title>
<script type="text/javascript">
Robot.prototype.hasJetpack = false;
Robot.prototype.actionValue = "Alert!";
Robot.prototype.doAction = function(){alert(this.actionValue);};
function Robot(flying, action){
if(flying == true) { this.hasJetpack = true;}
if(action) { this.actionValue = action};
}
var guard = new Robot(true, "BOOM");
guard.doAction();
</script>
</head>
<body>
</body>
</html>
"http://www.w3.org/TR/xhtml1/DTDxhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Prototype</title>
<script type="text/javascript">
Robot.prototype.hasJetpack = false;
Robot.prototype.actionValue = "Alert!";
Robot.prototype.doAction = function(){alert(this.actionValue);};
function Robot(flying, action){
if(flying == true) { this.hasJetpack = true;}
if(action) { this.actionValue = action};
}
var guard = new Robot(true, "BOOM");
guard.doAction();
</script>
</head>
<body>
</body>
</html>
А вот вам наследование классов и переопределение методов и свойств:
Код:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTDxhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Prototype</title>
<script type="text/javascript">
Robot.prototype.hasJetpack = false;
Robot.prototype.actionValue = "Alert!";
Robot.prototype.doAction = function(){alert(this.actionValue);};
function Robot(flying, action){
if(flying == true) { this.hasJetpack = true;}
if(action) { this.actionValue = action};
}
//var guard = new Robot(true, "BOOM");
//guard.doAction();
function UltraRobot(extraFeature){
if(extraFeature) this.feature = extraFeature;
}
UltraRobot.prototype = new Robot();
UltraRobot.prototype.feature = "Radar";
var guard = new UltraRobot("Search...");
var feature = guard.feature;
var canFly = guard.hasJetpack;
guard.doAction();
</script>
</head>
<body>
</body>
</html>
"http://www.w3.org/TR/xhtml1/DTDxhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Prototype</title>
<script type="text/javascript">
Robot.prototype.hasJetpack = false;
Robot.prototype.actionValue = "Alert!";
Robot.prototype.doAction = function(){alert(this.actionValue);};
function Robot(flying, action){
if(flying == true) { this.hasJetpack = true;}
if(action) { this.actionValue = action};
}
//var guard = new Robot(true, "BOOM");
//guard.doAction();
function UltraRobot(extraFeature){
if(extraFeature) this.feature = extraFeature;
}
UltraRobot.prototype = new Robot();
UltraRobot.prototype.feature = "Radar";
var guard = new UltraRobot("Search...");
var feature = guard.feature;
var canFly = guard.hasJetpack;
guard.doAction();
</script>
</head>
<body>
</body>
</html>
[quote=shaelf]
Теперь от себя. Я считаю что язык, которы может называться ООП языком должен поддерживать 3 основные парадигмы ООП, а именно:
1. Наследование.
2. Инкапсуляция
3. Полиморфизм.
Покажите мне это в JavaScript, тогда я соглашусь, что он ООП.
[/quote]
Надеюсь я был убедителен? ;)
В ответе, я использовал примеры из книги:
"Полный справиочник по Javascript" (Второе издание). Авторы: Томас Пауэлл и Фриц Шнайдер.
*Нехотя соглашается с skywalker*
skywalker, знакомый код. Из какой-то книжки?
В JS нельзя создавать классы. Класс это внутренняя структура, хранящаяся в голове программиста и в структурах данных компилятора в момент компиляции (для C++ и подобных). Для PHP и т.п. она хранится где-то в недрах нативных структур.
В JS можно извратившись с прототипами создать API, работа с которым будет внешне походить на работу с классами.
У кого-то была фраза (не помню у кого, к сожалению), про то, что добиться настоящего класс-ориентированного подхода на JS можно только одним образом — написать на JS транслятор классориентированного языка.
В JS нельзя создавать классы. Класс это внутренняя структура, хранящаяся в голове программиста и в структурах данных компилятора в момент компиляции (для C++ и подобных). Для PHP и т.п. она хранится где-то в недрах нативных структур.
В JS можно извратившись с прототипами создать API, работа с которым будет внешне походить на работу с классами.
У кого-то была фраза (не помню у кого, к сожалению), про то, что добиться настоящего класс-ориентированного подхода на JS можно только одним образом — написать на JS транслятор классориентированного языка.
Цитата: vasa_c
skywalker, знакомый код. Из какой-то книжки?
Я в предыдущем сообщении писал:
[quote=skywalker]В ответе, я использовал примеры из книги:
"Полный справочник по Javascript" (Второе издание). Авторы: Томас Пауэлл и Фриц Шнайдер.[/QUOTE]
Что б ни кого не вводить в заблуждение, прочтите внимательно.
Цитата: vasa_c
В JS нельзя создавать классы. Класс это внутренняя структура, хранящаяся в голове программиста и в структурах данных компилятора в момент компиляции (для C++ и подобных). Для PHP и т.п. она хранится где-то в недрах нативных структур.
В JS можно извратившись с прототипами создать API, работа с которым будет внешне походить на работу с классами.
У кого-то была фраза (не помню у кого, к сожалению), про то, что добиться настоящего класс-ориентированного подхода на JS можно только одним образом — написать на JS транслятор классориентированного языка.
Хорошо, раз это было не убедительно, тогда поставлю вопрос иначе. В приведенных примерах доказано, что в JS можно использовать:
1. наследование.
2. инкапсуляцию
3. полиморфизм.
Но нельзя использовалось магическое, для программиста, слово: class, так можно ли на этом основании говорить, что JS не объектно-ориентирован?
Помоему, JS самый, что ни наесть объектно-ориентированный язык.
Цитата:
Помоему, JS самый, что ни наесть объектно-ориентированный язык.
Именно про это я и пишу в этой теме.
Что б ни кого не вводить в заблуждение, прочтите внимательно. :)
Не только нельзя использовать магическое слово class, но и не нужно использовать само понятие "класс". Другое дело, что в отсутствии этого понятия, JS не перестает быть объектно-ориентированным. Потому что в термине "объектно-ориентированное программирование" нет слова "класс", а есть производное от слова "объект". Класс же относится к класс-ориентированному подвиду объектно-ориентированного программирования.
Цитата: skywalker
Хорошо, раз это было не убедительно, тогда поставлю вопрос иначе. В приведенных примерах доказано, что в JS можно использовать:
1. наследование.
2. инкапсуляцию
3. полиморфизм.
А где здесь инкапсуляция?
Наследование есть, в prototype-based языках наследование может быть реализовано через делегирование, это тоже наследование, только вид сбоку... плюс это чётко заявлено в стандарте языка, спорить можно только на уровне - "to be or not to be", в принципе.
Полиморфизм не только есть, он паразитирует и жирует, сплошная динамика, late binding, постоянная конвертация из типа в тип в зависимости от операторов и проч., this определяется по ходу дела и т.д.
Инкапсуляция имитируется за счёт того, что внутри метода можно обращаться к идентификаторам объемлющего контекста (т.н. look-up в scope chain), соответственно на этом можно играть, пряча данные...
Учитывая то обстоятельство, что определений того же полиморфизма или инкапсуляции может быть 7643 штуки на квадратный сантиметр, спорить об этом можно бесконечно долго. Так же, как можно оспорить вообще необходимость вышеобозначимых признаков. Я для себя определился так - javascript весело и непринуждённо микширует разные парадигмы, но ECMAScript официально назван object-oriented, значит, необходимо было это обозначить при принятии стандарта, то есть это важно, так что javascript в моём представлении выглядит так:
Object-oriented
--- Object-based
------ Prototype-based
--------- Delegation-based
Полиморфизм не только есть, он паразитирует и жирует, сплошная динамика, late binding, постоянная конвертация из типа в тип в зависимости от операторов и проч., this определяется по ходу дела и т.д.
Инкапсуляция имитируется за счёт того, что внутри метода можно обращаться к идентификаторам объемлющего контекста (т.н. look-up в scope chain), соответственно на этом можно играть, пряча данные...
Учитывая то обстоятельство, что определений того же полиморфизма или инкапсуляции может быть 7643 штуки на квадратный сантиметр, спорить об этом можно бесконечно долго. Так же, как можно оспорить вообще необходимость вышеобозначимых признаков. Я для себя определился так - javascript весело и непринуждённо микширует разные парадигмы, но ECMAScript официально назван object-oriented, значит, необходимо было это обозначить при принятии стандарта, то есть это важно, так что javascript в моём представлении выглядит так:
Object-oriented
--- Object-based
------ Prototype-based
--------- Delegation-based
Цитата: Zeroglif
Инкапсуляция имитируется за счёт того, что внутри метода можно обращаться к идентификаторам объемлющего контекста (т.н. look-up в scope chain), соответственно на этом можно играть, пряча данные...
Не совсем понял что имеется в виду, но нельзя в JS закрыть для произвольного кода доступ к произвольному члену объекта. Поэтому нет в JS инкапсуляции.
Nixus, инкапсуляция в широком смысле, это просто собрание взаимосвязанных данных и кода по их обработки в одном месте. А закрывание данных от внешнего доступа, это уже не столько к сути инкапсуляции имеет отношение. В питоне вообще никакого сокрытия нет, он что не ООП от этого?
Тем более Zeroglif уже указал, что данные спокойно прячутся в объемлющем контексте. Если есть, конечно, желание так извращаться.
Тем более Zeroglif уже указал, что данные спокойно прячутся в объемлющем контексте. Если есть, конечно, желание так извращаться.
Цитата: vasa_c
Nixus, инкапсуляция в широком смысле, это просто собрание взаимосвязанных данных и кода по их обработки в одном месте. А закрывание данных от внешнего доступа, это уже не столько к сути инкапсуляции имеет отношение.
Вот всегда думал, что инкапсуляция есть сокрытие реализации объекта от клиента.
Что гуру ООП по этому поводу скажут?
Цитата: vasa_c
В питоне вообще никакого сокрытия нет, он что не ООП от этого?
Я не утверждаю, что JS не ООЯП, но и не утверждаю обратного.
Цитата: vasa_c
Тем более Zeroglif уже указал, что данные спокойно прячутся в объемлющем контексте. Если есть, конечно, желание так извращаться.
А при чем здесь контекст и приватные члены объекта? Я не вижу взаимосвязи.
Цитата: Nixus
Поэтому нет в JS инкапсуляции.
Ok. На мой взгляд инкапсуляция в javascript есть уже только по той причине, что есть объекты, а любой объект - структура самостоятельная, объединяющая в себе данные и код для манипуляции данными, вот и всё, больше ничего про инкапсуляцию в javascript доказывать не надо. Другой вопрос, что обычно на горизонте сразу появляются термины: public, protected, private и проч., то есть под инкапсуляцией однозначно подразумевается возможность скрывать код от прямого воздействия извне, никак не меньше. Во-первых, "сокрытие/защита" - это не инкапсуляция в целом, а только один из аспектов (хотя кто вообще знает это единственное всеобъемлющее определение?). Во-вторых, javascript 1.x, будучи динамичным скриптовым языком, спроектированный изначально под короткие задачи, не сильно-то и нуждается в калькировании класс-ориентированных подходов (я бы даже сказал, ему это нафиг не нужно и даже вредно). В-третьих, какой-никакой инструмент сокрытия кода для верующих всё-таки есть - это механизм вычисления идентификаторов, помноженный на вложенные функции или упрощённо говоря - лексические замыкания, примитивный пример:
Код:
function F(x) {
this.setX = function (y) {
x = y;
};
this.getX = function () {
return x;
};
this.x = x;
}
var o = new F('foo');
alert(o.x); //-> 'foo' (aka public x)
alert(o.getX()); //-> 'foo' (aka private x)
this.setX = function (y) {
x = y;
};
this.getX = function () {
return x;
};
this.x = x;
}
var o = new F('foo');
alert(o.x); //-> 'foo' (aka public x)
alert(o.getX()); //-> 'foo' (aka private x)
В любом случае, отрицание объектно-ориентированной сущности javascript (официально обозначенной, кстати, в стандарте ECMAScript) по той причине, что кто-то не может отыскать в нём классов и т.п. или не видит связи со своей любимой книжкой про С++ - это как узколобому js-программисту отрицать ту же сущность другого ОО-языка, не найдя там прототипов и делегирования... :)
Цитата: Nixus
Не совсем понял что имеется в виду, но нельзя в JS закрыть для произвольного кода доступ к произвольному члену объекта. Поэтому нет в JS инкапсуляции.
Да нет, есть. Есть глобальная зона видимости переменных, есть локальная зона видимости. Зоны есть, так что инкапсюляция вполне возможна.
Кстати. Вспомнилось, что уж есть строго подходить к определению ООП как это понимали изобретатели этой концепции, то на данный момент нет ни одного языка который можно было бы назвать ОО. Хоть один пункт из требований да не соблюдается. Даже где была по этому поводу статья, поискать что ли...
В общем думаю сойдемся на то, что JS все же ОО, но базирующийся на прототипах.
>>то на данный момент нет ни одного языка который можно было бы назвать ОО
Java, Ruby....
Java, Ruby....
Цитата: alekciy
Да нет, есть. Есть глобальная зона видимости переменных, есть локальная зона видимости. Зоны есть, так что инкапсюляция вполне возможна.
При чем здесь это? Строго говоря, зоны видимости в JS не существует, а существует цепочка поиска. Я не пойму как связано сокрытие членов и добавление объекта в цепочку поиска. Пример можно?
Цитата: Nixus
При чем здесь это? Строго говоря, зоны видимости в JS не существует, а существует цепочка поиска. Я не пойму как связано сокрытие членов и добавление объекта в цепочку поиска. Пример можно?
Смотря что ты понимаешь под "сокрытие членов" (хм... что есть член?) и "цепочка поиска".
Nixus, что тогда есть "зона видимости"?
Пример, который привел Zeroglif недостаточен?
Все локальные переменные в контексте конструктора, доступны для методов объекта, определенных в этом конструкторе, но не доступны извне.
Пример, который привел Zeroglif недостаточен?
Все локальные переменные в контексте конструктора, доступны для методов объекта, определенных в этом конструкторе, но не доступны извне.
Опять таки это член дургого объекта, сссылка на который связанна с 2-мя функциями. Но это не член этого объекта. Если так рассуждать, то можно даже в C найти сокрытие, полиморфизм и т.п.
Цитата: Zeroglif
...кто-то не может отыскать в нём классов и т.п. или не видит связи со своей любимой книжкой про С++...
Какой замечательный афоризм!!! Можно я буду цитировать его в дальнейшем (касательно "любимой книжки")?
Ладно, народ, заканчиваем флудить. Если кому-то хочется порасуждать о "что такое ООП" добро пожаловать в Гостевую книгу. Если у автора вопросов больше нет, то тему закрываем.
Ну вот, такой флейм испортили... :)