Good, it gets clearer all the time.

I am going to block out tomorrow to work on this. I will probably aim
to implement the pipe, and do it in a  way to make it easier to
implement the #. The code in there at the moment is all rather quick
and dirty string handling that ends up populating an associative
array. I think I will try to turn this into building an object: a
methodSignature object, perhaps, that contains an argumentList object,
which in turn contains argument objects, which have a list of
allowable types etc etc etc.

Also tomorrow, I want to get round to incorporating the other fixes
you, Mike, have sent us in a couple of the pecl defects. You are
leading the way in the code contribution stakes.

It's good working with you all.

Matthew

On May 16, 9:09 am, Graham Charters <[EMAIL PROTECTED]> wrote:
> Hi Mike,
>
> Thanks for clarifying the use of pipe with the phpDocumentor
> developer.
>
> Yes, the # notation was simply an alternative way to identify a
> complex type in a schema.  It's largely orthogonal to nillable but I
> mentioned it for a few reasons:
>
> 1.  To raise the idea of us making both changes together since they
> will be in the same area of code.
> 2.  As an example where we could improve preserving the phpDocumentor
> generation (at the moment the namespace gets generated into the
> description :-( ).
> 3.  To solicit more feedback.
>
> My apologies if I caused some confusion.  I hope this helps clarify my
> intentions.
>
> Graham.
>
> On 15 May, 18:14, "Caplan, Michael" <[EMAIL PROTECTED]>
> wrote:
>
> > Hi Matthew,
>
> > I guess I am a little confused about the # notation that Graham outlined
> > (and wondered if that was just a slightly different way to handle the
> > problem).  Am I correct that Graham is getting at a new notation for
> > specifying elements from a schema?
>
> > IE:
>
> > @return elementhttp://Schema_NameSpaceDescription
>
> > Becomes:
>
> > @returnhttp://Schema_NameSpace#elementDescription
>
> > As for implementing pipe support in types, I spent some time in the code
> > thinking through what this could programmatically look like.  But, I'm
> > not so sure about the structural changes I came up with and possible
> > side effects.  Also, I wouldn't want to interfere with an architecture
> > choices that may be tied to future initiatives.  This said, I could
> > submit a patch if it would be of assistance, but I wouldn't be able to
> > get to it for at least a week.  The sort of it, yes please implement it.
> > Let me know if I can help in any way.
>
> > Best,
>
> > Mike
>
> > > -----Original Message-----
> > > From: phpsoa@googlegroups.com [mailto:[EMAIL PROTECTED] On
> > > Behalf Of Matthew Peters
> > > Sent: May 15, 2007 1:47 PM
> > > To: phpsoa
> > > Subject: [phpsoa] Re: nillable
>
> > > (Joining this thread a week late :-))
>
> > > Mike, you have done a fantastic job of researching the options. I'm
> > > puzzled why you say _two_ options: isn't there just one surviving
> > > idea, which is what you and Graham have converged upon, the use of the
> > > pipe symbol for both @param and @return, as in:
> > >       * @returnhttp://example.org/contacts#contact|null The full
> > > contact details
>
> > > I agree that this is a fine idea. Would you like me to go ahead and
> > > implement it? The parsing of the annotations is a bit of a rough area
> > > of the code so it does not seem fair that you should have to implement
> > > it as well, especially as you have made several other contributions in
> > > quick succession recently. But you would however be very welcome to do
> > > so if you wanted :-)
>
> > > Matthew
>
> > > On May 14, 2:37 pm, "Caplan, Michael" <[EMAIL PROTECTED]>
> > > wrote:
> > > > Hi Graham,
>
> > > > FYI, I just got word back from a PHPDocumentor developer re: @param
> > > > support for multiple types:
>
> > > > Hello Mike,
>
> > > > That functionality is both in there and supported, though it looks
> > > like
> > > > we could improve on how we demonstrate it in our manual.  I've
> > opened
> > > > PEAR bug #11032
> > > > (http://pear.php.net/bugs/bug.php?id=11032) to get the manual
> > updated
> > > > with better examples showing that "param type1|type2" usage, and
> > will
> > > > also add more detail to the return tag's doc.
>
> > > > Thanks for the posting...
> > > > Chuck
>
> > > > Now that we know that this is supported behavior, any thoughts on
> > the
> > > > two outlined methods for supporting nillable parameters?
>
> > > > Best,
>
> > > > Mike
>
> > > > > -----Original Message-----
> > > > > From: phpsoa@googlegroups.com [mailto:[EMAIL PROTECTED] On
> > > > > Behalf Of Graham Charters
> > > > > Sent: May 12, 2007 6:16 PM
> > > > > To: phpsoa
> > > > > Subject: [phpsoa] Re: nillable
>
> > > > > Hi Mike,
>
> > > > > One of the goals of the SCA annotations has been to try to
> > preserve
> > > > > phpDocumentor generation, so I like your suggestion a lot.  I took
> > > a
> > > > > look at the phpDocumentor documentation and could only see mention
> > > of
> > > > > the pipe for multiple function returns, but not for parameters.  I
> > > > > gave it a whirl for both and phpDocumentor 1.3.0 doesn't appear to
> > > do
> > > > > anything special with the pipe and doesn't care if it's included
> > in
> > > an
> > > > > @param.
>
> > > > > If we include the modification suggested in another thread where
> > we
> > > > > would change the way complex types are specified to use the #
> > > > > character (will improve the quality of the phpDocumentor
> > > generation),
> > > > > then an example SCA component might look like this:
>
> > > > > /**
> > > > >  * Service for managing email contacts
> > > > >  *
> > > > >  * @service
> > > > >  * @binding.soap
> > > > >  * @typeshttp://example.org/contactscontacts.xsd
> > > > >  *
> > > > >  */
> > > > > class ContactService {
>
> > > > >     /**
> > > > >      * Retrieve contact details
> > > > >      *
> > > > >      * @param string|null $shortname The short name of the contact
> > > > >      * @returnhttp://example.org/contacts#contact|null The full
> > > > > contact details
> > > > >      */
> > > > >     public function retrieve($shortname) {
> > > > >     }
>
> > > > > }
>
> > > > > Let me know if I've misunderstood your proposal.
>
> > > > > The only reason I can think for the generation of nillable all the
> > > > > time would be to support as many calling options with as little
> > > > > configuration as possible.  I can understand why the other way
> > > round
> > > > > might be preferable and adding control through the annotations
> > gets
> > > my
> > > > > +1.
>
> > > > > Graham
>
> > > > > On 11 May, 18:40, Michael Caplan <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > > > 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 ...
>
> > > > > E-mail messages may contain viruses, worms, or other malicious
> > > code. By reading the message and opening any attachments, the
> > recipient
> > > accepts full responsibility for taking protective action against such
> > > code. Henry Schein is not liable for any loss or damage arising from
> > > this message.
>
> > > > The information in this email is confidential and may be legally
> > > privileged. It is intended solely for the addressee(s). Access to this
> > > e-mail by anyone else is unauthorized.
>
> > > E-mail messages may contain viruses, worms, or other malicious code. By 
> > > reading the message and opening any attachments, the recipient accepts 
> > > full responsibility for taking protective action against such code. Henry 
> > > Schein is not liable for any loss or damage arising from this message.
>
> > The information in this email is confidential and may be legally 
> > privileged. It is intended solely for the addressee(s). Access to this 
> > e-mail by anyone else is unauthorized.


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to