Fluent Generics in C#

Я бы пофантазировал на тему:

class FireBall : Spell
  .WithSphere<Fire>
  .WithTarget<LandPoint>
  .WithArea<SphereVolume>
  .WithEffect<AreaDamage>
{
  public override Cast(/* ... */)
  {
    //...
  }
}

class Heal : Spell
  .WithSphere<Light>
  .WithSelfTarget
  .WithEffect<RestoreHealth>
{
  public override Cast(/* ... */)
  {
    //...
  }
}

Но это не точно!

Fluent Generics in C#

Ну да. override не почистил, базовый класс не указал. Спасибо за замечание.

код оставлю в старом виде - чтобы было понятно, какой был оригинал )

Fluent Generics in C#

Подход забавный, но код, который приводится как пример не решает никакой полезной задачи. Вместо предлагаемого автором кода вида:

public class SignInEndpoint : Endpoint
    .WithRequest<SignInRequest>
    .WithResponse<SignInResponse>
{
    [HttpPost("auth/signin")]
    public override async Task<ActionResult<SignInResponse>> ExecuteAsync(
        SignInRequest request,
        CancellationToken cancellationToken = default)
    {
        // ...
    }
}

я могу спокойно написать:

public class SignInEndpoint
{
    [HttpPost("auth/signin")]
    public override async Task<ActionResult<SignInResponse>> ExecuteAsync(
        SignInRequest request,
        CancellationToken cancellationToken = default)
    {
        // ...
    }
}

Поэтому и сижу, думаю: зачем?! Не в плане покритиковать, а в плане придумать, где это может быть оправдано.

Раздувание кода стало астрономическим

Я бы маленькое уточнение добавил по поводу Elite: на спектурме все адресное пространство было размером в 64кб. Включая 16кб, занятых под ПЗУ (по современному - под операционную систему). И в это же адресное пространство входила и видеопамять размером порядка 6кб. То есть под саму игру было не 64кб, а всего 42кб.

Тайловое освещение без боли

Возможно, будет интересно.

Вот здесь описан похожий алгоритм с оптимизацией расчетов и использованием рекурсии (в конце статьи есть примеры реализации на разных языках).

Самый беззащитный — уже не Сапсан. Всё оказалось куда хуже…

суд не так работает (мы же говорим о том, попадает ли автор статьи под действие 272 УК?).

суд берет текст статьи, практику правоприменения данной статьи, а так же разъяснения верховного суда (если есть). и именно по ним и принимает решение.

а не вот эти все философские: «а если копнуть глубоко, то когда ты смотришь на объект, то ты создаешь в мозгу его копию в виде сигналов нейронов, а значит, если ты посмотрел, то ты скопировал» и т.п.

Самый беззащитный — уже не Сапсан. Всё оказалось куда хуже…

А скриншоты не являются копированием информации?

а вот тут уже надо смотреть юридическую практику.

сам не готов вот прямо сейчас дать готовый ответ: по остаточным знаниям от второго образования могу предположить, что зависит от того, какая информация есть на скриншоте.

это как с порно: замазал/замылил первичные и вторичные признаки и уже не попадаешь под определение порнографии. хотя суть-то осталась =)

Самый беззащитный — уже не Сапсан. Всё оказалось куда хуже…

суд принимает решение не по аналогиям, а по вполне определенным правилам: опираясь на текст конкретной статьи и практике применения данной статьи.

мы же говорим о том, «попадает ли автор под действие статьи?», а не про то, считаю ли я преступлением то, что кто-то сумел подобрать пароль к моей почте?

Самый беззащитный — уже не Сапсан. Всё оказалось куда хуже…

зачастую, абсурден не закон, а трактовка закона лицом, не имеющим юридического образования.

ну пусть даже без юр. образования. просто лицом, даже не прочитавшего статью целиком и судящего о статье по ее названию.

что-то в духе:
— ага, в названии есть словосочетание «неправомерный доступ»! ой, а я видел скриншоты… меня посадят! как страшно жить в этой(tm) стране…

Самый беззащитный — уже не Сапсан. Всё оказалось куда хуже…

и снова надо читать формулировку целиком:

Деяния, предусмотренные частями первой, второй или третьей настоящей статьи, если они повлекли тяжкие последствия или создали угрозу их наступления

нет деяний (а именно, копирования, модификации, удаления и т.п.) — нет состава преступления даже для первой части, не говоря уже о четвертой.

Самый беззащитный — уже не Сапсан. Всё оказалось куда хуже…

чтобы решать, попадает автор под действие статьи или нет, нужно не ее название читать, а саму статью:

Неправомерный доступ к охраняемой законом компьютерной информации, если это деяние повлекло уничтожение, блокирование, модификацию либо копирование компьютерной информации

Самый беззащитный — уже не Сапсан. Всё оказалось куда хуже…

по этой статье судят не за сам доступ, а за, цитирую:

«Неправомерный доступ к охраняемой законом компьютерной информации, если это деяние повлекло уничтожение, блокирование, модификацию либо копирование компьютерной информации»

Динамические мат. функции в C++

>Ну да, как это использовать.
>Например вот так:
>func_t f1 = cos(5 * func_t() + 8);
>это создаст, как видно, функцию
>f1(x) = cos(5x + 8)

Для тренировки полезно: пока все это заработает, надо достаточно много тонких моментов вспомнить. Только в реальных проектах этим лучше не пользоваться. Лучше:

double f1 (double x) { return cos(5*x + 8); }

=)

Миникостыли: склеиваем строку из фрагментов

Интересно было бы сравнить по скорости/памяти ваш и мой подходы.

Хотя заметный выигрыш в такой постановке задачи сложно получить: смысл увеличивать скорость функции, которая вызывается раз в несколько минут (ну пусть, в несколько секунд)?

Миникостыли: склеиваем строку из фрагментов

Знание лямбда-функций и Linq НЕ означает, что их надо использовать везде, где только можно =)

Миникостыли: склеиваем строку из фрагментов

Вот тут я поспорю: что легче воспринимается?

StringBuilder sb = new StringBuilder("1");
sb.Append("2");
string s = sb.ToString();

или

string s = "1" + "2";

И потом: простое != примитивное. Если уж на то пошло, вот такая строка (из комментария ниже) не примитивна, но и не читаема:

new [] { } .Where(p => p != null).Aggregate((f, s) => f + ', ' + s);

Миникостыли: склеиваем строку из фрагментов

Еще раз повторюсь:

последний пример был не очень удачным в том, что я сразу создал коллекцию как источник для фрагментов строк.

На самом деле речь идет о том, что у нас есть ряд независимых условий, каждое из которых проверяется отдельно. И только если это условие истинно, необходимо добавить в строку очередной фрагмент. А если работать с готовой коллекцией, то, разумеется, проще (как в первом комментарии):

s = string.Join(", ", arr);

Миникостыли: склеиваем строку из фрагментов

1) Не уверен, так ли это в C#, но почти наверняка конкатенация — это лишний вызов конструктора (как в Java и JS).

Так и будет. Но это не то место, где можно получить большую экономию в скорости/памяти. Поэтому я и предпочел использовать более читаемый вариант.

2) Цикл в примере ниже написан только для краткости самого примера. Я имел ввиду ситуацию, когда каждое условие проверяется отдельно. Поэтому Append может и не вызваться ни разу. Или всего для 1,2 условий из, скажем, десятка.

Естественно, когда у нас сразу есть коллекция, подобные костыли не нужны и задача решается гораздо проще.

Миникостыли: склеиваем строку из фрагментов

Спасибо! О таком теге раньше не знал, пользовался по-старинке сторонней утилитой.

Миникостыли: склеиваем строку из фрагментов

Join с уже готовой коллекцией работает. То есть сначала надо создать коллекцию, и только потом вызвать Join.