Re: [boost] Re: Re: Implicit conversions in dynamic_any / extract

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-22 18:22:59

Remy Blank <remy.blank_REMOVE_THIS_at_[hidden]> writes:

> On Fri, 22 Nov 2002 11:10:19 -0500, David Abrahams <dave_at_[hidden]> wrote:
>> Remy Blank <remy.blank_REMOVE_THIS_at_[hidden]> writes:
>> > I have looked at Boost.Python, and it is very similar to what I had in
>> > mind. Would it be possible to make Boost.Python more general to describe
>> > C++ class information for runtime use, and have Boost.Python be a
>> > subset?
>> 
>> ?? There's no way that Boost.Python could be a subset of the facility
>> we're talking about. It does way, way more than casting around an
>> inheritance hierarchy. IOW, it's already way more general.
>
> This is not what I meant. The word "subset" was badly chosen. Sorry
> for the confusion.

OK

> As I understand, Boost.Python features a class description and
> object management framework, 

Not sure what you mean by "object management", but OK...

> which allows to describe the type of a class, its inheritance, the
> members it contains, and to instantiate, access and modify objects
> of these classes. 

Well, yeah, but from Python.

> This can be called an "introspection and object management
> facility", can't it? 

Sort of. A big part of what it does is concerned with exposing C++
functions to Python.

> That was the goal of the library I am trying to develop.

I'm trying to imagine what you have in mind. How could this library be
used? Why would one use your library vs., for example, Boost.Python?

> Looking at Boost.Python, I saw that much (if not all) I needed was
> already there, and much more. So my question was: could the
> "introspection and object management" parts be separated from the
> Python-specific code?

I'm not sure which parts you think those are.

However, factoring out Python-independent functionality is probably a
good idea in general, and has been discussed a few times on this
list. One obvious reason to do so would be to build new back-ends for
different languages.

>> > I don't have a lot of time on my hands, but if you think this would
>> > be a good idea, I would love to give it a try (except that I'm a
>> > little scared by Boost.Python's complexity, and I don't know Python
>> > (yet)).
>> 
>> I don't understand. The stuff in inheritance.cpp doesn't touch Python
>> at all. It's pure C++.
>
> I haven't yet looked at inheritance.cpp, but your comment confirms
> that there is some very generic, not Python-dependent, code in
> Boost.Python

Yes.

> that provides the functionality needed for an introspection
> framework.

I'm not as sure about that part. I'd have to see what you're talking
about first.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution