Re: Re: ping?

At 16:39 2003-09-15, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> > Have you looked at the code in the repository,
>
>A bit.
>
> > if so; please comment on it.
>
>OK:
>
>* Comments are needed describing how each thing fits into the big
>   picture, and why.
>
>* Please try to use descriptive names for template parameters rather
>   than simply "T" and "U".

Right, I'll get around to that.

>* default_converter_generator.hpp
>
>   - U should be called "Direction"

Ok.

>   - Why do we have two directions selectably handled by the same
>     class?  I can't imagine where that would be important.  You
>     always know which direction you're going.
>
>   - The implementation seems incomplete (where's the nested "type"?)

You are right, it is incomplete. This is because we had not settled on the
converter interface and because the rvalue/lvalue converters wasn't written
yet.

>   - xxx_to_cpp and cpp_to_xxx are missing

Ok.

>* extension_registry.hpp
>
>   - What's this for?  What's the template parameter?

This handles the registration/importing of conversion registry/inheritance 
graph.
The template parameter is the LanguageDescriptor (or whatever we'll call it).
Obviously this should be reflected by the parameter name..

>* Removing my copyright from slightly modified files isn't
>   particularly cool

I can assure you this wasn't intentional. It seems like I have forgotten
to add your copyright to the files that I rewrote rather than copied from
BPL and modified. I'll fix this, unless you fix it first. ;)

>* I think the plan is to refer to the license via "see accompanying
>   LICENSE for conditions and terms of use." rather than embedding the
>   license in the files directly.

Ok, didn't know that.

>* I think the only way this is going to work out is for us to get
>   boost/langbinding onto the main trunk and for me to start
>   integrating it into Boost.Python forthwith.  Alternatively, you
>   could test your work by doing the Boost.Python integration.

Right, are there any issues with moving it to the main trunk? I don't
think I have time to do the Boost.Python integration right now, at
least not by myself.

> > Also Rene was going to put together some tests to confirm that the
> > shared library stuff works ok, I don't know how this is working
> > out. Rene?
>
>Also: I am starting to rethink the mechanism I'm using for wrapped
>function invocation, which among other things interacts with the
>nature and capabilities of call policies.  I'm going to make a post
>about it; I hope you'll have input.
>
>The name "policies" is way too nebulous.  I'm thinking we need at
>least two concepts:
>
>     ConversionPolicies - a class affecting the precise method of
>     converting arguments to or from XXX.
>
>     CallPolicies - a refinement of ConversionPolicies which includes
>     precall and postcall processing actions.  Only applicable in the
>     context of a wrapped function call.
>
>Thoughts?

Sounds about right. I'll need to think some more about this though.
For instance, are you sure we don't need something equivalent
to precall/postcall for object_cast<>() / extract<>()?

---
Daniel Wallin



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf