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

[David Abrahams]

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Monday, July 22, 2002 1:51 PM
Subject: Re: [C++-sig] additional files for pickle support


> --- 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.

No, I just want to experiment with naming before things get too solid. A
really good name improves the feel of a library immensely.

So, what about "pickle_suite" (not to be confused with sweet_pickle)?
Or more whimsically, "vinegar_and_spices" <wink>.

Seriously, I like "suite" a little better than "group" because it has more
of the right connotations.

> 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.

Yep, see the end of the test Jamfile. Those tests are normally off but you
can enable them from the command-line with -sTEST_EXPECTED_FAILURES=1

> > 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.

When I say "we could do X, but I'm not confident about it" you can trust
that I'm not about to take action on it.

> > 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.

Agreed. At least, I wouldn't deprecate existing syntaxes.

> > > 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.

Yep. I think that'll take a few days at most, and Joel has agreed to start
tomorrow.

> > The pickle group design is fine, though.
>
> Phew. (The alloted time to beat on the pickle support is up anyway.)

Good.

> > > 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&);

Ah, of course.

> 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)?

Yep, it saves code generation for incref and most especially decref, which
also generates code to destroy the object in case ob_refcnt == 0.

-Dave