Но ведь выполнение программы это тоже чтение данных — исходного (или скомпилированного) кода. Он тоже должен искажаться при каждом чтении. Тогда будет совсем весело.
Хабр такой хабр. Вместо того, чтобы указать на ошибки, людей затроллили напрочь.
Ошибки следующие: не стоит заниматься скрытым пиаром, вроде как сервис вам просто понравился, а сами вы мимо проходили — читатели не такие тупые.
На первых порах развития сервиса не стоит любой ценой вытащить из проекта прибыль — если конечно вы не создаете проект-однодневку. Брать 2/3 от суммы взноса, не упоминая об этом; задавать изначальные минимальные цены выше среднерыночных и т. д. — плохо.
Ну и основное — любая «гениальная» идея для стартапа, кроме своей гениальности, должна быть тщательнейшим образом продумана от и до, чтобы не возникало очевидных вопросов насчет честности схемы у пользователей. А 90% идей нужно отбрасывать вовсе.
Метод slice копирует элементы массива и создает новый массив. Соответственно, тратятся ресурсы на ненужную операцию.
А кроссбраузерность не нужна — речь шла о серверном JS. На клиенте можно было бы, например, воспользоваться методом jQuery.makeArray (который работает примерно так же, как предложенный вами вариант).
Вообщем, пока я решил проблему хаком указанным выше, правильного варианта, по-видимому, не существует.
Таким образом, вы сделали массив из пустого объекта. А если имеется объект типа {0:'x', 1:'y'}, то его можно превратить в «почти-массив» таким кодом: obj.__proto__ = Array.prototype;
obj.length = <длина массива>; // Допустим, в нашей задаче она известна
И такой подход точно работает (неправильно отрабатывает конструкция типа for (var i in obj), но ее можно заменить методами forEach и т. д.
Есть ли способ проделать то же самое, не трогая свойство __proto__?
Как корректно поменять __proto__ объекта, чтобы превратить его в массив (серверный JS)? Такой код работает: a.__proto__=Array.prototype
Но вы говорите, что использовать его некорректно. Есть ли какой-нибудь корректный способ без копирования элементов массива?
Это было бы возможно, если бы в каждом коммите была некая запись, которая сохраняла название «оригинальной» ветки, в которой был совершен коммит. Такая запись влияла бы только на просмотр истории изменений. Интересно, почему разработчики так не сделали.
Кстати, одно из неудобных вещей в git, это то, что когда из master-ветки вливаются изменения в «функциональную» (как бы это ни было неправильно, это часто необходимо), потом просмотр истории коммитов «фукнциональной» ветки (например, в веб-интерфейсе) теряет смысл. Ибо он, действительно, представляет собой свалку несвязанных между собой коммитов. Я плохо знаю устройство git'а изнутри, поэтому не знаю возможно ли это, но было бы неплохо иметь возможно смотреть «чистую» историю ветки. То есть, чтобы показывались коммиты, совершенные только непосредственно в этой ветке.
Открываем ваш модуль, и сразу видим window.Visibility = {/*...*/}. То есть у меня уже забит глобальный объект Visibility и мне никуда от этого не деться. Я не смогу использоваться 2 модуля с одинаковым названием.
Как должно быть: модуль должен только лишь объявлять какой то объект, который я могу при желании импортировать в свой код, под произвольным именем и только после этого использовать. И для этого необходим какой-то стандартный механизм, чтобы каждый не изобретать что-то новое. Что-то подобное как раз и предлагается в «новом» явасрикпте.
Просто синтаксис задавания классов слишком фундаментален, что бы было куда его развивать. Оператор присваивания тоже был придуман много лет назад, и как-то до сих пор никто не решил от него отказаться.
А вот другие, более прикладные вещи, конечно надо развивать, более того, в JS многие вещи и развиты больше чем в других языках.
Ну jQuery лучше оставить как есть, ибо сейчас там в коде есть такие выкрутасы, которые традиционным ООП-языкам не снились и в страшном сне, и оттого она такая маленькая и производительная.
Но в более высокоуровневых модулях, на мой взгляд, подобное лучше не применять, чтоб каждый мог открыть исходники и сразу понять: вот это модуль, который отвечает за то-то, называется так-то. В нем есть 4 класса, каждый из которых отвечает за то-то и то-то.
Да есть там ООП. Просто способов описания «классов» слишком много. И их код выглядит как-то не очень, они больше похоже на хаки… Поэтому я и предлагаю остановится на одном очевидном способе, который зарекомендовал себя в всех Явах, Сях++, Питонах и т. д.
>>Переписывать ничего не надо — в нём можно так же легко использовать JS код.
Чем больше языков используется в проекте, тем сложней его поддерживать. Пусть даже один из них компилируется в другой.
А можно запихивать функции внутрь других функций. А можно писать в JSDoc'е перед ними /** @private */. А можно писать комментарий вначале — «не трогать!». В том то и проблема, что все делают по разному, а хочется, чтоб везде все было одинаково. Просто и понятно.
Ну так и исходник jQuery для неподготовленного человека практически не читаем. Далеко не все поймут, где там какие функции куда запихиваются, и что где происходит. А если бы код выглядел, например, как описание класса jQuery-коллекции в традиционном синтаксисе, то все было бы просто и понятно с первого взгляда.
Ошибки следующие: не стоит заниматься скрытым пиаром, вроде как сервис вам просто понравился, а сами вы мимо проходили — читатели не такие тупые.
На первых порах развития сервиса не стоит любой ценой вытащить из проекта прибыль — если конечно вы не создаете проект-однодневку. Брать 2/3 от суммы взноса, не упоминая об этом; задавать изначальные минимальные цены выше среднерыночных и т. д. — плохо.
Ну и основное — любая «гениальная» идея для стартапа, кроме своей гениальности, должна быть тщательнейшим образом продумана от и до, чтобы не возникало очевидных вопросов насчет честности схемы у пользователей. А 90% идей нужно отбрасывать вовсе.
А кроссбраузерность не нужна — речь шла о серверном JS. На клиенте можно было бы, например, воспользоваться методом jQuery.makeArray (который работает примерно так же, как предложенный вами вариант).
Вообщем, пока я решил проблему хаком указанным выше, правильного варианта, по-видимому, не существует.
{0:'x', 1:'y'}, то его можно превратить в «почти-массив» таким кодом:obj.__proto__ = Array.prototype;
obj.length = <длина массива>; // Допустим, в нашей задаче она известна
И такой подход точно работает (неправильно отрабатывает конструкция типа
for (var i in obj), но ее можно заменить методами forEach и т. д.Есть ли способ проделать то же самое, не трогая свойство __proto__?
a.__proto__=Array.prototypeНо вы говорите, что использовать его некорректно. Есть ли какой-нибудь корректный способ без копирования элементов массива?
window.Visibility = {/*...*/}. То есть у меня уже забит глобальный объект Visibility и мне никуда от этого не деться. Я не смогу использоваться 2 модуля с одинаковым названием.Как должно быть: модуль должен только лишь объявлять какой то объект, который я могу при желании импортировать в свой код, под произвольным именем и только после этого использовать. И для этого необходим какой-то стандартный механизм, чтобы каждый не изобретать что-то новое. Что-то подобное как раз и предлагается в «новом» явасрикпте.
А вот другие, более прикладные вещи, конечно надо развивать, более того, в JS многие вещи и развиты больше чем в других языках.
Но в более высокоуровневых модулях, на мой взгляд, подобное лучше не применять, чтоб каждый мог открыть исходники и сразу понять: вот это модуль, который отвечает за то-то, называется так-то. В нем есть 4 класса, каждый из которых отвечает за то-то и то-то.
Чем больше языков используется в проекте, тем сложней его поддерживать. Пусть даже один из них компилируется в другой.