I'm not sure if allowing strings on the role class itself is a good idea. Programmers need to be aware that they are breaking the role relations when using these Methods. A string would indicate that an existing role would be used if it exists, but this isn't the case.

**Example:**
```php
$rbac->addRoleWithChildren('foo');

// later (foo already exists in rbac tree)
$newRole = new Role('bar');
$rbac->addRole($newRole);

$newRole->setParent('foo'); // new instance of a role named "foo"!
$newRole->addPermission('something');

$rbac->isGranted('foo', 'something'); // Will return false
```

**Option 1**
To allow strings without loosing the relations the implementation will need a deeper refactoring utilizing Rbac as role container: 
* The role itself will **not** contain any child roles itself, but name references to them. 
* The Rbac instance will keep all roles flat (this could also improve performance if the role name is used as key).
* The role must have a reference to the Rbac instance (possible BC break?)
* **Disadvantage**: Adding individual child roles with an existing name on purpose is no longer possible.

**Option 2**
Keep the existing implementation and
* Extend getRole() to search parents as well as children (what should be searched first?)
* Allow strings for add/setParent

Disadvantages:
* Performance impact (iteration over two iterators)
* Potential pitfall when using add/set methods on the role instances directly. (Requires documentation)
* Potential pitfall when accessing a role via its name (string value) with `Rbac::getRole`: The role might exist multiple times - only the first one is returned. (Requires documentation)
* Introduce a second iterator class to traverse parent roles recursively (the role iterator cannot satisfy this without breaking the permissions model)