Посмотрите внимательно на этот код:

Угадайте, что выведется в консоль? Меня интересует вопрос почему именно такой вывод?

Надо было данный вопрос в тему "Маленький тест" написать 

На первый взгляд должно получиться TREE#foo, но надо проверить...

Если бы было, автор бы не отписывал.

А вот фиг вам! Выводится TEST#foo... А вот почему?.. Надо подумать.

Мда... Royan, молоток. Никогда бы не подумал о подобных граблях.

ИМХО. 
Для компилятора здесь нет сравнения приоритетов, ибо в классе Test только одна подходящая функция.
Чтобы заработало иначе, нужно либо создать как

либо добавить метод void foo(String a) в класс Test
либо 


В компиляторах слабо разбираюсь, но могу предположить, что в данном случае компилятор в классе Test находит только одну функцию с подходящей сигнатурой, её и прописывает. А вот если вызвать ту же строчку кода но на прикастенном к Tree объекте, он уже будет анализировать обе функции. То же самое, если создать аналогичную функцию в классе Test


Это сообщение отредактировал(а) mindflyer - 18.10.2007, 08:44

batigoal, Royan просто к экзамену готовится, поэтому всякие странные вопросы из теста и спрашивает.


mindflyer, абсолютно верно.

Зато какой брейн сторм!!! Молот Royan!!!

Да действительно так и работает. Но этоже вообще тупой глюк компилятора.
Чё за ерунда:
Пишешь: Test a = new Tree(); Печатается: TEST#foo
Пишешь: Tree a = new Tree(); Печатается: TREE#foo
Лажа какая-то.
Вообще доложно быть так, что выбор метода должен зависеть только от типа объекта, а тут ещё есть зависимость от типа переменной.

Это не глюк компилятора, а полиморфизм )

добавить к примеру в класс Tree функцию bar(String a)
вызвать из main() a.bar("a");



Такой код даже не скомпилируется, потому что компилятор будет искать метод в классе Test.

А да точно, с компилатором всё нормально. jsse! +1

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

Вот!

Э... не вижу логики. Почему компилятор должен запретить компиляцию класса, который расширяет уже имеющийся? Я бы в данном случае запрещал компиляцию именно Test, т.к. в его коде идёт попытка вызвать несуществующий метод. Что, в общем-то, и делает компилятор. Мы с ним в этом вопросе выбрали одну точку зрения.   

Что-то у меня появилось непреодолимое желание забанить этого анонимного рекламодателя. 

Добавлено через 3 минуты и 16 секунд
Хм... это что, новая фишка форума - реклама от гугля в виде ответа в теме?

nornad,  тут почитай.

Модератор: В дальнейшем прошу не отклоняться от темы топика.

Господа, здесь работает перегрузка, а не полиморфизм.
Право  - даже странно, что Вы пытаетесь применить полиморфизм к данному случаю. 

Логика простая - пусть дочерний класс сколько хочет, столько и расширяет базовый, но только так, чтобы не запутать пользователя.

А запрещать компилировать класс Test нельзя, потому что он может быть в другом, уже откомпилированном пакете, и откомпилировать его мог кто-нибудь другой. А Вы вдруг ему из будущего запрещаете компилировать. Нарушаются базовые причинно-следственные связи! 

Добавлено через 9 минут и 48 секунд

А да точно, Вы правы. Я почемуто не заметил. Я думал под словом полиморфизм, слово перегрузка.

ЗЫ. Я вообще щитаю, что термин "перегрузка" не правильно придумали. Под словом "перегружать" ассоциируется что-то, что нужно заменить, чтобы старое определение изчезло, ну или что-то в этом духе. Можно былобы термин "перегрузить" сделать синонимом к термину "переопределить реализацию базового метода в доченем классе". А вместо "перегруженный метод" говорить "одноимённый метод" - сразу всё чётко ясно и понятно становиться. После таких рассуждений я начинаю понимать зачем появился язык Эспиранто"

Логика не такая уж и простая. При ней надо запрещать такое:

И что мы тогда получаем? В случае, если нам требуется различный код обработки различных объектов, придётся писать if по instanceof. Имхо, различные методы в данном случае удобнее.



Другой пакет в таком случае не мог быть откомпилирован. Если же класс был изменён - перестаём компилировать Test по уже названной причине и отрываем ноги такому "изменятелю". Лучше сразу по самую шею. Нефиг нарушать свои же принцыпы - "но только так, чтобы не запутать пользователя". Нефиг вызывать то, чего нет. Пытаешься - по кумполу и в канаву.