@xmoonlight: GLSL всякий всеравно будет один и тот же примерно что для C что для JS. Писать логику игры на JS - норм. Но вот графический/физический/аудио движок - как по мне это извращение.
@vasIvas: вы не можете создать приватные методы и свойства, следовательно вы можете только добавлять какие-то символы вроде _ к именам методов и свойств. Именно это и не рекомендуется. Сокрыть состояние или методы можно закрыв их в своей области видимости к которой имеет доступ только методы объекта.
@AxisPod: ну как... если у нас есть 4 потока, которые пишут в буфер результат каких-то вычислений и 1 пото которые эти результаты считает и что-то делаешь с этим дальше... скажем вычисления длятся 100 микросекунд, запись в буфер - 1 микросекунду, переключение контекста - 100 микросекунд... чтение из буфера - так же 1 микросекунду или итого меньше. Так у нас 4 потока за 100 микросекунд посчитают свои результаты и потратят ~4 микросекунды на то что бы записать все в буфер. Причем поток-читатель может обратиться к разделяемому ресурсу, залочиться, и это приведет к каким-то микролагам...
Хороший пример - воспроизведение аудио. Скажем у нас есть пара потоков которые занимаются обработкой аудио для каждого канала, и есть поток который отправляет все это дело в буфер устройства вывода. Между ними кольцо с мютексами. В итоге у нас могут быть существенные лаги и счелчки при прослушивании аудио...
@themailvnk: я думаю вам не стоит юзать API которого в следующей версии PHP не будет. И да, mysql/mysqli это низкоуровневое API. Вам стоит использовать PDO как обертку а prepared statements исключат вероятность SQL инъекций.
Евгений Петров: Если вам нужно что бы функция не выполнялась если аргумент не реализует какие-то методы, то думаю лучше уж так. а try/catch не сильно удобнее выйдет. Да и в циклах производительность просядет.