From: <[EMAIL PROTECTED]>
Sent: Thursday, April 12, 2001 10:37 AM
> On Thu, 12 Apr 2001, Harrie Hazewinkel wrote:
>
> > [EMAIL PROTECTED] wrote:
> > >
> > > On Thu, 12 Apr 2001, Harrie Hazewinkel wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have made a new patch for the mpm_query functionality.
> > > >
> > > > 1) This patch extends the information that can be retrieved.
> > > > 2) It also allows to return an MPM_TYPE which is a string.
> > > > This is used to provide some additional information
> > > > about the MPM used. It even could be used by an MPM
> > > > developper to provide an arbitrary human readable
> > > > string which can be used for management purposes.
> > >
> > > -1 for returning the string from this function. It makes the function
> > > harder to read and to use. If you absolutely must have a way to query the
> > > MPM name, then use a separate function for it. Something like
> > > ap_show_mpm() like Sander suggested yesterday.
> >
> > You definitly have not understood the use of it.
>
> What?!? How have I not understood the use of it? I have simply said that
> adding the ability to return a string from that function makes the code
> unnecessarily ugly. I have suggested using a separate function for
> getting the same information that you want. I am not removing
> functionality, I am asking to make the code and the API simpler.
>
> ap_show_mpm should definately not be a wrapper around ap_mpm_query. if
> you are going to do that, then just don't create ap_show_mpm. The goal is
> to keep the API simple, not to make it overly complex by having two ways
> to get the exact same information.
or ap_mpm_something, since that appears to be the convention.
Yes, I'll +1 adding Harrie's patch (sans string) and a string getname function
as you've suggested.
Unless we have a massive list of other 'string' queries, which I doubt. This
makes both functions more typesafe and simpler.
