Автор так и не узнал видимо, что помимо бинстолка и фаргейта, контейнеры можно легко запускать просто на ЕС2. И ECS это поддерживает из коробки аж бегом, launch type = container instance
Если посмотреть исходники, то внезапно можно обнаружить, что move_uploaded_file пытается сделать ренейм и только в случае если ренейм сфейлился, то копи+анлинк.
Я даже кандидатам в джуниоры не задаю вопросов вроде echo vs print и т.п. Предвижу в ближайшее время наплыв выпускников славной академии Шаг и прочих компьютерных колледжей, почитавших сей славный мануал, и желающих $1k+ (Харьков).
Боюсь, что unset реализован неправильно — следуя этому интерфейсу, клиент будет ожидать, что кука удалится на клиенте после вызова unset.
Да, и кстати, — переписывать супеглобальные массивы — это плохо :)
Кстати, каюсь, сам по молодости грешил частым использованием синглтонов (до 14 конечно не доходило, но все же). Когда дело дошло до юнит-тестирования и TDD — мигом слез, и что самое главное, никаких проблем от не использования синглтонов до сих пор нет и. я уверен, не будет :)
Не соглашусь, насчет того, что DI аналогично цепочке вызовов — в случае автоматизированного DI это не так. Кроме того, можно использовать Service Locator. А реальных юз-кейсов для синглтона на самом деле очень мало.
Потому что применение синглтона в подавляющем большинстве случаев не оправдано и создает проблемы в виде хардовой зависимости и усложненного юнит-тестирования, хотя при этом может быть безболезненно использован тот же DI вместо синглтона.
Автор оригинального комментария, так и не смог сказать, зачем оно нужно на практике. Может быть Вы сможете? То, что оно работает в Java — это не показатель.
Ну вот, Вы сами замкнули круг :) Вы говорите, о ЯП, поддерживающих перегрузку методов. Но перегрузка методов не является неотлемъемой частью ООП. Небольшой хинт: в Smalltalk'е нет перегрузки методов.