Почитал немного сырцы, нашел коммент к функции reduce (выше него в коде идет функция map)
<bloсkquote>
* Passes every element of an array into a function and accumulates the result.
* We're google; we can't have «map» without «reduce» can we?
</bloсkquote>
ну а как вы думаете, качественно расписанная идея, где подробно и на пальцах объяснено что это такое, как это работает и как будет выглядеть (с эскизами), с четким описанием сроков на реализацию — чем-то принципиально отличается от прототипа?
обычно, если все сделано правильно, превращение первого во второе — вопрос 1-2 месяцев и разумных финансовых вложений
другой вопрос, конечно, если инвестор завален заявками на инвестиции от команд, предоставивших готовые прототипы сразу — он на концепты может и не смотреть.
> Лично мне как концептологу порой хочется плюнуть в лицо тем, кто говорит что идея (как я её понимаю) не стоит ничего.
Идея как ее понимает большинство — действительно практически ничего не стоит. Потому что это обычно идея вида «а давайте сделаем свой facebook, только чтобы там еще поиск как у гугла, и видео, и блэкджэк, и ...».
Идея как ее понимаете вы (т.е. в виде проработанного ТЗ + очень желательно бизнес-план) — стоит примерно 50% рисков. Потому что на этапе принятия решения об инвестировании (или просто о запуске проекта) денег еще никаких нет — есть только риски.
Если есть только идея первого вида — то риски инвестора примерно 99%. И 1% — риски автора. Потому что инвестор должен вложить все, а автор еще не вложил ничего (просто идея в голову стукнула). Именно поэтому такой разрыв в понимании этими сторонами друг друга.
Идея второго рода, как я уже говорил, стоит примерно 50% (ну или 30-70%) рисков. Потому что автор рискует, тратя время на проработку идеи, которая может и не выстрелить. Порой значительное время.
Но тем самым значительно снижает риски инвестора. И инвестор это ценит.
Уважаемые авторы идей. Если вы думаете, что инвестор работает с идеями — вы ошибаетесь. Инвестор работает в сфере рисков и финансов. Его интересует одно — найти оптимальное сочетание возможной выгоды и возможных рисков.
Если вы сами не можете пойти на риск (проработать идею бесплатно), то не ждите, что кто-то пойдет вам навстречу.
В краткосрочной перспективе — да.
В долгосрочной — уровень оплаты вашего часа примерно одинаков (т.к. зависит от квалификации, а не от конкретного заказчика), поэтому нет особой разницы в деньгах, «тянуть» один проект 40 часов, или нормально сделать 2 по 20. Наоборот, во втором случае плюс в том, что растет кол-во сделанных проектов, рейтинг, ну и экспа для прокачивания скиллов разработчика :)
Это уже откровенное хамство. Может хватит обвинять меня в том, что я не делал?
Фразу про «экономию на слове this при доступе к свойствам в методах» вы уже столько раз процитировали, как будто она вообще единственная и ключевая в статье. Хотя этот момент упомянут вообще вскользь, с ремаркой «также к плюсам можно отнести».
Ваше упорство в приписывании мне утверждений, которых я не делал, и в мастерском опровержении их же наводит на мысль, что у вас слишком много свободного времени или вы просто тролль.
Меня как пользователя не интересует абсолютная скорость выполнения, меня интересует визуально заметная задержка.
Если приложение, написанное на ASM выполняется 5мс, а на C++ за 25мс — то и хрен с ним, несмотря на то, что разница пятикратная, на глаз она не заметна.
Вот если оно выполняется 250мс — это уже как-то не хорошо.
Я знаю, как писать быстрые приложение на высокоуровневых языках (по крайней мере на тех, которыми владею), и частью этого знания как раз поделился в статье.
Я, например, как IT-шник знаю, что процессор моего компьютера имеет тактовую частоту в несколько (2-3 в среднем) Ггц, что приблизительно означает выполнение нескольких миллиардов операций в секунду.
Как пользователь ПК, я желаю, чтобы реакция на все мои рядовые действия (не связанные с расчетом мат. моделей турбулентности, 3D сцен и т.д.) была мгновенной, что означает задержку не более 100мс в худшем случае. Я не хочу тратить свое личное время (которое невозможно вернуть назад ни за какие деньги) на ожидание окончания процессов в железяке.
Если создатели приложений, которыми я пользуюсь, ради своих архитектурных изысков накидывают на эту задержку ничем не обоснованные 200, 500 или 1000мс — я начинаю вспоминать разные нехорошие слова.
> Это вопрос эффективности реализации JS, имхо, а не языка как такового. Кстати, JIT вполне может помочь в этом вопросе.
Вопрос эффективности реализации JS в различных браузерах — это один из ключевых вопросов при разработке клиентских приложений под веб, в текущих реалиях. Супер красивый и логичный внутри, но приводящий к 0.5-1 секундным подвисаниям на каком-нибудь нетбуке код — нафиг никому не нужен.
> если конструктор объекта возвращает (любой) другой объект — то this-объект, созданный конструктором, теряется.
> Работает, только если то что мы возвращаем — уже объект.
я бы ответил чего-нибудь, но нифига не понял смысла этой метафоры с банкоматом :)
> есть я, банкомат и деньги.
ок — 3 разных сущности.
>зачем мне обращаться к банкомату и авторизовываться, не легче ли мне просто взять деньги?
здесь не понял, это ирония или реальный вопрос? конечно надо авторизоваться, вставлять карту и вводить ПИН — иначе как деньги-то получить?
> а) мои знания о системе ограничиваются банкоматом б) деньги инкапсулированы в банкомате
вы когда-нибудь сталкивались с тем, что деньги в банкомате закончились? причем он еще не всегда об этом сообщает в явном виде.
такой живой пример бага в «сокрытии реализации»
Ну мы же сейчас говорим про JS, верно?
И раз в нем другие умные дяди не сделали нативных возможностей для сокрытия свойств, стоит ли туда это тащить самостоятельно?
Насчет «не надо задумываться как они там работают» — это, имхо, скорее разрекламированный идеал, чем объективная реальность. Я когда класс ZipArchive хотел использовать, тоже думал, что задумываться не надо. Оказалось что надо, потому что скрипт тупо валился при создании архива из папки с кол-вом файлов больше тысячи. Выяснилось что это такая бага zlib, скудно описанная где-то в заросших мхом багрепортах.
А вы говорите — «не надо задумываться», «сокрытие реализации».
Нет, ничего там не приводится. Работает, только если то что мы возвращаем — уже объект. Попробуйте что-то типа: var foo = function(){this.b = 5; return 6;}
var o = new foo();
alert(o.b);
В любом случае в данном примере ретурны лишние (если их убрать, ничего не поменяется, т.к. возвращается тот же самый объект).
> если объект может делать do1 и do2, то зачем любому другому объекту, которому только do1 и do2 нужны, иметь возможность смотреть doWith и вызвать validateWith
видимо мы друг друга не поймем.
Объекты — они не живые, и даже не ИИ, это просто области в памяти, созданные кусками кода. Если не хотите, чтобы какой-то объект вызывал validateWith другого объекта — так не вызывайте, просто не пишите это в коде (ну или договоритесь с коллегами, чтобы они так не писали). Это не так сложно (договориться), как может показаться.
Логика взаимоотношений объектов — не самоцель, а лишь инструмент для выполнения задачи (которую можно и в процедурном ключе решить тоже, да, при желании).
У вас там во-первых два лишних return: «return Private(this, new Foo(x))» — потому что return в конструкторе вообще игнорируется, достаточно написать просто «Private(this, new Foo(x))», и в связи с этим «return pub» в функции Private (мы и так работаем с объектом pub по ссылке, возвращать его нет нужды).
А во-вторых, получается смена шила на мыло: вместо дублирования самих методов в объектах имеем кучу оберток в этих же самых объектах (которые тоже жрут память и на создание которых тоже расходуется время), плюс к тому дополнительный оверхед при дальнейшем вызове методов.
Особо торкающим побочным эффектом является то, что мы можем иметь в таком «как бы объекте» (который состоит из двух других) два свойства priv_x — публичное и приватное одновременно, причем они естественно будут независимы друг от друга, так как по факту принадлежат разным инстансам. По человечески очень жаль программиста, которому придется отлаживать такой код (и которому сходу никто не будет объяснять, как именно этот велосипед работает).
> Вы считаете, что единственный смысл инкапсуляции — скрыть значение переменной?
Нет, я так не считаю, и в общем-то именно поэтому данная статья и написана.
Возможность гарантированно запретить доступ к внутреннему свойству объекта напрямую — как раз основная цель эмулирования приватных свойств тем способом, недостатки которого я здесь расмматриваю.
Если же осознанно применять инкапсуляцию для уменьшения связи между объектами, то нет никакой нужды что-то скрывать принудительно — это все равно что запрещать себе использовать, например, буквы «n» и «p» в названиях функций, ради следования определенной концепции )
<bloсkquote>
* Passes every element of an array into a function and accumulates the result.
* We're google; we can't have «map» without «reduce» can we?
</bloсkquote>
Поржал :)
обычно, если все сделано правильно, превращение первого во второе — вопрос 1-2 месяцев и разумных финансовых вложений
другой вопрос, конечно, если инвестор завален заявками на инвестиции от команд, предоставивших готовые прототипы сразу — он на концепты может и не смотреть.
Идея как ее понимает большинство — действительно практически ничего не стоит. Потому что это обычно идея вида «а давайте сделаем свой facebook, только чтобы там еще поиск как у гугла, и видео, и блэкджэк, и ...».
Идея как ее понимаете вы (т.е. в виде проработанного ТЗ + очень желательно бизнес-план) — стоит примерно 50% рисков. Потому что на этапе принятия решения об инвестировании (или просто о запуске проекта) денег еще никаких нет — есть только риски.
Если есть только идея первого вида — то риски инвестора примерно 99%. И 1% — риски автора. Потому что инвестор должен вложить все, а автор еще не вложил ничего (просто идея в голову стукнула). Именно поэтому такой разрыв в понимании этими сторонами друг друга.
Идея второго рода, как я уже говорил, стоит примерно 50% (ну или 30-70%) рисков. Потому что автор рискует, тратя время на проработку идеи, которая может и не выстрелить. Порой значительное время.
Но тем самым значительно снижает риски инвестора. И инвестор это ценит.
Уважаемые авторы идей. Если вы думаете, что инвестор работает с идеями — вы ошибаетесь. Инвестор работает в сфере рисков и финансов. Его интересует одно — найти оптимальное сочетание возможной выгоды и возможных рисков.
Если вы сами не можете пойти на риск (проработать идею бесплатно), то не ждите, что кто-то пойдет вам навстречу.
В долгосрочной — уровень оплаты вашего часа примерно одинаков (т.к. зависит от квалификации, а не от конкретного заказчика), поэтому нет особой разницы в деньгах, «тянуть» один проект 40 часов, или нормально сделать 2 по 20. Наоборот, во втором случае плюс в том, что растет кол-во сделанных проектов, рейтинг, ну и экспа для прокачивания скиллов разработчика :)
Фразу про «экономию на слове this при доступе к свойствам в методах» вы уже столько раз процитировали, как будто она вообще единственная и ключевая в статье. Хотя этот момент упомянут вообще вскользь, с ремаркой «также к плюсам можно отнести».
Я хоть где-то (в статье или комментах) писал, что инкапсуляция (как концепция, а не в рамках JS) — это плохо и ее придумали злые дяди?
Напротив, я несколько раз черным по белому написал, что я так не считаю.
Вам кстати желаю того же — пишите на чем хотите, с использованием любых конструкций и парадигм. Не слушайте всяких дураков вроде меня.
Если приложение, написанное на ASM выполняется 5мс, а на C++ за 25мс — то и хрен с ним, несмотря на то, что разница пятикратная, на глаз она не заметна.
Вот если оно выполняется 250мс — это уже как-то не хорошо.
Я знаю, как писать быстрые приложение на высокоуровневых языках (по крайней мере на тех, которыми владею), и частью этого знания как раз поделился в статье.
Как пользователь ПК, я желаю, чтобы реакция на все мои рядовые действия (не связанные с расчетом мат. моделей турбулентности, 3D сцен и т.д.) была мгновенной, что означает задержку не более 100мс в худшем случае. Я не хочу тратить свое личное время (которое невозможно вернуть назад ни за какие деньги) на ожидание окончания процессов в железяке.
Если создатели приложений, которыми я пользуюсь, ради своих архитектурных изысков накидывают на эту задержку ничем не обоснованные 200, 500 или 1000мс — я начинаю вспоминать разные нехорошие слова.
Вопрос эффективности реализации JS в различных браузерах — это один из ключевых вопросов при разработке клиентских приложений под веб, в текущих реалиях. Супер красивый и логичный внутри, но приводящий к 0.5-1 секундным подвисаниям на каком-нибудь нетбуке код — нафиг никому не нужен.
Вот, взгляните, статистика по использованию браузеров www.liveinternet.ru/stat/ru/browsers.html?period=week
IE 6-8 в сумме по-прежнему держит более трети рынка. О какой JIT может идти речь?
> Работает, только если то что мы возвращаем — уже объект.
По моему эти фразы аналогичны :)
> есть я, банкомат и деньги.
ок — 3 разных сущности.
>зачем мне обращаться к банкомату и авторизовываться, не легче ли мне просто взять деньги?
здесь не понял, это ирония или реальный вопрос? конечно надо авторизоваться, вставлять карту и вводить ПИН — иначе как деньги-то получить?
> а) мои знания о системе ограничиваются банкоматом б) деньги инкапсулированы в банкомате
вы когда-нибудь сталкивались с тем, что деньги в банкомате закончились? причем он еще не всегда об этом сообщает в явном виде.
такой живой пример бага в «сокрытии реализации»
И раз в нем другие умные дяди не сделали нативных возможностей для сокрытия свойств, стоит ли туда это тащить самостоятельно?
Насчет «не надо задумываться как они там работают» — это, имхо, скорее разрекламированный идеал, чем объективная реальность. Я когда класс ZipArchive хотел использовать, тоже думал, что задумываться не надо. Оказалось что надо, потому что скрипт тупо валился при создании архива из папки с кол-вом файлов больше тысячи. Выяснилось что это такая бага zlib, скудно описанная где-то в заросших мхом багрепортах.
А вы говорите — «не надо задумываться», «сокрытие реализации».
var foo = function(){this.b = 5; return 6;}
var o = new foo();
alert(o.b);
В любом случае в данном примере ретурны лишние (если их убрать, ничего не поменяется, т.к. возвращается тот же самый объект).
видимо мы друг друга не поймем.
Объекты — они не живые, и даже не ИИ, это просто области в памяти, созданные кусками кода. Если не хотите, чтобы какой-то объект вызывал validateWith другого объекта — так не вызывайте, просто не пишите это в коде (ну или договоритесь с коллегами, чтобы они так не писали). Это не так сложно (договориться), как может показаться.
Логика взаимоотношений объектов — не самоцель, а лишь инструмент для выполнения задачи (которую можно и в процедурном ключе решить тоже, да, при желании).
У вас там во-первых два лишних return: «return Private(this, new Foo(x))» — потому что return в конструкторе вообще игнорируется, достаточно написать просто «Private(this, new Foo(x))», и в связи с этим «return pub» в функции Private (мы и так работаем с объектом pub по ссылке, возвращать его нет нужды).
А во-вторых, получается смена шила на мыло: вместо дублирования самих методов в объектах имеем кучу оберток в этих же самых объектах (которые тоже жрут память и на создание которых тоже расходуется время), плюс к тому дополнительный оверхед при дальнейшем вызове методов.
Особо торкающим побочным эффектом является то, что мы можем иметь в таком «как бы объекте» (который состоит из двух других) два свойства priv_x — публичное и приватное одновременно, причем они естественно будут независимы друг от друга, так как по факту принадлежат разным инстансам. По человечески очень жаль программиста, которому придется отлаживать такой код (и которому сходу никто не будет объяснять, как именно этот велосипед работает).
Нет, я так не считаю, и в общем-то именно поэтому данная статья и написана.
Возможность гарантированно запретить доступ к внутреннему свойству объекта напрямую — как раз основная цель эмулирования приватных свойств тем способом, недостатки которого я здесь расмматриваю.
Если же осознанно применять инкапсуляцию для уменьшения связи между объектами, то нет никакой нужды что-то скрывать принудительно — это все равно что запрещать себе использовать, например, буквы «n» и «p» в названиях функций, ради следования определенной концепции )
Вот, можно почитать мнение автора ООП на этот счет — http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en.
Есть там интересные пассажи, вроде этого
хотел сказать «реализация инкапсуляции»