hikari-no-yume

<?php

function fixDir($dir) {
    $files = glob($dir . '/*');

    foreach ($files as $file) {
        if (is_dir($file)) {
            fixDir($file);
        } else {
            fixFile($file);

hikari-no-yume

<?php

class NotStringable {}
class Stringable {
    public function __toString() {
        return "foobar";
    }
}

$values = [

hikari-no-yume

<?php

function repeat_chunked($str, $initial, $count, $hyphen = "", $end = TRUE) {
    $result = "";
    $chunk = substr($str, 0, $initial);
    for ($i = 0; $i < $count; $i++) {
        $result .= $chunk . $hyphen;
    }
    if ($end) {
        $result .= $str;

hikari-no-yume

<?php
class Stringable {
    public $string;
    public function __construct($string) {
        $this->string = $string;
    }
    public function __toString() {
        return $this->string;
    }
}

hikari-no-yume

#!/bin/sh
find $1 -type f -name '*.phpt' -exec ./fixer {}  \;

hikari-no-yume

<?php

// make barewords legal!
$foo = bar . qux . boo; // no notices

use bareword as b;
$qux = b\baz;

// make barewords *illegal*!
$foo = bar; // error!

hikari-no-yume

Whether or not scalar type hints should be strict or not is a divisive issue in PHP. Both non-strict hints which cast values and reject others, and strict hints which only accept exactly matching types, both have advantages and disadvantages, supporters and detractors.

To avoid the problems with choosing one or the other, some people have previously suggested allowing both with different syntaxes:

function foobar((int) $a); // non-strict
function bazqux(int $a);   // strict

However, this would mean that different APIs would be using different approaches, and some even mixing the two. So, in your code, you'd have to deal with untyped, non-strict scalar and strict scalar types. It'd be quite confusing. I don't think this would be a good compromise. Some people want strict hints, some people want non-strict hints. I doubt anyone really wants to handle both. With this approach, the API designer forces their personal preference onto the API user, whether they like it or not.

hikari-no-yume

<?php

class ProceduralNumericSequenceGenerator {
    private $algo, $state;
    
    public function __construct($seed = NULL, $algo = "sha256") {
        if ($seed === NULL) {
            $seed = time();
        }
        

hikari-no-yume

<?php

class cons {
    private $head;
    private $tail;
    public function __construct($head, cons $tail = NULL) {
        $this->head = $head;
        $this->tail = $tail;
    }
    static public function car(cons $cons) {

hikari-no-yume

const rot13c = (c) =>
  ('a' <= c && c <= 'z') ? String.fromCharCode(97 + (c.charCodeAt(0) - 97 + 13) % 26) :
  ('A' <= c && c <= 'Z') ? String.fromCharCode(65 + (c.charCodeAt(0) - 65 + 13) % 26) :
  c

const rot13 = (str) =>
  Array.prototype.map.call(str, rot13c).join('')