I've been looking into this issue further. The condition(s) to determine if a callable method parameter is nillable more tricky than I initially thought. I was hoping that a simple ReflectionParameter::allowsNull() call would be all that is necessary. However, and this makes perfect sense, all calls to allowsNull() will return true, with exception to parameters that use type hinting. Since type hinting does not cover primitives, this does not cut it.
I'm thinking that this boils down primarily to a PHPdoc issue. With the @param tag in PEAR's PHPDocumentor, you can split types with a pipe to indicate multiple acceptable types. So a "@param string|null $var" could be used to determine if the parameter is nillable or not. ReflectionParameter::allowsNull() could also be called to validate claims of something being nillable, should it be not using type hints. This would require a change to how SCA parses doc blocks to support piped types. However, probably there should be only one case where multiple types can be defined (this case), as it doesn't make sense in other SCA circumstances. Setting everything to nillable (as it currently does) does not make sense as I see it. If a system does not get put into place that allows for users to control how nillable is used in the generated WSDL, as a minimum, I think it should be suppressed. I think it makes more sense to assume all parameters as not accepting null values, then the reverse. Thoughts? Mike On May 9, 8:02 am, Caroline Maynard <[EMAIL PROTECTED]> wrote: > Caplan, Michael wrote: > > Forgive my ignorance, but why does the WSDL generator define all types > > as nillable? Should that not be defined depending on the prototype of > > the method it is bound to? > > You're right, there's a lot of information available from the > ReflectionParameter methods (allowsNull(), isOptional(), > isDefaultValueAvailable(), ...) which isn't being exploited at the > moment, but could potentially be used to improve the fidelity of the > generated WSDL. It's likely that Matthew already thought about this when > he developed that code and will know what the issues are. I'd say these > enhancements sound like wish-list items for someone ... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
