[ооп] class A extends B implements C нет доступа к свойствам B
 

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

В чём может быть проблема?

Потому что интерфейс не спрайт. Если нужно обратиться к свойствам спрайта, то либо надо сделать каст в Sprite, либо написать интерфейсы IDisplayObject, IDisplayObjectContainer и т. п. со всеми свойствами.

хм, как-то не логично...
То есть, интерфейс отрезает все родительские методы класса,
но не отрезает свои методы которых нет в интерфейсе. Не понимаю логики.
По-моему, надо или отрезать все, или не отрезать ничего.

интерфейс ничего не отрезает.

Интерфейс — это интерфейс. Он описывает методы, которые точно есть данного экземпляра класса. Интерфейс с методом getParam() может быть реализован как наследником Sprite, так и Array. По-вашему, вы сможете воспользоваться методами и Array и Sprite?

Под "отрезает" я имел ввиду

Так интерпретатор работает с экземпляром класса, реализующим данный интерфейс. О том, что это Sprite, он понятия не имеет.

__etc, я так понимаю, когда мы задаем тип объекта
то компилятор производит что-то вроде автогенерации интерфейса.
(как если бы мы вручную написали интерфейс ISprite добавив туда все публичные методы Sprite)
Вот и получается что
Это условно как

Нет никакой автогенерации интерфейсов.

Если класс наследник Sprite, то я бы хотел иметь возможность воспользоваться методами Sprite плюс методы описанные в интерфейсе.

Аналогично для Array.

Не понимаю подвоха. Про множественное наследование никто ничего не говорил.

Не будет такой возможности, компилятор не Нострадамус, чтобы знать, что в данная переменная ссылается на экземпляр класса Sprite, а не Array или вообще String. Вы указали, что это IMyInterface, значит там гарантированно будут методы IMyInterface и ничего более.

вот вам и методы спрайта и метода интерфейса.

Извиняюсь, я ошибся в тестовом файлике.
И еще etc во втором посте ввел в заблуждение -)
Все логично и все работает правильно (продолжаю думать что автогенератор интерфейсов существует-) )

Проблему автора топика нужно искать в конкретном коде.

Хм, похоже я понял в чём проблема.

Если описывать картину подробнее, то есть базовый класс, который наследуется от спрайта, и несколько потомков, наследующихся от этого базового класса.

И для того чтобы ссылаться на один из потомков, есть переменная, объявленная с типом интерфейса. Пожалуй что компилятору и правда неоткуда узнать, что там ещё и спрайт.

Но вопрос всё же актуален: как это лучше организовать? (кроме написания ISprite)

Альтернативный метот заключался в том, чтобы сделать ссылку типа базового класса, а в нём самом наопределять методов-пустышек, которые нужно оверрайдить в потомках. По-моему тоже довльно криво.

Эх, где абстрактные классы, когда они так нужны...

terbooter, нету генератора интерфейсов. просто интерфейс является типов представления данных. как и класс.

GAIKER, а чем Вам тут помогут абстрактные классы? проблемы останутся теми же.