Re: langbinding questions

Hi Jim,

Sorry this is so late.  Sick, work, sick, work... you know how it can
be.

on Sun Jan 15 2012, Jim Bosch <talljimbo-AT-gmail.com> wrote:

> I've been trying to wrap my head around some Boost.Langbinding
> concepts as part of my (slow, but not dead) work on an eventual
> Boost.Python v3. I've got some questions - and if there are others who
> I should be sending this email to, please let me know and/or forward.

Yeah, you should send it to the langbinding list and/or Cc: Daniel
Wallin.

> As I understand it, the basic idea is:
>
> 1) We build a language-agnostic front-end "module definition" data
> structure that gets stored in a static object.

I don't know what you mean by "static object," but the rest is dead on.

> 2) That data structure hides all the type information somehow

Hides it at compile-time; represents it at runtime.

> - I'm imagining a polymorphic non-template base class with templated
> derived classes, or something equivalent.  But I get the sense that
> this may be an incorrect assumption.

I don't know why; sounds like a classic type erasure pattern.

> 3) We pass in a target-language-specific "module builder" to the
> "module definition", which goes through itself and calls visit member
> functions on the "module builder", which in turn creates the
> target-language wrapper.

That sounds right.

> I can see, roughly, how this would work if there's only one module
> builder class (i.e. one target language).  The polymorphic classes in
> the module definition would have virtual functions that just take a
> module_builder instance, and then they can call templated visit member
> functions on the module_builder.
>
> But I don't think that model is what was intended - it doesn't scale
> well to multiple target languages, 

In what way?

> and it doesn't explain why the module_builder classes in the proposal
> (I'm looking here: http://www.boostpro.com/writing/oopsla04.html) use
> CRTP.

I don't see any CRTP.  There's some prototype code in SVN that might explain
details such as module_builder's template parameter. 

> I'm also confused (probably in a related way) about the type of the
> arguments to the module_builder::visit functions; somebody has to do
> the target-language specific dirty work of creating a wrapped
> backend::function<B> from an arbitrary C++ function pointer or other
> callable, and I would have expected that to be a job for the
> module_builder, not the front-end element that is calling
> module_builder::visit.

yep.  Seems like a bug in that doc.  I expect the module_builder to
visit frontend:: thangs.  Maybe, though, I had the idea that things in
the backend:: namespace should encompass everything the backend has to
process.  It's clearly not templatized on the backend language and
therefore not specific to the back-end at all.

> Note that I'm not trying to implement all of Boost.Langbinding, or
> even most - I'm just trying to understand it so I can write a more
> future-friendly Boost.Python.

Thanks for asking, Jim.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d