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

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

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

true, but "on the fly" for me is much more of a "I have to wrap this 
right now" type thing.  I need to solve it instantly or I see an 
annoyance right then.  I just need a place to dump the solution so I can 
continue working.  I think the adapter idea could work well for this.

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

Agreed.  doing a) effectively means that I am noting it since I will be 
writing code that addresses it.


As far as documentation, I would still really like to see the 
documentation move to more of a group effort on the wiki so the docs are 
always live and up-to-date for anyone to contribute to.  But that is a 
separate topic for another e-mail...

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

True, but the adapter would give me a way to test it out and let you 
review the idea.  We can see how it goes though.

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

The cases I would do this are where I think it may make it seem more 
like a DSL.  For example scons does this very well by masking the fact 
that when you call what looks like a method  what is actually happening 
is that a class is being created behind the scene. 

That said, I don't think I would do this much and once again where I do 
it the change will not be permanent.  Just something for you to review.

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

Yes.  This code looks pretty similar in spirit to the TemplateBuilder 
stuff I did for pyOpenSG.  I just want to take it that step further and 
make it very user friendly so the don't have to know all the ugly 
details happening behind the scenes to allow this to work.  I think it 
can be done and I will do it.

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

No.  I was meaning add methods to existing class interfaces or modules 
that py++ defines.

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

adapters, goodies, whatever.  It doesn't really matter to much since we 
can always move the file in svn.

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

I was thinking of just making it even simplier.  Just make it so if you do:

from adapter import *

Then you get the entire DSL or whatever API it defines.

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

Sure.

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

Not a problem.

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

What I need to see is the places that you said "no, you can do this", I 
need to see what you are saying can be done and how.  Because as I see 
it right now there is always going to be a two phase process where a 
template header has to be created behind the scenes before the parsing.

-Allen