Fully 30% of the window height is administrative debris. There are ten arrow buttons. The window close control is directly above the Edit menu.

Complexity is not your friend. Fitt’s Law is not your enemy.

bar = []
def test():
    new = ['this', 'comes', 'from', 'test']
    bar.extend(new)
    print bar

print bar
test()
print bar

This code generates this output:

[]
['this', 'comes', 'from', 'test']
['this', 'comes', 'from', 'test']

Which is to say, bar is empty before test(), has the contents of new inside of test(), and continues to have that value when test() returns.

Now, look at this code:

bar = []
def test():
    new = ['this', 'comes', 'from', 'test']
    bar = new
    print bar

print bar
test()
print bar

Which outputs:

[]
['this', 'comes', 'from', 'test']
[]

The value of bar is only changed inside test(). Upon further reflection, I realized that the assignment was assigning a new local variable inside the test() scope, whereas accessing bar returns the variable from the outer scope, which is then modified.

This behavior doesn’t make a whole lot of sense to me.

$db = new PDO('sqlite::memory:');
$stmt = $db->query('SELECT 1;');
$stmt->setFetchMode(PDO::FETCH_LAZY);
$row = $stmt->fetch();

$class = get_class($row);        // = "PDORow"
var_dump($row instanceof $class) // false!

What the hell. The object isn’t an instance of the class you just told me it was an instance of?

Or this lovely code I ran the other day, which crashes PHP:

class Yippee extends AppendIterator {
    public function __construct() {}
}
$yip = new Yippee;
$yip->rewind();

This will crash PHP with a segfault (on Linux) or a bus error (on OS X). Awesome.

class Foo
{
    private $var = 'avalue';
    private function doStuff()
    {
    }
}

As you might expect, you can’t access $var or doStuff() from outside Foo, which is well and good. However, things get strange when you throw overloading into the mix.

class Foo
{
    private $var = 'avalue';
    private function doStuff()
    {
    }
    public function __get($var)
    {
        return $this->$var;
    }
}

$foo = new Foo;
var_dump($foo->var);

This works; if a variable isn’t accessible from the calling scope, it will invoke __get() instead. Too bad it’s not consistent:

class Foo
{
    private $var = 'avalue';
    private function doStuff()
    {
    }
    public function __get($var)
    {
        return $this->$var;
    }
    public function __call($func, array $args = array())
    {
        return call_user_func_array(array($this, $func), $args);
    }
}

$foo = new Foo;
var_dump($foo->doStuff());

This breaks with: “Fatal error: Call to private method Foo::doStuff() from context ”.”

It would be really nice if PHP followed the same rules for overloaded methods as for overloaded variables.

It’s weird and frustrating, and I wish it wouldn’t do that. Some of the consequences of this:

1. OS X shares your home directory and all attached disks if you enable AFP. For some reason, the iDisk’s name takes precedence – the “ieure” share on my laptop is my iDisk, while “ieure_homeDir” is my home directory. Worse, if you toggle between the two modes, the name of your home directory share changes with it.
2. The path isn’t consistent. So if you have a link from your real disk to your iDisk, then change modes, your links break.
3. If you mount another share which has the same name as your username, such as a home directory on another machine (without offline iDisk), or a private directory on an AirDisk, the name gets a numeral appended. Perhaps a minor quibble, nonetheless irritating.

I’m sure the mount point has to be defined somewhere, but I don’t know where. Anyone?