Incorrect handling of union types

[smx-smx]

Describe the bug
An incorrect package is generated when having 2 different requests with the same field name but different type.
This is the relevant WSDL snippet (redacted)

What happens is that a single Items class is generated for both RequestA and RequestB, having a field of type string[] (probably the last type encountered in the WSDL).
This makes it impossible to call RequestA due to the wrong type bindings.

<!-- request A -->
<xs:complexType name="RequestA">
	<xs:sequence>
		<!-- Here "Items" is a struct array -->
		<xs:element name="Items" type="ns2:Items"/>
	</xs:sequence>
</xs:complexType>

<!-- request B -->
<xs:complexType name="RequestB">
	<xs:sequence>
		<!-- Here "Items" is a string array -->
		<xs:element name="Items">
			<xs:complexType>
				<xs:sequence>
					<xs:element name="Item" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
				</xs:sequence>
			</xs:complexType>
		</xs:element>
	</xs:sequence>
</xs:complexType>

<!-- struct typedef -->
<xs:complexType name="Item">
	<xs:sequence>
		<xs:element name="A" type="xs:string"/>
		<xs:element name="B" type="xs:int"/>
		<xs:element name="C" type="xs:string"/>
		<xs:element name="D" type="xs:string"/>
	</xs:sequence>
</xs:complexType>

<!-- Item[] typedef -->
<xs:complexType name="Items">
	<xs:sequence>
		<xs:element name="Item" type="ns2:Item" maxOccurs="unbounded"/>
	</xs:sequence>
</xs:complexType>

To Reproduce
Steps to reproduce the behavior:

• During the package generation? no/yes (package generates without errors, but incorrectly)
• During the usage of the generated package? yes (validation error when adding Item[], string[] expected)

Expected behavior
Generate 2 different classes for the union type, one with a string[] field and another with Item[]

Additional context
Using wsdltophp/packagegenerator @ 5c8ee49

[mikaelcom]

It's seems to me it's similar to #247, thus it can be hard to handle especially if it concerns the response object as PHP wouldn't be able to differentiate the two structs, this is why the generator creates only one class.

In addition, it's based on the Structs returned by the SoapClient class so this is also the possible origin of the generated class.

I can take a further look to it if you provide me the WSDL at contact@mikael-delsol.fr.

[smx-smx]

I worked around this issue by making a callable function and using it like this:

$setItems = function($items){
  $this->Items = $items;
};
$setItems->call($reqA, $items);

So that I can set the field directly and skip the setter (with its type check), and it works.
Therefore I was wondering, what if we keep a single class per-item with opaque fields, but have different "models" for the conflicting types? This would let us work around the single-class limitation you talked about.

We could have a 1 to many mapping between the item class and multiple representations (models) for its fields.

As for sending the WSDL, I'm afraid I'd have to create a simplified and abstracted test case first...

[mikaelcom]

Or you disable the validation rules on the generation. In your case it's working because the property is an array of string or of Items. But if the proprty was either a string of an Item, your anonymous function would fail, am I wrong?

[smx-smx]

Not if the fields are only type hinted, or in other words of "mixed" type (and therefore not checked by PHP upon assignment).
If the "root" model only has untyped fields, multiple strongly typed models can then be "derived" from it

[mikaelcom]

But if you pass to the SoapClient a derived model instance containing the typed properties, then it would generated a bad XML request because the derived modules would not be mapped correctly for the XML request, or I misunderstood what you're saying.

Can you give an example?

[mikaelcom]

Possibly related to #268