Javascript: передать функцию с заданными значениями аргументов

Нужно передать функцию, которая должна быть выполнена с определенными аргументами? Оберни ее в анонимную функцию:

someGuiElement.onclick = alert("Hello world");
// будет сразу выполнена - и onclick будет присвоен результат выполнения  alert("Hello world") - т.е.  undefined, так как alert() ничего не возвращает


someGuiElement.onclick =  function()) {alert("Hello world") };
// а так все ок

Finite-state machine GUI с помощью JavaScript

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

JUnit, форматирование логов

Захотелось немного порядка и эстетики в логах юнит-тестов - написал базовый для всех юнит-тестов  класс, который строит вот такие таблички:

+----------------------------------------+---------+
|      TEST                              | PASSED? |
+----------------------------------------+---------+
|RendererFilter.lastNthOccurence         | NO      |
+----------------------------------------+---------+
|RendererFilter.PathResolver             | YES     |
+----------------------------------------+---------+

Очень классно и удобно - всего две строки в каждом тесте, и все готово:

testNameIs("TestName"); //в начале

...

testPassed(); // в конце

На мой взгляд этого достаточно - по таблице можно быстро посмотреть что не прошло, и искать подробности ниже в логах Exception-ов JUnit-а.
Ссылка на исходник.

Required Projects в Eclipse

Хочу дать пояснения еще одному тегу:
dev_tools я буду использовать как обобщение для всех возможных IDE, редакторов, профайлеров и прочих программ, которые хоть сами написать код и не напишут, но в работе могут помочь.

В Eclipse код к проекту можно подключить различными способами:

1. добавить нужные пакеты к исходникам;
2. добавить Jar;
3. добавив Required Project.

Зачем нужен третий пункт?

Когда тянет использовать instanseof ...

Строить логику на проверках к какому классу принадлежит обьект - плохо. Аргументы я не обдумывал, но в утверждении интуитивно уверен.

Один из вариантов "хорошего" подхода: Liskov substitution principle. Вкратце - все public методы должны быть еще в самом корне иерархии. Все что выше:
1) должно любым способом их реализовывать;
2) не должно добавлять новых открытых методов и полей.
В чем плюс - если в чьем-то коде есть метод doSomethingWith(SomeBaseClass param) - он  никогда не сломается, какой бы наследник SomeBaseClass ни передавался.

Но иногда надо, чтобы наследники таки отличались от базового класса. Как же тогда использовать эти возможности там, где мы получаем BaseClass?