Ефективні цикли foreach: PHP і правильні масиви

Інформація, представлена в масивах, може відрізнятися типом значень і їх розміром, а кількість елементів не завжди можна визначити заздалегідь. Сучасне програмування, особливо в розподіленому варіанті, дозволяє створювати складні структури даних, зміст і властивості яких можуть визначитися динамічно невизначений момент часу в результаті різних дій або подій, в різній послідовності. Не завжди на етапі розробки можна спрогнозувати процес експлуатації, передбачити всі можливі варіанти подання і використання інформації, динаміку їх появи та використання.

Синтаксис циклу з утримання

Формулюючи синтаксис foreach, PHP запропонував два варіанти доступу до елементів. Обидва не залежать ні від типу ключа, ні від типу значення і можуть бути земульовані звичайним циклом. Запропоновано розглядати масив як сукупність елементів, кількість яких спочатку не визначено. Масив може формуватися на льоту, як з ключами, так і без. У масиві може бути видалений елемент, ключі можуть бути асоціативними та утвореними за замовчуванням.


foreach ($aArrayName as $xValue) {тіло циклу} Така конструкція зобов'язує цикл foreach PHP пройтися по всім елементів поспіль. У тілі циклу змінна $xValue буде послідовно приймати всі значення масиву $aArrayName в тому порядку, в якому вони були додані. Значення ключів елементів доступні не будуть. foreach ($aArrayName as $xKey => $xValue) {тіло циклу} Тут також, виконуючи конструкцію foreach, PHP прогляне весь вміст масиву, але в тілі циклу попарно будуть приймати відповідні значення як змінна $xValue, так і змінна $xKey - ключ елемента.

Послідовність елементів

Всередині foreach PHP буде пропонувати вміст в тому порядку, в якому додавалися елементи, але якщо при формуванні масиву мали місце неодноразові додавання/видалення, причому щось додавалось з ключами, а що-то без, то краще всього виконувати роботу з масивом не з позицій послідовності елементів, а грунтуючись на їх утриманні або на ключах. В силу різних об'єктивних причин послідовність всередині масиву може бути не дотримана і/або може не мати особливого значення, але на неї не слід орієнтуватися в будь-якому випадку. У простих завданнях, на нових наборах даних, проблем немає, і алгоритм можна налаштувати на послідовну обробку, але коли на процес створення/редагування масиву впливає безліч факторів, слід орієнтуватися на зміст.

Сучасні «правильні» елементи

З позицій сформованої власної концепції, без урахування навіть безуслово подібних мов, PHP foreach масив необхідно розробляти самостійно з урахуванням реальної конкретної задачі. Практика, коли є дане, а у цього є індекс загальної колекції йому подібних за певним критерієм, - це було вчора . Індекс став ключем, а масив прийняв вигляд асоціативного масиву. Тобто ключ загубив свою послідовну унікальність (зазвичай був послідовним: 012 n) і теж став значенням, але простим значенням (тобто ключем) пов'язаним з реальним значенням (тобто вмістом елемента). Це сьогодні, це правильно, але не зовсім .
Саме тому цикл foreach PHP розглядає як альтернативу звичайному циклу, орієнтованого на звичайні масиви. Це насамперед, і саме це дуже важливо, тому що з цього випливає реальна правильність елементів масиву само , як і їхні ключів!

Правильні масиви правильних елементів

Спочатку був елемент, потім два елементи так з'явився масив елементів і цикл по масиву таких: for ($i=0; $i тіло обробки кожного $aArrayName[$i] } Потім у елемента замість безликого 012 n з'явилося власне ім'я - ключ і стали тоді масиви асоціативним і знадобився тоді цикл foreach - «цикл по кожному»: foreach ($aArrayName as $xKey => $xValue) { тіло обробки кожного $aArrayName[$xKey]або $xValue що одне і те ж } Тепер настала пора, коли в масив повинні прийти правильні елементи , тобто такі, які самі по собі. Вони самі знають свій індекс, свій зміст, своє місце в послідовності, схильні проявляти власний вибір послідовності і делегувати всі ці свої можливості власне масиву, що їх містить. Такі правильні масиви будуть оброблятися самі по собі. Особливої потреби в використанні звичайних циклів і циклів по кожному просто не буде. Формально синтаксис і семантика це вже дозволяють, питання тільки за інерцією свідомості розробника.