Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Использование в теле анонимного класса считается использованием переменной до инициализации. Что логично - инициализация переменной t будет закончана только по завершении инструкции присваивания.
Ну это как бы объясняет почему не получилось (но это ж не неразрешимая проблема, имена методов он же находит в любом порядке). Мог бы и тут постараться немного.
Я подозреваю, что причина тут в том, что в общем случае нельзя гарантировать, что метод, в котором используется неинициализированная переменная, не будет вызван в момент инициализации (например, из конструктора).
Например, представьте, что в данном примере метод run вызывается из конструктора класса Thread (хоть это и не так, но компилятор об этом не знает). Тогда будет произведено обращение к переменной t до завершения создания объекта и тем более до того, как объект будет ей присвоен.
Ну это если смотреть на присваивание как на операцию, которую нужно как-то делать (как в С++). В Яве в присваивании ничего не сделать - в этом примере это, по сути, просто лексическое связывание, и технически ничего не мешает скомпилировать такой код всегда правильно. Почему я особенно бы рассчитывал на final в таком случае - он мог бы как раз помочь отличить лексическое связывание (просто ярлык для того, что находится справа от "=") от чего-то, что где-то по ходу программы будет еще менятся.
Я только что объяснила, почему это в общем случае невозможно.
Как должен вести себя компилятор?
Вот такой пример не компилируется:
public abstract class Test {
public Test() {
run();
}
public abstract void run();
public static void main(final String[] args) {
final Test t = new Test() {
@Override
public void run() {
System.out.println(t);
}
};
}
}
В общем случае - да, возможно, просто нужно уточнять семантику того, что подразумевается под final. То, что пример не компилируется - это следствие того, что компилятор его не может скомпилировать, а не того, что он в принципе не может быть скомпилирован.
> что бы вывелось?
Точно то же самое, что и при попытке распечатать this. Почему так? - потому что t - ето просто лексическое связывание, и this тождественно t.
Но если бы мы говорили об операции присваивания (и ситуация в которой t и this Test'a различны имела бы смысл), то тогда, конечно, так нельзя делать.
По крайней мере, мой аргумент такой, что новичек, пусть и не осознано, но нашел нетривиальный случай, где размыта семантика языка, и причины по которым мжно было бы сделать так, как автору хотелось, мне видятся вполне легитимными.
Хорошо, в данном случае компилятор может "догадаться" и заменить t на this (кстати, почему бы тогда программисту сразу и не написать this?). Но в общем случае так поступить нельзя.
Например, в приведённом выше коде участвуют два объекта: Thread и Runnable, при этом в тело объекта Runnable передаётся переменная типа Thread. Тут уже this не отделаешься. В момент конструирования объекта Runnable объект Thread ещё не существует.
Нет, вы все время пытаетесь перейти на детали реализации.
Во-первых, проблема, которую вы описываете - решаемая.
Во-вторых, вы игнорируете неоднозначность конструкции a = b в Яве. Неоднозначность заключается в том, что иногда ее можно воспринять как разрушающее присваивание, а иногда, как выражение тождества. В первом случае вы бы были правы. Во втором - нет. final имеет отличительную особенность - переменным с таким модификаторм нельзя ничего позже присваивать, и поэтому, интуитивно, хочется верить, что они выражают тождество.
Как вы это тождество реализуете? - уже ваши проблемы, но принципиально можно показать, что это всегда реализуемо.
Это та же проблема, которая возникает при определении рекурсии:
void f () { f(); }
Ведь вы же не считаете эту конструкцию невозможной потому что внутри f f "еще не известно".
В Java - invokevirtual/invokeinterface/invokestatic/invokespecial и пусть дальше JVM разбирается.
В нативном коде компилятор в момент генерации тела функции уже знает её адрес или по крайней мере смещение от текущей инструкции.
Как реализовать вышеупомянутую конструкцию - совершенно непонятно.
Вот ещё кусок кода, Фома ты неверующий:
public abstract class Inner implements Runnable {
public Inner() { run(); }
}
public class Test {
public Test(Inner i) {
i.run();
}
public static void main(final String[] args) {
final Test t = new Test(new Inner() {
@Override
public void run() {
System.out.println(t);
}
});
}
}
Что прикажете делать компилятору? Ведь объекты создаются в строгой последовательности: сначала Inner, потом t. В момент выполнения конструктора объекта Inner объект t ещё не существует и, соответственно, не может быть передан по ссылке. А ссылка-то уже нужна!
Еще раз, t тождественно this, если мы считаем, что final - это такой способ выразить тождество. Следовательно, везде, где можно подставить this, t имело бы точно тот же смысл.
Вот, смотрите:
(* Declares class `test' with two methods: *)
(* `test' and `printme' *)
class test =
object
method test = (Printf.printf "Who are you? - %s\n")
method printme = "I am t"
end;;
(* lexically binds `t' to the newly created instance of `test' *)
let t = new test in t#test (t#printme);;
Я же говорю ... в которой t и this Test'a.... И, опять же, вы говорите, что это не возможно потому что компилятор так не умеет - и тут я с вами согласен. Но когда вы гороворите, что так нельзя в принципе, то тут вы ошибаетесь, потому что в принципе так можно, тому я вам привел наглядный пример. другой язык, другой компилятор такое позволяет делать.
Да, уже было, клипсу уже несколько лет тогда было. Просто преподаватель был ничем не интересующийся старпер, который принимал лабы только в распечатках, и даже не запускал никогда.
Используйте нормальный look and feel. Nimbus, например, или третьей стороны.
У Swing и SWT разные области применения. Swing (или его современная замена - JavaFX) хорош для приложений, где важен одинаковый вид приложения на разных платформах. SWT - для нативного вида.
>одинаковый вид приложения на разных платформах.
Одинаковое говно на всех платформах, по крайней мере, на винде точно. Может одинаково мако- или прыщеблядский? Я еще не видел нормально смотрящегося на винде кроссплатформенного гуя. Или менее хуевый (QT, SWT), или совсем хуевый (GTK, все оставшиеся варианты явагуя). Ах да, swing еще и тормозной.
Swing тормозной? В таком случае SWT будет ещё тормознее. Хотя бы потому, что SWT использует "тяжёлые" нативные виджеты, а Swing - "лёгкие", которые рисует сам.
Look and feel - тема оформления Swing. Кстати, конкретно под Windows есть и нативная тема оформления Swing. Под Linux/GTK теоретически тоже есть, но выглядит убого.
Приверженцы свинга называют себя свингерами. Для облегчения общения с единомышленниками и поиска новых партнёров свингеры объединяются в свинг-клубы, в которые, как правило, принимаются уже сложившиеся пары.
просто в жаве есть жесткое правило: никаких ссылок вперед. нельзя ссылаться на еще необъявленную переменную. нельзя объявить константу или переменную, ссылаясь на константу, объявленную позже.
возможно, это связано с однопроходным анализатором.
t жеж final, компилятор вполне же мог сообразить, что это просто синоним this.
Например, представьте, что в данном примере метод run вызывается из конструктора класса Thread (хоть это и не так, но компилятор об этом не знает). Тогда будет произведено обращение к переменной t до завершения создания объекта и тем более до того, как объект будет ей присвоен.
Как должен вести себя компилятор?
Вот такой пример не компилируется:
Что бы вывелось, если бы он компилировался?
> что бы вывелось?
Точно то же самое, что и при попытке распечатать this. Почему так? - потому что t - ето просто лексическое связывание, и this тождественно t.
Но если бы мы говорили об операции присваивания (и ситуация в которой t и this Test'a различны имела бы смысл), то тогда, конечно, так нельзя делать.
По крайней мере, мой аргумент такой, что новичек, пусть и не осознано, но нашел нетривиальный случай, где размыта семантика языка, и причины по которым мжно было бы сделать так, как автору хотелось, мне видятся вполне легитимными.
Хорошо, в данном случае компилятор может "догадаться" и заменить t на this (кстати, почему бы тогда программисту сразу и не написать this?). Но в общем случае так поступить нельзя.
Например, в приведённом выше коде участвуют два объекта: Thread и Runnable, при этом в тело объекта Runnable передаётся переменная типа Thread. Тут уже this не отделаешься. В момент конструирования объекта Runnable объект Thread ещё не существует.
Во-первых, проблема, которую вы описываете - решаемая.
Во-вторых, вы игнорируете неоднозначность конструкции a = b в Яве. Неоднозначность заключается в том, что иногда ее можно воспринять как разрушающее присваивание, а иногда, как выражение тождества. В первом случае вы бы были правы. Во втором - нет. final имеет отличительную особенность - переменным с таким модификаторм нельзя ничего позже присваивать, и поэтому, интуитивно, хочется верить, что они выражают тождество.
Как вы это тождество реализуете? - уже ваши проблемы, но принципиально можно показать, что это всегда реализуемо.
Это та же проблема, которая возникает при определении рекурсии:
Ведь вы же не считаете эту конструкцию невозможной потому что внутри f f "еще не известно".
В Java - invokevirtual/invokeinterface/invokestatic/invokespecial и пусть дальше JVM разбирается.
В нативном коде компилятор в момент генерации тела функции уже знает её адрес или по крайней мере смещение от текущей инструкции.
Как реализовать вышеупомянутую конструкцию - совершенно непонятно.
Вот ещё кусок кода, Фома ты неверующий:
Что прикажете делать компилятору? Ведь объекты создаются в строгой последовательности: сначала Inner, потом t. В момент выполнения конструктора объекта Inner объект t ещё не существует и, соответственно, не может быть передан по ссылке. А ссылка-то уже нужна!
Вот, смотрите:
И работает ведь! 😉
В последнем моём примере t не тождественно this. Потому что внутри объекта Inner this - это объект Inner, а t - ещё не созданный объект Test.
Или имеется в виду "."? - тогда Баш, наверное.
Но зачем? Он же уебищен. Как и почти весь гуй на яве, но хотя бы есть SWT.
Потому что всем похуй. И мб SWT тогда еще не вырос.
У Swing и SWT разные области применения. Swing (или его современная замена - JavaFX) хорош для приложений, где важен одинаковый вид приложения на разных платформах. SWT - для нативного вида.
Одинаковое говно на всех платформах, по крайней мере, на винде точно. Может одинаково мако- или прыщеблядский? Я еще не видел нормально смотрящегося на винде кроссплатформенного гуя. Или менее хуевый (QT, SWT), или совсем хуевый (GTK, все оставшиеся варианты явагуя). Ах да, swing еще и тормозной.
А что за look and feel и как его менять?
Look and feel - тема оформления Swing. Кстати, конкретно под Windows есть и нативная тема оформления Swing. Под Linux/GTK теоретически тоже есть, но выглядит убого.
Как менять - погуглите на тему Nimbus.
SWT, может быть, тоже тормозной, но ему хоть можно простить, а тормозному кривому уебищу - как-то не хочется.
В зависимости от того, кто его танцует
возможно, это связано с однопроходным анализатором.