[REQ] Improve php-laravel generator output when using _oneOf_

[holkerveen]

Is your feature request related to a problem? Please describe.

The generator output for a oneOf could be improved. I need properly typed models for each oneOf case. However, right now it seems to generate an object containing all possible properties.

Given this (minimal) example:

openapi: 3.0.0
info:
  title: Test oneOf
  version: 1
paths:
  /form-elements:
    get:
      responses:
        '200':
          description: Successful operation
          content:
            application/json:
              schema:
                type: array
                items:
                  oneOf:
                    - $ref: '#/components/schemas/TextElement'
                    - $ref: '#/components/schemas/RadioElement'
components:
  schemas:
    TextElement:
      properties:
        type:
          type: string
          enum: [text]
        placeholder:
          type: string
    RadioElement:
      properties:
        type:
          type: string
          enum: [radio]
        options:
          type: array
          items:
            type: string

The php-laravel generator generates something like:

class FormElementsGet200ResponseInner {
    public function __construct(
        public \OpenAPI\Server\Model\RadioElementType $type,
        public string $placeholder,
        public array $options,
    ) {}

Where I would expect something more along the lines of e.g. the typescript-fetch generator:

export type FormElementsGet200ResponseInner = RadioElement | TextElement;
export function FormElementsGet200ResponseInnerFromJSON(json: any): FormElementsGet200ResponseInner {
    return FormElementsGet200ResponseInnerFromJSONTyped(json, false);
}
// .. other stuff

In addition I believe the \OpenAPI\Server\Model\RadioElementType in the constructor to be incorrect, as its type could also be TextElementType.

Describe the solution you'd like

I would like to extend support for at least oneOf in the php-laravel generator, so that the oneOf generates a proper set of models.

The generated code should be more usable that way. I would assume that fixing anyOf and allOf would be trivial once oneOf is working correctly.

Describe alternatives you've considered

I considered using the type as-is and creating the discriminator logic in my specific application, but I think it would be better to adapt the generator to be more precise.

Additional context

Requesting feedback here to check if the solution follows the general idea, before working on a PR. Would appreciate feedback