Не понимаю я вас, вы сами выше написали «Мифическая невозможность сигнатурного матчинга в данном случае не аргумент, поскольку… (а) и (б)» из этого предложения мною и был сделан вывод о том что реализация этого все же возможна.
> Смысл?
Не знаю. Но это был вопрос к возможности определения требуемой сигнатуры без полноценного type hinting-а.
> Для этого есть олдскульные проверки is_*.
Есть чуть менее олдскульный оператор instanceof.
> Тут же все ратуют за ООП. В данный момент (и этого более чем достаточно) PHP поддерживает специфицирование параметра классом или признаком кортежа. Этого чуть более, чем достаточно.
Только цель у этого сейчас совсем другая.
Что касается классической перегрузки методов, то сомневаюсь что в языках с динамической типизацией в ней есть практический смысл.
> а) PHP поддерживает уточнение типизации при вызове методов
Ну, я конечно, надеюсь, что когда нибудь можно будет использовать скалярные типы, но в данный момент это не так.
> б) даже если предыдущий пункт чем-то смущает вас, то есть мнение, что сигнатуры при динамической типизации не требуют спецификации типов.
Интересное мнение, и как, простите, определить, что Test::test($a) требуется параметр типа int, а Test::test($b) типа string?
> Поменяйте параметр «длина» у функции.
Вы не поняли, я про тот случай когда нужно преобразовать строку в массив символов, сейчас единственный способ это сделать — использование регеспов. Разве не костыль?
> А вы предлагаете всем пользователям принудительно докупить памяти.
Это все слова, как я понимаю, статистики по увеличению потребления памяти у вас нет? (у меня нет)
> А вы попробуйте
Нет, спасибо.
Если сами пробовали может быть поделитесь результатами?
> $second_utf8_symbol
А если нужен 10 символов? Или все символы в строке? Регекспы нам помогут?
Я бы предпочел нативную поддержку [].
> А теперь давайте подумаем
1) Почему именно должны? неужели нет ни одной альтернативы?
2) Не верю что это нельзя оптимизировать. Кэширование байткода разве не решает проблему?
3) В данном временном промежутке это не проблема (память копейки стоит), в тоже время вы упускаете тот факт, что всякие костыли типа регекпов для получения массивов символов также требую памяти и времени.
4) Ничего не придется переписывать, проблемы могут быть только в том, случае, если вы решитесь обновить древний скрипт работающий на древней версии PHP да еще и сохранённый в CP1251. Вот только зачем ему современные плюшки?
В нормальных скриптах разницы не будет, ибо mb_* останется и продолжить работать как раньше, а str* или все также будут перекрываться mbstring.func_overload или начнут нормально работать и без этой настройки.
Единственная проблема которая может возникнуть это определение кодировки самого скрипта, но и она могла бы решиться или глобальной настройкой или указанием кодировки в нем самом.
5) Браузер посылает данные в той же кодировке что и станица (у форм, кстати, есть атрибут accept-charset), про скрипты см. выше, вывод — отдельная настройка, БД все равно нужно указывать. Не вижу здесь каких либо серьезных проблем.
> Вот и приходим мы к тому, что толком это никому не нужно.
OpenSource, реализуется в первую очередь то, что хотят сами разработчики языка или за что им платят, поэтому данное высказывание не корректно, и, ИМХО, многим пишущим на PHP это нужно, другое дело, что за прошедшее время каждый из них уже реализовал необходимые функции (=костыли).
Вдогонку, наткнулся на старую презентацию: «Unicode & PHP6» (http://www.slideshare.net/kfish/unicode-php6-presentation), там есть решения некоторых проблем. Да и ранее достаточно активно велась работа на юникодом, текущую печальную ситуацию кто-то описывал на в одном из комментариев к какой-то статье, найти, к сожалению, так и не смог.
Хотя бы то, что не нужно будет задумываться о том как называется та или иная функция, кроме того не для всех функций есть соответствующий аналог. Реальный пример — как вы сейчас получаете символ с определенной позицией из строки в UTF-8?
Я вообще к тому, что не нужно все насильно конвертировать в исключения — не опасные ошибки (STRICT, DEPRECATED) разумнее игнорировать (= складывать куда нибудь для последующего исправления).
Вы бы предыдущий комментарий перечитали внимательно, тогда, возможно вам стало бы понятно, что в случае «когда все ошибки являются исключениями» (т.е. всё превращаем в исключения) вызов любого deprecated метода и последующий E_DEPRECATED делает все приложение неработоспособным.
> Я считаю наиболее правильным, когда *все ошибки* являются исключениями.
Вы это клиенту объясните, особенно когда у него после обновления версии PHP появится несколько E_DEPRECATED и сайт станет полностью неработоспособным.
> Без нотисов писать ведь очень просто.
Не все об этом знают.
> «Не так выведено» — тоже может быть огромной ошибкой.
А это как раз тот самый маловероятный случай. Хотя при разработке подобного приложения необходимо нормальное тестирование, оно то и должно было выявить отсутствующий пункт.
@deprecated можно использовать, но это больше для чужого кода — при обновлении велик шанс пропустить несколько устаревших методов, и вот тут, выброшенный нотис будет очень кстати.
> Поэтому нужно остановить приложение и насколько это возможно быстро исправить эту ПРОБЛЕМУ.
Как правило, в случае нотиса эта «ПРОБЛЕМА» не настолько огромная чтобы останавливать все приложение, ИМХО, лучше дать ему отработать, а вот после исправить все, что вылезло (я про сервер разработки).
Если рассматривать шаблоны, то там нотис говорит о том, что где-то что-то пропущено (== будет выведено не так как нужно), какие либо серьезные проблемы маловероятны.
К огромному сожалению не все разработчики придерживаются мнения что нотис это ошибка, и поэтому со спокойной совестью их игнорируют. Яркий пример — IP.Board, печально наблюдать за десятками нотисов на каждой странице…
> Приведите пример, где еще может понадобиться явно вызывать trigger_error вместо того, чтобы бросать эксепшены.
1) При обращении к несуществующим свойствам/методам класса при использовании __* — здорово помогает при обнаружении опечаток.
2) Предупредить о том, что метод устарел (resurection, чуть выше об этом уже сказал)
> И как потом эти внесенные изменения потом перенести в вашу рабочую копию?
Будет 2 рабочие копии, основанные на одной ревизии: (1) основная, (2) фикс. Коммитим (2), обновляем (1), коммитим (1), удаляем (2), если не нужен.
> Я говорю о ситуации (довольно стандартной для git), когда разработчик разрабатывает фичу в отдельной ветке, чтобы не засорять develop или master ветки.
В этом случае у него просто будет 2 рабочих копии (или больше если фич много). В конечном счете они все вольются в trunk и, возможно, будут удалены из репозитория. Неудобно, если фич много, но часто ли один разработчик параллельно разрабатывает много фич? ИМХО, 2-3-4 рабочих копии вполне нормально.
> В таком случае ваш план выглядит именно как извращение — ради правки в другой ветке создавать отдельную рабочую копию.
Нет, не извращение — особенность. Я ведь тоже могу сказать, что полностью извлекать себе весь репозиторий ради исправления одной строки в одном файле — это извращение…
С одной стороны, с другой — предостерегает от ошибок, т.к. приходится явно указывать что именно нужно. Удалив директории и создав новую с таким же названием — неизвестно что именно вы хотели сделать — удалить (разорвать историю) и создать новую или просто заменить существующие файлы. Именно поэтому это поведение мне кажется логичным.
Возможно, в 1.7 что-то поменялось в этом плане (не смотрел).
Если сервер лежит при этом (невозможно сделать checkout), то просто скопирую рабочую копию, откачу в ней все изменения, и внесу нужные исправления.
> «извращения»
Скорее особенности, но основной смысл в том, что и с svn можно некоторое время работать без связи с сервером.
Для мелких изменений (поправить один файл) в svn создавать отдельную глобальную ветку нецелесообразно, гораздо проще ограничиться еще одной рабочей копией (в этом случае её можно сравнить с локальными ветками в гите).
Физическое удаление директории не означает её удаления из репозиториия — поэтому все действия над файлами/директориями в svn очень желательно производить с помощью соответствующих команд, тогда и проблем не будет.
Это просто одна из особенностей, к которой достаточно быстро привыкаешь.
ИМХО, логичное поведение, т.к. по сути директория и не была удалена из репозитория, поэтому:
1) создайте папку, киньте в нее несколько файлов, закомитьте;
2) удалите папку, закомитьте;
3) создайте новую с тем же именем, накидайте в нее других файлов, закомитьте;
Непонятно только зачем так делать? Почему не удалить все файлы и не добавить новые в существующую директорию?
> Смысл?
Не знаю. Но это был вопрос к возможности определения требуемой сигнатуры без полноценного type hinting-а.
> Для этого есть олдскульные проверки is_*.
Есть чуть менее олдскульный оператор instanceof.
> Тут же все ратуют за ООП. В данный момент (и этого более чем достаточно) PHP поддерживает специфицирование параметра классом или признаком кортежа. Этого чуть более, чем достаточно.
Только цель у этого сейчас совсем другая.
Что касается классической перегрузки методов, то сомневаюсь что в языках с динамической типизацией в ней есть практический смысл.
Ну, я конечно, надеюсь, что когда нибудь можно будет использовать скалярные типы, но в данный момент это не так.
> б) даже если предыдущий пункт чем-то смущает вас, то есть мнение, что сигнатуры при динамической типизации не требуют спецификации типов.
Интересное мнение, и как, простите, определить, что Test::test($a) требуется параметр типа int, а Test::test($b) типа string?
Вы не поняли, я про тот случай когда нужно преобразовать строку в массив символов, сейчас единственный способ это сделать — использование регеспов. Разве не костыль?
> А вы предлагаете всем пользователям принудительно докупить памяти.
Это все слова, как я понимаю, статистики по увеличению потребления памяти у вас нет? (у меня нет)
> А вы попробуйте
Нет, спасибо.
Если сами пробовали может быть поделитесь результатами?
А если нужен 10 символов? Или все символы в строке? Регекспы нам помогут?
Я бы предпочел нативную поддержку [].
> А теперь давайте подумаем
1) Почему именно должны? неужели нет ни одной альтернативы?
2) Не верю что это нельзя оптимизировать. Кэширование байткода разве не решает проблему?
3) В данном временном промежутке это не проблема (память копейки стоит), в тоже время вы упускаете тот факт, что всякие костыли типа регекпов для получения массивов символов также требую памяти и времени.
4) Ничего не придется переписывать, проблемы могут быть только в том, случае, если вы решитесь обновить древний скрипт работающий на древней версии PHP да еще и сохранённый в CP1251. Вот только зачем ему современные плюшки?
В нормальных скриптах разницы не будет, ибо mb_* останется и продолжить работать как раньше, а str* или все также будут перекрываться mbstring.func_overload или начнут нормально работать и без этой настройки.
Единственная проблема которая может возникнуть это определение кодировки самого скрипта, но и она могла бы решиться или глобальной настройкой или указанием кодировки в нем самом.
5) Браузер посылает данные в той же кодировке что и станица (у форм, кстати, есть атрибут accept-charset), про скрипты см. выше, вывод — отдельная настройка, БД все равно нужно указывать. Не вижу здесь каких либо серьезных проблем.
> Вот и приходим мы к тому, что толком это никому не нужно.
OpenSource, реализуется в первую очередь то, что хотят сами разработчики языка или за что им платят, поэтому данное высказывание не корректно, и, ИМХО, многим пишущим на PHP это нужно, другое дело, что за прошедшее время каждый из них уже реализовал необходимые функции (=костыли).
Вдогонку, наткнулся на старую презентацию: «Unicode & PHP6» (http://www.slideshare.net/kfish/unicode-php6-presentation), там есть решения некоторых проблем. Да и ранее достаточно активно велась работа на юникодом, текущую печальную ситуацию кто-то описывал на в одном из комментариев к какой-то статье, найти, к сожалению, так и не смог.
Вы это клиенту объясните, особенно когда у него после обновления версии PHP появится несколько E_DEPRECATED и сайт станет полностью неработоспособным.
Не все об этом знают.
> «Не так выведено» — тоже может быть огромной ошибкой.
А это как раз тот самый маловероятный случай. Хотя при разработке подобного приложения необходимо нормальное тестирование, оно то и должно было выявить отсутствующий пункт.
Как правило, в случае нотиса эта «ПРОБЛЕМА» не настолько огромная чтобы останавливать все приложение, ИМХО, лучше дать ему отработать, а вот после исправить все, что вылезло (я про сервер разработки).
Если рассматривать шаблоны, то там нотис говорит о том, что где-то что-то пропущено (== будет выведено не так как нужно), какие либо серьезные проблемы маловероятны.
К огромному сожалению не все разработчики придерживаются мнения что нотис это ошибка, и поэтому со спокойной совестью их игнорируют. Яркий пример — IP.Board, печально наблюдать за десятками нотисов на каждой странице…
1) При обращении к несуществующим свойствам/методам класса при использовании __* — здорово помогает при обнаружении опечаток.
2) Предупредить о том, что метод устарел (resurection, чуть выше об этом уже сказал)
Будет 2 рабочие копии, основанные на одной ревизии: (1) основная, (2) фикс. Коммитим (2), обновляем (1), коммитим (1), удаляем (2), если не нужен.
> Я говорю о ситуации (довольно стандартной для git), когда разработчик разрабатывает фичу в отдельной ветке, чтобы не засорять develop или master ветки.
В этом случае у него просто будет 2 рабочих копии (или больше если фич много). В конечном счете они все вольются в trunk и, возможно, будут удалены из репозитория. Неудобно, если фич много, но часто ли один разработчик параллельно разрабатывает много фич? ИМХО, 2-3-4 рабочих копии вполне нормально.
> В таком случае ваш план выглядит именно как извращение — ради правки в другой ветке создавать отдельную рабочую копию.
Нет, не извращение — особенность. Я ведь тоже могу сказать, что полностью извлекать себе весь репозиторий ради исправления одной строки в одном файле — это извращение…
Возможно, в 1.7 что-то поменялось в этом плане (не смотрел).
> «извращения»
Скорее особенности, но основной смысл в том, что и с svn можно некоторое время работать без связи с сервером.
Для мелких изменений (поправить один файл) в svn создавать отдельную глобальную ветку нецелесообразно, гораздо проще ограничиться еще одной рабочей копией (в этом случае её можно сравнить с локальными ветками в гите).
Это просто одна из особенностей, к которой достаточно быстро привыкаешь.
Создам еще одну рабочую копию.
> И это могут быть несколько красивых коммитов
В svn это может быть несколько рабочих копий => несколько коммитов (менее удобно, но все же).
1) создайте папку, киньте в нее несколько файлов, закомитьте;
2) удалите папку, закомитьте;
3) создайте новую с тем же именем, накидайте в нее других файлов, закомитьте;
Непонятно только зачем так делать? Почему не удалить все файлы и не добавить новые в существующую директорию?