Re: [pygccxml-development] Future of pypp_api...

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

On 8/20/06, Allen Bierbaum <al...@vr...> wrote:
> Part of the reason this discussion has very few details is that this
> isn't something I can easily make a list of for you.  It is much more
> something that I would need to do "on the fly" while working on a project.

I could be wrong, but I usually response in a day or two.

> If it is okay with you, what I suggest is that I will use the Py++ API
> over the next couple of days.  As I find something annoying or that I
> think could be better I will either:  a) fix it in a way that won't
> break existing code or b) note it and let you know.

If you don't mind I prefer "and". May be the functionality you are looking for
already exists, so I will just point you to it. Or better I will write
documentation
for it.

> I have been thinking that one way I could do this is to make an adapter
> interface that modifies the existing interfaces at run-time to create a
> new interface that implements the ideas that I have.  The idea would be
> to make it possible for someone to import a single module (or package
> which is really the same thing) and then have a DSL for them to use.
>
> Things I know I would be looking into:
> - Importing everything that users may need for most cases

In  this case,  you can add the code to the module_builder/__init__.py file
directly without even asking me.

> - Simplified naming convention (so it doesn't look likes classes or
> interfaces)

What do you mean? Can you post some example? Also, you can, and it seems
is what you want, is to introduce the aliases:

class yyy_t:
   def yyyyyyyyyyy( ):
       ...
   y = yyyyyyyyyyy

Yyy = yyy_t

I understand, that not every one like my convention. Also I don't see how it
will move us closer to DSL or will significant improve user experience.

> - Template support by default

We are still working on the document.

https://python-ogre.python-hosting.com/file/trunk/python-ogre/ogre_generate_code.py?rev=13

Please take a look on generate_instantiations_string function and its usage.
It is possible to make this code much user friendly.

> - Some helper functions that I have found useful and may be helpful for
> others.
> - Adding methods to some existing interfaces to make some things simpler

I think I know what you mean: functions that creates "def" and similar
code, right?
That what cause use to know very little about boost.python, right?

If so, I have a problem with them: they don't work in all cases. For example
exception translator registration function from pypp_api, will
generate wrong code,
if exception class is template instantiation.

Also, in this specific case, I think user should mark class as
"exception" and add
"translation" code. Py++ should do the rest.

You will also need to write unit tests.

> I think I can do this in a way that you can take some things into the
> core if you want to and leave other things out if you want to.
>
> The way I would implement this is something like:
>
> ---------- module: user_interface.py -----------------

Can you propose another module name?

> from module_builder import module_builder, <other stuff>
> from pygccxml.declarations.type_traits import <things>
>
> # customize it
> ModuleBuilder = module_builder
>
> def mb_newmethod(self, arg):
>    pass
>
> ModuleBuilder.newMethod = mb_newmethod

I think about next name: goodies, adapters, convinience_methods
( or something like this )
This module will sit under module_builder package, and will expose
one function - install_[goodies|adapters|...]. It will add all your methods to
module_builder_t and other classes.

For the time being, until I release this version, can you put this code under
"contrib" directory?

This is basically your idea, right? I have nothing against it. It
could be nice, if you
can stick to the "small letters and underscore" convention.

> I think you can get the idea.  Basically make an interface that adapts
> the current stuff.  Then this interface can keep adapting and changing
> while still being based on the same code base.  And if you choose to
> pull things on over to core, then we just change the adapter a little
> bit.  I think this would make it so the efforts don't diverge as much.
> I just don't have the time or energy to spend wasted effort.

You are not alone.

> I need to focus on getting my work done. :)

Me too. The source code is ready for release, but documentation still needs
some work.

> Now to help this get going, Roman, could you comment on the questions I
> asked on the template page on the wiki today?
> https://realityforge.vrsource.org/view/PyppApi/TemplateSupport
>
> I still don't understand the method you are suggesting could work.  I
> put some comments in there and asked new questions.

See "template support by default". If it still will not be clear, I
will write a document.
And may be skeleton of implementation.

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