Split Driver interface into Driver\Read and Driver\Write?

[driesvints]

I've currently created a ReadOnlyDriver but something tells me I could best split up the Driver interface into a Driver\Read and a Driver\Write and require the developer to optionally implement the write one. This would make it easier to set up a Lock instance which is only used for reading permissions from a storage.

Good idea?

[franzliedke]

Does it even make sense to call allow() etc. on the lock instance? Shouldn't this be done directly on the array storage driver when that is used?

[driesvints]

Does it even make sense to call allow() etc. on the lock instance? Shouldn't this be done directly on the array storage driver when that is used?

The driver's only purposes are storing/retrieving permissions. All the logic of validating permissions is handled in the Lock class. I'd rather keep an object's responsibilities as few as possible. Plus a driver should be something easy to create for developers so they can create their own implementations for their specific systems.

That being said, I think atm the Lock class perhaps handles too much responsibilities. I'm planning on splitting it into a CallerLock and RoleLock to reduce the code duplication and perhaps move the registration of roles and aliases to the manager instance. I'm going to play around with this idea this weekend and see what I can come up with.

[driesvints]

I'm gonna stick to the ReadOnly driver for now. This could perhaps be something for a future release.