ReaderWriter constructor parameters

[determin1st]

checkout this issue:

php/doc-en#1397

name ~ cannot contain \ character
autounlock ~ is integer type not boolean type

[determin1st]

the same argument behaviour is for SyncEvent object

thrown errors

SyncEvent::__construct(): Argument #2 ($manual) must be of type int, bool given
SyncEvent::__construct(): Argument #3 must be of type int, bool given

[cubiclesoft]

The name limitation is kind of to be expected. On Windows, you are limited to what Windows named objects allow (see the Microsoft API documentation for CreateMutex, CreateEvent, etc.). On other OSes, you are limited to legal filesystem names as those are stored in shared memory objects. Mac OSX is the least flexible and has the most limitations. Your best bet is to stick to short and simple alphanumeric strings (A-Z, a-z, 0-9). Naming limitations are due to limits in the OS itself, not PHP.

As to the long/int vs. boolean issue, are you using PHP strict mode? Strict mode is the only thing I can think of that would trigger errors for simple type conversion. The zend_parse_parameters() function intakes a long int from the caller and internally converts to equivalent boolean for the actual OS level system calls (e.g. non-Windows needs the value to be an int). For PHP strict mode, you might have to explicitly cast the boolean to int. CPUs don't actually have a boolean data type. Booleans are therefore more or less a made up construct that are implemented using integers as zero vs. non-zero values. When I wrote that code for PHP 5.3, I was probably being strict in the documentation sense but more open on the actual implementation to allow a wider range of inputs (i.e. not force the average user to cast). Not sure if I should try to change it at this point. It would be nice if an extension could call zend_parse_parameters_ex() with a flag to bypass strict mode int/bool type checks.

[determin1st]

i see, good explanation, you are right, im using strict mode with this directive declare(strict_types=1);

as the php adopted this strict style in the doc, specifying true or false will not work in strict mode and it (the documented function spec) should change for this extension or the code should be corrected to accept bool. which variant you say is better? depends on your decision. maybe it will be easier to change the code than doc but then i would have to update every constructor call from int to bool, not a problem, because i've seen the doc about this extension only recently and decided to test it a bit, so, i've used file path as a name, i guess names should be hashes or identifiers then.