Цикл foreach

[Bilargo]

Добрый день!
Помогите разобраться, имеется следующая конструкция:

PHP код:

foreach($this->leading as $key=>$item):
$this->item=$item; 


Что означает строка $this->item=$item в частности оператор -> ?
Спасибо!

[Serge_Bliznykov]

обращение к свойству класса с именем item

читайте про ООП в PHP (например, Доступ к классам и объектам в PHP тут)

главное, что такое $this->leading у Вас вопросов не вызвало!

[Bilargo]

обращение к свойству класса с именем item

читайте про ООП в PHP (например, Доступ к классам и объектам в PHP тут)

Ок, спасибо за оперативность

главное, что такое $this->leading у Вас вопросов не вызвало!

У меня очень узкая задача стоит, но если просвятите буду благодарен

[Serge_Bliznykov]

Сообщение от Bilargo

У меня очень узкая задача стоит, но если просвятите буду благодарен

да я сам не очень "свят"

к тому же, я не вижу, какая именно у Вас задача стоит и чем я могу Вам помочь...

[GreenWizard]

Сообщение от Bilargo

У меня очень узкая задача стоит, но если просвятите буду благодарен

Судя по всему, с ООП совсем туго, поэтому скажем так:
есть элементарные типы данных, числа там, символы, которые хранятся в переменных, так сказать, как есть т. е. только само значение

есть более сложные типы (строки и массивы, в общем случае), которые уже устроены сложнее.. внутри них скрыто уже не просто число/символ, а, например, длина массива, его расположение в памяти и т.д., а в коде это отражается в поддержке доступа по индексу, например, что не применимо к символам и числам (если не опускаться до уровня байт, чего не должно быть в РНР, не для таких задач этот язык)

есть структуры, которых в РНР нету, но они являются промежуточным звеном... если два предыдущих типа были более-менее монолитными и программист мог выбрать только один тип хранимых в них данных, то тут программист уже может сказать "я хочу чтоб структура Х хранила в себе число А и массив В" т. е. любые переменные/значения типа Х будут, будто ящик, хранить в себе А и В (это члены записи или поля), которые можно получить дописав "->A" или, соответственно, "->В"
РНР является весьма динамичным языком, поэтому нельзя на 100% ни типы, ни наличие тех или иных полей, но это уже некоторый договор о формате данных, об их структуре, что позволяет писать более качественный код (отдельная тема для парочки книг)
структуры постепенно усложнялись и следующим важным этапом стало появление у них своих функций (они называются методами).. крайне важно тут слово "свои" т. к. до этого уже были функции работающие с записями, но теперь они стали тесно связанными с записями...... тут уже появилась необходимость во всяких this/self, которые, с одной стороны, делают код короче и читаемей, а ещё, с другой стороны, позволяет сказать "этот код тесно связан с данными записи, которая им владеет, и без неё он не может работать" и определить некий договор о структуре записи, указать какие поля и методы она должна иметь, чтоб код работал корректно
все эти сложности, как ни странно, существенно упрощают код и снижают вероятность ошибок (опять же, в РНР с этим чуть хуже, а в С++, например, позволяет напрочь исключить элементарные ошибки ещё до запуска кода), НО эта польза заметна лишь на сложных задачах, где рабочего кода больше чем само описание всех структур и методов
(я вырос на Паскале, поэтому пишу "записи", хотя "структуры" более правильное название, но менее удобное ("структура структуры" - звучит глупо))

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

опять же, вся эта эволюция позволяет легко решать сложные задачи, но простые задачи, увы, оно лишь усложняет, поэтому не стоит, решая простые задачи, думать "да ну, ООП и классы - это фигня, оно только усложняет код"... увы, но на начальном этапе обучения приходится именно так и поступать, чтоб получить хоть некоторые базовые навыки работы с классами.

P. s. я опустил очень многие нюансы, местами пришлось вовсе использовать весьма спорные утверждения, но полноценный материал по этим темам займёт не один десяток книг, поэтому не обессудь
P. p. s. увы, но пока классы не эволюционировали во что-то действительно новое... мир ООП уже переполнен всякими там паттернами, функторами, различными классными вещами, которые сильно отличаются от классов, НО это пока всё те же классы, пусть и сильно развитые

[Bilargo]

Сообщение от GreenWizard

Судя по всему, с ООП совсем туго, поэтому скажем так:
есть элементарные типы данных, числа там, символы, которые хранятся в переменных, так сказать, как есть т. е. только само значение

есть более сложные типы (строки и массивы, в общем случае), которые уже устроены сложнее.. внутри них скрыто уже не просто число/символ, а, например, длина массива, его расположение в памяти и т.д., а в коде это отражается в поддержке доступа по индексу, например, что не применимо к символам и числам (если не опускаться до уровня байт, чего не должно быть в РНР, не для таких задач этот язык)

есть структуры, которых в РНР нету, но они являются промежуточным звеном... если два предыдущих типа были более-менее монолитными и программист мог выбрать только один тип хранимых в них данных, то тут программист уже может сказать "я хочу чтоб структура Х хранила в себе число А и массив В" т. е. любые переменные/значения типа Х будут, будто ящик, хранить в себе А и В (это члены записи или поля), которые можно получить дописав "->A" или, соответственно, "->В"
РНР является весьма динамичным языком, поэтому нельзя на 100% ни типы, ни наличие тех или иных полей, но это уже некоторый договор о формате данных, об их структуре, что позволяет писать более качественный код (отдельная тема для парочки книг)
структуры постепенно усложнялись и следующим важным этапом стало появление у них своих функций (они называются методами).. крайне важно тут слово "свои" т. к. до этого уже были функции работающие с записями, но теперь они стали тесно связанными с записями...... тут уже появилась необходимость во всяких this/self, которые, с одной стороны, делают код короче и читаемей, а ещё, с другой стороны, позволяет сказать "этот код тесно связан с данными записи, которая им владеет, и без неё он не может работать" и определить некий договор о структуре записи, указать какие поля и методы она должна иметь, чтоб код работал корректно
все эти сложности, как ни странно, существенно упрощают код и снижают вероятность ошибок (опять же, в РНР с этим чуть хуже, а в С++, например, позволяет напрочь исключить элементарные ошибки ещё до запуска кода), НО эта польза заметна лишь на сложных задачах, где рабочего кода больше чем само описание всех структур и методов
(я вырос на Паскале, поэтому пишу "записи", хотя "структуры" более правильное название, но менее удобное ("структура структуры" - звучит глупо))

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

опять же, вся эта эволюция позволяет легко решать сложные задачи, но простые задачи, увы, оно лишь усложняет, поэтому не стоит, решая простые задачи, думать "да ну, ООП и классы - это фигня, оно только усложняет код"... увы, но на начальном этапе обучения приходится именно так и поступать, чтоб получить хоть некоторые базовые навыки работы с классами.

P. s. я опустил очень многие нюансы, местами пришлось вовсе использовать весьма спорные утверждения, но полноценный материал по этим темам займёт не один десяток книг, поэтому не обессудь
P. p. s. увы, но пока классы не эволюционировали во что-то действительно новое... мир ООП уже переполнен всякими там паттернами, функторами, различными классными вещами, которые сильно отличаются от классов, НО это пока всё те же классы, пусть и сильно развитые

Спасибо за Ликбез Было интересно прочитать!
Задачу я свою решил, поэтому спасибо всем за помощь))