C# nullable refs and virtual vs abstract properties

Consider:

public class InitialStep2Sqlite : ScriptMigration
{
    protected override string UpPath => "Sqlite2.Up.sql";
    protected override string DownPath => "Sqlite2.Down.sql";
}

public abstract class ScriptMigration : Migration
{
  protected virtual string UpPath {get;}
  protected virtual string DownPath {get;}

  protected override void Up(MigrationBuilder mb) 
    => mb.RunSqlFile(UpPath);
  protected override void Down(MigrationBuilder mb) 
    => mb.RunSqlFile(DownPath);
}

which, compiled under nullable enable, says “[CS8618] Non-nullable property 'UpPath' must contain a non-null value when exiting constructor. Consider declaring the property as nullable.”

Changing the property's virtual to abstact removes the warning.

The lesson: If your non-null proof of a property depends crucially on the subclass making it non-null, then making the parent property abstract not virtual is the correct statement of intent.

Generally, if a parent Member depends on the subclass for correctness – if the parent can't provide a correct implementation itself – then, logically, its correctness requires it to be abstract not virtual.

Simpson’s Paradox

Alice and Bob compete. Bob wins convincingly both times. But overall, Alice is better. How come?

This happens for real in medical trials and cases where you don't have much control over the size of groups you test on:


AliceBob
Trial 1 Score8010
–Out Of /100 /10
––Percentage => 80%=> 100%
Trial 2 Score240
–Out Of /10 /100
––Percentage=> 20%=> 40%
Total Score8250
–Total Trials /110 /110
––Percentage=> 75%=> 45%

The points to notice:

• In each trial, they got different sized groups assigned to them. There can be good reasons for this. One procedure may be known (or thought) to be better for specific circumstances so it would unethical to assign procedure based on “we want to simplify our statistical analysis” rather than on best possible outcome. Or you may simply be combining statistics about things not in your control.

• Alice's score for her largest group is better than Bob's score for his largest group, but those ‘largest groups’ were in different trials so they only ever get compared in the overall figure.

More on wikipedia: https://en.wikipedia.org/wiki/Simpson%27s_paradox.

Customise Macos XQuartz : xinitrc doesn’t work

If you installed XQuartz and are, for instance, irritated by the small white xterm window you get, you might try customising it in the usual way by editting an .xinitrc file. If only.

Instead, try this:

defaults read org.macosforge.xquartz.X11

to see all the settings; or to permanently change the startup xterm window, something like:

defaults write org.macosforge.xquartz.X11 app_to_run \
 "/opt/X11/bin/xterm -fa Monaco -fs 12 -fg green -bg black -sb -sl 1000"

Or, if you have installed a better bash with homebrew, then e.g. :

defaults write org.macosforge.xquartz.X11 app_to_run \
  "/opt/X11/bin/xterm -fa Monaco -fs 12 -fg green -bg black -sb -sl 1000 -ls /usr/local/bin/bash"

You can check your syntax before writing the default just by running your quoted command in a terminal, and then watch as XQuartz opens and xterm runs your shell:

~/Source/Repos/VMs] /opt/X11/bin/xterm -fa Monaco -fs 12 -fg green \
    -bg black -sb -sl 1000 -ls /usr/local/bin/bash

To set the default for a new xterm window from the XQuartz Application menu, the menu itself lets you edit the command.

In short, read the FAQ : https://www.xquartz.org/FAQs.html.