olleharstedt

//<?php echo "\x08\x08"; ob_start(); ?>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <glib.h>
#include <math.h>
#include <phollylib.c>
#if __PHP__//<?php
class GString { public $str; public function __construct($str) { $this->str = $str; } }
function g_string_new(string $str) { return new GString($str); }

olleharstedt

<?php

namespace LimeSurvey\Models\Services;

use DI\DependencyException;
use LimeSurvey\DI;
use LSYii_Application;
use Survey;
use Permission;
use Question;

olleharstedt

<?php

function getAttributesFromTheme(string $themeName)
{
    $theme = $this->getTheme($themeName);
    if (empty($theme)) {
        return null;
    }
    $xml = $this->getXmlFromTheme($theme);
    if (empty($xml)) {

olleharstedt

function getAttributesFromTheme(string $themeName)
{
    $theme = $this->getTheme($themeName);
    if (empty($theme)) {
        return null;
    }
    $xml = $this->getXmlFile($theme->path);
    if (empty($xml)) {
        return null;
    }

olleharstedt

//<?php echo "\x08\x08"; ob_start(); ?>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <glib.h>
#include <math.h>
#include <phollylib.c>
#if __PHP__//<?php
class GString { public $str; public function __construct($str) { $this->str = $str; } }
function g_string_new(string $str) { return new GString($str); }

olleharstedt

<?php // @pholyglot

class Body
{
    public float $x;
    public float $y;
    public float $z;
    public float $vx;
    public float $vy;
    public float $vz;

olleharstedt

<?php

namespace Tmp6;

use InvalidArgumentException;

interface Node
{
}

olleharstedt

<?php

/**
 * EDSL = embedded domain-specific language
 * The domain in this example is "side-effects", anything writing/reading to io, database, file, etc
 *
 * Using this EDSL, you neither need DI nor mocking to make the code testable. You can dry-run the particular
 * parts needed of the "effectful" logic.
 *
 * Inspired by tagless-final pattern from FP. https://okmij.org/ftp/tagless-final/course/optimizations.html#primer

olleharstedt

Pre-req: Functional core, imperative shell

Pre-req: Side-effects, purity, referential transparency

• The functional core is more testable and more composable than the imperative shell or effectful code
• Extending the functional core means making a bigger part of the software pure
• Side-effects can in some cases easily be lifted out from a function, creating a more composable and testable unit
• But sometimes, side-effects are tangled in business logic
• Some side-effects can be delayed until end of request (e.g., updating user's name in database; exception at failure can still be thrown)
• Example: Create dummy users

olleharstedt

class Query {
    constructor() {
        this.select = '';
        this.from = '';
        this.where = '';
    }
}

for (let i = 0; i < 1000000; i++) {
    const q = new Query();