> А вообще, нужно к питону присмотреться повнимательнее, хотя, без практического применения будет сложновато =(
да, одной из причин, в виду которых мне понравился Питон, была схожесть с JS (в отличии от того же PHP, например): делегирующая модель наследования (хотя в Питоне это названо «классом», а не «прототипом» — см. примеры выше — если абстрагироваться от технической реализации — практически полное сходство с JS (или наоборот — JS с Питоном)); замыкания (хотя в PHP 5.3 они тоже появились); mutable-объекты; и т. д.
Поэтому, я думаю, сложностей не будет.
> Это я к тому, что он не станет стандартом-«языком браузеров», как JS (из-за IE в первую очередь)
да ну не о стандартах я говорю =) я сам только сегодня узнал, что Питон уже давно Gecko'вцами поддерживается (хотя написано, что в Мозилле с версии 1.9 вообще появился). Ссылки были лишь на свой же комментарий из Википедии о «Python + JS» (но я не думаю, что «Python vs. JS» ;)). А вот что будет — посмотрим =) В конце концов, в Мозилла фаундэшн тоже-таки не идиоты сидят.
подожди, что-то я не нашел четкого определения «штрих» (дай ссылку, пожалуйста)
> примеси — довольно глупая концепция разделения методов и данных
> штрихи — примеси без состояния
вообще, в определении примеси как раз говорится, о том, что состояние (данные) определены в классе, а поведение (методы) подмешиваются. В первой цитате ты называешь это глупой концепцией, а во второй определяешь «штрих» определением «примесь». Или я не правильно понял?
> что наследование и инкапсулящия противоречат друг другу
ну, не обязательно, для это и сделали оговорки в виде «public / protected / private»; и где-то (опять — тот же Питон) это соглашение осуществляется на уровне именования переменных.
> наследование — распространённая, но не слишком удачная схема реюзинга кода, порождающая жёсткую зависимость внутренней структуры потомков от внутренней структуры родителя
ну, да — альтернатива — примеси и агрегация; а можно даже и совмещать — что мешает унаследовать общую структуру, агрегировать еще двух «родителей», плюс к этому подмешать еще три объекта? =)
да ну, бросьте, я еще и не начал заводится (и не горю желанием, и думаю, надобности нет) =)
Мне просто показалось, что Вы несколько… эмм… =) — поддерживаете чьи-то слова, при этом процент собственных мыслей по этому вопросу у Вас меньше (сказал, настолько корректно, насколько мог ;)) (ну а иначе — к чему подобные утверждения («Гуру JS не используют искусственное натягивание чужеродной парадигмы», «гуру JS… радуется, что ES4 обломался»), написанные от третьего лица, а не от Вашего?)
гуру сам за себя отвечает, а вот Вам — (Вы тоже гуру?) — лично Вам, чем понравился облом ES4? :) Только, пожалуйста, обоснованно, а не минусами =) И Вы ничего не ответили на мои ответы по поводу Ваших высказываний о «гуру и --чужеродных-- парадигмах»
> Python — серверный язык
> JavaScript — язык браузера
Все это, возможно, — *пока*; JavaScript и на данный момент — достаточно мощный язык; и тот факт, что основное его применение пока реализуется в песочнице в виде браузера, не означает, что он не найдет более серьезного применения в дальнейшем, нежели onmouseover/onmouseout =) — к тому же, для меня JS (как и для многих, уверен, в этом блоге) — это не только визуальные эффекты. И более того, тот же XUL использует JS, в Java встроен JS-интерпретатор Rhino.
Кстати, в статье о JS в Википедии есть забавная цитата:
JavaScript в данный момент полностью занимает нишу браузерных языков. Несмотря на то, что по слухам некоторые разработчики браузеров встраивают (или уже встроили) в дополнение к JavaScript-у такой язык как Python, для динамического изменения веб-страниц на стороне клиента, официальной информации по этому вопросу нет.
=) тоже не знаю, на сколько это правда (так — слухи), но тут обратная ситуация, которую Вы описали — Питон может стать «языком браузеров».
> Как я понял — он возник после PHP, Perl и всего такого
ну Перл-то понятно — появился раньше (1987), а вот PHP и JS (1995) — позже Python'a (1990).
> Даже его нет — есть jQuery
А про фреймворки — это вообще отдельный разговор, я уже упоминал не раз, что фреймворк может помочь не только с преодолением рутины, но и в (возможно) равной степени с отупением.
о! =) и еще одно проверил в Python (я его знаю пока на среднем уровне, поэтому новое что-то узнавать всегда приятно):
> он же конструктор, может тихо издохнуть, и это никак не скажется на цепи прототипов объекта, где и производится поиск
class A: pass
a = A()
# видим, что и класс "А" и инстанс "а" присутствуют в глобальном объекте
print globals() # вернет объект, где свойства - все глобальные переменные
# расширим класс через инстанс
a.__class__.b = 10
print a.b # 10
# а теперь класс "тихо издыхает"
del globals()['A']
# проверим
print globals() # "A" - исчез
# однако, ествественно, не исчез сам объект класса
print a.__class__ # <class __main__.A at 0x00E243F0>
# т.е. исчезла *лишь ссылка на объект-класс*
# аналогия с JS - конструктор издох (который в
# этом плане служил ссылкой на прототип),
# но объект-инстанс имеет связь с классом
a.__class__.c = 20
a.c # 20
А вот создать новый инстанс класса "А" уже не получится (ссылки нет):
b = A() # .error
>> > B.superClass.prototype.constructor.call(this, arguments);
> Масло масляное, есть же уже ссылка на нужный конструктор.
Ы )) естественно =) это я просто, чтобы показать, как вызвать другие методы родительского класса, конструктор же можно было вызвать — B.superClass.apply(this, arguments);
> Основная роль конструктора — связать новый объект с прототипом и его (объект) вернуть
да, Zeroglif, это я знаю, именно поэтому цепь прототипов — implicit, а не явная — объект имеет доступ к прототипу через нужный слот (в одной из реализации — __proto__; кстати, все в том же Python это свойство называется __class__ — и обращаясь из объекта-инстанса можно так же, как и в JS расширить класс (прототип) — «obj.__class__.new_method = lambda self, x: x + 1» — новый метод, который будет доступен всем уже существующим инстансам и последующим), и конструктор смотрит на прототип через свой слот (prototype) — понятно, что конструктор может издохнуть.
Я всего лишь проводил абстрактную аналогию, чтобы показать, что классы — это не только С++.
> Победить это возможно строгим терминологически лаконичным разбором происходящего, что сделать очень непросто…
да, и это тоже верно — только вот там концов не сыщешь — откуда какая терминлогия пошла (так, примеру, (и я не знаю, кто писал эту статью) в Википедии в разделе Python написано (справа сверху) — «оказал влияние на:… Ruby, Boo, Groovy, *ECMAScript*» — я не знаю, насколько это может быть правдой, хотя — почему нет?)
> 50
а, да, пардон — но это просто опечатки (я не тестировал; копи-паст)
Ну я не думаю, что наличии статических Java-классов — признак того, что язык стал для «программистов», а не для «разработчиков интерфейсов и дизайнеров» =) Мне видится это заблуждением.
Возьмем, к примеру, Python (а конкретно, — его построение классов; — это для тех, кто любит придраться к словам и начнет мне сейчас говорить — «нашел, что сравнивать — Питон и JS!» — повторю — только лишь *абстрактно* — работу классов в Питоне). Так вот — абстрагируемся от технической реализации (хотя, там так же налицо — делегация — если свойство не найдено в родном объекте, его поиск продолжается в цепи классов (цепи прототипов конструкторов в JS)):
Py:
# создали класс A, присвоили инстанс-свойству «а» значение 10 (__init__ — играет роль «конструктора»)
class A(object):
def __init__(self):
self.a = 10
JS:
// аналог на JS (вместо понятия «класс» — функция-конструктор)
function A() {
this.a = 10;
}
Py:
# класс B, наследуемый от А, self-свойство «b» = 20
class B(A): # наследование
def __init__(self):
self.b = 20
A.__init__(self)
JS:
// аналог на JS
function B() {
this.b = 20;
B.superClass.prototype.constructor.call(this, arguments);
}
// наследование (имеем возможность достучаться через цепь прототипов до нужного свойства)
var __inheritance = function() {};
__inheritance.prototype = A.prototype;
B.prototype = new __inheritance();
B.prototype.constructor = B;
B.superClass = A; // явная ссылка на «А» для вызова родительских методов
Расширяем класс в Питоне и прототип конструктора в JS новым слотом:
A.c = 30 # Py:
A.prototype.c = 30 // JS:
Свойство посредством делегирования (во всяком случае в JS) доступно через конструкцию «роднойОбъект.свойство»
print obj.c # Py: 30
alert(obj.c) // JS: 30
Добавляем новые родные свойства:
obj.d = 40 # Py: 40
obj.d = 50 // JS: 40
Добавляем свойство с таким же именем в класс (Питон) и прототип конструктора (JS) — на сей раз — «B»:
B.d = 70
B.prototype.d = 70
Пока берется родное «d»:
print obj.d # Py: 40
alert(obj.d) // JS: 30
Удаляем:
del obj.d #Py:
delete obj.d // JS:
А вот теперь — снова за счет делегирования из класса (прототипа конструктора):
print obj.d # Py: 70
alert(obj.d) // JS: 70
Так вот, Covex, скажите мне — разве Питон не язык «программистов»? В нем, как Вы видите, нет Java-классов.
А для тех, кто при выходе очередной статьи про «*оболочки* в виде классов в JS» не ленится каждый раз написать — «зачем классы?! это вам не С++!», скажите мне — где в примерах выше вы увидели С++? Тем не менее, приводились тоже классы. И, в виду того, что мы абстрагировались, визуальная разница — это наследование:
Py: class B(A):
JS:
var __inheritance = function() {};
__inheritance.prototype = A.prototype;
B.prototype = new __inheritance();
B.prototype.constructor = B;
B.superClass = A; // явная ссылка на «А» для вызова родительских методов
И вот, чтобы не писать каждый раз эту длинную конструкцию, люди делают свои обертки и называют их «классами», и, во всяком случае я, в этот момент не думают ни о каких классах из С++. Для меня это просто обертка, я знаю, что что бы я ни написал — внутри будет — *prototype-based inheritance*.
Да что вы все привязались — «чужеродная парадигма, чужеродная парадигма! классы не нужны!» =) и что с того, что на данный момент в JS только делегирующая прототипная модель наследования? — ну нравится человеку называть свою обертку «классами». Ведь по сути, использует-то он для реализации этой обертки все ту же делегирующую к прототипам конструкторов модель. И не важно, как он это называет — Class, _class, moyaUdobnayaObyortkaDlyaPrototypnogoNasledovaniya или еще как — *суть не меняетя*! Главное, — что человек понимает, *что* он пишет *и для чего*.
[.quote: «#Zork 25 сентября 2008, 16:43 „]
> А чем мешает прототипное наследование? Оно же, как бы язык то другой, парадигма как бы тоже другая, зачем с++ опять городить?
Так все и используют *единственное* prototype-based inheretance (другого нет), просто называют свои обертки, как им удобно.
Другое дело (и вот это, действительно, очень жаль), когда человек может нести всякий бред, говоря: я выучил JS по Prototype.js (или jQuery/Mootools/Ext — не важно) и при этом еще может начать яро доказывать, что в JS есть классы (т.к. Class.create() =))
А еще жаль, когда человек ведется на подобные классы в виду недостаточного количества информации, часто даже не признавая механизм протоипного наследования альтернативой классовому — вот в этом случае подобные статьи могут сыграть не положительную роль.
P.S. ES4 (JS2), к сожалению (или к счастью =)) обломался, так что классов пока не будет :( Но ведь их планировали. Хотя они были бы похожи на классы из Руби и Питона (динамическая часть классов, т.к. планировались еще и неизменяемые, как в C++). Да, вот хороший пример — Питон — там есть классы, но там так же можно динамически менять слоты класса (аналогия — смена слотов в протоипе конструктора в JS) и слоты порожденного инстанса (как и в JS).
> Профессионализм в капиталистическом обществе — штука хитрая, не знаниями едиными и килобайтами прочитанного/написанного текста/кода она достигается
ну, для потребителей, желающих лишь быстро срубить бабла, «профессионализм» может быть выражен и не «в килобайтах прочитанного», а копи-пастом с сайта django (при этом, подобные скрипт-кидисы будут аристократично придерживаться терминологии «быдло-кодер» и т.д. =)). Есть категория профессионалов — чисто разработчиков-теоретиков (которые строят системы, структуры, паттерны и т.д., которые потом, в свою очередь, будут использовать «профессионалы-потребители», цель которых часто лишь очень прагматична — «срубить бабла, и чтобы при этом надо было одну строчку написать» — и нельзя сказать, что эта цель плоха, нет — умение поймать момент (возможно, пустив пыль в глаза, не имея знаний) — тоже своего рода «профессионализм», но, я уверен, что люди с глубокой теоретической базой всегда будут шагов на 100 впереди и все эти определения «быдло-кодер», «малолетний хабразадрот» и т.д. будут восприниматься лишь с саркастической улыбкой =)
Конечно, реальный опыт никак не равен опыту в годах (т.е. продолжительность фильма != содержание фильма, а важно именно содержание).
P.S.: знал я одного человека, который не ленился похвастаться своим 8-летним опытом в области web-программирования =) — на деле же — это быдло-кодер (да-да — со всеми вытекающими — кашеобразный код и т.д.), который научился что-то там 8 лет назад и до сих пор применяет свои устаревшие тактики.
P.S.[2]: автор, статья интересная, и примеры на реальных велосипедах — тоже в тему =)
P.S.[3]: однако, в любом случае (это автора не касается), тот, кто яро призывает не изобретать велосипеды — потребитель. Ведь, задачи, как были разделены на два больших условных раздела, так и остаются разделенными: 1. «задачи на инструментарий» (написание языков программирования, сред, фреймворков, виджетов и т.д.) и «задачи на данные (повседневные, прикладные)». И ясно-понятно, что для выполнения первых нужны более глубокие знания, больший опыт, и (возможно) больший «полет фантазии» (ну, мы ж изобретаем, а не потреблям, поэтому творческая фантазия тут очень важна =)) И, естественно, работа первых оплачивается больше — это справедливо. И именно эта группа пионеров и изобретателей задает направление. Если все будут только потреблять готовые велосипеды — вернемся в пещеры есть сырое мясо.
P.S.[3]: а в правильном использовании фреймворков (устранение рутины, поручение «неблагодарной работы по генерации кода» машине) — тоже прогрессивное дело (однако, фреймворки разработатывают те же обычные люди, они так же ходят на работу, им за это платят деньги, они так же, порой, пишут всякий бред в своем коде, который потом ярые почетатели (потребители) этого фреймворка с пеной у рта выдают за уникальную особенность их любимого творения, тогда как хочется уже носом ткнуть в спецификацию языка и сказать: «Да посмотри же ты! Как ты можешь отстаивать этот бред?! Люди ошиблись, а ты — »мой любимый jQuery-мой любимый jQuery!« (кстати, ничего против jQuery не имею против — просто пришло на ум; хотя — в том же jQuery — есть ну такие бредовые куски кода, что просто вырезай и выкладывай в раздел юмора) „) — и тут уже видно, что, посмотрев в спецификацию, человек понимает, что слегка вообще не в теме =)
Поэтому, действительно, искать нужно всегда знания. Все эти локальные беды (“фу! ты пишешь на пхп? былокодер!» — «ты пишешь на рельсах? — респект!») — только лишь от незнания. А как человек получает эти знания — изобретая ли свой велосипед или анализируюя (и синтезируя) существющие — это уже второстепенный вопрос.
недоказуемый субъективизм (локальная привычка к синтаксису). Повторю, никто не отрицает if'ы — я как раз за них (в случае, если условий больше одного). Однако, a = a || true; — прозрачно, чисто и красиво (кстати, я прекрасно осознаю, что и мое утверждение — тоже локальный субъективизм, но я в отличии от Вас не позволяю себя навязывающе утверждать)
> не имеет смысла
на нет — и суда нет, только в таком случае к фразам типа «Ужаснее подхода не встречал.» добавляйте магическое слово «ИМХО» — тем самым Ваше мнение не будет утверждающим, а лишь предполагающим.
ах да, при этом я, естественно, не отрицаю if'ы, сокращенные конструкции я использую лишь для одиночных условий (дальше, уже, действительно, может начаться каша — поэтому — все в меру надо!)
да, одной из причин, в виду которых мне понравился Питон, была схожесть с JS (в отличии от того же PHP, например): делегирующая модель наследования (хотя в Питоне это названо «классом», а не «прототипом» — см. примеры выше — если абстрагироваться от технической реализации — практически полное сходство с JS (или наоборот — JS с Питоном)); замыкания (хотя в PHP 5.3 они тоже появились); mutable-объекты; и т. д.
Поэтому, я думаю, сложностей не будет.
> Это я к тому, что он не станет стандартом-«языком браузеров», как JS (из-за IE в первую очередь)
да ну не о стандартах я говорю =) я сам только сегодня узнал, что Питон уже давно Gecko'вцами поддерживается (хотя написано, что в Мозилле с версии 1.9 вообще появился). Ссылки были лишь на свой же комментарий из Википедии о «Python + JS» (но я не думаю, что «Python vs. JS» ;)). А вот что будет — посмотрим =) В конце концов, в Мозилла фаундэшн тоже-таки не идиоты сидят.
> примеси — довольно глупая концепция разделения методов и данных
> штрихи — примеси без состояния
вообще, в определении примеси как раз говорится, о том, что состояние (данные) определены в классе, а поведение (методы) подмешиваются. В первой цитате ты называешь это глупой концепцией, а во второй определяешь «штрих» определением «примесь». Или я не правильно понял?
> Питон может стать «языком браузеров».
developer.mozilla.org/en/Python
developer.mozilla.org/en/PyDOM
а что за штрихи?
ну, не обязательно, для это и сделали оговорки в виде «public / protected / private»; и где-то (опять — тот же Питон) это соглашение осуществляется на уровне именования переменных.
> наследование — распространённая, но не слишком удачная схема реюзинга кода, порождающая жёсткую зависимость внутренней структуры потомков от внутренней структуры родителя
ну, да — альтернатива — примеси и агрегация; а можно даже и совмещать — что мешает унаследовать общую структуру, агрегировать еще двух «родителей», плюс к этому подмешать еще три объекта? =)
да ну, бросьте, я еще и не начал заводится (и не горю желанием, и думаю, надобности нет) =)
Мне просто показалось, что Вы несколько… эмм… =) — поддерживаете чьи-то слова, при этом процент собственных мыслей по этому вопросу у Вас меньше (сказал, настолько корректно, насколько мог ;)) (ну а иначе — к чему подобные утверждения («Гуру JS не используют искусственное натягивание чужеродной парадигмы», «гуру JS… радуется, что ES4 обломался»), написанные от третьего лица, а не от Вашего?)
> По поводу Ваших ответов — слишком много букаф
ах… пардон, вопрос исчерпан.
> JavaScript — язык браузера
Все это, возможно, — *пока*; JavaScript и на данный момент — достаточно мощный язык; и тот факт, что основное его применение пока реализуется в песочнице в виде браузера, не означает, что он не найдет более серьезного применения в дальнейшем, нежели onmouseover/onmouseout =) — к тому же, для меня JS (как и для многих, уверен, в этом блоге) — это не только визуальные эффекты. И более того, тот же XUL использует JS, в Java встроен JS-интерпретатор Rhino.
Кстати, в статье о JS в Википедии есть забавная цитата:
=) тоже не знаю, на сколько это правда (так — слухи), но тут обратная ситуация, которую Вы описали — Питон может стать «языком браузеров».
> Как я понял — он возник после PHP, Perl и всего такого
ну Перл-то понятно — появился раньше (1987), а вот PHP и JS (1995) — позже Python'a (1990).
> Даже его нет — есть jQuery
А про фреймворки — это вообще отдельный разговор, я уже упоминал не раз, что фреймворк может помочь не только с преодолением рутины, но и в (возможно) равной степени с отупением.
> он же конструктор, может тихо издохнуть, и это никак не скажется на цепи прототипов объекта, где и производится поиск
class A: pass a = A() # видим, что и класс "А" и инстанс "а" присутствуют в глобальном объекте print globals() # вернет объект, где свойства - все глобальные переменные # расширим класс через инстанс a.__class__.b = 10 print a.b # 10 # а теперь класс "тихо издыхает" del globals()['A'] # проверим print globals() # "A" - исчез # однако, ествественно, не исчез сам объект класса print a.__class__ # <class __main__.A at 0x00E243F0> # т.е. исчезла *лишь ссылка на объект-класс* # аналогия с JS - конструктор издох (который в # этом плане служил ссылкой на прототип), # но объект-инстанс имеет связь с классом a.__class__.c = 20 a.c # 20 А вот создать новый инстанс класса "А" уже не получится (ссылки нет): b = A() # .error> Масло масляное, есть же уже ссылка на нужный конструктор.
Ы )) естественно =) это я просто, чтобы показать, как вызвать другие методы родительского класса, конструктор же можно было вызвать — B.superClass.apply(this, arguments);
да, Zeroglif, это я знаю, именно поэтому цепь прототипов — implicit, а не явная — объект имеет доступ к прототипу через нужный слот (в одной из реализации — __proto__; кстати, все в том же Python это свойство называется __class__ — и обращаясь из объекта-инстанса можно так же, как и в JS расширить класс (прототип) — «obj.__class__.new_method = lambda self, x: x + 1» — новый метод, который будет доступен всем уже существующим инстансам и последующим), и конструктор смотрит на прототип через свой слот (prototype) — понятно, что конструктор может издохнуть.
Я всего лишь проводил абстрактную аналогию, чтобы показать, что классы — это не только С++.
> Победить это возможно строгим терминологически лаконичным разбором происходящего, что сделать очень непросто…
да, и это тоже верно — только вот там концов не сыщешь — откуда какая терминлогия пошла (так, примеру, (и я не знаю, кто писал эту статью) в Википедии в разделе Python написано (справа сверху) — «оказал влияние на:… Ruby, Boo, Groovy, *ECMAScript*» — я не знаю, насколько это может быть правдой, хотя — почему нет?)
> 50
а, да, пардон — но это просто опечатки (я не тестировал; копи-паст)
Возьмем, к примеру, Python (а конкретно, — его построение классов; — это для тех, кто любит придраться к словам и начнет мне сейчас говорить — «нашел, что сравнивать — Питон и JS!» — повторю — только лишь *абстрактно* — работу классов в Питоне). Так вот — абстрагируемся от технической реализации (хотя, там так же налицо — делегация — если свойство не найдено в родном объекте, его поиск продолжается в цепи классов (цепи прототипов конструкторов в JS)):
Py:
# создали класс A, присвоили инстанс-свойству «а» значение 10 (__init__ — играет роль «конструктора»)
class A(object):
def __init__(self):
self.a = 10
JS:
// аналог на JS (вместо понятия «класс» — функция-конструктор)
function A() {
this.a = 10;
}
Py:
# класс B, наследуемый от А, self-свойство «b» = 20
class B(A): # наследование
def __init__(self):
self.b = 20
A.__init__(self)
JS:
// аналог на JS
function B() {
this.b = 20;
B.superClass.prototype.constructor.call(this, arguments);
}
// наследование (имеем возможность достучаться через цепь прототипов до нужного свойства)
var __inheritance = function() {};
__inheritance.prototype = A.prototype;
B.prototype = new __inheritance();
B.prototype.constructor = B;
B.superClass = A; // явная ссылка на «А» для вызова родительских методов
Далее, объекты-инстансы:
obj = B() # Py:
var obj = new B() // JS:
print obj.a, obj.b # 10, 20 — self-свойства
alert([obj.a, obj.b]) // 10, 20 — this-свойства
Расширяем класс в Питоне и прототип конструктора в JS новым слотом:
A.c = 30 # Py:
A.prototype.c = 30 // JS:
Свойство посредством делегирования (во всяком случае в JS) доступно через конструкцию «роднойОбъект.свойство»
print obj.c # Py: 30
alert(obj.c) // JS: 30
Добавляем новые родные свойства:
obj.d = 40 # Py: 40
obj.d = 50 // JS: 40
Добавляем свойство с таким же именем в класс (Питон) и прототип конструктора (JS) — на сей раз — «B»:
B.d = 70
B.prototype.d = 70
Пока берется родное «d»:
print obj.d # Py: 40
alert(obj.d) // JS: 30
Удаляем:
del obj.d #Py:
delete obj.d // JS:
А вот теперь — снова за счет делегирования из класса (прототипа конструктора):
print obj.d # Py: 70
alert(obj.d) // JS: 70
Так вот, Covex, скажите мне — разве Питон не язык «программистов»? В нем, как Вы видите, нет Java-классов.
А для тех, кто при выходе очередной статьи про «*оболочки* в виде классов в JS» не ленится каждый раз написать — «зачем классы?! это вам не С++!», скажите мне — где в примерах выше вы увидели С++? Тем не менее, приводились тоже классы. И, в виду того, что мы абстрагировались, визуальная разница — это наследование:
Py: class B(A):
JS:
var __inheritance = function() {};
__inheritance.prototype = A.prototype;
B.prototype = new __inheritance();
B.prototype.constructor = B;
B.superClass = A; // явная ссылка на «А» для вызова родительских методов
И вот, чтобы не писать каждый раз эту длинную конструкцию, люди делают свои обертки и называют их «классами», и, во всяком случае я, в этот момент не думают ни о каких классах из С++. Для меня это просто обертка, я знаю, что что бы я ни написал — внутри будет — *prototype-based inheritance*.
пожалуй ) Вы как в воду глядели, когда у себя в блоге на винграде в теме «ECMA-разборок» надеялись, что что-нибудь не срастется в ES4 =)
[.quote: «#Zork 25 сентября 2008, 16:43 „]
> А чем мешает прототипное наследование? Оно же, как бы язык то другой, парадигма как бы тоже другая, зачем с++ опять городить?
Так все и используют *единственное* prototype-based inheretance (другого нет), просто называют свои обертки, как им удобно.
Другое дело (и вот это, действительно, очень жаль), когда человек может нести всякий бред, говоря: я выучил JS по Prototype.js (или jQuery/Mootools/Ext — не важно) и при этом еще может начать яро доказывать, что в JS есть классы (т.к. Class.create() =))
А еще жаль, когда человек ведется на подобные классы в виду недостаточного количества информации, часто даже не признавая механизм протоипного наследования альтернативой классовому — вот в этом случае подобные статьи могут сыграть не положительную роль.
P.S. ES4 (JS2), к сожалению (или к счастью =)) обломался, так что классов пока не будет :( Но ведь их планировали. Хотя они были бы похожи на классы из Руби и Питона (динамическая часть классов, т.к. планировались еще и неизменяемые, как в C++). Да, вот хороший пример — Питон — там есть классы, но там так же можно динамически менять слоты класса (аналогия — смена слотов в протоипе конструктора в JS) и слоты порожденного инстанса (как и в JS).
ну, для потребителей, желающих лишь быстро срубить бабла, «профессионализм» может быть выражен и не «в килобайтах прочитанного», а копи-пастом с сайта django (при этом, подобные скрипт-кидисы будут аристократично придерживаться терминологии «быдло-кодер» и т.д. =)). Есть категория профессионалов — чисто разработчиков-теоретиков (которые строят системы, структуры, паттерны и т.д., которые потом, в свою очередь, будут использовать «профессионалы-потребители», цель которых часто лишь очень прагматична — «срубить бабла, и чтобы при этом надо было одну строчку написать» — и нельзя сказать, что эта цель плоха, нет — умение поймать момент (возможно, пустив пыль в глаза, не имея знаний) — тоже своего рода «профессионализм», но, я уверен, что люди с глубокой теоретической базой всегда будут шагов на 100 впереди и все эти определения «быдло-кодер», «малолетний хабразадрот» и т.д. будут восприниматься лишь с саркастической улыбкой =)
> вот только не все их них нужны на деле
а вот это уже крайне субъективно — у кого-то деятельность научная и изобретательная, у кого-то — прикладная на основе этих изобретений
P.S.: знал я одного человека, который не ленился похвастаться своим 8-летним опытом в области web-программирования =) — на деле же — это быдло-кодер (да-да — со всеми вытекающими — кашеобразный код и т.д.), который научился что-то там 8 лет назад и до сих пор применяет свои устаревшие тактики.
P.S.[2]: автор, статья интересная, и примеры на реальных велосипедах — тоже в тему =)
P.S.[3]: однако, в любом случае (это автора не касается), тот, кто яро призывает не изобретать велосипеды — потребитель. Ведь, задачи, как были разделены на два больших условных раздела, так и остаются разделенными: 1. «задачи на инструментарий» (написание языков программирования, сред, фреймворков, виджетов и т.д.) и «задачи на данные (повседневные, прикладные)». И ясно-понятно, что для выполнения первых нужны более глубокие знания, больший опыт, и (возможно) больший «полет фантазии» (ну, мы ж изобретаем, а не потреблям, поэтому творческая фантазия тут очень важна =)) И, естественно, работа первых оплачивается больше — это справедливо. И именно эта группа пионеров и изобретателей задает направление. Если все будут только потреблять готовые велосипеды — вернемся в пещеры есть сырое мясо.
P.S.[3]: а в правильном использовании фреймворков (устранение рутины, поручение «неблагодарной работы по генерации кода» машине) — тоже прогрессивное дело (однако, фреймворки разработатывают те же обычные люди, они так же ходят на работу, им за это платят деньги, они так же, порой, пишут всякий бред в своем коде, который потом ярые почетатели (потребители) этого фреймворка с пеной у рта выдают за уникальную особенность их любимого творения, тогда как хочется уже носом ткнуть в спецификацию языка и сказать: «Да посмотри же ты! Как ты можешь отстаивать этот бред?! Люди ошиблись, а ты — »мой любимый jQuery-мой любимый jQuery!« (кстати, ничего против jQuery не имею против — просто пришло на ум; хотя — в том же jQuery — есть ну такие бредовые куски кода, что просто вырезай и выкладывай в раздел юмора) „) — и тут уже видно, что, посмотрев в спецификацию, человек понимает, что слегка вообще не в теме =)
Поэтому, действительно, искать нужно всегда знания. Все эти локальные беды (“фу! ты пишешь на пхп? былокодер!» — «ты пишешь на рельсах? — респект!») — только лишь от незнания. А как человек получает эти знания — изобретая ли свой велосипед или анализируюя (и синтезируя) существющие — это уже второстепенный вопрос.
недоказуемый субъективизм (локальная привычка к синтаксису). Повторю, никто не отрицает if'ы — я как раз за них (в случае, если условий больше одного). Однако, a = a || true; — прозрачно, чисто и красиво (кстати, я прекрасно осознаю, что и мое утверждение — тоже локальный субъективизм, но я в отличии от Вас не позволяю себя навязывающе утверждать)
> не имеет смысла
на нет — и суда нет, только в таком случае к фразам типа «Ужаснее подхода не встречал.» добавляйте магическое слово «ИМХО» — тем самым Ваше мнение не будет утверждающим, а лишь предполагающим.