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

[Nikolay Mladenov]

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, but I don't 
insist doing it in the keywords docs and samples.

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



> > 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. 
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 have exported a lot non-constructable classes as bases and as
collections of staticmethods.
And we don't really need the default constructability shortcut,
especially now, having 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:) 


Regards,

Nikolay