[C++-sig] Re: (return_self_policy / return_arg): Keywors

[David Abrahams]

Nikolay Mladenov <nickm at sitius.com> writes:

> David Abrahams wrote:
>> 
>> Nikolay Mladenov <nickm at sitius.com> writes:
>> 
>> > David Abrahams wrote:
>>
>> >> OK, I would like to see "irrelevancies" removed from the code for any
>> >> test case, though... unless you think the efficiency issue is closely
>> >> related to the keyword support, in which case you'll have to convince
>> >> me (please).
>> >
>> > I am not sure what needs convincing? There is an efficiency issue. Don't
>> > you agree?
>> 
>> I suppose so.  I meant that if you want to keep those extra
>> constructors in the examples or tests for this feature I want to be
>> convinced that they're relevant.  It sounds like you don't want to
>> keep them, though.
>
>
> It is probably good to make clear the advantages and disadvantage of
> the different ways of defining optional arguments

Agreed.

> but I don't insist doing it in the keywords docs and samples.

Good.  Probably the tutorial should have some info about this.

> I'll keep those extra constructors in my code though:)

It's your code!

>> > I was not realizing the fact that class_() implicitly defines
>> > default constructor for a long time, and I think that this is
>> > somewhat confusing.
>> 
>> Understandable.  People were even more confused when BPL allowed
>> them to write classes that couldn't be constructed by default.
>> 
>> Maybe we should deprecate the def() way and provide a mechanism for
>> chaining init<...>() instances in the class_<...> constructor
>> (e.g. with commas).  At least that would focus all attention in the
>> same place.
>
> I would better like it if def is the only way of defining constructors.
> Initially I thought that staticmethod should be implemented as policy, 
> but you convinced me into the "python"-ian way: staticmethod is a
> statement in python.
> Well so is __init__, and in python it is def'ed as any other
> method. 

Well, that's a good point.

> Why should we explicitly specify that the class is not constructable
> (with no_init) (the c++ way), 
> instead of explicitly exporting constructor with def (the python way).
> "There should be one-- and preferably only one --obvious way to do it"
> ;-)
> and def should be it for exporting methods:)

I understand the principle, but sometimes you have to make compromises
at the language boundary.  Besides, not having to explicitly specify
default constructors is both the C++ and the Python way.  Consider:

         >>> class Foo:
         ...     pass  # no explicit __init__
         ...
         >>> x = Foo() # OK

         struct Foo {}; // no explicit constructor
         Foo x;         // OK

Why should I have to write an explicit __init__ in order to expose
Foo to Python?

> I have exported a lot non-constructable classes as bases and as
> collections of staticmethods.

Yes, but at least if the class is abstract you'll get a compile-time
error if you don't supply no_init, while if we eliminate the default
constructor definition compiling and linking would succeed for default
constructible classes, but fail at runtime when you try to instantiate
them (unless you remember the init<...>(), which maybe doesn't appear
anywhere in the C++ class declaration).  I consider failing at compile
time to be far superior.

> And we don't really need the default constructability shortcut,
> especially now, having pyste.

A lot of people still don't use Pyste.

>> It's "unpythonic".  Have you tried
>> 
>>      >>> import this
>
> I see:). Zen is speaking:)
> It was good reminding it.
>
>> What about
>> 
>>         ( arg("a"),"b", "c", arg("d")=1, arg("e")=std::string() )
>> 
>
> I had not thought about that one and I like it. And I'll do it.
>
>
>> Instead?
>> 
>> >       ( arg("a"), arg("d")=1, arg("e")=std::string() )
>> 
>> Fine.
>> 
>> -Dave
>> 
>> P.S. I'm not terribly convinced of my own position here.  Any bit of
>> additional resistance from you and I'll probably cave ;-)
>
>
> I wasn't really resisting. Until you mentioned deprecating
> def(init<...>()).  And if you promise to forget about it, than we
> can probably say we agree:)

I guess I'm not feeling quite *that* relaxed yet ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com