Введите стирание, переопределение и дженерики
Вам нужно создать функцию без параметров, которые вы можете использовать в качестве команды:
b = Button(admin, text='as', command=lambda: button('hey'))
См. раздел «Передача аргументов в обратные вызовы» в этом документе .
2 ответа
Подпись fooMethod(Class<?>) совпадает с подписью fooMethod(Class) после стирания, так как стирание Class<?> просто Class ( JLS 4.6). Следовательно, fooMethod(Class) подподпись fooMethod(Class<?>), но не противоположное ( JLS 8.4.2 ).
Для переопределения с методами экземпляра Вам нужен метод переопределения быть подподписью переопределенного метода ( JLS 8.4.8.1 ). Это - ясно не случай здесь.
Теперь, когда мы установили то, что Ваш метод подклассов не переопределяет метод суперкласса согласно JLS, давайте посмотрим на последствия во время выполнения, когда стирание типа произошло. У нас теперь есть два метода, которые смотрят точно 'то же' (то же имя, те же типы параметра), но не переопределяют друг друга. Если они не переопределяют, они должны быть оба доступными на подтипе как отдельные методы, но у них есть идентичные подписи во время выполнения: конфликт. Таким образом, Java должен запретить его.
Переопределяющие универсальные типы параметра с помощью необработанных типов параметра , позволил, потому что необработанные типы существуют просто поэтому: они - удобный механизм с определенными необоснованными правилами типа снабдить взаимодействие с унаследованным кодом. Таким образом, система типов здесь решит, что метод подклассов делает , переопределяют суперкласс один, они идентичны после стирания типа, и у нас никогда не может быть конфликта. В результате этого библиотеки могут быть generified независимо от существующего необщего кода.
Поскольку Class<?> более конкретно, чем всего Class.
, Например, foo(Class<List>) не может переопределить foo(Class<Collection>). Я забываю термин, но типы с дженериками будут всегда отличаться от тех, которые не имеют.