Почему фреймворки веб-разработки имеют тенденцию работать вокруг статических особенностей языков?

Question

Когда я начал использовать Lift, я был немного удивлен, насколько интенсивно он использует отражение (или кажется), это было немного неожиданно для статически типизированного функционального языка. Мой опыт работы с JSP был похожим.

Я довольно новичок в веб-разработке, поэтому я не знаю, как работают эти инструменты, но мне интересно,

1. Какие аспекты веб-разработки поощряют использование рефлексии?

2. Существуют ли какие-либо инструменты (на языках со статической типизацией), которые обрабатывают (1) ссылку на код страницы шаблона (2) объектно-реляционное отображение способом, не использующим отражение?

Answer 1

В частности, обращаясь к проблеме <lift:Foo.bar/>:

Когда в коде встречается <lift:Foo.bar/>, Lift делает несколько предположений о том, каким должно быть исходное имя (различные соглашения об именах), а затем вызывает java.lang.Class.forName чтобы получить класс.(Соответствующий код в LiftSession.scala и ClassHelpers.scala.) Он найдет только классы, зарегистрированные с addToPackages во время загрузки.

Обратите внимание, что также возможно (и часто) регистрировать классы и методы вручную.Все еще существует соглашение, что все преобразования должны иметь форму NodeSeq => NodeSeq, потому что это единственное, что имеет смысл для нетипизированного вывода HTML / XHTML.

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

Answer 2

Пожалуйста, смотрите источник лифта.Он не использует отражения для большей части кода, который я изучал.Почти все статически типизировано.Если вы имеете в виду виды лифта, они обрабатываются как узлы Xml, это тоже не отражение.