А я как-то столкнулся с такой задачей, и на коленке придумал вроде бы работающий алгоритм, интересно, можно ли найти пример, на которых он не сработает?
public static Control FindCommonAncestor(Control a, Control b) {
if (null == a)
throw new ArgumentNullException("a");
if (null == b)
throw new ArgumentNullException("b");
//
List<Control> visited = new List<Control>();
Control refA = a;
Control refB = b;
bool f = true;
for (;;) {
if (refA == refB)
return refA;
if (visited.Contains(refB))
return refB;
if (visited.Contains(refA))
return refA;
if (refA.Parent == null && refB.Parent == null)
return null;
if (f) {
if (refA.Parent != null) {
visited.Add(refA);
refA = refA.Parent;
}
} else {
if (refB.Parent != null) {
visited.Add(refB);
refB = refB.Parent;
}
}
f = !f;
}
}
При вызове у вас перебираются обработчики и вызываются. Если один из вызываемых обработчиков подпишется на то же событие еще раз или отпишется, то произойдет модификация коллекции, код упадёт и остальные обработчики не вызовутся. В этом месте нужно либо копировать список обработчиков в локальный, либо использовать одну из CopyOnWrite-коллекций для хранения обработчиков. А ссылка на гитхаб будет?
Да, но по сути это то же самое, просто команды выделены в отдельный класс (презентер), а не болтаются вместе с данными. Так что это что-то среднее между классическим MVP (в котором работа с data binding не предусмотрена) и MVVM. Мне такой подход представляется очень удобным.
А мне не нравится задавать команды конструированием в ViewModel-классе. Предпочитаю подход, при котором команды задаются методами презентера (контроллера), помеченными специальным атрибутом. Пример использования такого подхода можно посмотреть здесь.
Именно так. И наоборот — умеет загружать CLR в рамках java-процесса и взаимодействовать с ней через jni. Но прокси-классы генерируются в обоих случаях, то есть работаете вы уже с аналогами ваших классов. Просто вызовы их методов транслируются в интероп/jni.
Прикольно. Я недавно делал похожую штуку, используя jni4net. Прочитать подробнее можно здесь, там же можно утянуть шаблон проекта, в котором из JVM можно вызывать код .NET.
Статья неплохая, но позволю себе высказать пару замечаний. При определении префиксной функции используется формальное определение с небольшим пояснением, оба они читаются очень тяжело. Вот тут, к примеру, к этому добавлено текстовое описание того, что означают элементы посчитанной префиксной функции, это очень помогает понять её суть. Потому что об формальное определение (и о пояснение) можно мозг сломать. То же самое можно сказать и о дальнейшем описании уже сути алгоритма. По приведённой выше ссылке всё понятно, а здесь, увы, нет. Это касается и свойств префиксной функции, и собственно алгоритма.
Как я понимаю, описанная проблема аналогична проблеме разрешения транзитивных зависимостей в Gentoo Linux, где тоже нельзя одновременно в систему поставить 2 версии пакета, и если есть различные приложения, которым требуются разные версии этих библиотек, то ничего нельзя сделать. Думается, что в таких ситуациях нужно переходить к более «умному» рантайму (OSGI или как в .NET CLR), или эмулировать его (например как это сделано в NixOS с пакетным менеджером Nix). Этот рантайм должен уметь одновременно грузить обе версии так, чтобы они друг другу не мешали. Ведь нет никаких гарантий, что пакет, который хочет зависимость именно D версии 2, заработает успешно на D версии 1, и наоборот.
Мою посуду во время приготовления пищи, все равно делать нечего пока стоишь на кухне и ждёшь. Главное не откладывать это дело в долгий ящик, потому что смотивировать себя разобраться с горой посуды несравнимо сложнее, чем помыть 2 тарелки и одну сковородку за 3 минуты.
Интересно! Давно хотел почитать какую-нибудь книгу именно о философии практик программирования, ведь в современных подходах просто до ужаса много общего, и всегда интересно знать мнение товарищей, чей опыт использования отличается от собственного. Надеюсь, в продолжении книги этот лейтмотив развивается, а не остается на уровне тривиальных примеров.
Снова великий и ужасный user experience. Сложнопереводимая штука )