Re: [pygccxml-development] Current status...
Brought to you by:
mbaas,
roman_yakovenko
From: Matthias B. <ba...@ir...> - 2006-03-14 11:04:18
|
Roman Yakovenko wrote: >> I implemented some stuff today that mainly deals with the selection of >> declarations (all additions are beneath the experimental directory, but >> I didn't commit anything yet). It's not finished but I just wanted to >> keep you informed about what I'm currently doing. > > I am a little bit surprised. I struggle with my self for 3 or more > weeks not to write > high level api. But this is okay. I thought we (Allen and I) are supposed to try out ideas and come up with prototype implementations (within the experimental directory)....? > I have something like 10 hours in a > week to work on > py++. It would be nice to know how many hours do you have to work on > it, so we could plan features. As I'm still not able to re-create the full Maya bindings as I had them 2 or 3 weeks ago, I'm currently dedicating quite a lot of time to get that back. > Can you commit your changes? I would like to analyze your code, as I > did with Allen one. I am sure I can find some piece of code that > should be placed in an other place :-). Please, let's wait with moving stuff from the experimental code to the actual pyplusplus code base. I think it's too early to do that when it's still not clear whether that code is really "stable" or not. Our main interest is what an optimal *high level API* looks like, right? So currently, I think the actual implementation is not so important. Let's optimize that once the API is stable. Immediate changes to pyplusplus are only required when we want to do something in the high level API that is impossible to do with the current version. The last change to pyplusplus was already like an "earthquake" that has shattered our APIs from which they still haven't fully recovered (using some sort of "dramatic" language here... ;-) And instead of spending my time "repairing" the API I'd rather like to try out *new* ideas and move the API forward. The newly introduced decl_wrappers are fine as they provide a common interface to do the decorations, but I think some other stuff was moved there too quickly. >> - I implemented an alternative version of the >> DeclWrapper/MultiDeclWrapper classes >> >> - To prevent chaos I didn't actually change anything in pypp_api but >> implemented the new DeclWrapper in a separate module and replaced the >> DeclWrapper in pypp_api at runtime > > I hope you read my post about adding some teaching/guiding functionality to > decl_wrappers. Did you created DeclWrapper base on my work or you wrote > something new? Of course, I'm using the decl_wrappers from pyplusplus to decorate the declarations. Otherwise, pyplusplus wouldn't work anyway, would it? But as they are not the same as the DeclWrapper class I don't return the decl_wrappers to the user directly but instead "wrap" them (actually, I'd still vote for renaming the decl_wrappers into decl_decorators. I think this is a more precise name). For example, the decl_wrappers don't provide the selection interface, which is already the main reason why they cannot be passed to the user directly. > Also what is wrong with mdecl_wrapper_t class? Well, it's not entirely clear to me how this class eases the implementation of the high level API... (that's an example of a class where I'd say it was moved too quickly down to pyplusplus) >> - I only dealt with the selection so far, so the decoration still works >> as before. The heart of the selection is a single function select() that >> takes as input the root of the pygccml declaration tree and a single >> filter "function" and returns a list of declarations that matched the >> filter. Conceptually, the search is always done recursively. > > What is wrong with pygccxml.declarations.matcher? Even if you say that > search is always done recursively you still can use it. Am I wrong? I guess the find() method could be used, but this method always searches the entire tree whereas I have some code that can restrict the search to certain parts of the tree. Also, I didn't use the matcher classes from the declarations.filters module because they also differ somewhat in the way they work (especially the regex stuff. I'm not really sure yet how this is supposed to be used). > First of all I like you idea about using and\or\not for > matchers\select function. > Why did not you modify matchers? This is exactly how things should work. Because they are part of pyplusplus which is your domain. I won't change anything "down there" without your approval. Isn't that what the experimental folder is for? I don't consider the experimental folder to be part of the official pyplusplus code base, I rather see it as a "common playground" where Allen and I can mess around and try out new stuff. And if we end up with something useful then we can decide how this is best moved to pyplusplus. Isn't that how it was supposed to work? >> There is a global option that controls whether queries producing no >> results should be considered an error or not (for both cases). By >> default, empty queries are considered an error. > > Global variables? -brrr :-). Can I propose solution for this? Can you > add all those global variables as class members? To which class? > Please commit your changes. Do not forget license. People should know > who is guilty :-). :) I've committed what I have so far. Note however, that this is still much work in progress! I still left Allen's original version intact, so to activate the new "DeclWrapper" I did the following in my driver script: from pypp_api import * # Replace with test version import pypp_api import declwrapper pypp_api.DeclWrapper = declwrapper.IDecl This "IDecl" class is based on my previous version with additions from Allen's DeclWrappers. Most stuff should be compatible to Allen's version. Here are some things that differ: - I left out the "expose" flag in the Class, Method, etc. methods. This actually led to some confusion here because I didn't know why a class was exposed even though I wasn't exposing it. (But of course, it would be easy to add that feature again if somebody insists on it) - Is a return value policy also a "call policy" in Boost.Python terms? (I was calling my version setPolicy() whereas Allen's version is called setCallPolicy(). I thought that a call policy is already a specialized policy but I could be wrong) - addMethod()/wrapMethod() and everything else with custom code creators is not implemented yet. - Matthias - |