Здравствуйте, so5team, Вы писали:

S>Конкретно этот фрагмент -- это ни разу не хотелка, а обязательное требование к нормальному статически-типизированному языку: если у нас есть независимые интерфейсы A и B, то в consume_A нельзя передать ссылку на реализацию интерфейса B, а в consume_B -- нельзя передать ссылку на реализацию интерфейса A.
Эээ.. Погоди. С интерфейсами как раз всё в порядке. В интерфейсах нет никакого "f из A", т.к. A — это интерфейс и там никакой реализации быть не может. Там лишь декларация метода. Сама реализация будет в D.

S>Дальше вопрос уходит в область того, а может ли какой-то тип D реализовывать сразу оба интерфейса.
На самом деле твой вопрос ушел в область множественного наследования _реализаций_, а не интерфейсов.

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

S>Другое дело, что в известных мне динамически-типизированных языках показанное выше нельзя реализовать в принципе. Т.е. если у D есть метод f, но сам по себе D не является ни A, ни B (т.е. не выполняется отношение "is a"), то все равно ссылку на D можно пихнуть как в consume_A, так и в consume_B.
Начнём с того, а где там вообще будет D/A/B?? Не окажется, ли что там будет Object/Object/Object?

Здравствуйте, so5team, Вы писали:

S>Конкретно этот фрагмент -- это ни разу не хотелка, а обязательное требование к нормальному статически-типизированному языку: если у нас есть независимые интерфейсы A и B, то в consume_A нельзя передать ссылку на реализацию интерфейса B, а в consume_B -- нельзя передать ссылку на реализацию интерфейса A.
Эээ.. Погоди. С интерфейсами как раз всё в порядке. В интерфейсах нет никакого "f из A", т.к. A — это интерфейс и там никакой реализации быть не может. Там лишь декларация метода. Сама реализация будет в D.

S>Дальше вопрос уходит в область того, а может ли какой-то тип D реализовывать сразу оба интерфейса.
На самом деле твой вопрос ушел в область множественного наследования _реализаций_, а не интерфейсов.

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

S>Другое дело, что в известных мне динамически-типизированных языках показанное выше нельзя реализовать в принципе. Т.е. если у D есть метод f, но сам по себе D не является ни A, ни B (т.е. не выполняется отношение "is a"), то все равно ссылку на D можно пихнуть как в consume_A, так и в consume_B.
Начнём с того, а где там вообще будет D/A/B?? Не окажется ли, что там будет Object/Object/Object только?