Haven't used the locks myself yet, but as it's not in the interface, how will I know this method exists?

with() doesn't tell me what this method does nor when it should be called (withXX is common for named constructors, not the case here).
Agree with Iltar about adding it to the interface while we can.

Thinking about closing this PR, Don't see a real avantage to use it

$lock->acquire()
try {
  doSomthing();
  doSomthing();
  doSomthing();
} finally {
  $lock->release()
}

vs

$lock->with(function() {
  doSomthing();
  doSomthing();
  doSomthing();
});

WDYT?

👍 for closing

Don't see a real avantage to use it

The advantage is to remove the freedom of a developer to produce a class of bugs where code never reaches the release() call. There are some developers, like me, who are lazy as shit and don't want to think at all. When I see your API I would probably never think about the consequences not putting the release into finally block. By not even giving me that opportunity, you will make my code a bit more robust.

Actually I would even suggest removing acquire and release completely from the public API.

Btw. anyone interested in taking over a surprisingly similar named project: php-lock/lock#13

I also agree that requiring two calls is more error prone. The same goes for transactions with DBAL: you have both choice for greater flexibility but using the transaction(callback) method is always safer.

+1 that this method is more solid than acquire/release pair. This just needs better name.

Well, as we cannot add the method in the LockInterface (it would be a BC break), this API is not possible. The helper function would need to be implemented separate (and receiving the LockInterface object and the callable as argument)

Well, as we cannot add the method in the LockInterface (it would be a BC break)

Adding is not a BC break. I suggest, add it and mark the others as deprecated. That should discourage users enough to use them. Then, the others can be removed in some distant new major release.

Adding a method to an interface is a BC break, given everybody who implements the interface will get a Fatal error: Class XXX contains 1 abstract method and must therefore be declared abstract or implement the remaining methods

Not sure to understand the point of deprecating all others (methods?)

Adding a method to an interface is a BC break, given everybody who implements the interface

Oh, true. Ok, you can't do that without BC breaking.

Not sure to understand the point of deprecating all others (methods?)

Removing freedom to enforce more robust client code. The idea of having one method is to help the user not to make the mistake of forgetting a release. If you still leave acquire and release in the API, users will use it and potentially shoot them self. Maybe I'm too drastic as there might well be a use case for having them serperate.

@chalasr @b1rdex I've suggested "with" as name because it is very common for this kind of RAII support, see try/with statement in Java 8+ or with statement in Python.
The meaning is "WITH this acquired resource do something then release it".