Почему в PHP для конкатенации строк используется «.»?
Большинство языков программирования, в которых есть операция конкатенации строк,
используют для обозначения таких операций символ «+»:
string A = "Hello";
string B = ", ";
string C = "world";
cout << A + B + C; // выводится "Hello, world"
Однако PHP для этой операции использует «.».
Почему?
Просто проверим:
$a = "987";
$b = "13";
echo $a . $b; // выводится "98713"
echo $a + $b; // выводится 1000
Строки в PHP могут арифметически складываться, если они содержат числа!
Хорошо ли это или плохо?
Не будем торопиться давать окончательный ответ.
Но не трудно догадаться, что арифметическое сложение строк и их конкатенация трубуют разных обозначений для этих операций.
Опубликовано: 2012.09.25, последняя правка: 2014.12.20 11:45
Отзывы
✅ 2013/05/07 16:05, kboa #0
Просто для напоминания: awk для конкатенации вообще никаких знаков не использует. Это не хорошо и не плохо -- это другой принцип✅ 2013/09/10 16:13, Данила Летуновский #1
зато можно написатьвсё .= "строка1"; всё .= "строка2"; всё .= "строка3"; print всё; ✅ 2014/01/16 11:42, Pensulo #2
В VisualBasic для явной конкатенации строк используется специальная операция "&". Есть ещё неявная конкатенация с помощью операции "+", но сам не использую этот способ и другим не советую. Запятую для конкатенации было бы использовать логичнее нежели точку.✅ 2014/01/22 05:29, Для Данилы #3
Ну, в Питоне используется знак "+" для сцепления (так по-русски) строк, и там тоже можно писать:всё = "строка1" всё += "строка2" всё += "строка3" print(всё) Так что возможность такой записи сцепления строк в ПХП совсем не за счёт точки.✅ 2014/01/22 05:30, Для Pensulo #4
Нет. Всё-таки для сцепления строк логичнее использовать знак "+".✅ 2014/01/23 19:35, Pensulo #5
Дело в том что правила принятые в VisualBasic для приведения типов при операциях с разнотипными операндами допускают среди прочего и конвертирование строковых типов в числовые с последующим выполнением арифметических операций. Т.о. Выражение "10" + 2.3 даст в результате число 12.3 Ньюансов в правилах автоматического приведения типов в VisualBasic предостаточно. Однако всех этих медвежьих услуг можно избежать при использовании явных операций и явных приведений типов.✅ 2014/01/24 10:43, Автор сайта #6
Тут есть два пути.- Для сцепления строк используем «+». Так привычнее, но тогда нельзя суммировать внутри строк: «123»+«456» будет «123456», а не «579». Думаю, числовое преобразование и обратное преобразование в строку — не слишком большая цена, которую заплатим за прозрачность действий.
- Для сцепления строк используем «.». Тогда по привычке пишем «abc»+«def» и удивляемся, почему у нас получается ерунда.
✅ 2014/05/23 08:33, Pensulo #7
Посетила "гениальная" мысль, с которой спешу поделиться. Не совсем к теме данной статьи, но идеально подходящей статьи всё равно нет, посему — здесь:
Что если для пущей однозначности и наглядности вместо комплексных операций интегрированных с операцией присвоения вида "операция=" и "=операция" использовать обычную операцию присвоения, в правом выражении которой употреблять специальное подстановочное обозначение заменяющее собой имя объекта (переменная, ссылка, указатель, объект и прочее)в который собственно присваивается полный результат вычисления выражения? Тогда вместо кода:
всё = "строка1" всё += "строка2"
можно было бы написать, например, так:
всё = "строка1" всё = @ + "строка2"
, где @ — специальный символ подстановки (можно придумать что-то более подходящее, но желательно лаконичное) действительный только внутри выражения присвоения и в данном примере заменяет собою переменную "всё". С точки зрения переопределения (перегрузки) операторов, как мне кажется, тоже меньше неоднозначностей возникает.
Вот ещё пример, когда вместо кода:
LongVarName++
можно было бы написать, немногим длиннее, однако универсальнее:
LongVarName = @+1✅ 2014/05/24 13:01, Автор сайта #8
Приятно иметь дело с людьми, у которых развита фантазия :) Если есть желание — напишите мне на указанный ниже почтовый адрес, можно будет поближе познакомиться.
Ровно такая же мысль меня посетила уже давно. Для подстановки можно зарезервировать ключевое слово. Когда-то на Руси в обиходе было слово «оный», оно мне нравится. Современники предпочитают говорить «он же». Подстановка упростит сложные выражения, когда одно и то же повторяется несколько раз, например: объект = (он же — 1) / (он же + 1) Повторяющийся в выражении объект может отсутствовать в левой части выражения, тогда можно сделать вот так: он же = объект // это что-то типа define другой объект = (он же — 1) / (он же + 1) Тут ещё следует учитывать возможность употребления одного и того же объекта как в левой, так и в правой части выражения. Например, в Си есть приставка «const», которая запрещает изменение значения. В Ада есть 3 режима доступа (кажется, только для параметров функций, и если так, то их следовало бы распространить на все объекты, а не только на параметры): «in» (только чтение), «out» (только запись) и «inout» (и чтение, и запись). Поэтому если «in» или «out», то эту подстановку «@» или «он же» можно делать только в одной из частей выражения. Но это компилятор должен отследить, это его задача.
Было бы неплохо прикинуть, как это всё ляжет на функциональное программирование. Похоже, только оно сейчас подпитывает развитие языков программирования. А в функциональном программировании предпочитают не модифицировать имеющийся объект, а создавать новый на основе старого. Там операция «=» — это однократное действие, т.е. инициализация, в дальнейшем этот объект менять нельзя. Всё подчинено тому, чтобы компилятор мог знать маршрут вычислений, поэтому отсекают языковые ветви, мешающие этому своей сложностью.
Когда-то была такая мысль:какое-то выражение, делающее нечто -//- -//- что-то другое Поняли, в чём идея? Когда мы что-то пишем на бумаге и нам лень повторять некие одинаковые фрагменты, мы просто пишем «-//-», это признак того, что текст надо взять со строки выше. Правда, изощрённые тестовые редакторы снижают ценность такого нововведения. Хотя... Взгляд меньше «замыливается». Мысль стопорится, когда «многа букаф».
Вообще-то идей много, и здесь изложено не всё. Есть какие-то черновики, есть то, что только в голове, а есть то, что пока не сложилось в стройную картину. Кое-что могу выкладывать на сайт в режиме «чтение только для своих» — в том случае, если это не готово к всеобщему обозрению.✅ 2014/05/26 08:14, Pensulo #9
Сразу вопрос по следующему примеру:
a = 1; b = 2; c = 0; c = a++ + a++ + b++ + c++;
Чему будут равняться переменные a, b и c после выполнения этого фрагмента кода? Однозначен и естественен ли такой исход для вас?
Ещё один пример:
объект = он же + (объект = он же - 1) — он же;
Чему будет равняться "объект" ?
Ещё одно "дельное" предложение — ввести "институт" псевдонимов (Alias) внутри выражений (а можно и для более широкой области видимости), кои очень похожи на локальные переменные, однако по сути являются лишь заменителями порою неприлично длинных имён адресуемых объектов. Тогда пример их (псевдонимов) употребления мог бы выглядеть следующим образом:
{x ~ LongVarName; y ~ Object y = x * x - y + 100; } И тогда объект с именем "@" являлся бы псевдонимом по-умолчанию заменяющим левый объект (присваеваемый) в выражениях присвоения.
В моём коде конструкция "-//-" употреблялась бы крайне редко. Хотя, для подмены части выражения я бы не отказался от подобной конструкции.
Но то лишь моё видение, а кто сказал что оно подходит Идеально для всех? ;)✅ 2014/05/26 13:01, Автор сайта #10
a и b будут равны 3, с будут равно 5.
Этот код мне не нравится, он не прозрачен. Почитайте на этом сайте статью про постфиксные инкремент и декремент. Вот потому функциональное программирование поощряет создание новых объектов вместо модификации значений старых объектов — так понятнее.
Все текстуальные подмены — это, в принципе, можно отнести к макросам. Среди «языкописателей» бытует мнение, что макросы свидетельствуют о плохом проектировании языка. Так что стоит сто раз об этом подумать.✅ 2014/06/17 04:49, utkin #11
Все текстуальные подмены — это, в принципе, можно отнести к макросам. Верно, если текстовые подмены не являются главным механизмом языка. OCaml к примеру проводит компиляцию путем символических замен в тех участках программы, где это возможно. Например: а=а+в+а+к-е --> а=2а+в+к Такое преобразование будет выполнено ещё до этапа компиляции. Последние версии вроде как рассматривают уже группы строк для анализ. В плоть до того, что возможно перемещение строк и их слияние в одну. Тот же пример: 1. а=а+в+а+к-е 2. в=в+4 3. а=5 Результат: 1. в=в+4 2. а=5 Первая строка не имеет смысла и будет просто выкинута ещё до компиляции программы. Фишка пока экспериментальная, описания языка очень мало, более подробную информацию найти не удалось.✅ 2014/12/25 01:42, Сергей #12
Вообще-то, слово «оный» до сих пор употребляется. Чего вы его испугались?✅ 2014/12/25 11:48, Автор сайта #13
Ни разу не слышал это слово в устной речи от окружающих. В книгах читал, по радио слышал. А от обычных людей не слышал. Умирают, к сожалению, старые слова. И в словарях «оный» помечается, как устаревшее.✅ 2016/03/20 11:01, rst256 #14
Правильное решение, конкатенация это не сложение, т.к. оно не коммутативно и имеет совсем иной приоритет✅ 2016/03/21 13:28, Автор сайта #15
По большому счёту, использование бинарных и унарных операций — это блажь, потаканием привычкам, выработанным в докомпьютерную эпоху. Всё можно сделать функциями, просто операции привычнее и нагляднее. В отличие от функций, перегрузка операторов может привести к проблемам, когда их используют не по назначению. Проблемы идентификации, приоритета и ассоциативности приводят к усложнению грамматики языка. Поэтому без особой нужды упирать на операции (в ущерб функциям) не стоит, наверное.✅ 2018/05/27 17:28, Александр Коновалов aka Маздайщик #16
Выше в комментариях была интересная мысль по использованию идентификатора @ или «он же». Хочу поделиться похожей мыслью.
Я понемногу разрабатываю свой функциональный язык программирования (Модульный Рефал), а поскольку он функциональный, в нём циклов нет. Вместо них используется рекурсия. Как-то подумывал сделать для рекурсивных вызовов (чтобы не писать имя рекурсивной функции) использовать какое-нибудь ключевое слово. Типа там $SELF или $REC. Но поленился так сделать.
Возможно, к этой мысли я вернусь... Спасибо за поддержку идеи. Добавить свой отзыв
Написать автору можно на электронную почту mail(аt)compiler.su
|