Re: [pygccxml-development] Re: recent changes to pygccxml\pyplusplus

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

On 3/5/06, Matthias Baas <ba...@ir...> wrote:
> Roman, is it ok when I commit that cache into the pygccxml directory?
> The implementation consists of one single file "directory_cache.py"
> which I would put into the pygccxml.parser directory. The new class is
> called "directory_cache_t" (because the user has to specify a directory
> name instead of a file name). There are also a few internal helper
> classes, but those aren't meant to be instantiated by the user. I was
> using your naming conventions as far as I could figure them out (lower
> case class/method names with underscores between words and the classes
> have a "_t" suffix. Private methods have a leading underscore). Doc
> strings are available. I haven't modified any other file, so everything
> will still work as before (and the file cache is still the default). To
> activate the directory cache the user currently has to instantiate a
> class himself and pass this instance to the parse() method.
> I can also email you the file first if you want to have a look at it
> before it is actually added to the repository.

Please commit your changes to repository. Don't forget to put license
within the file.
Also, I am sure that you tested your directory cache class, right? Can
you create also
unit test for it? If not I will do that. Can you save your numbers
somewhere? I think we
will need them for release notes.

Thanks

> There's still one more question I have regarding the
> source_reader_t.__parse_gccxml_created_file() method. What is the exact
> meaning of the returned file list?

All files that have been parsed

> The update() method of a cache class
> receives this list as "included_files" argument, so one might think the
> list only contains the files that were included from the corresponding
> header file. But I noticed that the list also contains the header file
> itself. Is this intentional (and can I rely on that behavior) or is this
> a bug and the header file does not belong into this list?

It is not intentional, but we can say that from now this is a protocol.

> > 2. I updated setup file before release, when I have something like
> > "feature freeze" period.
> >     I suppose, that every one who use CVS will be able to use it
> > without setup. I could be
> >     wrong, but right now I prefer to concentrate my attention on someth=
ing else
>
> Well, it's only two lines that need to be added to setup_pyplusplus.py:
>
>                      , 'pyplusplus.decl_wrappers'
>                      , 'pyplusplus.module_builder'
>
> If you want I can commit that change back into the repository myself.

Yes, go ahead please.

> >> Well, you could fill in some extra words (such as class_wrapper_t) but
> >> as Python already organizes code in a hierarchy I guess it would be a
> >> better idea to use decl_wrapper.class_t explicitly instead of importin=
g
> >> the classes into the namespace of another module. Then it's also clear
> >> to the reader which class is being referred to.
> >
> > So, basically you would like to stay with name I proposed,  but user
> > is forced to use "fully qualified" names, am I right?
>
> No. I don't want the user having to deal with all those classes anyway,
> so the user should only need *one* such class (of each kind) which he
> might import into his namespace if he wishes to.
> My suggestion to use the fully qualified names only refers to the
> internal implementation (of course, this is entirely up to you what
> conventions you want to use as you're the maintainer of the package.
> I
> was just thinking that it might prevent confusion among those people who
> also want to have a look at the sources of pyplusplus... :)

So I don't understand. Within the code I always use fully qualified name -
package.class .  Even within package I use module.class. Do you think
that this is a right approach?

> > May I give you a small advice? You can combine between power of pyplusp=
lus and
> > power of C++. I think that using creating single template for every
> > group is better solution.
>
> I'm not sure if I understand what you mean. The above classes aren't
> implemented by myself, they are part of the Maya SDK and, of course, I'm
> not in the position to change that SDK.

Those classes have same interface, may be you can create boost python wrapp=
ers
using templates?

> - Matthias -


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