Сейчас? Обратная совместимость, версионность и всё отсюда вытекающее. Тогда (имеется ввиду, когда принималось решение о синтаксисе) - сказать точно не могу. Есть, не скрою, фактор "исторически сложилось". Но в основном - это то, что касается неоднозначности перекрытия различных комбинаций (наподобие - статический член класса во вложенном неймспейсе, у которого есть статический метод. Или различные трюки с областями внутри классов и их наследников - решить при помощи приоритетов можно, но то, насколько это будет нечитаемо в подобных случаях - лучше даже не задумываться).
Использовать таблицу-связку и не записывать в одно поле несколько значений через разделитель. Тогда простой JOIN даст все нужные данные для INSERT..SELECT
Любое ПО с закрытым кодом может делать то же самое - ведь нет способа это проверить. Любое ПО с открытым кодом может делать то же самое - ведь не возможно проследить за всем (однако, конечно, ситуация в случае с открытым кодом намного более прозрачна). Ну и, самое главное, существует вероятность уязвимости самих алгоритмов. Например, генерация ключей с заведомо ослабленной сложностью. Это практически невозможно проверить без специального анализа (но и тот не даст 100% ответа "да" или "нет").
Вывод - можно сказать так - "вероятно, нас всех прослушивают". Что делать? Быть в курсе этого - максимум, что доступно. Либо же - писать свои программы (начиная с контроллеров процессоров и ОС). Ах да, нет гарантии, что сами процессоры (или любое другое оборудование) не содержат закладок. И вот там что-либо проверить уже практически невозможно, ведь в шутке "Что делается в процессорах Intel не знает даже Intel" есть доля правды. Конечно, не всё то процессоры, что Intel - но иллюстрация достаточна.
Потому что он сортирует по значению выражения "int=0". Это значение будет равно 1, если int в самом деле 0 (ведь 0=0) или 0, если int не равен 0 (поскольку всё, что угодно, кроме 0, не равно 0). Поэтому сначала будут идти строки, у которых значение выражения "int=0" равно 0 (то есть всё, где int не 0), затем те, у которых значение выражения "int=0" равно 1 (то есть все те, у которых int=0)
Смотря какую хочется написать книгу. И при этом многое зависит от того, на какую аудиторию она будет ориентирована, поскольку написать хорошую книгу для новичков - много сложнее, чем написать хорошую книгу для профессионалов: ведь для вторых будет, как правило, достаточно высокого уровня знаний в предметной области, тогда как для первых - нужен ещё и большой опыт (знания "плохих практик", равно как и хороших) - и умение понятно излагать, исходя из минимального уровня знаний читателя.
Я не стану говорить ничего против, ведь больше литературы - значит больше возможностей. И всякая книга, как правило, находит своего читателя. Поэтому- пожелаю удачи в начинании.
P.S. По моему мнению, моих собственных знаний сильно не хватает для написания хорошей книги.
Так некорректно делать, поскольку end лишь переводит внутренний указатель, она не возвращает массив. Но, если честно - использовать end в общем случае я бы не рекомендовал. Это, действительно, быстрый способ, однако если забыть о таком действии, то можно получить очень трудно уловимую ошибку, ведь при операциях с массивом внутренний указатель будет передвинут. Здесь - либо использовать reset, либо использовать вообще другой способ. При этом reset тоже плох в общем случае - ведь в контексте операции нахождения ключа может быть так, что происходит итерация какого-либо внешнего цикла, к примеру, так что нарушать позицию указателя будет неверным решением.
Безопасным (но не самым быстрым) способом будет уже упомянутая array_keys. Она плоха лишь тем, что создаёт новый массив для такой простой операции. В случае, если массив большой, это может вызвать проблемы.
Небольшая иллюстрация того, почему бездумно использовать end - плохо:
OrmaJever
В этом Вы не правы. Простое действие - гораздо сложнее, чем кажется. Больше можно прочесть здесь, но и это - далеко не полное объяснение имеющейся картины.
старые не опытные версии позволяли такой (class::test()) вызов для не статических методов.
Новые тоже позволяют. Дело другое, что всегда будет выдаваться предупреждение.
Завершится ли ошибкой такой вызов, или нет - зависит от того, использует ли не статический метод, вызванный как статический, обращение к контексту текущего объекта (то есть $this)