Comments 13
Экспоненциальный оператор? Мне всегда казалось, что это называется «возведение в степень», а экспонента — это когда в основании степени е.
„экспоненциально умножающий числа“ — это шедевр.
Unicode в планах хоть есть?
Больших проблем и так нет.
Был. Эдак где-то в году 2006-ом… А если серьёзно, то забудьте про юникод в ядре и почитайте статью habrahabr.ru/post/138269/
Чем вас не устраивает использование UTF-8 повсеместно? Не понимаю, что плохого если все методы будут явно использовать ByteArray в виде UTF-8?
Кстати говоря взгляните сколько проблем с Unicode появилось в Python? А неумение пользоваться этим ставит надежность и необходимость применения под сомнение.
Хотя сложно представить где действительно нужен UNICODE. Приведите пожалуйста конкретные проблемы где не обойтись и как внедрение UNICODE решило бы проблему?
Кстати говоря взгляните сколько проблем с Unicode появилось в Python? А неумение пользоваться этим ставит надежность и необходимость применения под сомнение.
Хотя сложно представить где действительно нужен UNICODE. Приведите пожалуйста конкретные проблемы где не обойтись и как внедрение UNICODE решило бы проблему?
Эм… а где unicode не нужен? Данные в базе хранятся обычно в нем, клиенту так же в нем отдаются. Следовательно весь код обрабатывающий данные работает с юникодом так или иначе. Другой вопрос, что это не нужно делать на уровне ядра, и мне сложно придумать задачи при которых поддержки юникода в php не хватает. Регулярки замечательно с ним работают, для всего остального есть mb_string. Вообще в большей части приложения что-то сложное делать с текстами не приходится, так что опять же проблемы нету.
> Данные в базе хранятся обычно в нем, клиенту так же в нем отдаются.
Как хранятся данные в базе данных мы с вами не знаем (по хорошему внутри движка СУБД это как-то «хитро» реализовано), но вот получаем мы их в виде массива символов кодированных в UTF-8 (не путайте UNICODE и данные в кодированном виде).
Клиенту мы отправляем так же данные кодированные в виде UTF-8.
Таким образом мы еще не разу не столкнулись напрямую с обработкой данных в UNICODE. Которая вероятно где-то скрыта внутри вашей бизнес логики.
А теперь внимание вопрос, а какие сложные операции по работе со UNICODE есть в вашей бизнес логике? Подстановка, количество элементов? Вы сами отвечаете на вопрос, что нет особой проблемы в использовании регулярных выражений и mb_ функций.
> Вообще в большей части приложения что-то сложное делать с текстами не приходится, так что опять же проблемы нету.
То есть я вижу в очередной раз «шум» и главное даже приходиться расплачиваться за этот «шум» вполне конкретной кармой,
но конкретики почему и зачем нужна мифическая поддержка данной возможности я пока не понимаю. Очень хочу наконец-то разобраться.
P.S. На случай же когда речь идет о невозможности использовать строки на уровне приложения в удобном ООП стиле, так
кто мешает создать класс Unicode и реализовать в нем все чего вам не хватает? Появиться ваша собственная прослойка для работы
с Unicode.
Как хранятся данные в базе данных мы с вами не знаем (по хорошему внутри движка СУБД это как-то «хитро» реализовано), но вот получаем мы их в виде массива символов кодированных в UTF-8 (не путайте UNICODE и данные в кодированном виде).
Клиенту мы отправляем так же данные кодированные в виде UTF-8.
Таким образом мы еще не разу не столкнулись напрямую с обработкой данных в UNICODE. Которая вероятно где-то скрыта внутри вашей бизнес логики.
А теперь внимание вопрос, а какие сложные операции по работе со UNICODE есть в вашей бизнес логике? Подстановка, количество элементов? Вы сами отвечаете на вопрос, что нет особой проблемы в использовании регулярных выражений и mb_ функций.
> Вообще в большей части приложения что-то сложное делать с текстами не приходится, так что опять же проблемы нету.
То есть я вижу в очередной раз «шум» и главное даже приходиться расплачиваться за этот «шум» вполне конкретной кармой,
но конкретики почему и зачем нужна мифическая поддержка данной возможности я пока не понимаю. Очень хочу наконец-то разобраться.
P.S. На случай же когда речь идет о невозможности использовать строки на уровне приложения в удобном ООП стиле, так
кто мешает создать класс Unicode и реализовать в нем все чего вам не хватает? Появиться ваша собственная прослойка для работы
с Unicode.
Я ничего и не спрашивал собственно. Вы видимо меня не поняли, я интересовался больше «а что php сейчас не может такого делать что столько шума»? Опять же я указал что для подавляющего большинства проектов такой уж сложной работы со строками и нету (если мы про бизнес логику), а все мало мальски простое и так хорошо работает.
Что до «не путайте», мне всегда казалось что юникод он и в африке юникод, а UTF-8 это один из вариантов представления. Так что от этого это не-юникодом не становится.
Что до «удобного ООП стиля», это то тут вообще причем? Для этого нужно что бы сами строки были объектами или реализовывать враппер для этого. Мне если честно и с функциями норм.
Что до «не путайте», мне всегда казалось что юникод он и в африке юникод, а UTF-8 это один из вариантов представления. Так что от этого это не-юникодом не становится.
Что до «удобного ООП стиля», это то тут вообще причем? Для этого нужно что бы сами строки были объектами или реализовывать враппер для этого. Мне если честно и с функциями норм.
Fesor, собственно реакция скорее на "-1" к комментарию, а вашу позицию разделяю и с ней согласен.
Вообще если перечитать сообщения почти одинаковую мысль несут.
P.S. А к UTF-8 так это вариант представления (давайте называть его бинарным представлением UNICODE или способом кодирования UNICODE) и разделять эти понятия, так как массив байт ByteArray с UTF-8 и объект строка в UNICODE разные объекты. Разница будет видна в индексной адресации (скажем утверждение unicodeStrInUTF[0] != unicodeStr[0], так как в первом случае по первому индексу будет «char_t», а во втором «wchar_t» (сейчас вроде это — int) в терминах C/C++). Я бы сказал разного порядка объекты.
Вообще если перечитать сообщения почти одинаковую мысль несут.
P.S. А к UTF-8 так это вариант представления (давайте называть его бинарным представлением UNICODE или способом кодирования UNICODE) и разделять эти понятия, так как массив байт ByteArray с UTF-8 и объект строка в UNICODE разные объекты. Разница будет видна в индексной адресации (скажем утверждение unicodeStrInUTF[0] != unicodeStr[0], так как в первом случае по первому индексу будет «char_t», а во втором «wchar_t» (сейчас вроде это — int) в терминах C/C++). Я бы сказал разного порядка объекты.
Прошу прощения за возможно школьный вопрос, но как из 2 получается -3?
unset($exponent); // удалили переменную(null)
$exponent = ~2; // Этот момент не понятен
var_dump($exponent); // int(-3)
unset($exponent); // удалили переменную(null)
$exponent = ~2; // Этот момент не понятен
var_dump($exponent); // int(-3)
Sign up to leave a comment.
Нововведения в PHP 5.6 beta 3