- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
private static Properties[] GetProperty(Properties[] collection, string property, string userName)
{
if (collection.Contains(property))
{
return collection[property];
}
else
{
throw new ArgumentException($"Property '{property}' for user '{userName}' was not found");
}
}
Шарпик таки превратили в пыху?
https://www.python.org/dev/peps/pep-0498/
Хз, может нету, но будет
пистон 2.7 надо запретить, а таких как ты -- насильно пересадить на 3.6
обосцать и сжечь
Да и хуй с ним. Байтовые строки - это хорошо (я кретушок).
> асинкио
Да и хуй с ним. Есть торнадо.
> опт стат тип
Да и хуй с ним. Даже не знаю, что это.
> тупое ооп
Нормальное ооп: классы, объекты там. Это же скриптота, зачем там мощные средства для создания абстрактных фабрик интерфейсов?
нет
>>Да и хуй с ним. Есть торнадо.
стандартное лучше кастомного
>>Нормальное ооп:
(object) ггг
>> Ну это точно не нужно
а ABC нужны? "string-like classes" нравяца?
теперь и в питоне и в котлине и в руби и в перле и в выхе и с решеточке
Завидовать ПХП может только тот, кто ничего кроме пхп не знает
Вот типа такого:
Т.е. шаблоны могут по строке с известной максимальной длиной парсить и подставлять сущности.
Только там sqr и f2 у меня были жёстко заданы.
boost::lambda можно расширять своими оперециями на своих типах: http://www.boost.org/doc/libs/1_60_0/doc/html/lambda/extending.html
Скажем, у нас есть KEY("abc"), который на самом деле key<'a','b','c'> - точно можно реализовать. Компайл тайм парсинг строки реализовать можно. Для %{abc} построить key<'a','b','c'> наверно можно.
Для каждого участка строки без форматирования запиливаем insert_string<строка>, для переменных - insert_variable<ключ>. Для конкатенации - concat<x, y>.
По умолчанию insert_variable<любая фигня>::value будет генерировать ошибку компиляции, а мы, если язык позволяет определить специализацию insert_variable<key<'a','b','c'>>, победим хотя бы в случае с глобальными переменными.
INTERPOLYACYYA("x: %{x}!") превратится в concat<concat<insert_string<'x',':',' '>, insert_variable<key<'x'>>>, insert_string<'!'>>::to_string()
Конечно, может в реальности наткнёмся на подводные камни, но можно попробовать.
При создании каждой переменной будет создаваться объект типа Variable, который
1. будет хранить ссылку на переменную
2. будет уметь преобразовывать её в строку
3. в конструкторе зарегистрирует переменную в скопе variables
4. в деструкторе удалит переменную из скопа variables
Т.е. в рукотворном динамическом контексте variables будет жить отображение нашей переменной из лексического столько же, сколько живёт сама переменная.
insert_variable будет доставать переменную из variables.
variables будет мапой со стеком
push(name, variable) добавит или перекроет name
pop(name) откроет предыдущую версию name
get(name) вернёт текущую Variable для name
Имея зарегистрированные на этапе исполнения переменные, мы просто вызываем функцию от строки, которая их печатает подставляет.
Richard M. Stallman, Zachary Weinberg - The C Preprocessor https://gcc.gnu.org/onlinedocs/cpp.pdf, 3.9 Directives Within Macro Arguments:
Occasionally it is convenient to use preprocessor directives within the arguments of a macro. The C and C++ standards declare that behavior in these cases is undefined. GNU CPP processes arbitrary directives within macro arguments in exactly the same way as it would have processed the directive were the function-like macro invocation not present.
Если мы магически сможем обернуть #include в макрос, то создав файлы "a", "b", "c", ..., которые хранят a, b, c, мы получим преобразование символа в токен.
С токенами уже можно работать, определяя фигню вида #define F(x) F_##x, а так же запиливать конкатенацию или преобразовывать в строке.
Если обернём include, получим INTERPOLATE("x",":"," ","{","x","}","!"), которое преобразуется в фигню вида S0x7e S0x5c ... (с кодами символов, полученных через include), которое преобразуем в "x" ":" " " x "!".
а, точно
https://youtu.be/Jl8iYAo90pE