Re: [pygccxml-development] single/multiple select interface

[Roman Y. <rom...@gm...>]

On 3/13/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > 1) In [1] function name is member_function, while in [2] it is member_f=
unctions.
> > I think that "s" is essential. First time when an user starts to use th=
is API
> > it could be confusing. I think he will expect one m.f. but will get som=
e other
> > class instance.
>
> I agree that distinguishing between a "1-result" and a "n-result" query
> has its merits. It's a much shorter form of the assert_count argument
> which enables the query function to perform a check on the number of
> declarations found.

Good.

> > 3) Lets see some ( =3D=3D my :-) ) patterns that an user has, while exp=
orting C++
> > library:
> > [...]
> >         If I will use [1] approach, I always will be forced to add a
> > "num_expected" argument.
>
> Why are you "forced" to do so? In my practical experience with my API
> this has not been the case and I was using the explicit assertion only
> in one single place.

May be because I want to track changes. Or may be, I want to be sure that
this is special case and it was applied only on single declaration.

> When you do queries for anything else than methods, then the cases where
> the user could be confused are rather rare. Suppose the user queries one
> particular class in some namespace:
>
> ns.Class("Foo")
>
> I believe your concerns so far have been that this might confuse a user
> when the result actually references more than one class. But when can
> that happen at all? C++ doesn't allow several classes with the same name
> in one namespace, so the undesired extra class must come from a
> namespace that lies within the ns namespace.
> In my case, I knew already in advance that all Maya classes are located
> in the standard namespace and there are no children namespaces that
> carry classes with the same name, so a line like the above could *never*
> reference more than 1 class and that's why I didn't need to add the
> assert_count argument to my queries.

So you do know the library you wrap :-). Also, while reading this code user
should remember that "recursive" flag value. In single select he does not n=
eed -
module builder will do the job.

> Don't get me wrong, I'm not arguing against the single/multiple
> interface. In fact, in a case like the above I agree that it is even
> superior because pyplusplus has more information about what the user
> actually intends (and it gets this information with very little effort
> from the user).

:-) We are talking about high level API, so I do want to argue a little :-)=
.
Also it was my filling, that you do not want to provide single API, because
you can achieve same effect using multi select version.

> I just wanted to point out that in most cases my version of the API is
> not as confusing as you make it sound sometimes. ;-)

Sorry, I tried to build a disscussion based on facts only, but it is
too difficult :-).

> However, it does make a difference when selecting methods (more on that
> below).

> > 5) How can an user rename all overloaded functions?
> >    mfs =3D module_builder.member_functions( .... )
> >    mfs.rename( "......" )
> >    In both solutions it simple
>
> Now that's the area where my concerns have actually been.
> In the above example the user *must* know in advance that he's dealing
> with a set of overloaded methods, and I think it could happen that he
> isn't really aware of the fact that a method has overloads.
>
> What if we treat a set of overloaded methods like one single method? I
> might argue that conceptually they already are one single method and
> it's only a syntax peculiarity of C++ that they have to be defined as
> separate methods (whereas on the Python side they will be combined to
> one single method again).

There are few possible solutions to the problem, but I prefer to solve
them next week,
after we will have some high level api that actually work.

> > 6) An other problem that I see in [1] approach. We want multi_decl_wrap=
per_t
> > to behave, as it is an instance of some declaration decorator/wrapper. =
We can
> > implement such behaviour only for "set" properties and functions that u=
ser
> > does not care about their return values. "get" properties could not be
> > implemented at all.
>
> I was always using the result of a query for decorating the
> declarations, so there was no case where I had to read attributes.
> But this could still be handled as follows: If all declarations return
> the same value for a particular attribute then this value is returned,
> otherwise None is returned or an exception is thrown.

Well, now we don't have to define the behaviour :-)

> Basically, I'm in favor of the single/multiple result distinction
> because it provides additional information to pyplusplus which can be
> used for checks.

Good. It was important to me to get your agreement. Now I also can work
on high level API.

Allen if you don't have some strong arguments against s/m select interfaces
I am going to implement that interfaces.

> The only problematic case is the presence of overloaded methods. Maybe I
> like the above exception best (i.e. to treat them as one single
> declaration).

After we will have some initial version we can try to implement
different solution.

> - Matthias -
>

Thanks for comments.

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/