[C++-sig] additional files for pickle support

[Ralf W. Grosse-Kunstleve]

--- David Abrahams <david.abrahams at rcn.com> wrote:
> > pickle_support_base -> pickle_group
> 
> Hmm, what about just "pickle_functions"?

I am trying to emphasize that the collection of pickle support functions for
one type form one entity. IMO "group" (singular) does this better than
"functions" (plural).
Anyway, if you have strong opinions about this please feel free to make the
changes you'd like to see.

> "boost::python::error_messages::missing_pickle_group_function_or_inco
> >           rrect_signature<boost::python::class_<<unnamed>::world,
> >           boost::python::detail::not_specified,
> >           ...
> 
> I'll look again.

Is there a framework for having tests that are supposed to fail at
compile-time? Then I could make a few pickle1_fail.cpp, pickle2_fail.cpp etc.
files.

> > I am /very/ nervous about these ideas.
> 
> Which ideas? Don't worry, I'm not doing the Phoenix-syntax thing anytime
> soon.

Phew. It would help if you could more often indicate what is brain-storming and
what is in fact planned for the nearer future.
 
> > Collaborators keep asking about V2 and is getting more and more
> > difficult to keep them interested. Maybe it is time to start a list
> > of potential V3 projects.
> 
> V3? No, it's not time for that. For V2.01 et al. I already have a list.

What I mean is that I hope to see radical changes such as adoption of the
Phoenix syntax on the V3 list rather than any 2.x list.
 
> > BTW: what is the status of the mpl1 -> mpl2 transition, and how
> > much instability will this generate for how long?
> 
> I've asked Joel de Guzman to look into it, and I'm waiting for him to get
> back to me about it. It should not cause any instability or changes to the
> public interface.

I am anxious to get past that transition. Mainly to make sure our collaborators
(non-computer scientists!) will not have to deal with "road construction ahead"
signs.
 
> Actually, the named parameter interface also allows you to do the
> consistency checks. Each method call in the chain builds a new type which
> includes the information about which of them has been called.
> 
> The pickle group design is fine, though.

Phew. (The alloted time to beat on the pickle support is up anyway.)

> > > >   void class_base::enable_pickle_support(bool getstate_manages_dict)
> > > >   {
> > > >       setattr("__reduce__", make_instance_reduce_function());
> > > >       handle<> one(PyInt_FromLong(1));
> > > >       setattr("__safe_for_unpickling__", one);
> > > >       if (getstate_manages_dict) {
> > > >         setattr("__getstate_manages_dict__", one);
> > > >       }
> >
> > BTW: I will change this to work with object as soon as setattr()
> > is modified accordingly.
> 
> What modification were you expecting?

self& setattr(char const* name, object);

or

self& setattr(char const* name, object const&);

BTW: since the only data member in object is a pointer, does it make sense to
pass a const& (i.e. a pointer to the contained pointer) instead of just a copy
of object (i.e. the contained pointer itself)?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com