Механизмы Java при использовании в lambdaj закрытиях
Мы используем систему, аналогичную CWT: общий код, как правило, является самостоятельным проектом и, как таковой, существует отдельно в хранилище (или в отдельном хранилище). В рамках проекта, который использует внешние проекты (проект upstream ), мы включаем скомпилированные / упакованные двоичные файлы для проекта shared / downstream.
Таким образом, вышестоящий проект не будет отстрелен неожиданными изменениями в нижестоящих проектах.
Мы написали несколько сценариев для автоматического обновления основных проектов верхнего уровня новыми версиями этих двоичных файлов при необходимости (в противном случае это ручной процесс копирования пакета в соответствующие проекты, но это не так уж и сложно).
Недостаток, который мы до сих пор видели в этом методе madnes ^ W, заключается в том, что нижестоящие проекты, находящиеся на стадии очень активного развития (скажем, на ранних стадиях новой библиотеки), требуют того, что может показаться чрезмерным количество обновлений для вышестоящего проекта. Тестирование вышестоящего проекта может потребовать обновления разделяемой библиотеки, компиляции, копирования этого двоичного восходящего потока и компиляции / развертывания / любого другого вышестоящего проекта. Тем не менее, как только начальное безумие разработки библиотеки замедляется и библиотека становится несколько стабильной, эта «проблема» испаряется.
Как и в случае с CWT, вышестоящий проект не может каким-либо образом изменить общий код. Изменения вниз по течению должны быть сделаны в пределах этого проекта явно, и распространяться вверх по течению, где это необходимо.
2 ответа
Well, of is presumably a static method which is imported statically so it can be called without the enclosing class name. I expect that var is the same. Both methods must return some type which have the methods subsequently called:
public class Printable {
public void println(Var var);
}
public class Fac {
public static Printable of(Object o) {
return new Printable(o);
}
public static Var var(Class<?> clazz) {
return new Var(clazz);
}
}
All of a sudden:
Fac.of(System.out).println(Fac.var(String.class));
Is valid Java. Using static imports, hey presto:
import static Fac.*;
of(System.out).println(var(String.class));
The curly-braces are obviously valid Java as you can add these in any method to aid in defining a lexical sope. This API-design style is called fluent and is best showcased by the JMock testing library.
By the way, if this is supposed to introduce closures to Java, it's quite ridiculous - the syntax is unreadably awful. Their I/O example actually made me laugh out loud. Try Scala!
EDIT - the two println calls are associated I believe because the first sequence of calls allow the library to capture the variables which you have passed in as parameters. These are probably captured in some ThreadLocal structure. When you then call a (also presumably static) println method, the library is using this captured data to actually execute the behaviour at a later point. Also testing related, the EasyMock test framework uses a similar mechanism (which uses Java proxies in the background) to capture expected values.
Я Марио Фуско, и я являюсь основным разработчиком библиотеки lambdaj.
Прежде всего, я хотел бы кое-что прояснить: lambdaj не предназначен для замены какого-либо функционального языка. Как я сказал на прошлой неделе в своей речи в Jug of Zurich, если у вас есть возможность использовать Scala, сделайте это и никогда не оглядывайтесь назад. Здесь вы можете найти резюме моего выступления, в котором четко указано, что:
http://ctpjava.blogspot.com/2009/10/lambdaj-new-trends-in-java.html
Я счастливый разработчик Scala. Но иногда вы просто обязаны разрабатывать на Java (по моему опыту, в реальном мире примерно в 80% случаев вы не можете выбрать, на каком языке вы должны писать свой код), и в этом случае некоторые из функций лямбдажа могут быть полезно (или я надеюсь на это). Я просто хотел привнести в Java некоторые функциональные возможности, которые полностью отсутствуют. Конечно, результат не является полностью удовлетворительным, в основном из-за ограничений, налагаемых самой Java.
Что касается внутреннего механизма лямбда-кода, да, он использует ThreadLocal для достижения этого результата. Если у вас есть другие вопросы, любопытства или даже лучшие предложения и конструктивная критика в отношении lambdaj, возможно, вам будет интересно зарегистрироваться в списке рассылки lambdaj здесь:
http://groups.google.com/group/lambdaj
до свидания Марио