Struct

gistfile1.php

<?php

// Basically a strict object with no methods
class Struct {
public $foo;
public $bar;
}

$struct = new Struct(['foo' => 'something']); // constructor args would get pushed to properties ???
$struct->foo = 'whatever';
$struct->no = 'foo'; // This would throw an exception

// But how woudl you type it? perhaps a special method to get teh definition?
class Struct {
public $foo;
public $bar;

protected function define() {
  return ['foo' => 'int',
  'bar' => 'mixed'];
}

$struct = new Struct();
$struct->bar = 'hi!'; // ok
$struct->foo = 2; // ok
$struct->foo = 'boo'; // exception

@Antnee That's essentially what I was proposing above, although I would go a step further and include Properties.

What I'm not sure about is inheritance and interfaces. Does extending a struct make sense, or should it be mixins-only via traits? Does an interface on a struct even make sense? I'm not sure.

@Crell - I like the idea of property accessors for classes, but I need something much more lightweight. Something where all properties are public and there are no methods attached, or at least as few as possible. Bare minimum magic. Basically, something that I can use huge numbers of (if necessary) in a small script and not have a server come crashing to the ground. Add accessors to classes (at some point, please!) but let's have simple structs.

Traits vs inheritance? Aren't traits pretty much a workaround for the fact that there is no multiple inheritance in PHP and for handling conflicting methods? Personally, I dislike the trait syntax, and since my struct is nothing more than a strict property container, I don't see any benefit from using traits right now. Just allow multiple inheritance instead. Same job, surely?

<?php
struct User {
    string $name;
    string $email;
    bool   $active;
    int    $maxLogins;
}

struct Admin {
    int  $maxLogins = -1;
    bool $admin = true;
}

/**
 * Extends multiple structs
 */
struct AdminUser extends User, Admin {}

The issue here would be that $maxLogins exists in both User and Admin. Both are int types, but the Admin property has a default value. Would suggest that if one has a default and the other doesn't that the default value is applied, but what if both have default values? Probably going to end up with some messy syntax and traits become the preferred solution. I may have just convinced myself that traits are a better solution... but I still don't like the syntax...

Well, the concern with property access on classes is that determining at runtime what was a property and what was a bare object member was prohibitively costly. My thinking is that if structs are a new thing, baking property accessors in from the get-go sidesteps that question. (And it's on value objects where they would be most useful anyway.) That said, they can/should be optional. If all you want is the default behavior of write-to-property/read-from-property, sure, leave them out.

Traits vs. multiple inheritance: Meh, as long as I can mix multiple pieces together to make one big piece I'm impartial on the details. I'm thinking, eg, cases where I've had Doctrine objects with 4-5 traits in them for fields that are shared between many entities (one property, 2 methods, plus annotations), but inheritance is a wrong/unworkable tool. Traits are fantastic for that, I found. 😄