Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Прочее

Почему в 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 могут арифметически складываться, если они содержат числа! Хорошо ли это или плохо? Не будем торопиться давать окончательный ответ. Но не трудно догадаться, что арифметическое сложение строк и их конкатенация трубуют разных обозначений для этих операций.

Последняя правка: 2014-12-20    14:45

ОценитеОценки посетителей
   ███████████████████████ 7 (53.8%)
   ███████ 2 (15.3%)
   █████████████ 4 (30.7%)
   ▌ 0

Отзывы

     2013/05/07 16:05, kboa

Просто для напоминания: awk для конкатенации вообще никаких знаков не использует. Это не хорошо и не плохо -- это другой принцип

     2013/09/10 16:13, Данила Летуновский

зато можно написать
всё .= "строка1";
всё .= "строка2";
всё .= "строка3";
print всё;

     2014/01/16 11:42, Pensulo

В VisualBasic для явной конкатенации строк используется специальная операция "&". Есть ещё неявная конкатенация с помощью операции "+", но сам не использую этот способ и другим не советую.
Запятую для конкатенации было бы использовать логичнее нежели точку.

     2014/01/22 05:29, Для Данилы

Ну, в Питоне используется знак "+" для сцепления (так по-русски) строк, и там тоже можно писать:
всё = "строка1"
всё += "строка2"
всё += "строка3"
print(всё)
Так что возможность такой записи сцепления строк в ПХП совсем не за счёт точки.

     2014/01/22 05:30, Для Pensulo

Нет. Всё-таки для сцепления строк логичнее использовать знак "+".

     2014/01/23 19:35, Pensulo

Дело в том что правила принятые в VisualBasic для приведения типов при операциях с разнотипными операндами допускают среди прочего и конвертирование строковых типов в числовые с последующим выполнением арифметических операций.
Т.о.  Выражение "10" + 2.3 даст в результате число 12.3
Ньюансов в правилах автоматического приведения типов в VisualBasic предостаточно. Однако всех этих медвежьих услуг можно избежать при использовании явных операций и явных приведений типов.

     2014/01/24 10:43, Автор сайта

Тут есть два пути.
  • Для сцепления строк используем «+». Так привычнее, но тогда нельзя суммировать внутри строк: «123»+«456» будет «123456», а не «579». Думаю, числовое преобразование и обратное преобразование в строку – не слишком большая цена, которую заплатим за прозрачность действий.
  • Для сцепления строк используем «.». Тогда по привычке пишем «abc»+«def» и удивляемся, почему у нас получается ерунда.

     2014/05/23 08:33, Pensulo

Посетила "гениальная" мысль, с которой спешу поделиться. Не совсем к теме данной статьи, но идеально подходящей статьи всё равно нет, посему - здесь:

Что если для пущей однозначности и наглядности вместо комплексных операций интегрированных с операцией присвоения вида "операция=" и "=операция" использовать обычную операцию присвоения, в правом выражении которой употреблять специальное подстановочное обозначение заменяющее собой имя объекта (переменная, ссылка, указатель, объект и прочее)в который собственно присваивается полный результат вычисления выражения? Тогда вместо кода:

всё = "строка1"
всё += "строка2"

можно было бы написать, например, так:

всё = "строка1"
всё = @ + "строка2"

, где @ - специальный символ подстановки (можно придумать что-то более подходящее, но желательно лаконичное) действительный только внутри выражения присвоения и в данном примере заменяет собою переменную "всё".
С точки зрения переопределения (перегрузки) операторов, как мне кажется, тоже меньше неоднозначностей возникает.

Вот ещё пример, когда вместо кода:

LongVarName++

можно было бы написать, немногим длиннее, однако универсальнее:

LongVarName = @+1

     2014/05/24 13:01, Автор сайта

Приятно иметь дело с людьми, у которых развита фантазия :) Если есть желание – напишите мне на указанный ниже почтовый адрес, можно будет поближе познакомиться.

Ровно такая же мысль меня посетила уже давно. Для подстановки можно зарезервировать ключевое слово. Когда-то на Руси в обиходе было слово «оный», оно мне нравится. Современники предпочитают говорить «он же». Подстановка упростит сложные выражения, когда одно и то же повторяется несколько раз, например:
объект = (он же – 1) / (он же + 1)
Повторяющийся в выражении объект может отсутствовать в левой части выражения, тогда можно сделать вот так:
он же = объект  // это что-то типа define
другой объект = (он же – 1) / (он же + 1)
Тут ещё следует учитывать возможность употребления одного и того же объекта как в левой, так и в правой части выражения. Например, в Си есть приставка «const», которая запрещает изменение значения. В Ада есть 3 режима доступа (кажется, только для параметров функций, и если так, то их следовало бы распространить на все объекты, а не только на параметры): «in» (только чтение), «out» (только запись) и «inout» (и чтение, и запись). Поэтому если «in» или «out», то эту подстановку «@» или «он же» можно делать только в одной из частей выражения. Но это компилятор должен отследить, это его задача.

Было бы неплохо прикинуть, как это всё ляжет на функциональное программирование. Похоже, только оно сейчас подпитывает развитие языков программирования. А в функциональном программировании предпочитают не модифицировать имеющийся объект, а создавать новый на основе старого. Там операция «=» – это однократное действие, т.е. инициализация, в дальнейшем этот объект менять нельзя. Всё подчинено тому, чтобы компилятор мог знать маршрут вычислений, поэтому отсекают языковые ветви, мешающие этому своей сложностью.

Когда-то была такая мысль:
какое-то выражение, делающее нечто
-//- -//- что-то другое
Поняли, в чём идея? Когда мы что-то пишем на бумаге и нам лень повторять некие одинаковые фрагменты, мы просто пишем «-//-», это признак того, что текст надо взять со строки выше. Правда, изощрённые тестовые редакторы снижают ценность такого нововведения. Хотя... Взгляд меньше «замыливается». Мысль стопорится, когда «многа букаф».

Вообще-то идей много, и здесь изложено не всё. Есть какие-то черновики, есть то, что только в голове, а есть то, что пока не сложилось в стройную картину. Кое-что могу выкладывать на сайт в режиме «чтение только для своих» – в том случае, если это не готово к всеобщему обозрению.

     2014/05/26 08:14, Pensulo

Сразу вопрос по следующему примеру:

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, Автор сайта

a и b будут равны 3, с будут равно 5.

Этот код мне не нравится, он не прозрачен. Почитайте на этом сайте статью про постфиксные инкремент и декремент. Вот потому функциональное программирование поощряет создание новых объектов вместо модификации значений старых объектов – так понятнее.

Все текстуальные подмены – это, в принципе, можно отнести к макросам. Среди «языкописателей» бытует мнение, что макросы свидетельствуют о плохом проектировании языка. Так что стоит сто раз об этом подумать.

     2014/06/17 04:49, utkin

Все текстуальные подмены – это, в принципе, можно отнести к макросам.

Верно, если текстовые подмены не являются главным механизмом языка. OCaml к примеру проводит компиляцию путем символических замен в тех участках программы, где это возможно.
Например:
а=а+в+а+к-е --> а=2а+в+к
Такое преобразование будет выполнено еще до этапа компиляции. Последние версии вроде как рассматривают уже группы строк для анализ. В плоть до того, что возможно перемещение строк и их слияние в одну.
Тот же пример:
1. а=а+в+а+к-е
2. в=в+4
3. а=5
Результат:
1. в=в+4
2. а=5
Первая строка не имеет смысла и будет просто выкинута еще до компиляции программы.
Фишка пока экспериментальная, описания языка очень мало, более подробную информацию найти не удалось.

     2014/12/25 01:42, Сергей

Вообще-то, слово «оный» до сих пор употребляется. Чего вы его испугались?

     2014/12/25 11:48, Автор сайта

Ни разу не слышал это слово в устной речи от окружающих. В книгах читал, по радио слышал. А от обычных людей не слышал. Умирают, к сожалению, старые слова. И в словарях «оный» помечается, как устаревшее.

     2016/03/20 11:01, rst256

Правильное решение, конкатенация это не сложение, т.к. оно не коммутативно и имеет совсем иной приоритет

     2016/03/21 13:28, Автор сайта

По большому счёту, использование бинарных и унарных операций – это блажь, потаканием привычкам, выработанным в докомпьютерную эпоху. Всё можно сделать функциями, просто операции привычнее и нагляднее. В отличие от функций, перегрузка операторов может привести к проблемам, когда их используют не по назначению. Проблемы идентификации, приоритета и ассоциативности приводят к усложнению грамматики языка. Поэтому без особой нужды упирать на операции (в ущерб функциям) не стоит, наверное.

Написать отзыв

Написать автору можно на электронную почту mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Каким должен быть язык программирования?

Анализ и критика

Устарел ли текст как форма представления программы

Русский язык и программирование

Многоязыковое программирование

Синтаксис языков программирования

Синтаксический сахар

Некоторые «вкусности» Алгол-68

«Двухмерный» синтаксис Python

Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

Должна ли программа быть удобочитаемой?

Стиль языка программирования

Тексто-графическое представление программы

●  Разделители

●  Строки программы

●  Слева направо или справа налево?

Комментарии

●  Длинные комментарии

●  Короткие комментарии

●  Комментарии автоматической генерации документации

●  Нерабочий код

Нужны ли беззнаковые целые?

Шестнадцатиричные и двоичные константы

Условные операторы

Переключатель

Циклы

●  Продолжение цикла и выход из него

Некошерный «goto»

Операции присвоения и проверки на равенство. Возможно ли однаковое обозначение?

Так ли нужны операции «&&», «||» и «^^»?

Постфиксные инкремент и декремент

Почему в PHP для конкатенации строк используется «.»?

Указатели и ссылки в C++

Использование памяти

Почему динамическое распределение памяти – это плохо

Как обеспечить возврат функциями объектов переменной длины?

●  Типы переменного размера (dynamically sized types, DST) в языке Rust

●  Массивы переменной длины в C/C++

●  Размещение объектов в стеке, традиционный подход

●  Размещение объектов переменной длины с использованием множества стеков

●  Размещение объектов переменной длины с использованием двух стеков

●  Реализация двухстековой модели размещения данных

●  Двухстековая модель: тесты на скорость

●  Размещение объектов переменной длины с использованием одного стека

Можно ли забыть о «куче», если объекты переменной длины хранить в стеке

Безопасность и размещение объектов переменной длины в стеке

Массивы, структуры, типы, классы переменной длины

О хранении данных в стеке, вместо заключения

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Прочее

Последние комментарии

2018/04/16 15:09, Олег
Русский язык и программирование

2018/04/02 22:42, rst256
Программирование без программистов — это медицина без врачей

2018/03/25 21:14, Денис Будяк
Энтузиасты-разработчики компиляторов и их проекты

2018/03/21 23:37, Marat
Почему обречён язык Форт

2018/03/10 20:05, Comdiv
«Двухмерный» синтаксис Python

2018/02/24 14:51, Эникейщик
Русской операционной системой должна стать ReactOS

2017/12/12 13:32, Comdiv
Отечественные разработки

2017/11/05 17:26, rst256
Электроника без электронщиков