Dependency Injection in MediaWiki

Today I read the documentation for how Dependency Injection is done in MediaWiki.

I had a few small nits to pick (such as their statement that services should be stateless) but… fair enough.

For myself I don’t usually use Dependency Injection and a Service Container, instead I prefer the Service Locator pattern which I find is simpler and more economical to use, especially in PHP where there is a single process per request.

Extreme late binding

There’s a famous quote from Alan Kay that you will see bandied about:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

I think I agree with him, but I often find myself wondering quite what he meant by “extreme late-binding”. I suspect he means that object instances can redefine stuff they inherited from their concrete class. If your OOP platform doesn’t support that, you can emulate it with data and API.

On the value of foreign key constraints

Here is something I would like to demo regarding foreign key constraints.

This regards what type of errors foreign key constraints can (and can’t!) save you from.

Occasionally you hear developers say how important foreign key constraints are and how foreign key constraints saved them from some bug. That might all seem well and good but when you think it through if a foreign key constraint saved you from a bug it also might very well just have been luck that saved you and the thing that went wrong might have gone wrong another way and have gone undetected as database corruption and potential accidental data disclosure to an incorrect entity.

To set the scene let’s use some schema/data from what we were talking about earlier:

create table t_skinny_customer (
  customer_id bigint not null primary key,
  customer_name varchar(255) not null,
  customer_record_created_on timestamp default current_timestamp,
  customer_record_updated_on timestamp default current_timestamp on update current_timestamp

create table t_skinny_customer_phone (
  customer_phone_id bigint not null primary key,
  customer_id bigint not null references t_skinny_customer( customer_id ) on delete cascade,
  phone_number varchar(255) not null,
  phone_type enum( 'phone', 'tollfree', 'mobile' ) not null default 'phone',
  phone_type_order tinyint unsigned not null default 0,
  phone_record_created_on timestamp default current_timestamp,
  phone_record_updated_on timestamp default current_timestamp on update current_timestamp

insert into t_skinny_customer (
values (
  'John Doe'
), (
  'Jane Doe'

insert into t_skinny_customer_phone (
values (
), (

Then let’s run this code:

    $stmt = $pdo->prepare("
        customer_id = :customer_id
        customer_phone_id = :phone_id

    try {

        'customer_id' => 3,
        'phone_id' => 11,

      assert( false );

    catch ( PDOException $ex ) {

      // 2024-02-13 jj5 - foreign key constraint saved the day!

        0 === strpos(
          'SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails'


      'customer_id' => 2,
      'phone_id' => 11,

    // 2024-02-13 jj5 - ... whoops! what we've done here is switch
    // one of John Doe's phone numbers to be one of Jane Doe's
    // phone numbers. The foreign key constraint is of no value in
    // detecting this type of data corruption.

Now I’m not saying that you shouldn’t have foreign key constraints. I’m just pointing out that if you do have foreign key constraints and you’re relying on them for “referential integrity” your door may be open for all manner of bugs (and exploits).

That your foreign key points to an actual record doesn’t necessarily imply that your foreign key points to a correct record.

Context object versus global variables

I’m reading A Philosophy of Software Design by John Ousterhout and he says:

The context object unifies the handling of all system-global information and eliminates the need for pass-through variables. If a new variable needs to be added, it can be added to the context object; no existing code is affected except for the constructor and destructor for the context. The context makes it easy to identify and manage the global state of the system, since it is all stored in one place. The context is also convenient for testing: test code can change the global configuration of the application by modifying fields in the context. It would be much more difficult to implement such changes if the system used pass-through variables.

Contexts are far from an ideal solution. The variables stored in a context have most of the disadvantages of global variables; for example, it may not be obvious why a particular variable is present, or where it is used. Without discipline, a context can turn into a huge grab-bag of data that creates nonobvious dependencies throughout the system. Contexts may also create thread-safety issues; the best way to avoid problems is for variables in a context to be immutable. Unfortunately, I haven’t found a better solution than contexts.

Okay, so I’m just gonna step way out of line over here and suggest something heretical… but shouldn’t you just use global variables? You only introduced the context object so you could tweak it in unit tests, and you could just change your tests so that each one ran in a new process. Just sayin’.

…I suppose for the sake of completeness I should add a little more from Ousterhout which he said prior to the above:

Another approach is to store the information in a global variable, as in Figure 7.2(c). This avoids the need to pass the information from method to method, but global variables almost always create other problems. For example, global variables make it impossible to create two independent instances of the same system in the same process, since accesses to the global variables will conflict. It may seem unlikely that you would need multiple instances in production, but they are often useful in testing.

…so he is bending over backward to support multiple tests in one process, but he could just run each test in its own process and his problem evaporates.

Learning Kdenlive: Audio Normalization

I’m slowly learning how to use my video production tools.

Yesterday I discovered the 2 pass audio normalization feature in kdenlive.

You seem to need to apply this effect to each clip separately.

This 2 pass effect is much easier to configure than the other normalization option, which requires more configuration settings.

With the 2 pass audio normalization you just nominate your desired volume, click Analyze, and you’re done. You need to do that for each clip.

Now that I know how to do this the audio on my videos shouldn’t be as terrible as it has been. Getting better. Slowly.