Привет, Хабр! Меня зовут Юра Кучанов, работаю Android разработчиком в Garage Eight и сегодня хочу рассказать о том, как мы делали Retrofit-подобную библиотеку для JSON-RPC протокола. Началось всё с того, что нам потребовалось для общения сервера и Android приложения использовать протокол JSON-RPC. Что значит “потребовалось”? Если кратко – бэкендеры предложили, а сильных аргументов против, в сущности, не нашлось =) Возможно, тут сработала, например, вот эта статья с хабра про выбор между REST и JSON-RPC. В итоге я пошёл искать библиотеки в сети и… И обнаружил, что готовые решения не подходят (так как там, конечно же, есть хотя бы один фатальный недостаток). В итоге сделал свою библиотеку в стиле Retrofit. Ниже расскажу, почему не подошли готовые решения, как реализовал своё через рефлексию и как копался в исходниках Retrofit и OkHttp для реализации нужного нам функционала.
Вы знали, что AutoMapper и MediatR создал один и тот же человек?
Джимми Богард создал две крайне обсуждаемые и спорные темы в .NET разработке. Если с MediatR уже разобрались, то c AutoMapper также хотелось бы расставить все точки над "ё".
В этой статье хочу поговорить об истории возникновения библиотеки. О том какую задачу она была призвана решать изначально. И уделить внимание её недостаткам.
В процессе разработки очень часто возникает необходимость создать экземпляр класса, имя которого хранится в конфигурационном XML файле, или вызвать метод, название которого написано в виде строки как значение атрибута аннотации. В таких случаях ответ один: “Используй reflection!”.
В новой версии CUBA Platform одной из задач по улучшению фреймворка было избавление от явного создания обработчиков событий в классах-контроллерах UI экранов. В предыдущих версиях объявления обработчиков в методе инициализации контроллера очень захламляли код, так что в седьмой версии мы решительно намерились все оттуда вычистить.
В статье рассматривается декларативный скриптовый язык JavaPath как альтернатива использованию Java Reflection и способ избежать "сервисного ада" в обособленных приложениях использующих сложные структуры данных.
Рассмотрим глубоко вложенную структуру
class A{
B b;
}
class B{
C c;
}
class C{
String name;
}Если нам нужно присвоить значение полю name класса C, не имея при этом непосредственного доступа к экземпляру A, то на помощь, обычно, приходит промежуточный слой сервисного API.
private A a;
public void setNameService(String name) {
a.b.c.name = name;
}Совершенно очевидно, что данный код не работоспособен, так как ни одно из полей у нас не проинициализированно. Для того чтобы сделать этот код работоспособным, все поля должны существовать до того как выполнится цепочка вызовов.
private A a;
public void setNameService(String name) {
if(a == null) {
a = new A();
}
if(a.b == null) {
a.b = new B();
}
if(a.b.c == null) {
a.b.c = new C();
}
a.b.c.name = name;
}
Каждый Ангуляр разработчик видел декораторы в тайпскрипт коде. Их используют, чтобы описать Модули, сконфигурировать Dependency Injection или настроить компонент. Другими словами, декораторы используются, чтобы описать дополнительную информацию, или метаданные, для фреймворка или компилятора (в случае Ангуляра). При чем, Ангуляр лишь один из примеров. Существуют многие другие библиотеки, использующие декораторы для простоты и наглядности кода, как декларативный подход. Как .NET разработчик в прошлом, я вижу много сходства между TS декораторами и .NET аттрибутами. Наконец, набирающий популярность NestJS фреймворк для бекенд приложений (абстракция над Node), также построен на интенсивном использовании декораторов и декларативном подходе. Как это все работает и каким образом использовать декораторы в своем коде, чтобы он был более удобным и читабельным? Мы все понимаем, что после компиляции TS кода мы получаем Javascript код. В котором нет понятия декоратор, как и многих других Typescript особенностей. Поэтому для меня наиболее интересным является вопрос, во что превращается декоратор после компиляции. Занимаясь этим вопросом, я сделал выступление на митапе в Минске и хочу поделиться статьей.
Привет, Habr! Сегодня хочу рассказать про свой костыль, который помог мне не погружаться в дебри PHP Reflection. Ведь все пишут костыли, просто кто-то пишет большие, а кто-то поменьше.
Продолжаю серию публикаций Fil по CppCon 2017. В докладе представлены ранние наработки по добавлению рефлексии и кодогенерации в C++, а также по метаклассам, которые позволят генерировать части классов C++. В стандарт эти новшества попадут не ранее, чем в C++23.
Конструктор java.lang.Class является одной из самых охраняемых сущностей в языке Java. В спецификации чётко сказано, что объекты типа Class может создавать только сама JVM и что нам тут делать нечего, но так ли это на самом деле?
Предлагаю погрузиться в глубины Reflection API (и не только) и выяснить, как там всё устроено и насколько трудно будет обойти имеющиеся ограничения.
struct complicated_struct {
int i;
short s;
double d;
unsigned u;
};
#include <iostream>
#include "magic_get.hpp"
struct complicated_struct { /* … */ };
int main() {
using namespace pod_ops;
complicated_struct s {1, 2, 3.0, 4};
std::cout << "s == " << s << std::endl; // Compile time error?
}
antoshkka@home:~$ ./test
s == {1, 2, 3.0, 4}
Эта статья является пересказом моего доклада на Java-конференции SnowOne 2021 года. LJV — проект, созданный в 2004 году как инструмент для преподавания языка Java студентам. Он позволяет визуализировать внутреннее устройство структур данных. В этом докладе я запускаю LJV на разных структурах (от String до ConcurrentSkipListMap) в разных версиях Java и разбираю, что там внутри, как оно менялось от версии к версии, и как это всё работает.
C# — невероятно гибкий язык. На нем можно писать не только бэкэнд или десктопные приложения. Я использую C# для работы, в том числе, и с научными данными, которые накладывают определенные требования на инструменты, доступные в языке. Хотя netcore захватывает повестку дня (учитывая, что после netstandard2.0 большинство фич как языков, так и рантайма, не бэк-портируются в netframework), я продолжаю работать и с легаси-проектами.
В этой статье я рассматриваю одно неочевидное (но, наверное, желаемое?) применение Span<T> и отличие реализации Span<T> в netframework и netcore из-за особенностей clr.
