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('')

hikari-no-yume

#!/bin/sh
make clean
./vcsclean
./buildconf
YACC=/usr/local/opt/bison27/bin/bison ./configure --enable-debug --enable-phpdbg "$@"

hikari-no-yume

In languages like C, C++, C#, Java, and so on, void is used as the return type of a function that only performs side effects and does not return any value:

void foobar() {
    some_state++;
}

In such functions, it is illegal to use any form of return other than a no-value return:

void foobar() {

return; // okay

hikari-no-yume

# imagine, for a second:
db = new db('mysql:localhost')

results = (
    select
        name, age, photo
    from
        db.elePHPants
    where
        age > 16