Я читал о двух (относительно) новых концепциях в языке Javascript - Web Workers и потрясающем Processing.js Джона Резига (ну, на самом деле, это не совсем новая «концепция Javascript», но вы поняли мою идею). Несколько замечательных примеров того, как оба бродят по интернетам, но мне еще предстоит найти тот, который эффективно использует обе техники. Это выглядит довольно интересно и мощно для меня, поэтому я подумал, что мне лучше попробовать.
Тем не менее, я не могу придумать лучший дизайн сценария для интеграции двух из них ... Мне кажется, что обычно, когда используется Processing.js, некоторые классы определяются в «Обработка-заявка». Это позволяет вам использовать Java-подобный синтаксис для этого. Однако эти классы доступны только в приложении обработки - что очевидно. Но потом у нас есть работники ... В этом удивительном примере объект функции Javascript сначала определяется в отдельном сценарии, и, если желательно использование Worker, сценарий Worker импортирует прототип этого объекта и как бы "болтится" на него.
Мне эти два не кажутся «взаимозаменяемыми» в том смысле, что вы не можете получить доступ к классу, который вы определили в приложении для обработки, когда находитесь в своем рабочем сценарии. Вероятно, по какой-то причине, поскольку классы, подобные обработке, определенно не очень похожи на Javascript. Насколько я вижу, мне придется сделать аналогичное определение класса (в форме нового прототипа функции) в моем рабочем скрипте - что не очень хорошо для удобства сопровождения, и просто кажется ужасно плохим дизайном для меня, хотя я все еще большой новичок на эту тему.
Я что-то пропускаю? Хочу ли я чего-то, чего просто не должно быть? Или я просто неправильно понял некоторые фундаментальные понятия?
Спасибо за помощь!
Edit:
Продолжил пытаться связываться с прототипом Рабочего, чтобы «придать ему форму», как объект, для которого он должен работать, но вскоре понял, что это не тот путь.
Давайте попробуем наброски для работы с:
У меня есть класс «Ball», который почти ничего не делает, кроме хранения двумерной позиции. В каждом цикле draw() Processing.js вызывает свой метод update(), который заставляет мяч занять новую позицию. После этого вызывается метод display(), в котором Шар рисует маленький кружок в своей текущей позиции.
Ничего сложного для начала. Теперь предположим, что определение нового местоположения шара - довольно дорогая операция, например, если она включает движение шара через «сложное» гравитационное поле. Если этот расчет должен выполняться каждый раз перед рисованием, это вызовет некоторую задержку. Тем не менее, если вам удастся сделать это одновременно, он может пройти более плавно. Итак, я понял, что мог бы дать классу Ball дополнительный массив 'положений' в своем списке свойств, который будет содержать все его последовательные местоположения. Когда создается экземпляр Ball, он создает нового работника, который начинает вычислять позиции, и каждый раз, когда он завершает одну, он отправляет обратно на Ball сообщение, содержащее новую двумерную позицию. Затем Ball будет помещать этот элемент в свой массив позиций, поэтому каждый раз, когда ему нужно обновить свою позицию, он просто переходит к следующей записи в массиве.
В целом - хорошая или плохая идея? Если хорошо, какие-либо предложения о том, как спроектировать это?