Different state of real class properties and schema properties: nullable

[dmitrach]

Hello. Thank you for your package, it has saved some my time due to existent documentation in classes.

But I found a feature or a bug) when the real properties of a class are different with schema properties.

Steps to reproduce

I have the next code.

    /**
     * Some description.
     *
     * @OA\Property(nullable=false, format="number", example="0.00")
     */
    public ?string $value = null;

It describes the value that has the default value null, but this value is never returned in responses and there is always non-null values, like 0.00.

I expected the follow description in yaml. There is nullable: false or without nullable due to I redefine this property.

      properties:
        annual:
          description: 'Some description.'
          type: string
          nullable: false # here
          format: number
          example: '0.00'

or

      properties:
        annual:
          description: 'Some description.'
          type: string # there isn't nullable here
          format: number
          example: '0.00'

But I got the follow result.

      properties:
        annual:
          description: 'Some description.'
          type: string
          nullable: true # here
          format: number
          example: '0.00'

To fix it I've redefined the value type: type="string".

    /**
     * Some description.
     *
     * @OA\Property(type="string", format="number", example="0.00")
     */
    public ?string $value = null;

Now I got this result.

      properties:
        annual:
          description: 'Some description.'
          type: string # there isn't nullable here, because I defined another type.
          format: number
          example: '0.00'

I would like to know, it is a bug or a feature? Perhabs the tool should override the detected state of the property.

Thank you!

[DerManoMann]

A bit of both, probably.

Type handling is not very consistent and the introduction of attributes added to that too.

There are no clear rules about priority, but I agree the annotation should be the authority in this case.
Hopefully this will be fixed as part of #1310