Приведение типов, значит, что ты можешь в качестве аргумента передать только объект типа methodName

разве об этом не говорится в книге до рассмотрения делегирования?

В книге об этом говорится намного раньше чем тема делегирование

Нету там никакого присвоения метода и быть не может. Тем более $o как раз и есть экземпляр класса MethodName

это просто синтаксис PHP делегирование тут ни при чем

А не уточнение ли это?

Точно !
(methodName $o) и есть уточнение типа, так чего спрашивал если знал ?
Я написал

т.к. не мог вспомнить это слово "уточнение"

<?php

class classA {
    private $msg="Прювет!!!";
    public $cnt=0;
    public function metodA(){
		$this->cnt++;
		return $this->msg;
    }
}

class classB  {
	private $obj;
	function __construct($arg) {
	$this->obj=$arg;
	}
    public function metodB() {
        echo $this->obj->metodA();
    }
}

class classC extends classA {
    public function metodC() {
        echo 'test';
    }
}
$obj1=new classA();
$obj2=new classB($obj1);
$obj3=new classC();
echo $obj2->metodB();
echo $obj1->cnt;
echo $obj3->cnt;

?>

Я не даром добавил вот эту строчку

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

В большинстве случаев для различеых callback функций

Например для обработчиков событий - клас выполняет какуюто бизнес логику потом проверяет - если у него присвоен делегат - дергает его (возможно с параметрами)

когда ты присваиваешь тэгу onclick яваскрипт функцию обрабочик - это и есть пример делегата

О! Отличное сравнение... теперь понятнее....

А то!
Мэтт Зандстра тебе понятных примеров не приведет - не царское дело (точнее не та распальцовка).

Ну разница в чем,
при делегировании вы работаете с уже созданным обьектом,
при наследовании вы создаете копию classA и присоединяете что у вас уже есть ,то есть classС.
Тоесть ,что получается ,при наследовании вы можете выполнять код classA,но при этом вы не рискуете изменить свойства другого обьекта.
А при делегировании,вам прийдется контролировать этот вопрос,что бы случайно не вызвать
нежелательное изменение свойства другого обьекта.
А в сложном коде,этот вопрос достаточно актуальный.
Это все касаемо многократного использования одинакового кода.
Если же нужно получить просто свойство чужого обьекта,достаточно просто сделать снаружи этих обьектов вот так.
$obj1->pro=$obj2->pro;

Делегирование как таковое вообще не связано с наследованием
в большинстве случаев делегаты либо просто ссылки на функцию в нетипизированных языках либо соответствующим образом объявленные типы в типизированных

Не могу - я изучал ООП когда не было никакого PHP и интернета. А была одна на всех книжка Страуструпа по С++ в читалке заводской библиотеки..

Что сейчас читать фиг его знает. Новичкам бы советова книгу Котерова. Естиственно при внимательном изучении подряд по всему языку.

Лично мое мнение - нет смысла изучать ООП (как и паттерны) как некую отдельную дисциплину . Как результат мы видим вопросы - человек даже не понимает где клас где объект. Потому что голая теория вне контекста бесполезна.

Я кстати изучал не ООП как таковое а C++. Остальное приложилось в процесссе изучения и написания программ.
Глупо звучит когда новичок тут пишет - я вот ООП выучил - где бы мнее его применить. А на фига ты учишь то что не знаешь где применять. С таким же успехом мог выучить как коровам в колхозе хвосты крутить.
Если есть задача где нужно ООП то просто бери и решай ее изучая по дороге методы решения синтаксические конструкции и прочее.

Фигасе, как давно

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

Просто изобразили идею в виде паттерна, а какой же паттерн без ООП - несолидно типа.

Ну знаю я,ну нет у ПХП ни событий ни многопоточности ни прерываний ни dll со своими потоками,калбекам неоткуда взятся,что поделаеш ?
Но нужно же куда нибудь впихнуть такую фичу,правда?
Ну нашли ООП ,тоже хорошо,дружно говорим респект Мэтту Зандстре

этого обычно нет в большинстве языков
это создается когда пишуться библиотеки фреймворки и все такое
например есть кнопка у нее событие
но кнопка - это не конструкция языка программирования.

в C++ никаких потоков нет - это либо API либо классы с той или иной библиотеки.

Там ты пишешь код прямо на железо и никакой Билл Гейтс со своим виндовым API на дороге не стоит

Впрочем С для микроконтролеров как правило обрезанный и как правиило не C++ - это слишком громоздко для ограниченного объема памяти..

Ну действительно
а API или библиотеки на каком языке написаны?
На инопланетном ?
Вам просто не приходилось их готовить.C++ - Потоки в Win32

Ну что есть ,то есть
урезано там,урезано на ПХП - вот так и живем с обрезаниями.

Потоки есть в операционной системе (это объект ядра), а не в С или каком либо еще языке програмирования.

И кстати речь шла не о потоках stream а о потоках thread